یادگیری کانبان (1)

  • یوسف مهرداد بی‌بالان

مترجمان: یاسر کازرونی، مریم معصومی‌راد

پیشگفتار

بخشهایی از کتاب Kanban in Action نوشته مارکوس هامربرگ و یوآخیم ساندن به فارسی برگردانده شده است؛ قسمتهایی از آن به مرور در اینجا منتشر خواهد گردید.

بخش اول

بخش اول کتاب به معرفی کاربردی کانبان می‌پردازد. هدف بخش اول این است که شما بتوانید اجرای کانبان را شروع کنید و در کنار آن، درک اولیه‌ای از اصول حاکم بر کانبان پیدا کنید و با بعضی از موضوعات پیشرفته‌ی آن نیز آشنا شوید تا اشتیاق‌تان ­برای ادامه‌ی این مسیر بیشتر شود.

با یک داستان کوتاه شروع می‌کنیم که داستانِ آشنایی یک تیم توسعه‌­ي نرم‌­افزاری با کانبان و استفاده از آن را روایت می­کند. اگر رویکرد داستانی را دوست ندارید، می­‌توانید از این فصل بگذرید و مستقیماً به سراغ فصل بعد بروید؛ نگران نباشید، بخش عمده‌ای از مطالب فصل یک با جزئیات بیش­تری در فصل‌های بعد بررسی می‌شوند.

گروه كانبانِروس[1] كار خود را شروع مي­‌كند

مارکوس[2] و یوآخیم[3] در حال سخنرانی در یک گردهمایی‌اند که موضوع آن، «معرفی کاربردی کانبان» است. سخنرانی در حال اتمام است. بیایید به آن­ها ملحق شویم.

k1

«جمع‌بندی: کانبان رویکردي برای توسعه­ي نرم­افزاره که مبتنی بر اصول نابه[4]. خیلی از شرکت‌های دنیا به سرعت کانبان رو انتخاب کردند. شما هم می­تونید كانبان رو انتخاب کنید! از فردا شروع کنید، باید شروع کردن رو متوقف کنید و تمام کردن رو شروع کنید.». یوآخیم سخنرانی را با این جمله تمام کرد: «معرفی کوتاه و كاربردي ما درباره‌ی کانبان تمام شد. ولی گفته‌های قبلی ما رو فراموش نکنید؛ شما می­‌تونید از فردا شروع کنید. شروعش سخت نیست. اجراش می‌تونه اثرات شگفت‌­انگیزی روی بهره­وری شما داشته­ باشه.»

مارکوس در حالی‌که تلاش می‌­کرد سخنانش را تمام کند تا برای یک بار هم که شده ارائه‌اش را سروقت تمام کند، گفت: «از همه­‌ي شما که تشریف آوردید متشکرم! اگه سوالی داشتید ما برای چند دقیقه‌ای همین دور و برا هستیم.»

k2

یوآخیم مشغول پاک کردن تابلو و جمع کردن یادداشت­ها از روی دیوار شد؛ مارکوس درحالي­‌كه به سمت درب خروج می‌رفت، به تعدادی از پرسش‌های کوتاه، پاسخ داد و به بعضی از افراد هم گفت که برای پیدا کردن پاسخ پرسش‌های خود، اسلایدها را دانلود کنند. هنوز چند قدم بیشتر نرفته بود که وسط راه، ناگهان خانمی جلوی او را گرفت.

زن مانند کسی که کلاه سرش رفته با ناامیدی نگاهی ‌کرد و گفت: «اینجا چه خبره؟ چرا دارید می‌­رید؟ به من نگید که سخنرانی رو کلاً از دست دادیم؟»

مارکوس پاسخ داد: «چی رو از دست دادید؟ سخنرانی رو؟ بله، سخنرانی همین الآن تموم شد، ولی می‌­تونید فیلمش رو آنلاین ببینید.»

زن شروع کرد به گریه: «اوه نه!». با سرش به مردی که گروهی را به داخل اتاق راهنمایی می­کرد اشاره کرد و گفت: «ما فقط برای این سخنرانی اینجا اومدیم! اون رو ببین! شبیه کسی‌ یه که فقط چند دقيقه‌ی ابتدایی یک سخنرانی رو از دست داده.»

