فصل ۵ — Scrum Planning: User Story، Story Point و Velocity | Learning Agile

عنوان اصلی اثر

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

عنوان این مقاله

فصل ۵ — Scrum Planning: User Story، Story Point و Velocity

عنوان بخش منبع

Chapter 5: Scrum planning

نویسندگان

Andrew Stellman و Jennifer Greene

زبان اصلی

English

صفحات منبع

157 تا 178 از PDF

حق‌نشر منبع

Copyright © 2015 O’Reilly Media, Inc. — All rights reserved.

تاریخ ترجمه

1405/05/20 / 2026-08-11

اعتبار ترجمه

ترجمه با کمک هوش مصنوعی

فروش یا انتشار این ترجمه منوط به داشتن مجوز لازم از صاحب حقوق اثر است.

فصل ۵ — برنامه‌ریزی Scrum و تعهد جمعی

«هر توسعه‌دهنده باید با تعهددادن به کاری که برای انجام آن ثبت‌نام کرده احساس راحتی کند. و چون تیم نگرشِ «همه با هم در این ماجرا هستیم» دارد، همه باید با تعهد کلی تیم نیز احساس راحتی کنند.» — Mike Cohn¹

تا اینجا سازوکار Scrum و الگوی پایه‌ای آن را برای کارکردن تیم در کنار هم آموخته‌اید. اما میان نظریهٔ Scrum و واداشتن یک تیم به ساخت واقعی نرم‌افزار در یک پروژهٔ زنده تفاوت بزرگی وجود دارد. چگونه تیم Scrum را برای موفقیت آماده می‌کنید؟ چگونه همه را به سمت هدف‌های یکسان سوق می‌دهید؟ به بیان دیگر، اکنون که می‌دانید Scrum حول خودسازمان‌دهی (self-organization) و تعهد جمعی (collective commitment) می‌چرخد، چطور این مفاهیم را در دنیای واقعی عملی می‌کنید؟

در این فصل با Practiceهایی آشنا می‌شوید که بسیاری از تیم‌های Scrum برای برنامه‌ریزی Sprintهای خود استفاده می‌کنند. خواهید دید User Story چگونه کمک می‌کند دقیقاً بفهمید کاربران از نرم‌افزار چه می‌خواهند؛ چگونه Story Point و Velocity پروژه تصویری واقع‌بینانه از مقدار کاری می‌دهند که تیم در یک Sprint می‌تواند انجام دهد؛ و چگونه دو ابزار بصری مهم، Burndown Chart و Task Board، کمک می‌کنند همه تصویر مشترکی از وضعیت کار داشته باشند.

همچنین خواهید دید چرا این Practiceها و حتی الگوی پایهٔ پروژهٔ Scrum به‌تنهایی برای رسیدن به «بهره‌وری فوق‌العاده» یا «نتایج شگفت‌انگیز» کافی نیستند. دوباره به ارزش‌های Scrum برمی‌گردیم و بررسی می‌کنیم که آیا فرهنگ تیم و شرکت با آن ارزش‌ها سازگار است و اگر نیست چه می‌توان کرد.

¹ Mike Cohn, User Stories Applied: For Agile Software Development, Pearson Education, 2004.

شکل ۵-۱ — Product Ownerها اغلب برای واردشدن به ذهن کاربرانشان با چالش روبه‌رو می‌شوند.

روایت

تیمی در یک شرکت کوچک روی اپلیکیشن تلفن همراه کار می‌کند:

• Roger — رهبر تیم که می‌خواهد Agile شود.
• Avi — Product Owner.
• Eric — Scrum Master در تیمی دیگر.

پردهٔ پنجم: انتظار چیزی را نداشتیم که انتظارش را نداشتیم

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

در طول بحث سرها با تأیید تکان می‌خورد و لبخند زیاد بود؛ همه می‌فهمیدند وقتی نرم‌افزارشان واقعاً استفاده می‌شود، از کارشان بیشتر لذت می‌برند. سپس Eric از زمانی پرسید که فهمیدند هیچ‌کس نرم‌افزارشان را استفاده نمی‌کند. معلوم شد سال قبل تیم چهار ماه روی سامانهٔ ردیابی کاربران و مدیریت حساب کار کرده بود، اما درست در آخرین لحظه یک معاون ارشد تصمیم گرفت به‌جای آن، یک سامانهٔ آماده را لایسنس کنند. پس از آن دو نفر استعفا دادند و همه احساس بسیار بدی داشتند. یکی از توسعه‌دهندگان ارشد که برای آن پروژه اضافه‌کاری زیادی کرده بود با تردید پرسید: «چه چیزی تضمین می‌کند دوباره همین اتفاق نیفتد؟»

Roger ارتباط میان موضوع‌ها را برایش روشن کرد: «وقتی مردم نرم‌افزاری را که می‌سازیم استفاده می‌کنند خوشحالیم و وقتی روی چیزی کار می‌کنیم که دور انداخته می‌شود متنفریم. پس فقط باید راهی پیدا کنیم مطمئن شویم نرم‌افزاری می‌سازیم که مردم واقعاً از آن استفاده خواهند کرد.»

از آنجا همراه‌کردن تیم ساده شد. Roger توضیح داد Sprint Planning چگونه کار می‌کند و Avi چگونه با تیم و کاربران همکاری خواهد کرد تا فقط ارزشمندترین موارد وارد Sprint Backlog شوند. تا پایان جلسه، Avi، Roger و Eric احساس کردند تقریباً همهٔ اعضا واقعاً مفهوم تعهد جمعی را فهمیده‌اند و حقیقتاً می‌خواهند نرم‌افزاری بسازند که کاربران برایش ارزش قائل‌اند.