k3

مارکوس در­حالی­که سعی می­کرد مشکل را حل کند گفت: «خب، اگه دوست دارید در سخنرانی حضور داشته باشین، احتمالاً توی پاییز سخنرانی دیگه‌ای داریم.»

زن با چهره‌ای واقعاً غمگین گفت: «این حرفها مشکل ما رو حل نمی­کنه؛ ما می‌­خواستیم فوراً کار رو شروع کنیم! همه‌ی تیم هم اینجان؛ حتی بچه‌های کسب­‌وکار هم به توصیه‌­ي من، برای این دوره‌ی آموزشی همراه ما اومدند. راستی! سلام، من دافنه[5] هستم.»

یوآخیم به آنها ملحق شد، خودش را به دافنه معرفی کرد و بعد پیشنهاد داد: «خب؛ اگر عجله دارید، چرا من یا مارکوس رو برای گرفتن مشاوره، یک روز به شرکت‌تون دعوت نمی‌کنید؟»

مرد محترمی که خودش را به دافنه رسانده بود گفت: «خب، ما می­‌تونیم این کار رو بکنیم اما در حال حاضر، شکایت­‌های زیادی هم از طرف تیم و هم افرادی که با ما کار می‌­کنند وجود داره. می­‌خواستیم کاری برای حل آنها انجام بدیم و امیدوار بودیم که امروز چیزی یاد بگیریم که توی این کار به ما کمک کنه».

یوآخیم پرسید: «منظور شما چه نوع مشكلاتيه؟»

مرد خیلی صریح و رک گفت: «تیم حس می­‌کنه در باتلاقی از کارها گیر کرده و افرادی هم که در انتظارند تا کارها رو تحویل بگیرند، فکر می­کنند این کارها حالا حالاها تمام نمیشه و تا ابد طول می‌کشه».

دافنه وسط حرفهای او پرید و گفت: «با وجودی که کارهای زیادی برای انجام داریم، درباره‌ی اینکه کدام پروژه­ مهم‌تره و اول باید شروع بشه بحث­‌های طولانی داریم. با همه‌ی این کارها، باز هم در انتخاب پروژه­ی درست­ اشتباه می­کنیم».

مرد گفت: «و … خب، مشکلات که زیاده ولی نمی­خواهیم وقت شما رو بگیریم.» و در حالی که منتظر پاسخ بود پرسید: «داشتید می­‌رفتید؟ آره؟»

مارکوس خیلی‌ سریع جواب داد: «بله! مگر اين­كه شما پیشنهاد بهتری داشته باشید». و گفتن این جمله، شروع یک چالش جذاب بود.

رییس محترم گفت: «این کاری است که ما می‌خواهیم انجام بدیم! همین الآن و همین جا شما دو نفر را به عنوان مشاور استخدام می‌کنم. روی اسلایدی كه روی پرده است نوشته «از فردا شروع کنید». به شما فرصت می­دم که نشان بدید به حرف­هایی که می­زنید اعتقاد دارید؛ دو صد گفته چون نیم کردار نیست. چقدر مي­تونيد وقت بذاريد؟» سپس سکوت کرد و به چشم‌های مارکوس و یوآخیم خیره شد.

یوآخیم به ساعتش نگاه كرد و گفت: « هنوز دو ساعت تا زمان حرکت ما مونده.»

ریيس دستش را دراز کرد و گفت: «خب! اگه این طوره: کانبان را در دو ساعت راه می‌اندازیم».

یوآخیم به مارکوس نگاه ­کرد و گفت: «نمي­‌تونيم همه‌ی مسأله‌ها را حل کنیم، فقط می‌­تونیم شما را توی مسیر درست قرار بدیم». آنها به یکدیگر نگاه کردند و سرشان را به نشانه‌ی تأیید تکان دادند و گفتند: «خب! دو ساعت وقت داریم. چالش پیشنهادی شما پذیرفته شد!»

بخش بعدی

[1]Kanbaneros

[2] Marcus

[3]Joakim

[4] Lean

[5] Daphne

گزیده:

“Those who cannot change their minds cannot change anything.” George Bernard Shaw

سال نو مبارک

  • یوسف مهرداد بی‌بالان

 

کای تازه بهار عالم افروز
هر روز تو عید باد و نوروز

بخت تو بهار بی‌خزان باد
عالم ز تو رشگ بوستان باد

 

دوستان و همراهان گرامی، سال نو بر شما خوش باد

در سال نو،
دلی خوش، لبی خندان، تنی سالم، آرزوهای زیبا، روزهایی قشنگ، پیروزی‌های پی‌درپی و آینده‌ای درخشان
برایتان آرزومندم

 

بهار 1395 خورشیدی

حرفهایی برای نگفتن

  • یوسف مهرداد بی‌بالان

مقدمه:

در دوره هایی که برگزار می کنم معمولا دانشجویان باید یک پروژه را انجام بدهند. میزان مشارکت دانشجویان در پروژه، شدت و ضعف دارد. اما در یکی از دوره ها، دانشجویان آن قدر خوب کار کردند که خیلی تحت تأثیر قرار گرفتند. این نوشته را برای آنها نوشتم.

نامه:

سلام، شب به خیر!
کارهای شما در پروژه‌ی دوره متدهای چابک، مرا بسیار تحت تاثیر قرار داد. این نوشته را در پی آن نوشتم.

«حرفهایی برای نگفتن»
ای کاش آن قدر سرمایه داشتم که می‌توانستم هزینه‌ی یک زندگی راحت را برایتان فراهم کنم و ازتان می‌خواستم که ایده‌ای را انتخاب کنید و آن را اجرا کنید. همان طور که به دنبال تاکسی‌یاب هستید. ایده‌ای که زندگی را برای مردم راحت‌تر کند و رفاه آنان را افزایش دهد.
ای کاش می‌توانستم فضایی برایتان فراهم کنم که همان قدر که در تاکسی‌یاب خوشحال هستید، در آنجا نیز کار کنید و خوشحال باشید.
نه به سیستم حضور و غیاب نیازی بود و نه به مدیری!
فقط هیجان بود، شادی بود و تلاش!
مسابقه‌ای که رقیب‌اش، فقط خودمان بودیم.
ای کاش می‌توانستیم با این عمر، با این نعمت خدادادی، کاری کنیم که بتوانیم با افتخار زیرش را امضاء کنیم.
به امید آینده
یوسف مهرداد
چهارم اسفند نود و چهار

برنامه‌ریزی چندسطحی در اسکرام – بخش سوم

  • یوسف مهرداد بی‌بالان

مترجم: یاسر کازرونی

برنامه‌ریزی انتشار

هدف از برنامه‌ریزی انتشار، ایجاد توازن[1] بین محدوده، تاریخ انتشار و بودجه در تحویل‌ تدریجی محصول است.

معمولاً در توسعه­ی محصول، منطقی و ضروری است که برنامه‌ریزی انتشار پس از ترسیم چشم‌انداز (برنامه‌ریزی محصول) و قبل از شروع اولین اسپرینتِ هر انتشار انجام شود. در این مقطع از کار می‌توانید برنامه‌ای برای انتشار تهیه کنید که بین میزان کاری که می­توانید انجام دهید و تاریخ انتشار، تعادل ایجاد ‌کند.

برای تعیین تعداد ویژگی‌هایی که می‌توانید در تاریخ معینی تحویل دهید (انتشار با تاریخ ثابت) یا تعیین تاریخ تحویل مجموعه‌ای از ویژگی­ها (انتشار با محدوده‌ی ثابت) باید تعداد قابل قبولی از اقلام بک‌لاگ محصول را ایجاد و برآورد کنید.

یک روش ساده برای تصویرسازی[2] یک انتشار، کشیدن خطی افقی بر روی بک‌لاگ محصول است (شکل 15-3). اقلام بالای این خط در این انتشار قرار دارند و اقلام زیر این خط در این انتشار قرار نمی‌گیرند. به مرور زمان که دید بهتری از محصول پیدا می‌کنید، ممکن است این خط به سمت بالا یا پایین جا‌به‌جا شود. در فصل 18 درباره­ی روش تعیین محل این خط توضیح خواهیم داد.