بعد از جلسه Eric، Roger و Avi نشستند تا وضعیت را ارزیابی کنند. Roger و Avi شروع کردند به تبریک‌گفتن به یکدیگر که بالاخره تیم را به فکرکردن جمعی رسانده‌اند؛ اما دوباره واکنش Eric غافلگیرشان کرد. او به‌جای خوش‌بینی نگران به نظر می‌رسید.

Eric گفت: «بسیار خوب، تیم را با Sprint Planning همراه کرده‌اید و این عالی است؛ اما مسئلهٔ بزرگ‌ترتان حل نشده: چطور Featureهای درست را وارد Sprint Backlog می‌کنید؟ اگر ارزشمندترین چیزها را آنجا نگذارید، دقیقاً به همین وضعیت امروز برمی‌گردید؛ کاربران از نبود چیزهای مهم شکایت می‌کنند و هم‌زمان زیر حجم Featureهایی که حتی یادشان نیست درخواست کرده باشند دفن می‌شوند.»

Roger و Avi تردید داشتند، اما در Sprint Review بعدی با کاربران، این تردید از بین رفت. Avi با افتخار آخرین نسخهٔ Lolleaderz.com را روی سرور آزمایشی باز کرد و Feature جدید «Create an achievement» را نشان داد. در این Feature کاربران می‌توانستند معیارهایی تعیین کنند تا دوستانشان با Upload ویدئوهای مشخص «Achievement» بگیرند. او Achievementای با نام «Got your goat!» ساخت: کلیدواژهٔ «goat» را از فهرست Drag کرد، با Toolbox تعیین کرد بعد از 500 Page View جایزه داده شود، و با قابلیت Upload گرافیک یک Pop-up Animation به آن افزود. وقتی Demo تمام شد، اتاق ساکت بود.

یکی از Account Managerها گفت: «اِمم... به نظر می‌رسد کار خیلی زیادی برده. خب... چرا ساختیدش؟»

این اصلاً واکنشی نبود که انتظارش را داشتند. معلوم شد تمام چیزی که کاربران می‌خواستند یک قابلیت ساده بود تا ویدئوی دوستشان را Nominate کنند و یک ستارهٔ کوچک کنار آن ظاهر شود. تیم somehow یک درخواست ساده را به ویرایشگر کامل معیارهای Achievement تبدیل کرده بود؛ همراه با زبان شبه‌اسکریپتی مخصوص و زیرساخت Service، در حالی که هیچ‌کدام از Account Managerها نمی‌دانستند این مجموعه را چگونه به مشتریان بفروشند. مقدار عظیمی از تلاش تیم هدر رفته بود و بدتر اینکه Featureهای واقعاً لازم در Backlog باقی مانده و ساخته نشده بودند.

قرار نبود Scrum این‌گونه پیش برود.

بعد از جلسه Roger و Avi نزد Eric برگشتند؛ او اصلاً از نتیجه تعجب نکرده بود. Roger پرسید: «پس چطور درستش کنیم؟»

Avi گفت همین حالا هم تمام تلاشش را می‌کند تا چیزی را بدهد که Account Managerهای دیگر می‌خواهند. Backlog را نگهداری می‌کرد، بر اساس ارزش مرتبش می‌کرد و به تیم می‌آورد. چه کار بیشتری می‌توانست بکند؟ Roger حتی نمی‌دانست از کجا شروع کند، اما می‌دانست اگر تغییری ندهند، همان نتایج تکرار می‌شود. این بار تازه تیم را با یک سخنرانی پرانرژی دربارهٔ Scrum هیجان‌زده کرده بودند و حالا ناامیدی بزرگی برای همه داشتند. اگر خیلی زود تغییری رخ نمی‌داد شاید تیم را برای همیشه از دست می‌دادند.

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

Roger تردید داشت، چون از تجربه می‌دانست کاربران اغلب تا وقتی چیزی را نبینند نمی‌دانند دقیقاً چه می‌خواهند. Avi هم دوباره احساس می‌کرد برای نقش Product Owner «کوتاه‌ترین چوب قرعه» نصیبش شده است.

Avi پرسید: «چطور وارد ذهنشان شویم؟»

User Story، Velocity و Practiceهای عموماً پذیرفته‌شدهٔ Scrum

کاربران و Stakeholderها از پیش‌بینی‌ناپذیری متنفرند. حتی اگر تیم واقعاً تعهد جمعی داده باشد که ارزشمندترین نرم‌افزار ممکن را بسازد، اگر نرم‌افزار Working که در پایان Sprint تحویل می‌شود شبیه قول ابتدای Sprint نباشد، کاربران ناامید می‌شوند. پس صرفاً تحویل ارزشمندترین نرم‌افزار ممکن کافی نیست؛ باید وقتی افرادی که نرم‌افزار برایشان ساخته شده آن را دریافت می‌کنند، غافلگیری نامطلوبی وجود نداشته باشد.

حتی غافلگیری خوشایند هم می‌تواند تقریباً به اندازهٔ نوع ناخوشایند آسیب‌زا باشد، اگر این انتظار را ایجاد کند که تیم همیشه فراتر از ظرفیت معمولش تحویل خواهد داد. جلوگیری از این وضعیت معمولاً به دو موضوع برمی‌گردد.