شکل 153: استفاده از خط انتشار در بک‌لاگ محصول

1-1

حالا به آسانی می‌توانید ارتباط بین نقشه‌ی راه محصول و بک‌لاگ محصول را برقرار کنید و به کمک آن جزییات بیش‌تری از محتوای چند انتشار آتی در نقشه‌ی راه محصول دست پیدا کنید (شکل 15-4). هر انتشار در نقشه‌ی راه محصول با مجموعه‌ای از ویژگی‌ها در بک‌لاگ محصول در ارتباط است.

شکل 154: نگاشت انتشارهای نقشه‌ی راه محصول به بک‌لاگ محصول

2-1

برنامه‌ی انتشار باید دارای بُعد زمان نیز باشد. بُعد زمان را می‌توان با اسپرینت‌هایی که برای تکمیل انتشار لازم است نشان داد. اغلب انتشارها از نظر حجم کار، بزرگ هستند و ویژگی‌های موجود در آنها را نمی­توان در یک اسپرینت انجام داد و تمام کرد (شکل 15-5).

شکل 155: هر انتشار می­تواند شامل یک یا چند اسپرینت باشد

3-1

ممکن است در برنامه‌ریزی انتشار بخواهید پا را فراتر بگذارید و ویژگی‌هایی را که در چند اسپرینت اول قابل تحویل‌اند تخمین بزنید. این کار می­تواند برای ایجاد هماهنگی بین چند تیم یا درخواست زودتر از موعد یک تیم برای سخت‌افزار، ابزار یا کمکِ دیگران، مفید باشد. اما تخمین بیش از چند اسپرینت معمولاً بی‌فایده است و اصلِ«به‌موقع»[3] و «به اندازه‌ی کافی»[4] بودن برنامه‌ریزی را نقض می‌کند.

برنامه‌ریزی اسپرینت

برنامه‌ریزی اسپرینت در ابتدای هر اسپرینت انجام می‌شود و طی آن در مورد اقلامی از بک‌لاگ محصول که در اسپرینت جاری انجام خواهند شد، توافق می‌شود. تیم در این فعالیت، بک‌لاگ اسپرینت را تهیه می‌کند که شامل کارهایی است که در سطح وظیفه­اند[5] و انجام آنها برای تکمیل اقلام بک‌لاگ محصول ضروری است (شکل 15-6).

تیم در برنامه‌ریزی اسپرینت، سطح بعدی از رویکرد برنامه‌ریزی تفصیلی[6] و به‌موقع را انجام می­دهد[7]. جزییات برنامه‌ریزی اسپرینت را در فصل 19 بررسی خواهیم کرد.

برنامه‌ریزی روزانه

جزیی‌ترین سطح برنامه‌ریزی تیم در جلسات روزانه‌ی اسکرام اتفاق می‌افتد. همان‌طور که قبلاً گفته شد برنامه‌ریزی روزانه فعالیتی است که در آن، اعضای تیم دور هم جمع می‌شوند و هر کس به­نوبت توضیح می‌دهد که:

  • از اسکرام روزانه‌ی قبلی تا حالا چه کارهایی انجام داده است
  • چه کارهایی را برای امروز برنامه‌ریزی کرده است
  • با چه مشکلات و موانعی روبه­روست

شکل 156: هر اسپرینت دارای یک بک‌لاگ اسپرینت است

4-1