اول، تیم باید در ابتدای Sprint انتظارها را درست تنظیم کند. دوم، با پیشرفت Sprint باید همه را دربارهٔ تغییرهایی که در Daily Scrum کشف می‌شود به‌روز نگه دارد. به همین دلیل حضور کاربران و Stakeholderها در Daily Scrum ارزشمند است، هرچند الزامی نیست؛ اما بسیار مهم است که فقط مشاهده‌گر باشند و دخالت نکنند. Daily Scrum زمان تیم برای برنامه‌ریزی کار روز بعد است، نه پاسخ‌گویی به سؤال افراد خارج از تیم.

همهٔ Stakeholderها نمی‌توانند در Daily Scrum حاضر شوند و گاهی هیچ‌کدام نمی‌آیند؛ اشکالی ندارد. حضورشان مفید است اما الزام نیست. تا وقتی Product Owner متعهد باشد Stakeholderها را از تغییرهای برنامه آگاه نگه دارد، در پایان Sprint همه تصویر مشترکی خواهند داشت.

ولی اگر تیم نرم‌افزار غیرمفید بسازد، هیچ‌کدام از این‌ها اهمیتی ندارد.

نرم‌افزار خود را مفید کنید

دوباره به نقل‌قول Ken Schwaber در ابتدای فصل ۴ فکر کنید: اگر تعهد جمعی ندارید، Scrum ندارید. اما «تعهد جمعی» دقیقاً یعنی چه؟ تیم به چه چیزی متعهد می‌شود؟

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

این ایده مستقیماً در Agile Manifesto وجود دارد. «Working Software» یعنی چه؟ ساخت برنامه‌ای که صرفاً اجرا شود ساده است. ساخت نرم‌افزاری که ظاهراً «کار می‌کند» اما وقتی کاربر می‌خواهد کار واقعی‌اش را انجام دهد دیوانه‌اش می‌کند هم چندان دشوار نیست. Working Software واقعی یعنی نرم‌افزاری که به کاربر کمک کند کارش را انجام دهد. مؤثرترین راه شناخته‌شده برای ساخت چنین نرم‌افزاری نیز Customer Collaboration است. به همین دلیل Working Software را بر Comprehensive Documentation و Customer Collaboration را بر Contract Negotiation ترجیح می‌دهیم.

پیش از تغییر دنیای توسعه توسط Agile، تیم‌ها مرتب نرم‌افزارهایی می‌ساختند که مفید نبودند و شواهد زیادی هم وجود داشت. تقریباً هر کتاب دانشگاهی Software Engineering از اواخر دههٔ 1990 یا اوایل 2000 را باز کنید، احتمالاً به گزارش CHAOS از Standish Group اشاره کرده است. Standish Group این گزارش را از میانهٔ دههٔ 1990 در پاسخ به این تصور ــ که واقعاً درست بود ــ آغاز کرد که تعداد عظیمی از پروژه‌ها شکست می‌خورند؛ در آن زمان حدود یک‌سوم پروژه‌ها موفق محسوب می‌شدند.²

مطالعات سالانهٔ آن‌ها بارها نشان داد تیم‌های پروژه احساس می‌کردند بسیاری از Featureهای ساخته‌شده اصلاً استفاده نمی‌شوند. مطالعهٔ 2002³ رقم بسیار بالای 64% را گزارش کرد: 45% هرگز استفاده نمی‌شدند و 19% به‌ندرت.

ممکن بود این نتیجه جامعهٔ دانشگاهی را شوکه کند، اما برای بسیاری از تیم‌های نرم‌افزار آن دوره واضح بود. در واقع چیزی که CHAOS Report «شکست» می‌نامید آن‌قدر رایج بود که بسیاری آن را واقعیت عادی توسعهٔ نرم‌افزار می‌دانستند. تیم نرم‌افزار را می‌ساخت، «از روی دیوار» به کاربران پرتاب می‌کرد و امیدوار بود بخشی از آن به کار بیاید. بسیاری از بحث‌ها با کاربران به جملهٔ معروف توسعه‌دهنده ختم می‌شد: «این Bug نیست، Feature است.» یعنی نرم‌افزار دقیقاً همان‌طور کار می‌کند که توسعه‌دهنده می‌خواسته و کاربر باید انتظارش را تغییر دهد. این شیوهٔ بسیار بدی برای رفتار با کاربران است.

Roger و Avi با Achievement Editor به مشکل خوردند چون برای حل یک مسئلهٔ ساده، ابزاری پیچیده و Over-engineered ساختند. این یکی از رایج‌ترین راه‌های تولید نرم‌افزاری است که ارزشش کمتر از ظرفیت واقعی آن است. این رفتار آن‌قدر رایج است که نام دارد: Gold-plating. تیم با نیت خوب Featureهای اضافی و درخواست‌نشده اضافه می‌کند. توسعه‌دهنده می‌خواهد کمک کند و تصور می‌کند چیزی بسیار جذاب و ارزشمند ساخته است. این واکنش برای توسعه‌دهندهٔ هیجان‌زده طبیعی است و یکی از منابع اصلی Featureهای بلااستفاده محسوب می‌شود.