در اسکرام روزانه، اعضای تیم به صورت دسته­جمعی و به شیوه‌ای بسیار شفاف، تصویر کلانی از برنامه‌ی روزانه‌ی­ تیم را ارائه می‌دهند. چنین کاری به تیم کمک می‌کند تا از هشدار و آماده­باش­ اعضایش استفاده کند. مثلاً ممکن است یکی از اعضا بگوید: «امروز می‌خواهم روی رویه‌ی ذخیره­شده‌ی‌[8] پایگاه داده کار کنم و باید آن را تا ظهر تمام کنم. کسی که می‌خواهد روی منطق کسب‌وکار[9] کار کند باید آماده باشد تا بلافاصله بعد از ناهار کارش را شروع کند و حواسش باشد که پیاده‌سازی منطق کسب‌وکار برای تکمیل کارِ ما در این اسپرینت روی مسیر بحرانی[10] قرار دارد». چنین گفتگوهایی باعث می‌شود تا موانع احتمالی در اولین فرصت شناسایی شوند و رفع آنها منجر به بهبود اجرای اسپرینت گردند.

سخن پایانی

در این فصل نشان داده شد که برنامه‌ریزی در توسعه به روش اسکرام، چگونه در چندین سطح و هر یک با جزییات متفاوت انجام می‌شود. در شکل 15-7 فراورده‌های هر یک از این سطوح (به جز برنامه‌ریزی سبد محصول و برنامه‌ریزی روزانه) و نحوه‌ی ارتباط آنها با یکدیگر به تصویر کشیده شده است.

در فصل‌های بعد به طور عمیق‌تری به برنامه‌ریزی سبد محصول، برنامه‌ریزی محصول، برنامه‌ریزی انتشار و برنامه‌ریزی اسپرینت خواهیم پرداخت.

شکل 157: برنامه‌ریزی سلسلهمراتبی[11] در اسکرام

5-1

[1] Trade-off

[2] Visualize

[3] Just in time

[4] Just enough

[5] Task-level

[6] Detailed planning

[7] همان‌طور که گفته شد، برنامه‌ریزی در اسکرام در سطوح مختلفی از جزییات مانند استراتژی، سبد محصول، محصول، انتشار، اسپرینت و روزانه انجام می‌شود. هر سطح، جزییات موارد تعیین‌شده‌ در سطح قبلی را برنامه‌ریزی می‌کند. برنامه‌ریزی اسپرینت پس از برنامه‌ریزی انتشار انجام می‌شود که در آن جزییات روش انجام اقلام بک‌لاگ در یک اسپرینت را برنامه‌ریزی می‌شود. [مترجم]

[8] Stored procedure

[9] Business logic

[10] Critical path

مسیر بحرانی، مجموعه‌ای از فعالیت‌ها هستند که بلندترین مسیر در طول پروژه را تشکیل می‌دهند. جمع زمان فعالیت‌های موجود در مسیر بحرانی نشان‌گر حداقل مدت ممکن برای انجام پروژه است و هرگونه تغییری در آنها باعث افزایش مدت پروژه خواهد شد. [مترجم]

[11] Hierarchical

The Illusive Definition of Agile

  • یوسف مهرداد بی‌بالان

What is Agile? Is it a set of practices, a set of values, or a set of mind—or some combination of the three? Is it “Doing Agile” or “Being Agile?”

Is agile defined by a checklist of offered practices—the Nokia test for Scrum, or checking 9 of 12 practice boxes for XP?

Is agile a mindset, an amalgamation of adaptation, embracing change, transparency, collaboration, complex systems theory, or courage?

Is agile the frequent delivery of high quality customer value while effectively adapting to change, regardless of specific practices? (Ken Collier)

The right-brained and the left-brained are alive and well in this debate. Daniel Pink (A Whole New Mind) refers to this as L-directed thinking, “sequential, literal, functional, textual, and analytic,” versus R-directed thinking, “simultaneous, metaphorical, aesthetic, contextual, and synthetic.” This agile definition debate is a classic one that pits these two halves of ourselves against each other.

Is agile a management style, one that encourages self-organization, servant leadership, controlled chaos, or light-touch management?

Is agile a set of technical practices—iterative development, refactoring, coding standards, pair programming, or test-driven development?

Is agile a methodology or a set of core values and guiding principles?

There are many people and organizations who want a prescriptive, non-ambiguous definition of agile (or Scrum or XP or …). They are the L-directed thinkers, the ones who still want predictable plans and measures for the un-measurable. Conversely, there are those who insist that agile is a state of mind, a style of management, a wisp of content and a whisper of context.