عامل دیگر، همان ذهنیت «پرتاب از روی دیوار» است. کاربران احساس می‌کنند زمان محدودی برای تعامل با تیم توسعه دارند، بنابراین می‌کوشند در همان بازه تا جای ممکن درخواست Feature ثبت کنند؛ و گاهی خود Stakeholderها Featureهایی درخواست می‌کنند که هنگام تحویل ارزش کمی دارند.

اما تیم‌های Agile مؤثر به‌ندرت چنین تجربه‌ای دارند. بسیار بعید است Featureهایشان بلااستفاده بماند، چه برسد به دو سوم آن‌ها. تا جایی که بعضی Agile Evangelistها نتایج CHAOS Report را با طعنه «ردشده» می‌خوانند. سؤال مهم این است: تیم‌های Agile مؤثر چه کاری انجام می‌دهند که نرم‌افزارشان تا این اندازه مفید می‌شود؟

² J. Laurenz Eveleens and Chris Verhoef, “The Rise and Fall of the Chaos Report Figures,” IEEE Software, 2010.

³ 2002 CHAOS Report, The Standish Group International Inc., 2002.

User Story کمک می‌کند Featureهایی بسازید که کاربران واقعاً استفاده می‌کنند

تیم‌های Agile با تلاش برای واردشدن به ذهن کاربران شروع می‌کنند و ابزار بسیار مؤثری برای این کار دارند. User Story ابزاری فریبنده‌وار ساده است: توضیحی سریع و کوتاه از یک شیوهٔ مشخص استفادهٔ کاربر از نرم‌افزار. بیشتر User Storyها بین یک تا چهار جمله‌اند. بسیاری از تیم‌ها قانون سرانگشتی دارند که Story باید روی جلوی یک کارت 3×5 جا شود.

بسیاری از تیم‌ها User Story را با قالب جای‌خالی شبیه Mad Libs می‌نویسند:

• As a <type of user>, I want to <specific action I’m taking> so that <what I want to happen as a result>.
• «به‌عنوان <نوع کاربر> می‌خواهم <عمل مشخص> را انجام دهم تا <نتیجهٔ مورد انتظار> رخ دهد.»

برای Feature مربوط به Achievement، تیم Lolleaderz.com می‌توانست Storyای با همین ساختار بنویسد.

شکل ۵-۲ — یک User Story نوشته‌شده روی Index Card.

این Story سه موضوع مهم را آشکار می‌کند:

• کاربر کیست: «کاربر بازگشتی با فهرست بزرگی از دوستان».
• چه می‌خواهد بکند: «ویدئوی یکی از دوستان را برای Achievement نامزد کند».
• چرا می‌خواهد: «تا همهٔ دوستان مشترک بتوانند رأی بدهند و به او یک ستاره بدهند».

Story یک عنوان هم دارد، مثلاً «Nominate a video for an achievement»، تا تیم هنگام گفت‌وگو نام ساده‌ای برای ارجاع به آن داشته باشد.

اطلاعات زیادی در چنین Story کوچکی فشرده است. برای پیاده‌سازی آن احتمالاً باید رابط کاربری Nomination و Voting، مکانیزم ذخیرهٔ Nomination و Vote، تغییر در سیستم نمایش ویدئو برای بررسی Achievement و نمایش Star، و چند جزء دیگر ساخته شود.

به همان اندازه مهم است که چه چیزی در Story نیست: هیچ اشاره‌ای به Criteria Editor ــ چیزی که تیم بی‌دلیل اضافه کرده بود ــ یا Featureهای غیرضروری دیگر وجود ندارد. به همین دلیل User Story ابزار خوبی علیه Gold-plating است. اگر تیم Storyها را بنویسد، با Product Owner و در صورت امکان با کاربران و Stakeholderها مرور کند و به آن‌ها پایبند بماند، احتمال اینکه نرم‌افزار را با Featureهای غیرضروری متورم کند بسیار کمتر می‌شود.

User Storyها مدیریت Backlog را هم آسان می‌کنند. بسیاری از تیم‌های Agile مؤثر Backlogی دارند که تقریباً به‌طور کامل از User Story تشکیل شده است. چون هر Story ساده و از دید کاربر نوشته شده، Product Owner می‌تواند همراه کاربران و Stakeholderها مشخص کند کدام Story ارزشمندتر است. Storyها کوچک‌اند و در هر زمان می‌توان Story تازه اضافه کرد یا ترتیبشان را تغییر داد. هنگام شروع Sprint، Product Owner و تیم تعدادی Story را از Product Backlog بیرون می‌کشند و برای تحویل در Sprint انتخاب می‌کنند.

سپس تیم دربارهٔ هر Story با Product Owner گفت‌وگو می‌کند تا معنای آن روشن باشد و همه بدانند چه زمانی Done محسوب می‌شود. بیشتر تیم‌ها Story را به Taskهای کوچک می‌شکنند و مدت یا اندازهٔ کار را برآورد می‌کنند. Taskها در ستون «To Do» روی Task Board قرار می‌گیرند. عضو تیم وقتی آمادهٔ کار تازه است، باارزش‌ترین Taskی را که می‌تواند انجام دهد انتخاب می‌کند، نامش را روی کارت می‌نویسد و آن را به «In Progress» منتقل می‌کند.

Conditions of Satisfaction