And, there are those who are comfortable in-between—realizing that while at one level agile might be evaluated by a core set of practices, the essence of agile involves more philosophy than tutorial.

Is agile a set of rules established by some prescient guru, or an adaptive learning process that uses rules merely as a starting point?

Is agile a transcendent concept for bringing purpose, meaning, satisfaction, and fun to work?

The motto of the Scrum Alliance, “Transforming the World of Work,” speaks to agile’s wider purpose and meaning. In the final chapter of Adaptive Software Development I make two statements about work:

“People want to succeed; given the right environment, people motivate themselves to heroic achievements.

The right environment is one of adaptation through self-organization.”

In its search for purpose and meaning the core of agile has a secular spirituality feel to it. This core is why thousands upon thousands of individuals have signed the Agile Manifesto. It’s why hundreds of thousands around the world have embraced agile—even though they can’t quite define it.

Agile is one of those illusive things that the harder you try to grasp it, the more it slips through your fingers.

For me, the day we explicitly define agile, is the day it becomes sterile and lifeless.

For me, the day agile becomes whatever someone wants it to be, is the day it becomes useless.

For me, agile is a whole-minded philosophy, one that combines the left-brained and the right-brained—balancing on the precarious edge between the literal and the metaphysical, between performance and meaning. We need to revel in that balance and ambiguity, not try to define away its awe, grandeur, and paradox.

Jim Highsmith

برنامه‌ریزی چندسطحی در اسکرام – بخش دوم

  • یوسف مهرداد بی‌بالان

مترجم: یاسر کازرونی

بک‌لاگ کلان محصول

پس از تدوین چشم‌انداز محصول، نوبت به ایجاد نسخه‌ی اولیه‌ای از بک‌لاگ کلان محصول می‌رسد. در نمونه­ی قبلی یعنی طراحی مجدد وب‌سایت اتحادیه‌ی اسکرام، در پایان سال 2006 بک‌لاگی از محصول داشتیم که اقلام آن در حال افزایش بود؛ این اقلام شامل ویژگی‌های درخواستی ذینفعان و کاربران از نسخه‌ی جدید و بهبودیافته‌ی وب‌سایت می‌شد.

بک‌لاگ محصول شامل اپیک­‌های (داستان بلند) زیر بود:

  • به عنوان مربی رسمی اسکرام[1]، می‌خواهم برگزاری دوره‌های عمومی‌ام را در وب‌سایت اتحادیه‌ی اسکرام اعلام کنم تا اعضای اتحادیه از زمان و مکان برگزاری آن‌ها باخبر شوند.
  • به عنوان یک دانشجو می‌خواهم اطلاعات همه‌ی دوره‌های عمومی اسکرام را ببینم تا کلاسی را پیدا کنم که با شرایطم مطابقت داشته باشد.

اگر قرار بود محصول کاملاً جدیدی تولید کنیم، حداقل باید بخش کمینه­ای از نیازمندی­ها را در ابتدا شناسایی می­کردیم و در بک‌لاگ محصول قرار می‌دادیم و سپس بااولویت­ترین اقلام را برآورد می‌کردیم. اما در اینجا بخشی از اقلام بک‌لاگ محصول قبلاً وجود داشت که از آن به عنوان نقطه شروعی برای تدوین ایده‌های موجود در چشم‌انداز وب‌سایت جدید استفاده کردیم.

 

نقشه‌ی راه محصول

پس از تهیه­‌ی چشم‌انداز و بک‌لاگ کلان محصول، تهیه‌ی نقشه‌ی راه محصول که به آن نقشه‌ی راه انتشار[2] هم گفته می­‌شود می‌تواند مفید باشد. نقشه‌ی راه محصول بیان­گر ماهیتِ تدریجی ساخت و تحویل یک محصول در طی زمان و عوامل مهم و تأثیرگذار در هر یک از انتشارهای آن است.