یک راه مطمئن برای فهمیدن اینکه چه چیزی می‌سازید این است که بتوانید شکل نهایی آن را تصور کنید. برای توسعه‌دهنده رضایت‌بخش است که عقب بایستد، چیزی را که ساخته نگاه کند و احساس کند کار تمام شده است. Conditions of Satisfaction ابزاری مؤثر برای مشخص‌کردن شکل نرم‌افزار در حالت کامل و سنجش فاصله تا Done است. برخی تیم‌ها به آن Acceptance Criteria می‌گویند.

این Conditions نیز مثل User Story ساده به نظر می‌رسند ولی هدف پیچیده‌ای را محقق می‌کنند. بیشتر تیم‌ها برای هر Story، چند قابلیت مشخص را می‌نویسند که کاربر پس از تکمیل Story باید بتواند انجام دهد.

معمولاً Conditions of Satisfaction روی پشت همان کارت 3×5 جا می‌شوند. Product Owner معمولاً در نوشتن آن‌ها مشارکت می‌کند یا دست‌کم نسخهٔ نوشته‌شده را Review می‌کند.

شکل ۵-۳ — Conditions of Satisfaction نوشته‌شده پشت کارت User Story.

این شرایط به توسعه‌دهنده کمک می‌کند خیلی زود اعلام پیروزی نکند. رایج است برنامه‌نویس بیشتر اجزای Feature را بسازد اما پرداخت نهایی را تا آخر Sprint عقب بیندازد. مثلاً صفحات Nomination را بسازد و کد نمایش ویدئو را برای Star تغییر دهد، ولی تا وقتی همه‌چیز را به هم متصل نکرده، Linkها سر جایشان نیستند و کد جدید کامل با Codebase موجود Integration نشده، Feature تمام نشده است. بسیار کارآمدتر است همین حالا که موضوع در ذهنش تازه است کار Story را واقعاً کامل کند.

Conditions of Satisfaction یک تعریف عینی از «Done» به تیم می‌دهد. برای اینکه Story Done باشد، تمام کار لازم برای فهم، ساخت، Test و Deploy آن نیز باید Done شده باشد. Story زمانی Done است که کاربر بتواند Working Software را باز کند و هر Condition را دقیقاً همان‌گونه اجرا کند که در Sprint Review نمایش داده خواهد شد. تا آن لحظه Story تمام نیست و عضو تیم روی همان Story متمرکز می‌ماند. به محض تکمیل، کارت آن به ستون Done می‌رود.

Story Point و Velocity

در Sprint Planning کل تیم با هم مشخص می‌کند چه مقدار کار می‌تواند در Sprint انجام دهد تا هدف Working Software پایان Sprint واقع‌بینانه باشد. اما این مقدار چگونه تعیین می‌شود؟

تقریباً به تعداد تیم‌ها روش Estimation وجود دارد. یکی از تکنیک‌هایی که در طول سال‌ها برای Scrum بسیار مؤثر بوده Story Point است. Story Point راهی برای فهم میزان Effort مورد نیاز یک User Story است؛ با تخصیص یک عدد و مقایسهٔ Story فعلی با Storyهای مشابهی که همین تیم قبلاً ساخته است.

قانون سخت و یکتایی برای تعداد Point وجود ندارد. بعضی تیم‌ها از 1 تا 5 استفاده می‌کنند؛ بعضی 1 تا 10؛ بعضی Fibonacci یا اعداد نمایی. مهم ثبات Scheme و راحت‌بودن تیم با آن است. یک Story سه‌Point باید تقریباً به اندازهٔ Story سه‌Point دیگر کار بخواهد.

وقتی تیم به Storyها Point می‌دهد، به‌تدریج می‌فهمد در هر Sprint چند Point می‌تواند «بسوزاند» یا تکمیل کند. اگر به‌طور متوسط 25 Point در Sprint انجام می‌شود، Project Velocity برابر 25 Point per Sprint است.

Velocity تیم‌ها در چند Sprint معمولاً نسبتاً ثابت است. پیش از شروع کار با تیم پیش‌بینی Velocity دشوار است، اما می‌توان Velocity Sprintهای قبلی را برای برنامه‌ریزی Sprint بعدی به کار برد.

البته همان هشدار سرمایه‌گذاری اینجا هم صادق است: عملکرد گذشته تضمین آینده نیست. اگر تیم Sprint قبل 32 Point و Sprint قبل‌تر 29 Point Burn کرده، تضمینی نیست این بار حدود 30 باشد. اشتباه در تخمین، مشکل فنی غیرمنتظره، مرخصی، استعفا یا رویدادهای زندگی می‌تواند ظرفیت را تغییر دهد. با این حال Story Point و Velocity در طول زمان برای بسیاری از تیم‌های Scrum راهنمایی شگفت‌آور قابل اعتماد هستند.

یک جلسهٔ Sprint Planning بر اساس Story Point می‌تواند چنین باشد:

1. با ارزشمندترین User Storyهای Product Backlog شروع کنید.
2. یک Story از فهرست بردارید؛ ترجیحاً کوچک‌ترین مورد، چون Baseline خوبی است. Story مشابهی از Sprint قبلی پیدا کنید و همان تعداد Point بدهید.
3. با تیم دربارهٔ دقت تخمین صحبت کنید. کشف مشکل، کار یا Challenge فنی جدید تخمین را بالا می‌برد؛ عامل ساده‌کننده، Reuse کد موجود یا کاهش دامنه آن را پایین می‌آورد.
4. ادامه دهید تا مجموع Pointها به اندازه‌ای برسد که Sprint پر شود.