امروزه بسیاری از سازمان‌ها تلاش می‌کنند تا به روش استقرار پیوسته[3] کار کنند؛ یعنی به‌محض آماده شدن ویژگی‌ها، آنها را در محیط عملیاتی مستقر می­کنند[4]. اگر سازمان شما نیز به همین روش کار می­کند، نیازی به تهیه‌ی نقشه‌ی راه محصول نیست. اما با وجود استفاده از «استقرار پیوسته»، نقشه­ی راه محصول می‌­تواند ابزار مناسبی برای کمک به سازمان در موارد زیر باشد:

  • بررسی و انتخاب مجموعه­‌ی بزرگ­تری از ویژگی­‌ها
  • شناسایی قیدها و محدودیت­‌هایی که منجر به توسعه­‌ی هم‌زمان برخی از ویژگی­‌ها می­‌شوند
  • تعیین زمان مناسب برای انتشار ویژگی­ها

شکل 15-2 نمونه‌­ای از نقشه‌ی راه محصول را در قالبی که لوک هومن[5] پیشنهاد کرده است نمایش می‌دهد [22].

این نقشه دو انتشار را نشان می‌­دهد؛ یکی در سه‌ماهه‌ی اول و دیگری در سه‌ماهه‌ی دوم سال 2007. انتشار «0.5» که در سه‌ماهه‌ی اول سال 2007 منتشر شد اولین انتشار از وب‌سایت جدید بود. دلیل انتخاب عدد 0.5 این بود که هرچند وب‌سایت جدید نسبت به وب‌سایت قدیمی امکانات بهتری داشت، ولی فقط نیمی از ویژگی­های[6] وب‌سایت قدیمی در برنامه‌ریزی این انتشار گنجانده شده بود. در مجموع ویژگی‌های مطلوب این انتشار مربوط به مشاهده‌ی دوره‌های عمومی اسکرام در دنیا و حداقلِ پشتیبانی از مربیان رسمی اسکرام یا CSTها بود. انتشار شماره‌ی 0.5، «انتشاری با محدوده‌ی ثابت»[7] بود زیرا می‌دانستیم وب­سایت جدید باید چه ویژگی‌هایی داشته باشد تا بتواند جایگزین وب‌سایت قدیمی شود و انتشار سایت بدون این مجموعه از ویژگی­ها امکان‌­پذیر نبود. آنچه نمی‌دانستیم این بود که پیاده‌­سازی این ویژگی‌ها چقدر طول می‌کشد. در فصل 18 به بررسی این موضوع خواهیم پرداخت که چگونه می‌توان تاریخ عرضه‌ی «انتشاری با محدوده‌ی ثابت» را تعیین کرد.

 

شکل 152: نقشهی راه وبسایت اتحادیه‌ی اسکرام