Sprint Backlog را Overload نکنید. جا گذاشتن ظرفیت اشکالی ندارد، اما فراتررفتن از چیزی که تیم در گذشته انجام داده مناسب نیست. اگر Average Velocity برابر 28 است و 26 Point Story وارد Sprint کرده‌اید، فقط یک Story دوPoint یا دو Story یک‌Pointی اضافه کنید. توسعه‌دهندگان ذاتاً خوش‌بین‌اند ــ باید هم باشند چون سازنده‌اند ــ و ممکن است وسوسه شوند Story سه‌Pointی هم اضافه کنند و فقط «یک Point» بیشتر بروند. تسلیم نشوید؛ این مسیر خوبی برای ناامیدکردن کاربران در Sprint Review بعدی است.

بار اول چه کنیم؟ ساخت سابقهٔ Story و درک مشترک اینکه Story سه‌Pointی چقدر بزرگ است زمان می‌برد. بار نخست حدس بزنید: یک Story متوسط را 3 Point، بزرگ‌ترین Story ارزشمند را 5 Point و کوچک‌ترین را 1 Point فرض کنید و از آن‌ها برای تخمین باقی Storyها استفاده کنید. پس از دو Sprint، نمونه‌های کافی برای مقایسه و تصویر مناسبی از Average Velocity خواهید داشت.

چرا Story Point کار می‌کند؟

مثل User Story، Story Point هم ساده‌تر از آن است که در نگاه اول انتظار داریم. شروع استفاده از آن آسان است، هرچند ظرافت‌های فراوانی دارد.

ساده است

توضیح Story Point به عضو جدید آسان است. عددها هم معمولاً کوچک‌اند ــ ده‌ها یا صدها، نه هزاران ــ و فهمشان راحت‌تر است.

جادو نیست

بسیاری از توسعه‌دهندگان و مدیران پروژه تخمین‌های ناموفق زیادی دیده‌اند و به این نتیجه رسیده‌اند که توسعهٔ نرم‌افزار اساساً قابل تخمین نیست. Story Point بر تجربهٔ واقعی همین تیم تکیه دارد؛ بنابراین منشأ عدد مرموز نیست.

کنترلش دست خود تیم است

وقتی رئیس یک هدف عددی یا Metric را تحمیل می‌کند، فشار و Stress بالا می‌رود. اما وقتی تیم خودش روش سنجش کارش را تعیین می‌کند و آن Metric را فقط برای برنامه‌ریزی خودش استفاده می‌کند، ابزار ارزشمندی می‌شود.

تیم را دربارهٔ تخمین به گفت‌وگو وادار می‌کند

ممکن است توسعه‌دهنده‌ای که وارد اولین تیم Scrum می‌شود برای نخستین بار در حرفه‌اش آزادانه دربارهٔ Estimate حرف بزند یا نظرش واقعاً پرسیده شود. Estimation مهارت است و تنها راه بهترشدن تمرین است؛ یعنی حرف‌زدن دربارهٔ Effort لازم برای کارها.

توسعه‌دهندگان از آن نمی‌ترسند

توسعه‌دهندگان زیادی تجربه کرده‌اند که Estimate بداهه‌شان ناگهان تبدیل به Deadline سخت روی Project Schedule شده است. Story Point چنین کاری نمی‌کند، چون هرگز به Hour یا Date تبدیل نمی‌شود. Date اصلی ــ پایان Sprint ــ ثابت است و مقدار Work وعده‌داده‌شده در چرخهٔ Visibility–Inspection–Adaptation در Daily Scrum قابل تنظیم است.

کمک می‌کند تیم معنای دقیق Story را کشف کند

اگر شما Story را 5 Point و من 2 Point می‌بینم، ممکن است اختلاف ما دربارهٔ حجم کار نباشد، بلکه دربارهٔ معنای Story باشد. گفت‌وگو ممکن است روشن کند من Command-line Tool ساده تصور کرده‌ام و شما GUI. بسیار بهتر است این اختلاف در Sprint Planning آشکار شود تا وسط Sprint Story دوPointی ناگهان پنج‌Pointی از آب دربیاید.⁴

تعهد واقعی همهٔ اعضا را تقویت می‌کند

Story Point و Velocity یک Waypoint عینی می‌دهند که همه می‌توانند بر آن توافق کنند: Sprint قبل 26 Point Burn شد؛ دربارهٔ این Story هم روی 4 Point توافق کردیم. اگر فردی نقش «Chicken» را داشته باشد و از مشارکت کنار بکشد، بعداً می‌بیند دیگران بدون او تصمیم گرفته‌اند. روزی که بفهمد اطلاعاتش می‌توانست Estimate را از 1 به 3 Point اصلاح کند، شروع می‌کند به اهمیت‌دادن به Sprint Planning و واقع‌بینانه‌ماندن Estimateها؛ و این بخشی از ایجاد تعهد واقعی است.

⁴ امتیازی دیگر برای Face-to-face Communication نسبت به Comprehensive Documentation.

Burndown Chart

Burndown Chart راهی است تا هرکس با یک نگاه ببیند Sprint در مقایسه با Velocity گذشته چگونه پیش می‌رود. برای ساخت Burndown بر پایهٔ Story Point:

1. یک Line Chart خالی بسازید. محور x تاریخ‌های Sprint از روز اول تا آخر است. محور y Story Point از صفر تا حدود 20% بیشتر از کل Pointهای Sprint Backlog. نخستین نقطه را در روز صفر و برابر کل Pointها بگذارید. سپس یک خط مستقیم یا Guideline از آن نقطه تا صفر Point در پایان Sprint رسم کنید.

شکل ۵-۴ — Burndown Chart در شروع Sprint. این نمودار با Story Point ساخته شده، اما Hour، Day یا واحد دیگری نیز قابل استفاده است.

1. به محض تکمیل اولین User Story و انتقالش به ستون Done، نقطهٔ بعدی را با تعداد Point باقی‌مانده در روز جاری رسم کنید. با تکمیل Storyهای بیشتر و Burnشدن Pointها، روزهای بیشتری در Chart پر می‌شود.

شکل ۵-۵ — دو Story به ارزش 7 Point تکمیل و از Backlog سوخته‌اند.

1. ممکن است در Daily Scrum بفهمید کار بیشتری باید اضافه شود. شاید تیم سریع‌تر از انتظار Point Burn کرده و زودتر تمام می‌کند؛ یا Task پشتیبانی مهمی آمده و تیم و Product Owner توافق کرده‌اند وارد Sprint شود، اما هنوز نمی‌دانند برای حفظ تعادل چه مقدار Work باید حذف شود. کارت‌های کار تازه را روی Task Board اضافه کنید، جلسهٔ Follow-up برای Estimate Story Pointهای آن تشکیل دهید و Pointها را به Chart اضافه کنید. بهتر است یک خط اضافه نشان دهد کجا Point جدید وارد شده و از نوشتن Note روی Chart نترسید.

شکل ۵-۶ — Product Owner در نیمهٔ Sprint Storyهایی اضافه کرده است.

1. هرچه به پایان Sprint نزدیک می‌شوید Pointهای بیشتری Burn می‌شوند. فاصلهٔ میان Guideline و Burndown واقعی را زیر نظر بگیرید؛ فاصلهٔ زیاد می‌تواند نشان دهد Point زیادی باقی مانده و شاید لازم باشد یک User Story از Sprint حذف شود.

شکل ۵-۷ — فاصلهٔ Burndown واقعی با Guideline نشان می‌دهد احتمالاً همهٔ Storyها تا پایان Sprint تمام نمی‌شوند.

نرم‌افزارهای زیادی Backlog، Story و Story Point را مدیریت و Burndown را خودکار رسم می‌کنند. با این حال بسیاری از تیم‌ها ترجیح می‌دهند نمودار را دستی بکشند و کنار Task Board، اغلب روی همان Whiteboard، نگه دارند. به این ترتیب وضعیت پروژه همیشه جلوی چشم همه است. برای تیم نیز رضایت‌بخش است که هر توسعه‌دهنده پس از تکمیل Story و انتقال کارت به Done، شخصاً Burndown را Update کند.

برنامه‌ریزی و اجرای Sprint با Story، Point، Task و Task Board

Scrum Guide و ابتدای فصل ۴ می‌گویند Sprint Planning باید پاسخ دقیق دو سؤال را بدهد:

• تیم در این Sprint چه چیزی تحویل خواهد داد؟
• تیم چگونه این کار را انجام خواهد داد؟

Story Point و Velocity روش رایجی برای پاسخ‌دادن به نیمهٔ اول هستند. اما برای نیمهٔ دوم و برنامه‌ریزی Work واقعی چه می‌شود؟

یکی از رایج‌ترین روش‌ها افزودن کارت برای Taskهای توسعه‌ای منفرد است. Task می‌تواند هر کاری باشد که تیم واقعاً انجام می‌دهد: نوشتن Code، Design و Architecture، ساخت Test، نصب Operating System، طراحی و ساخت Database، Deploy به Production Server، Usability Test و هر کار روزمرهٔ دیگری که برای ساخت و Release نرم‌افزار لازم است.

بسیاری از تیم‌ها این روند را دنبال می‌کنند:

1. تیم جلسهٔ دوم Sprint Planning را برگزار می‌کند. Scrum Master از اولین Story شروع می‌کند و دربارهٔ کارهای دقیق لازم برای ساخت آن بحث را هدایت می‌کند. همه با هم فهرستی از Taskهایی می‌سازند که هر کدام حداکثر حدود یک روز طول بکشد. هر Task روی کارت جداگانه نوشته می‌شود. برخی تیم‌ها برای Story و Task رنگ متفاوت به کار می‌برند. کارت Story کنار Taskهای مربوط گروه‌بندی می‌شود. این کار تا برنامه‌ریزی همهٔ Storyها ادامه دارد. اگر Timebox Sprint Planning پیش از پایان همهٔ Storyها تمام شد، برای هر Story برنامه‌ریزی‌نشده یک Task با مضمون «برنامه‌ریزی این Story» ایجاد می‌شود.

شکل ۵-۸ — نیمهٔ دوم Sprint Planning دربارهٔ شکستن Storyها به Taskهایی است که اعضای تیم در Sprint انجام خواهند داد.

1. Storyها و Taskهایشان با هم گروه‌بندی شده و در ستون To Do روی Task Board قرار می‌گیرند.

شکل ۵-۹ — کارت هر Story همراه کارت Taskهایش در بخش To Do قرار می‌گیرد.

1. وقتی عضو تیم Task را تمام می‌کند، کارت Task تکمیل‌شده را به Done منتقل می‌کند. سپس کارت Task بعدی را از To Do برمی‌دارد، نامش را روی آن می‌نویسد و در In Progress می‌گذارد. اگر کارت Story هنوز در To Do باشد، آن را هم به In Progress می‌برد، اما نام خودش را روی Story نمی‌نویسد، چون اعضای دیگر هم ممکن است هم‌زمان Taskهای همان Story را انجام دهند.