سه ماهه‌ی اول 2007 سه ماهه‌ی دوم 2007 سه ماهه‌ی سوم 2007
نقشه‌ی بازار[8] راه‌اندازی وب‌سایت جدید وکنار گذاشتن وب‌سایت قدیمی
نقشه‌ی ویژگی/مزیت[9] فهرست دوره‌هاپشتیبانی از مربیان رسمی اسکرام عضویتورود دسته‌ای داده­‌ها[10] جستجوپالایش (فیلتر)
نقشه‌ی معماری[11] [Ruby on Rails [12 یکپارچه‌سازی با سیستم ثبت نام آنلاین
رویدادهای بازار[13] گرد­همایی اسکرام کنفرانس چابک 2007
زمان‌بندی انتشار[14] 0.5 1.0

 

انتشار 1.0 از نوع «انتشار در تاریخ ثابت»[15] بود. زیرا می‌خواستیم تاریخ انتشار وب­سایت با تاریخ کنفرانس اتحادیه‌ی اسکرام در پورتلند اورگان[16] آمریکا که در تاریخ 7 می 2007 شروع می‌­شد همزمان شود. هدف ما این بود که در اولین روز کنفرانس، مجموعه‌ی جذابی از امکانات آماده باشد. اما نمی‌دانستیم که چه تعداد از ویژگی‌ها را می­‌توانیم برای این انتشار آماده کنیم. در فصل 18 روش تصمیم­‌گیری در مورد محتوای یک «انتشار در تاریخ ثابت» را بررسی می­کنیم.

خلاصه این­که در نقشه‌ی راه اولیه‌ی محصول، هم انتشاری با محدوده‌ی ثابت (0.5) و هم انتشاری در تاریخ ثابت (1.0) وجود داشت.

صرف نظر از این‌که چه محصولی می­‌خواهید تولید کنید، در پایان برنامه‌ریزی محصول باید فراورده‌های زیر وجود داشته باشد:

  • چشم‌انداز محصول
  • بک‌لاگ کلان محصول به‌همراه داستان‌های کاربر برآورده­‌شده
  • نقشه‌ی راه محصول (اختیاری)

البته ممکن است برای افزایش اطمینان خاطر تصمیم‌گیرندگان برای تأیید توسعه‌‌ی محصول، فراورده‌های دیگری نیز تهیه کنید.

خروجی‌­های برنامه‌ریزی محصول به عنوان ورودی‌ به برنامه‌ریزی سبد محصول برگشت داده شد تا انتشار نسخه‌ی 0.5 از وب‌سایت جدید مورد تأیید هیأت مدیره قرار گیرد.

[1] (Certified Scrum Trainer (CST

[2] Release roadmap

[3] Continuous deployment

[4] Deploy

[5] Luke Hohmann

[6] Feature

[7] Fixed-scope release

[8] Market map

[9] Feature/benefirt map

[10] Bulk loading

[11] Architecture map

[12] Ruby on Rails

روبی یک زبان برنامه‌نویسی انعطاف‌پذیر، پویا و شی‌گرا است. روبی ویژگی‌های نگارشی Perl و شی‌گرایی SmallTalk را در خود دارد. زبان روبی در سال‌های میانی دهه ۱۹۹۰ توسط یوکی هیرو ماتسوموتو در ژاپن اختراع شد. ویژگی‌های گوناگون زبان‌های Perl، Lisp، SmallTalk و Eiffel الهام‌بخش ماتسوموتو در ساخت روبی بودند. رِیلز چارچوبی کدباز و مبتنی بر وب است که به زبان روبی نوشته شده است. طراحی این چارچوب با هدف ساده‌سازی برنامه‌نویسی تحت وب انجام شده است با این فرض که هر برنامه‌نویسی بتواند به آسانی از آن استفاده کند. حجم کد مورد نیاز برای ایجاد یک ویژگیِ تحت وب در رِیلز نسبت به بسیاری از زبان‌ها و چارچوب‌های موجود کم‌تر است. [ویکی­پدیا] [مترجم]

[13] Market events

[14] Release schedule

[15] Fixed-date release

[16] Portland, Oregon

Does a Team Need to Finish Everything Every Sprint?

  • یوسف مهرداد بی‌بالان

When a team selects a set of product backlog items to work on in a sprint, the ScrumMaster and product owner should expect that the team will finish those items. Not always, but most of the time.

I coach teams that during sprint planning they are to commit to a set of product backlog items that they will deliver.

(Yes, I know the word commit has gone out of favor in the Scrum world over the past few years. But I think that’s a mistake and a misunderstanding of the word.)

When a team commits to a set of product backlog items, they are saying they will do their best to deliver those items within the sprint.

The team is not making a guarantee. They are committing to do their best to deliver what they said they would. That’s all.

I tell teams I’d like to see them fulfill that commitment about 80 to 90% of the time. That is, I want them to make it most of the time.

I never actually measure how often they deliver everything. I never track anything like number of product backlog items delivered divided by number of product backlog items committed to.

I really don’t want to know it that precisely. Tracking it at that level would introduce too much dysfunctionality into the team’s behavior.

If a team is told they must deliver everything every time, the team may respond by under committing during sprint planning. I would rather have a team that feels safe sometimes grabbing a little more than they may finish, knowing there are no repercussions if they don’t finish.

So, I want the team to finish all they say they will in most but not in all sprints. If a team finishes everything most of the time, the organization will have a great deal of predictability.

And that will help our organizations succeed with agile,

Mike Cohn

برای خروج از جستجو کلید ESC را بفشارید