شکل ۵-۱۰ — هر عضو تیم در هر لحظه دقیقاً روی یک Task کار می‌کند؛ نام خود را روی کارت می‌نویسد و آن را به In Progress می‌برد.

1. با پیشرفت Sprint، Taskها از To Do به In Progress و بعد Done می‌روند. بسیار عادی است تیم وسط کار Task تازه‌ای برای تکمیل Story کشف کند. Task جدید به Board افزوده می‌شود و عضو تیم در Daily Scrum آن را مطرح می‌کند تا همه از وضعیت آگاه شوند و بتوانند مشکل احتمالی را زود ببینند.

1. وقتی آخرین Task یک Story تمام شد، عضو تیم کارت Story را از Board برمی‌دارد، بررسی می‌کند تمام Conditions of Satisfaction انجام شده‌اند و سپس Story را به Done می‌برد تا کنار Taskهای خودش قرار گیرد. با این حال Story «واقعاً Done» نیست تا Product Owner به نمایندگی از شرکت آن را Potentially Shippable بپذیرد. اگر یکی از Conditions برآورده نشده باشد، هنوز Work باقی است؛ Story به In Progress برمی‌گردد و Taskهای لازم برای تکمیل شرط‌ها به To Do اضافه می‌شوند.

شکل ۵-۱۱ — پس از تکمیل Task، کارت آن به Done می‌رود و عضو Task دیگری را Claim می‌کند. اگر همهٔ Conditions of Satisfaction Story برآورده شده باشند، کارت Story نیز به Done منتقل می‌شود.

1. Sprint وقتی تمام می‌شود که Timebox منقضی شود. ممکن است هنوز Story و Task در To Do یا In Progress باقی مانده باشد. Storyهای ناتمام به Product Backlog برمی‌گردند تا در Sprint Planning بعدی اولویت‌بندی شوند.⁵ تیم می‌تواند بر اساس Taskهای باقی‌مانده Point آن‌ها را کاهش دهد، اما تا زمانی که کارت Story و تمام Taskهای آن به Done نرفته‌اند، برای تکمیل Story Credit نمی‌گیرد.

Practiceهای عموماً پذیرفته‌شدهٔ Scrum

اگر کتاب اصلی Ken Schwaber، Agile Project Management with Scrum را جست‌وجو کنید، اشاره‌ای به User Story یا Story Point پیدا نمی‌کنید. بسیاری از تیم‌ها این مفاهیم را از منابع دیگری مثل کتاب عالی Mike Cohn، User Stories Applied، آموخته‌اند.⁶

⁵ میان Scrum Trainerها دربارهٔ برگرداندن Work ناقص به Product Backlog و Re-estimate کردن Point اختلاف نظر وجود دارد. برخی آن را مجاز می‌دانند؛ برخی می‌گویند Point هرگز تغییر نکند تا تیم در Estimation بهتر شود؛ و برخی معتقدند در بلندمدت تفاوت مهمی ایجاد نمی‌کند.

⁶ Mike Cohn, User Stories Applied: For Agile Software Development, Pearson Education, 2004.

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

به همین دلیل تیم‌های زیادی از ابزارها و تکنیک‌های اضافی استفاده می‌کنند که Cohn آن‌ها را Generally Accepted Scrum Practices (GASPs) نامید.⁷ برای نمونه، خیلی از تیم‌ها Daily Scrum را وقتی به‌صورت Standup برگزار می‌شود مؤثرتر می‌بینند؛ همه تا پایان جلسه ایستاده می‌مانند. این Practice جزو هستهٔ Scrum نیست، اما میان تیم‌های Scrum پذیرفته شده است.

اصل پایانی Agile Manifesto را به یاد بیاورید:

در فاصله‌های منظم، تیم دربارهٔ اینکه چگونه مؤثرتر شود تأمل می‌کند، سپس رفتار خود را متناسب با آن تنظیم و اصلاح می‌کند.

این اصل را در Retrospectiveها به خاطر داشته باشید. دنبال راه بهتر باشید، اما چرخ را دوباره اختراع نکنید. اگر با مسئله‌ای در Scrum روبه‌رو هستید، احتمالاً تیم دیگری قبلاً با آن مواجه شده است. Mentor خوبی ــ مثل Eric برای Roger و Avi ــ می‌تواند Practice یا تغییری پیشنهاد کند که مسئله را حل کند.

نکته‌های کلیدی

• User Story با توضیح روشن یک نیاز مشخص و نحوهٔ پاسخ نرم‌افزار به آن، به تیم کمک می‌کند کاربران را بهتر درک کند.
• هر User Story دارای Conditions of Satisfaction است تا تیم بداند Story چه زمانی Done شده است.
• تیم‌ها از Story Point و Velocity برای تخمین تعداد Storyهای قابل گنجاندن در هر Sprint استفاده می‌کنند.
• نصب Burndown Chart در جایی که همه آن را ببینند کمک می‌کند تیم بداند چه چیزی تکمیل شده، چه چیزی باقی مانده و آیا در مسیر رسیدن به هدف است یا نه.

⁷ برگرفته از “GASPing About the Product Backlog”، دسترسی در 26 ژوئیهٔ 2014.