فصل ۴ — Scrum: Daily Scrum، آخرین لحظهٔ مسئولانه، Sprint و Retrospective
روایت: تیمی در یک شرکت کوچک که روی اپلیکیشن تلفن همراه کار میکند
- Roger — سرپرست تیم که میکوشد Agile شود
- Avi — Product Owner
- Eric — Scrum Master تیمی دیگر
پردهٔ دوم: Status Update برای شبکههای اجتماعی است!
صفحهٔ PDF 129
در تیم Lolleaderz.com، Roger و Avi به کمک نیاز داشتند و خودشان هم میدانستند. میدانستند تیم دیگری در Hover Puppy تجربهٔ بسیار خوبی با Scrum داشته است. Roger با افراد آن تیم صحبت کرد تا راز موفقیتشان را بفهمد، اما بیشتر گیج شد: آنها هم Sprint، Daily Scrum، Retrospective، Backlog، Product Owner و Scrum Master داشتند. ظاهراً هر دو تیم همان کارها را میکردند، ولی یکی نتیجهٔ عالی میگرفت و دیگری آرامآرام غرق میشد.
Roger و Avi با Eric، Scrum Master تیم دیگر، نشستند. Eric با Scrum موفق بود و با خوشحالی پذیرفت کمک کند مشکل را پیدا کنند. اولین سؤالش این بود: «Coach دارید؟» Roger دقیق نمیدانست منظور چیست. Eric توضیح داد: «Mentor؛ کسی که کمک کند Scrum را درست اجرا کنید. تیم من بدون Coach هرگز اینقدر خوب نمیشد.» آنجا Roger برای نخستین بار واقعاً فهمید Avi چه فروشندهٔ خوبی است؛ تا پایان گفتوگو Eric را قانع کرده بود Coach تیم Lolleaderz.com شود.
دوشنبهٔ بعد Roger و Avi میخواستند معرفی Eric در Daily Scrum را رسمی و پررنگ کنند. Eric خواست همه طبق معمول پیش بروند؛ خودش Work را میبیند و بعد چند پیشنهاد کوچک میدهد. تصمیم خوبی بود، چون هنگام معرفی فقط نصف Team حاضر بودند. همه میدانستند Lead Developer همیشه اول صحبت میکند و چون Update او معمولاً از همه طولانیتر است، بقیه اغلب وسط Status Report او میرسیدند.
در ادامهٔ Meeting، اعضا یکییکی با Roger دربارهٔ Taskهایشان صحبت کردند؛ Progress کارهای Assigned را گزارش دادند و Assignment بعدی را از Roger خواستند. یکی گفت هنوز منتظر Sysadminها هستند تا Configuration یکی از Web Serverها را Fix کنند و از Roger پرسید چه خواهد کرد. Roger آن را به فهرست Roadblockهای خودش افزود. Eric تمام جلسه را بیکلام نگاه کرد.
روز بعد Daily Scrum همانطور تکرار شد. Eric متوجه شد عضوی گفت Taskش ۹۵٪ تمام است؛ جلسهٔ قبل هم همان Task ۹۵٪ تمام بود. بعد از Meeting از Roger پرسید. Roger گفت: «بله، احتمالاً Slip میکند. نگران نباش، حواسم هست. Schedule را Update کردهام. او همیشه در Taskها دیر میکند، پس Contingency کافی گذاشتهام و اگر بیشتر Slip کند مطمئن میشوم Avi و CEO خبردار شوند.»
Eric همان روز جلسهای با Roger و Avi گذاشت و مشکل اصلی را توضیح داد: «Roger، تو Daily Scrum را فقط برای Manage کردن Schedule استفاده میکنی. اگر این عضو باز هم Slip کند چه؟ Schedule را Update میکنی و Job خودت تمام است؟ Update کردن یک Gantt Chart در یک Folder هیچ چیزی از Late بودن Project کم نمیکند.»
Roger از شنیدن این حرف خوشش نیامد؛ Avi هم نه، چون همان Schedule را برای Update Stakeholderها استفاده میکرد. Eric ادامه داد که Roger Daily Scrum را برای گرفتن Status Update از Team به کار میبرد و این بدتر است. Roger گفت: «معلوم است! مگر این جلسه برای همین نیست؟» و داشت از آوردن Eric بهعنوان Coach پشیمان میشد.
چرا Eric با استفاده از Daily Scrum برای Status Update یا نگهداری Schedule مشکل داشت؟ اگر Daily Scrum برای این نیست، پس هدفش چیست؟
کل تیم از Daily Scrum استفاده میکند
Daily Scrum یکی از مؤثرترین Toolهای Scrum Team است، چون دو کار بسیار مهم انجام میدهد: اول، Inspection کار Team است تا بتوانند Work را برای تحویل بیشترین Value Adapt کنند؛ دوم، فرصت میدهد Decisionها در Last Responsible Moment گرفته شوند، تا فرد درست در زمان درست کار درست را انجام دهد. وقتی همه Daily Scrum را برای محدودکردن Planning به فقط آن چیزی که برای Increment بعدی Software لازم است به کار میگیرند، ارزش آن را میفهمند و مؤثر استفاده میکنند.
Feedback و چرخهٔ Visibility–Inspection–Adaptation
بسیاری از Developerهای تازهوارد Agile از دنیایی میآیند که حول Programming میچرخد: صبح فهرستی از چیزهایی برای ساخت دارند و عصر آنها را ساختهاند. این برای Developer راحت است چون میتواند روی Technical Problem تمرکز کند.
اما هر Programmer تجربه کرده وقت زیادی روی Solution بگذارد و آخر کار بفهمد بخش مهمی از Problem را نمیفهمیده—معمولاً چون هرگز به او Communicate نشده است. در Projectهای سنتی BRUF این مسئله شدیدتر است. Requirement پیش از رسیدن به Developer معمولاً این زنجیره را طی میکند:
- Project Manager Scope را، اغلب در Business Requirements یا Scope/Objectives Document، مشخص میکند.
- Managerها Scope را Sign off میکنند.
- Business Analyst Scope را Review، سپس با User و Stakeholder دربارهٔ Jobشان صحبت میکند.
- Business Analyst Use Case، Functional Requirement و مانند آن میسازد.
- Programmer Requirement را میگیرد و Estimate تولید میکند.
- Project Manager Requirement و Estimate را میگیرد، Schedule میسازد و با Stakeholder/Manager Review میکند.
قبل از Development زنجیرهٔ بلندی طی شده است؛ پس عجیب نیست Requirement در این «بازی تلفن» بهندرت کاملاً سالم وارد ذهن Developer شود.
این فقط مشکل Waterfall نیست. حتی Teamی که تقریباً کامل بر Face-to-face Communication تکیه دارد میتواند Misunderstanding داشته باشد. ارتباط رودررو بسیار Efficient است اما از Written Communication کمدقتتر است، هرچند اغلب Accurateتر. سه نفر ممکن است گفتوگوی عالی داشته باشند و فکر کنند Consensus دارند، ولی سه برداشت متفاوت از آن بیرون بیاورند.
یک ضربالمثل میگوید: «Sunlight بهترین Disinfectant است.» شاید توصیهٔ پزشکی دقیقی نباشد، اما برای Project Team عالی است. بهترین راه سنجش اینکه Software واقعاً Value دارد این است که Working Software را تا حد ممکن مکرر در دست User بگذاریم. این Visibility یا Transparency است و به Communication هم مربوط میشود.
Daily Scrum Visibility را تقویت میکند، چون مشکلهای Communication در Work ظاهر میشوند. سه نفری را تصور کنید که از یک Discussion سه برداشت دارند و بعد سه Task جدا انجام میدهند که در پایان Sprint Integrate میشود. سوءتفاهمهای کوچک اگر زود کشف نشوند جمع میشوند، اصطکاک میسازند و Quality Code را آرامآرام فرسایش میدهند؛ Defect کوچک بعداً باید Rip out، Patch یا با Change بزرگ اصلاح شود و در Project طولانی Codebase رو به زوال میرود.
اما اگر همین سه نفر هر روز ۱۵ دقیقه بنشینند و بپرسند:
- از Meeting قبلی چه کردهام؟
- تا Meeting بعدی چه برنامهای دارم؟
- چه Roadblockهایی سر راه من است؟
وقتی اعضا هر روز Work را به یک شیوه برای هم شرح میدهند، مشکلهای ناشی از Miscommunication قبل از گرانشدن پیدا میشوند. همه Work هم را Inspect میکنند، با هم Conclusion میگیرند و Understanding مشترکی از Goalهای Project و مسیر رسیدن به آنها حفظ میکنند.
وقتی یک نفر Workش را توضیح میدهد، همتیمی میتواند Improvement پیشنهاد کند یا حتی متوجه شود کل Task اشتباه انتخاب شده است. این تغییرها Adaptation هستند. چرخهٔ روزانهٔ Visibility، Inspection و Adaptation به Team اجازه میدهد Feedback واقعی Project را پیوسته برای بهتر ساختن Software استفاده کند. این از مهمترین ویژگیهای Scrum است. Scrum Team Decision را براساس Experience و Fact شناختهشدهٔ واقعی میگیرد.⁸
⁸ در نظریهٔ Scrum این Empirical Process Control نامیده میشود؛ برای Empiricism به صفحهٔ ۴ Scrum Guide مراجعه کنید.
این Feedback «واسطه» یعنی Project Manager جدا از Work را حذف میکند، آسیب بازی تلفن را کم و همزمان Quality را بالا میبرد. این Loop پروژه را On Track و همه را On the Same Page نگه میدارد.
نقش Inspector برای Work همکارها در ابتدا برای Programmer راحت نیست، اما حتی افراد Introvert هم معمولاً عادت میکنند و خیلیها بعداً منتظر Daily Scrum هستند، چون کارآمدترین راه Scrum Team برای مدیریت Communication و ساخت Shared Understanding است.
آخرین لحظهٔ مسئولانه (Last Responsible Moment)
اینجا Project Manager باهوش و شکاک Command-and-Control ممکن است بگوید: «باشه، فهمیدیم. Scrum ادعا نمیکند همهچیز را از اول میداند. Communication مهم است. اما Work باید انجام و به افراد Assigned شود. Task واقعی Programming، DBA یا Testing چطور وارد To-do List یک نفر میشود؟»
Coachهای Agile گاهی برای بهترشدن Daily Scrum اجازه میدهند Team شکست بخورد.⁹ Team عادتکرده به Command-and-Control در Daily Scrum به Project Manager یا Scrum Master نگاه میکند تا Status بخواهد و Assignment بعدی را بدهد. Coach ممکن است از Scrum Master بخواهد فقط همین یک بار سکوت کند. معمولاً یک یا دو دقیقه سکوت دردناک ایجاد میشود. بالاخره کسی Workش را توضیح میدهد و اگر Team خوششانس باشد، بعد میپرسد: «خب Task بعدی من چیست؟»
این لحظه فرق Scrum Master و Project Manager را روشن میکند. Project Manager Task آماده تحویل میدهد. Scrum Master این را فرصت «آها!»ی جمعی میبیند تا Team بفهمد Task Assignment از کجا میآید. شاید بپرسد: «خودت فکر میکنی بعدش باید چه کار کنی؟» یا فقط سکوت کند.
نکته این است که خود اعضای Team منبع Assignment هستند. هر فرد وقتی Task فعلی تمام شد Task بعدی را Self-assign میکند. این در Daily Scrum انجام میشود تا بقیه Input بدهند و Course-correct کنند. اگر Developer یک Database Optimization پیچیده را برای خودش بردارد، DBA میتواند پیشنهاد دهد آن را فعلاً رها کند و خودش بعداً انجامش دهد.
⁹ این Technique و Techniqueهای مؤثر دیگر Coaching در کتاب Lyssa Adkins، Coaching Agile Teams شرح داده شده است.
مگر با Up-front Planning نمیتوان Bottleneck را حذف کرد؟
Command-and-Control با این فرض شروع میکند که بعضی Taskها حتماً باید به Team Member مشخصی برسند، معمولاً بهخاطر Skill تخصصی مثل DBA. این ظاهراً Argumentی برای Up-front Planning است: Taskهای فرد متخصص Bottleneck Schedule میشوند و باید از ابتدا Around آن Plan کرد.
طنز این است که همین یکی از منابع رایج مشکل است. Task پیچیده سختتر Estimate میشود و Task وابسته به یک Person/Resource Risk بیشتری از Task قابل انجام توسط چند نفر دارد. پس پیچیدهترین Taskی که فقط یک Expert میتواند انجام دهد، دقیقاً همان Taskی است که Estimate آن بیشتر احتمال خطا دارد؛ و Project Manager معمولاً برای خود Estimate هم به همان فرد وابسته است.
نمیتوان همهچیز را از قبل دانست. بعضی Decisionها باید آغاز Project گرفته شوند—Java یا C#؟ Windows یا Linux؟ Mac یا PC؟—و بعضی Taskها واقعاً فقط توسط یک نفر انجام میشوند. اما Scrum Team عموماً Assignment را نه آغاز Project و حتی نه آغاز Sprint نهایی نمیکند.
در واقع Team تلاش نمیکند Sequence «نهایی» Taskها را بسازد. برای اکثر Taskها، بهخصوص Programming، Duration دقیق تا شروع کار معلوم نیست و Dependency اغلب وقتی ظاهر میشود کشف میگردد. Missing Task، بزرگشدن Task کوچک یا کوچکترشدن Task بزرگ رایج است. البته این مسئولیت Team برای ساخت کاملترین Task List ممکن در Sprint Planning را از بین نمیبرد.
پس بهجای Decompose، Sequence و Assign کردن همهچیز پیش از شروع و Track کردن همان Plan، Agile Team Rule سادهای دارد: همهٔ Decisionها را در Last Responsible Moment بگیر.
مشکل Sprint چهارم Lolleaderz.com از Overplanning آمد: فرض شد DBA همهٔ Taskهای تخصصی را انجام میدهد. این Taskها بیشترین Risk Slip را دارند و چون شخص دیگری نمیتواند بگیرد، Delayها Cascade یا به Overtime و Work ضعیف Expert منجر میشوند.
Scrum Team بهجای فرض اولیه، Taskهای DBA را روی Index Card یا معادل Electronic در ستون To Do روی Task Board میگذارد. Daily Scrum آنها را Visible میکند و Team زود میپرسد آیا بعداً Bottleneck خواهند شد.
Open Source جملهای دارد: «با چشمهای کافی، همهٔ Bugها سطحیاند» (Linus’s Law). همین برای Plan صدق میکند. Daily Scrum چشمهای Team را روی Plan میگذارد. وقتی Work پروژه بهاندازهٔ Source Code با دقت دیده شود، Bugهای Schedule هم زود پیدا میشوند. کشف Bottleneck در Daily Scrum از پیشبینی کامل Project Manager آسانتر است. Team وقتی مشکل را میبیند وقت پیدا میکند راه دورزدن آن را بسازد و میفهمد Last Responsible Moment بعضی Taskها خیلی زودتر از بقیه است. این Value چرخهٔ Visibility–Inspection–Adaptation است.
اگر Roger و Avi Daily Scrum مؤثرتری داشتند، بهجای Assign Work میتوانستند همه را برای شناسایی Schedule Problem و Self-assignment دور هم بیاورند. شاید زود میفهمیدند فردی غیر از DBA باید Stored Procedureها را شروع کند؛ یا اگر ممکن نبود، زودتر میفهمیدند بیش از Capacity تعهد کردهاند و Expectationها را دربارهٔ Working Software پایان Sprint تنظیم میکردند.
چگونه Daily Scrum مؤثر برگزار کنیم
مثل «خوک» رفتار کنید
در این Meeting هر Team Member به همتیمیها پاسخگوست و اگر Commitment جلسهٔ قبل انجام نشده باید توضیح دهد. خودتان را در Self-organizing Team تصور کنید که واقعاً نسبت به Project Accountable هستید. هر روز چه چیزی باید بدانید؟ مهمترین چیز Work خودتان است؛ اما اگر Team واقعاً Self-organizing است، نمیتوانید منتظر Project Manager بمانید تا برایتان تصمیم بگیرد چه کار کنید.
وقتی نوبت شما برای پاسخ به «تا Daily Scrum بعدی چه میکنی؟» رسید و Work فعلی تمام شده، باید به ستون To Do نگاه کنید و Taskی را بردارید که برای شما و Project منطقیتر است. اگر انتخاب مناسب نباشد، Team Member دیگری که واقعاً «خوک» متعهد است دخالت میکند.
گفتوگوهای جزئی را خارج از Daily Scrum ادامه دهید
هدف Daily Scrum شناسایی Problem است، نه حل کامل آن. اگر بعد از یک یا دو دقیقه حل نشد، Follow-up Meeting با افراد لازم تعیین کنید. بسیاری از این جلسهها دربارهٔ این است که چه کسی کدام Task را انجام دهد. Self-organization همینطور رخ میدهد: بیشتر Taskها Self-assign میشوند و بعضی نیاز به Discussion دارند؛ Inspection روزانه نشان میدهد کدامیک از کدام نوع است.
نوبتی جلسه را شروع کنید
هیچ «Keeper of Schedule» واحدی وجود ندارد و هیچکس از بقیه مهمتر نیست. بعضی Developerها Expert بیشتری دارند، اما Good Idea از هرکس ممکن است بیاید. Idea یک Junior را فقط به این دلیل که از Top Programmer نیامده کنار نگذارید؛ شاید Problem جدیای را دیده باشد. یک روش ساده برای واداشتن همه به شنیدن یکدیگر این است که هر روز Team Member متفاوتی Daily Scrum را شروع کند.
آن را Ritual نکنید
هرچند جلسه هر روز برگزار میشود و بعضی Scrum Teamها حتی آن را Ceremony مینامند، همه باید واقعاً حاضر و درگیر باشند. سه سؤال نباید Ritualی شود که علتش فراموش شده است. Ritualها با زمان رنگ میبازند. این سه سؤال هستهٔ Daily Scrum هستند چون دقیقاً چیزهاییاند که Team باید هر روز Inspect کند تا Problem را زود پیدا کند. مثلاً Bottleneck ناشی از Taskهای زیاد برای یک Person وقتی زود دیده میشود که همه دربارهٔ Blocker خود حرف بزنند؛ نخستین کسی که قرار است در آینده Block شود احتمالاً آن را زودتر از بقیه میبیند.
همه شرکت میکنند
Tester، Business Analyst، Product Owner و هرکس دیگری در Team. همه متعهدند. Product Owner نقش ویژهای دارد چون Team را از ارزش نسبی Taskهای Backlog برای User و Company آگاه نگه میدارد. هرچه Team Value را بهتر بفهمد Software را دقیقتر به نیاز User هدف میگیرد. Product Owner هم باید همان سه سؤال را پاسخ دهد، چون Team باید ببیند او نیز Job واقعی و تماموقتی دارد: صحبت با User، فهم Business و مدیریت Backlog. Developer وقتی این را مستقیم میبیند بیشتر به Role او احترام میگذارد.
آن را Status Meeting نکنید
Status Meeting معمول Ritual هفتگی است: ظاهراً هم Team و هم Management را Informed نگه میدارد، اما در عمل اغلب مجموعهای از Conversationهای دو نفره بین هر Team Member و Project Manager است. در Daily Scrum همه باید واقعاً گوش کنند—نه Email چک کنند، نه Phone و نه Work دیگر. وقتی Team میبیند Daily Scrum Problem را زود میگیرد و از تلفشدن Developer Time در مسیر غلط جلوگیری میکند، دیگر Red Tape بوروکراتیک به نظر نمیرسد و Toolی Developer-centric برای Better Code میشود.
همهٔ Taskها را Inspect کنید
برای Roadblock فقط Work فعلی را نبینید؛ چند حرکت جلوتر بروید و تمام اقلام To Do را نگاه کنید تا Impact احتمالی پیدا شود. Potential Problem را اکنون مطرح کنید حتی اگر Team آن را رد کند؛ بهتر از سکوت و سوختن بعدی است. این Inspection به Trust نیاز دارد. اگر کسی عمداً یا ناخواسته Work و Plan خودش را دقیق توضیح ندهد، Team ممکن است Roadblock را از دست بدهد و بعد Problem بزرگتری بگیرد.
اگر لازم است Plan را تغییر دهید
این بخش Adaptation چرخهٔ Visibility–Inspection–Adaptation است و Self-organization را واقعی میکند. فرض کنید Team Roadblock جدی میبیند و در Follow-up میفهمد Major Feature وعدهدادهشده قابل تحویل نیست. آیا باید Plan شکستخورده را ادامه دهد؟ نه. Backlog و Task Board باید Reality Project را منعکس کنند و کل Team آنها را اصلاح کند. Product Owner متعهد در همین لحظه میتواند Expectationها را با Stakeholderها تنظیم کند. هرچقدر مردم امروز از خبر بد ناراحت شوند، اگر امروز نگویید و بعداً بفهمند بدتر واکنش خواهند داد.
نکات کلیدی Daily Scrum
- هر Team Member سه سؤال را پاسخ میدهد: از Daily Scrum قبلی چه کردهام؟ تا بعدی چه میکنم؟ Bottleneckهای من چیست؟
- Team با این سؤالها هر روز Project Plan را با هم Inspect و در برابر Change Adapt میکند و Feedback مداوم میگیرد.
- Scrum Team مؤثر Decision را در Last Responsible Moment میگیرد تا Optionها باز بمانند و Adaptation آسانتر شود.
- Daily Scrum مال کل Team است، نه فقط Scrum Master یا Product Owner؛ همه برابر شرکت میکنند.
پردهٔ سوم: Sprint به دیوار میخورد
صفحهٔ PDF 137
بعد از ناهار طولانی Eric، Roger و Avi دربارهٔ Daily Scrum، Roger Ideaای داشت. جلسهٔ بعد از یکی از Junior Developerها خواست اول سه سؤال را جواب دهد. وقتی او پرسید Task بعدیاش چیست، Roger سکوت کرد. نیم دقیقه سکوت ناراحتکننده گذشت و درست وقتی Roger شک کرد، یک Senior Developer وارد شد. پس از Discussion کوتاهی با چند نفر، Junior دقیقاً میدانست چه کند. Index Card Task را از To Do برداشت، Name خودش را روی Card نوشت و در In Progress چسباند.
بقیهٔ Daily Scrum عالی شد. انگار همان یک Discussion کافی بود تا Team ناگهان «بگیرد»: دربارهٔ Taskهای هم حرف زدند و فقط دو Follow-up برای تعیین Who Does What لازم شد. Roger حتی لازم نبود در یکی شرکت کند. Follow-upی که خودش Lead کرد دربارهٔ Developerی بود که Taskش یک هفته ۹۵٪ مانده بود؛ معلوم شد Roadblock جدی دارد و از کسی Help میخواهد اما بهخاطر ترس از Waste کردن وقت Team و کمی خجالت درخواست نکرده بود.
چند Daily Scrum بعد، Eric گفت Team واقعاً دارد با هم کار میکند. در هفتهٔ بعد Roger حس کرد آنها Self-organization را نه در Theory بلکه بهعنوان Team فهمیدهاند. هر روز همه Work روز بعد را با هم انتخاب، همدیگر را On Track نگه و Problem حل میکردند. Daily Scrum ابزار Course-correct جمعی براساس Review واقعی Work بود.
همهچیز تا پایان Sprint عالی به نظر میرسید. Team مثل شش Sprint قبلی Working Software جدید Release کرد.
فاجعه بود.
Avi از Stakeholder Meeting با حال خراب برگشت. انتظار داشت Account Managerها از نسخهٔ تازهٔ Achievement Editor هیجانزده شوند که User میتوانست Achievement بسازد و در Social Network Share کند. همچنین Banner Ad Feature Update شده بود تا هر Account Manager برای مشتریان خودش Page سفارشی با Page View و Advertising Cost روزآمد بسازد.
اما بیشتر Account Managerها گیج و غافلگیر شده بودند. احساس میکردند کسی نگفته اینهمه چیز قرار است عوض شود. ناگهان هرکدام دهها Voicemail از Clientهایی داشتند که دربارهٔ Feature جدید سؤال میکردند. قبلاً Scheduleهای Roger Notice کافی میداد تا برای Sell کردن Feature آماده شوند؛ حالا دنیا سریع تغییر میکرد و حس میکردند نمیرسند.
خبر بدتر: بعضی Stakeholderها Schedule قدیمی را میخواستند و پیشنهاد کردند Release تا Quarter بعد متوقف شود. انگار Company میخواست Scrum را کامل کنار بگذارد و به Waterfall برگردد. وحشتناک بود!
یا واقعاً بود؟ Eric همان خبر را شنید اما بهجای ناامیدی عجیب Optimistic بود. چرا؟
Sprint، Planning و Retrospective
برای بعضی Projectها Sprint Planning آسان است—مثلاً وقتی فقط باید Featureهایی را بسازید که ماهها User درخواست کرده و در Backlog ماندهاند. Feature پرتقاضا را High Priority میکنید و برد سادهای میگیرید. اما گاهی Planning ظریفتر است و Team باید دربارهٔ نیاز و Value User به شیوهای فکر کند که قبلاً نکرده است. وقتی میگویند Scrum سخت است معمولاً منظور همین است.
Scrum Team مؤثر Weapon نهچندان مخفی دارد: Product Owner. وقتی Product Owner وقت میگذارد Need و Value Stakeholder را واقعاً بفهمد، میتواند هر Sprint را به سمت Problemهایی هدف بگیرد که Company ابتدا نیاز به حلشان دارد. با Visible کردن Value و کمک به Plan تازهٔ هر Sprint، Incremental Process ساده را به Iterative Process واقعی تبدیل میکند. Retrospective مؤثر هم Lessonهای Team را به Company برمیگرداند تا Expectation با چیزی که واقعاً قابل Deliver است هماهنگ بماند.
Iterative یا Incremental؟
Value هر Release پایان Sprint چیست؟
اگر Sprintهای Timeboxed داشته باشید، با تمامشدن Time کار را Stop کنید و در پایان هر Sprint Working Software تحویل دهید، Benefit زیادی میگیرید: Checkpoint روتین برای Quality، Functional Complete Version برای Product Owner/User/Stakeholder و کاهش Risk Integration چون Featureهای افراد مختلف تا End Project برای Integrate شدن صبر نمیکنند.
یک Thought Experiment: دو عضو Team روی Featureهای متفاوتی کار میکنند که باید Current Work کاربر را File کنند، اما متفاوت. Conflictهای ممکن فراوان است: یکی Save Icon و دیگری File Menu؛ روش ناسازگار Access به Shared Resource؛ File Format ناسازگار؛ Overwrite کردن Shared Data؛ و Problemهای Integration دیگر. اگر مدتها Software ساختهاید اینها را بارها دیدهاید.
Integrate کردن Development در پایان هر Sprint بسیاری از Problemها را زود آشکار یا پیشگیری میکند. Communication بهتر، Stakeholder درگیرتر و Status قابلسنجشتر هم Benefitهای دیگرند. وقتی Project به Phase/Increment تقسیم میشود Incremental Development است؛ Sprint هم Increment میسازد، پس Scrum Incremental Methodology است.
اما Scrum بیشتر از این است. Sprint فقط Deliver کردن Working Software در Schedule Timeboxed نیست؛ دربارهٔ فهم Value Software، نحوهٔ تحویل آن و Change Course برای Value بیشتر است. وقتی Process اینگونه کار کند، Iterative Development است. بنابراین Scrum هم Incremental و هم Iterative است.
Mike Cohn در User Stories Applied تفاوت را خوب شرح میدهد:
در Iterative Process پیشرفت با Successive Refinement رخ میدهد. Team نخست نسخهٔ اولیهای از System میسازد و میداند در بعضی یا بسیاری بخشها ناقص یا ضعیف است؛ سپس Iteratively همان بخشها را تا رضایتبخششدن Product Refine میکند و هر Iteration با Detail بیشتر Software را بهبود میدهد.
>
در Incremental Process، Software به Pieceها ساخته و تحویل میشود. هر Increment زیرمجموعهای Complete از Functionality است؛ ممکن است کوچک مثل Login Screen یا بزرگ مثل مجموعهٔ Flexible Data Management Screen باشد. هر Increment کاملاً Code و Test میشود و انتظار معمول این است که Work آن Iteration نیاز به بازگشت نداشته باشد.¹⁰
ما برای «نسخهٔ اولیه و سپس Refinement» اصطلاحی داریم: همان Visibility–Inspection–Adaptation Cycle. Scrum Team این چرخه را که در Daily Scrum استفاده میکند به کل Project اعمال میکند. Sprint Planning، Sprint Backlog و Retrospective برای همیناند.
پس Product Owner بسیار مهم است. Job او:
- بفهمد Company بیش از همه چه نیاز دارد و Knowledge را به Team بیاورد.
- بداند Team چه Software Featureهایی بالقوه میتواند Deliver کند.
- Value نسبی Featureها را تشخیص دهد.
- با Team Difficulty ساخت Featureها را بفهمد.
- Value، Difficulty، Uncertainty، Complexity و غیره را برای انتخاب Feature مناسب هر Sprint استفاده کند.
- این Knowledge را به Company برگرداند تا برای Release بعدی آماده شوند.
Product Owner میتواند Sprint را بسازد یا خراب کند
Product Owner مالک Product Backlog است و High Priority Itemها را برای Sprint پیشنهاد میکند. در Sprint Planning با Team تصمیم میگیرد کدام Item وارد Sprint Backlog شود؛ Sprint Backlog بهصورت جمعی مال Team است. سپس Itemهای Finished را از طرف Company Accept میکند.
پس Product Owner باید Authority واقعی داشته باشد. کسی که اختیار این Decisionها را ندارد یا از گرفتنشان میترسد فرد مناسبی نیست. همچنین باید Sense بسیار خوبی از Value شرکت داشته باشد. میتواند با دیگران دربارهٔ Value مشورت کند، اما Decision نهایی Priority همهٔ Product Backlog بر عهدهٔ اوست.¹⁰ Mike Cohn, User Stories Applied: For Agile Software Development (Pearson Education, 2004).
به همین دلیل Team و Product Owner باید از شروع Sprint دربارهٔ محتوای هر Backlog Item توافق کنند. هنگام ساخت Sprint Backlog باید همه تعریف مشترکی از Done داشته باشند—نه فقط done، بلکه واقعاً «Done».
یک Backlog Item وقتی «Done» است که Product Owner بتواند آن را Accept کند و برای بقیهٔ Company قابل تحویل باشد. اگر Definition روشن و بدون Ambiguity وجود نداشته باشد، پایان Sprint Confusion و Argument شدید تقریباً قطعی است. اگر همه Definition مشترک داشته باشند، Team در هر لحظه Sense خوبی از میزان Progress Sprint دارد.
Sprint Timeboxed است؛ اغلب ۳۰ روز، هرچند برخی Teamها دو یا سه هفته را انتخاب میکنند. وقتی Sprint تمام میشود، همهٔ Itemهای Done توسط Product Owner Accept میشوند. هر Item ناتمام، حتی اگر بیشتر Work آن انجام شده، به Product Backlog برمیگردد. لازم نیست Code Delete یا Work Undo شود؛ فقط تا وقتی واقعاً Done و Accept نشده Credit «Finished» نمیگیرد.
این Rule مانع میشود Team به User القا کند Valueای تحویل شده که واقعاً تحویل نشده است. بهتر است دربارهٔ Commitment تحویلشده Conservative باشید. Sprint Review تنها زمانی است که کل Team در برابر User و Stakeholder میایستد و Work ۳۰ روز اخیر را Demo میکند. اگر Commitmentی انجام نشده، همه باید چشم در چشم User توضیح دهند چه تحویل دادهاند و چه نه. این Tool قدرتمندی برای Collective Commitment است. Interaction انسانی Review همچنین سؤال و Feedback میآورد و Trust واقعی میسازد. هرچه این گفتوگو بیشتر شود، Trust و آزادی Team برای ساخت Software بیشتر خواهد شد. بااینحال Accept نهایی Work از طرف Company با Product Owner است.
در موارد نادر، Team و Product Owner میفهمند Sprint بسیار بد Plan شده یا Change جدیای رخ داده که تا پایان Sprint نمیتواند صبر کند. Product Owner Authority دارد Sprint را بشکند، Work را متوقف و همهٔ Sprint Backlog را به Product Backlog برگرداند. این باید فوقالعاده نادر باشد چون Trust سختساختهشده با User/Stakeholder را نابود میکند.
Visibility و Value
به Motivation خود در Work فکر کنید. چند بار چنین فکرهایی داشتهاید؟
- «کار با این Technology در Résumé من عالی است.»
- «اگر در این Project خودم را ثابت کنم Teamم بزرگتر میشود.»
- «اگر این Deadline بزرگ را بزنم Promotion میگیرم.»
- «اگر آن Client بزرگ را بگیرم Bonus بزرگی میگیرم.»
همه چنین فکرهایی داریم و اشکالی ندارد. Self-interest طبیعی است. اما Motivation فردی بهتنهایی بهترین راه متحدکردن Team نیست. وقتی افراد برای یک Goal مشترک کار میکنند بسیار بیشتر از مجموع توان فردی انجام میدهند. اگر هرکس منفعت شخصی را دغدغهٔ اصلی کند، خروجی جمعی کمتر میشود.
نمونهٔ آسیب Self-interest: Senior Developer کارهای کسلکننده یا آزاردهنده را روی Junior میاندازد. مثلاً Senior آنقدر سرگرم Feature جدید است که Bug Fix را عقب میاندازد و ترجیح میدهد Maintenance Team ارزانتر آن را Fix کند. بسیاری شرکتها عمداً «A Team» باتجربه برای New Feature و Maintenance Team کمتجربه برای Bug/Patch میسازند.
برای Senior با سبک «Fire and Forget» جذاب است؛ میداند Bug را دیگری Fix میکند. اما برای Team در بلندمدت بسیار Inefficient است. تقریباً همیشه کسی که Bug را Introduce کرده بهترین فرد برای Fix است: Code را میشناسد و Style خودش است. Handoff نیاز به Email/Documentation مثل Bug Report یا Spec Update دارد و فرد دوم باید Code را بفهمد. Bug چنددقیقهای برای Creator میتواند برای Junior ساعتها یا روزها طول بکشد.
در Scrum Team متعهد این «Push off grunt work» کمتر دیده میشود. Senior چند دقیقه Work کسلکننده را وقتی Context تازه است انجام میدهد بهجای اینکه Junior ساعتها بعداً صرف کند؛ همین میتواند منبع Hyper-productivity و نتایج شگفتانگیز Scrum باشد.
هر Teamی میتواند Rule منع Dump کردن Work بسازد، اما Team مؤثر Scrum به Rule جداگانه برای هر Situation نیاز ندارد، چون همه حس مالکیت واقعی نسبت به تمام Project دارند. برای Senior اصلاً Dump کردن Task به ذهن نمیآید؛ منطقی است خودش انجام دهد و آن Work همان لحظه مهمترین کارش است، درست مثل مثال CEO که برای Team قهوه میگرفت.¹¹ Bug Fix و Maintenance به Sprint Backlog میرود، Daily Scrum آن را Review میکند و فرد درست در زمان درست انجام میدهد؛ Last Responsible Moment احتمالاً همین الآن است چون Context هنوز در ذهن Developer تازه است.
در Team مؤثر، همه نهفقط Code خودشان، بلکه Backlog و Work کل Team را مالک میدانند. Sprint Backlog Commitment واقعیای است که حتی Junior احساس میکند به User داده است. همان Collective Commitment مورد نظر Ken Schwaber یعنی همه Owner Backlog هستند و شخصاً مسئول Deliver کردن Valuable Software کل Team، نه فقط Feature خودشان.
¹¹ کسی که در Scrum Team مؤثر کار کرده احتمالاً حتی خواندن ایدهٔ Seniorی که Task را روی دیگران «Dump» میکند برایش عجیب و ناراحتکننده است، چون چنین رفتار بیگانهای است.
Goalهای ارتقابخش همهٔ Team را انگیزه میدهند
آیا Volunteer Work کردهاید؟ به Open Source کمک کردهاید؟ عضو Club، Amateur Sports Team، Rock Band یا Choir شدهاید؟ آخرین بار چرا به Groupی خارج Work/Family پیوستید؟ چون به چیزی که آن Group برایش تشکیل شده اهمیت داشتید. اگر Voter Drive بود، Participation در Election مهم بود؛ اگر Soccer Team بود، Winning و خوب بازیکردن مهم بود. چرا Work متفاوت باشد؟
همه Self-motivated هستیم. حداقل برای Money کار میکنیم؛ اگر Salary قطع شود، حضور هم قطع میشود. Bill داریم و Family. Salary، Office امن و تمیز، Workable Hours و Basic Condition ما را پشت Desk میآورد. اما آیا برای اینکه واقعاً به Great Software اهمیت بدهیم کافی است؟
اگر در Team بیانگیزه کار کردهاید جواب «نه» است. بسیاری هرگز Team واقعاً Motivated ندیدهاند. اگر دیدهاید احتمالاً بهترین Experience شغلیتان بوده: افراد بیشتر Communicate میکنند، کمتر Argument دارند (و وقتی دارند Passionate و Productive است) و Work واقعاً Done میشود.
Team میتواند با Technology تازه، Domain جذاب، Promotion، Bonus یا Work from Home انگیزه بگیرد؛ یا با عامل منفی مثل ترس از Boss، Yelling، Loss of Money یا Job. اینها فرد را برای Self-interest فعال میکنند، نه Team را برای هدف مشترک.
Motivation مؤثر حول Elevating Goal است. Steve McConnell در Beautiful Teams مثال میزند: کندن خندق بهخودیخود الهامبخش نیست، اما اگر برای محافظت شهر در برابر حمله باشد همان Activity معنا پیدا میکند. کار Leader این است که Activity را طوری Frame کند که People Value آن را بفهمند.
تقریباً همهٔ Software توسط Team ساخته میشود. پس Motivation باید جمعی باشد. Delivering Value میتواند Elevating Goal قدرتمندی باشد. وقتی Team به Goal واقعاً باور دارد و آزادی تصمیم دربارهٔ نحوهٔ رسیدن و Risk-taking دارد، برای حل هر مانعی سخت کار میکند.
در Agile، Value معنای مشخص دارد: Software وقتی Valuable است که زندگی User را بهتر کند. جملهٔ «کار شما ۰٫۰۲۴٪ به Revenue سهماههٔ سوم اضافه کرد» برای بیشتر Developerها چندان انگیزهبخش نیست، حتی با Stock Option. اما «قبلاً هر روز سه ساعت Numberها را Sort میکردم، Software شما آنقدر خوب است که حالا ده دقیقه طول میکشد؛ ممنون!» بسیار انگیزهبخش است.
Developer—منظور همهٔ اعضای Agile Team، حتی Non-coderها—با Pride of Workmanship انگیزه میگیرد. میخواهیم Software مفید، دوستداشتنی، Efficient و Well-built باشد. به همین دلیل دربارهٔ Design، Architecture و Technology بحث میکنیم. بهترکردن زندگی User مستقیمترین شکل Delivering Value و یک Elevating Goal واقعی است.
اصل نخست Agile Manifesto دقیقاً همین را میگوید: «بالاترین اولویت ما رضایت Customer از طریق Early and Continuous Delivery of Valuable Software است.» این بالاترین Priority است چون Delivering Value مؤثرترین Motivation Team و نیروی محرک Sprint Planning خوب است.
چگونه Sprint مؤثر را Plan و Run کنیم
از Backlog شروع کنید، یعنی از User شروع کنید
چرا Feature خاصی را این Sprint Deliver میکنیم نه Sprint بعد؟ چون Team با هم فهمیده کدام Feature برای User بیشترین Value را دارد. Product Owner برای همین حیاتی است: User را میشناسد و Team را از نیازهای اصلی بهروز نگه میدارد.
دربارهٔ چیزی که میتوانید تحویل دهید واقعبین باشید
بعضی Managerها فکر میکنند اگر Developer را Push نکنند کمترین Work ممکن را Commit میکند و Deadline طولانی میگیرد. در بیشتر Teamها برعکس است: Developer تمایل به Over-optimism دارد؛ برای همین Late Project زیاد دیدهایم ولی Very Early Delivery کم. Feature بیش از حد در Sprint جا ندهید. User فقط تا Sprint بعدی صبر میکند. Scrum Master خوب در Estimate و تشخیص Capacity کمک میکند.
اگر لازم است Plan را تغییر دهید
Daily Scrum را برای فهمیدن اینکه همهٔ Sprint Commitment واقعاً تمام میشود استفاده کنید. اگر Plan باید Change کند، مسئولیت Team است. اگر همهٔ Sprint Backlog تمام نمیشود، Low-value Itemها را اول به Product Backlog برگردانید و Scrum Master مطمئن شود همه Change را فهمیدهاند. Userی که Frequent Working Software دیده، با Sprint Review ناقص کمتر Shock میشود، مخصوصاً اگر Product Owner Expectation را خوب Manage کرده باشد.
همه را دربارهٔ Value به گفتوگو بیندازید
Scrum Team مؤثر پر از افرادی است که Need واقعی User و Value را میفهمند. هرکس باید بداند Feature برای User چه میکند: Life را چطور آسانتر میکند؟ چه کاری را ممکن میکند؟ چقدر Time/Effort ذخیره میکند؟ اینها واقعاً برای Agile Developer مهماند. هرچه بیشتر دربارهشان حرف بزنید Software بهتر میشود.
نکات کلیدی Sprint Planning
- Scrum هم Incremental است چون Sprintهای پیاپی دارد و هم Iterative چون هر Sprint با Changeهای Project Adapt میشود.
- وقتی Scrum Team میگوید با Value انگیزه میگیرد، یعنی Goal اصلی ساخت Softwareی است که زندگی User را بهتر کند.
- Product Owner با کمک به فهم User، Work و Need او، Team را حول Value Motivated نگه میدارد.
پردهٔ چهارم: سگ به ماشین میرسد
صفحهٔ PDF 149
وقتی Roger و Avi خبر «Stakeholder Meeting from Hell» را برای Eric آوردند، نمیفهمیدند چرا Optimistic است. چند روز بعد هر سه زودتر از Work بیرون رفتند و در Restaurant نشستند.
Eric پرسید: «چرا فکر میکنید Account Managerها ناراحت شدند؟»
Roger جواب روشنی نداشت. گفت اینهمه برای Agile شدن کار کردهاند؛ در ذهن او یعنی Ability برای Adjust دائمی به Feature Request و ساخت Product جدید هر وقت لازم باشد. Avi هم حس میکرد کاملاً با Team «Plugged in» شده و Stream بزرگی از Ideaهای خوب Account Managerها را میآورد. هر دو فکر میکردند دقیقاً چیزی را تحویل دادهاند که Stakeholder خواسته. Avi گفت: «از تکتکشان Email دارم که همین چیزها را خواستهاند. چطور ممکن است ناراحت باشند؟»
Eric توضیح داد چرا بهعنوان Agile Coach از چیزی که میدید خوشحال است، حتی با وجود Trouble. قبلاً Team مثل Cruise Ship عظیمی بود که برای Turn کردن Miles دریایی میخواست؛ حالا مثل Fleet قایقهای تندرو هماهنگ بود. Communication بیشتری میخواست اما میتوانست فوراً جهت عوض کند. Avi هم از فردی Overwhelmed و کمی Antagonistic نسبت به Team به یک Team Member واقعی تبدیل شده بود.
تبدیلشدن به عضوی واقعی از تیم و مجرایی مؤثر میان تیم و کاربران
با کمک به تیم برای برقراری یک Daily Scrum مؤثر، راجر تیم را توانمند کرد تا پیرامون اولویتهای در حال تغییر، خودسازمانده (self-organizing) شود. اما مشکل تازهای پدیدار شد؛ اریک توضیح داد که بسیاری از تیمهایی که از مجموعهٔ نخست چالشهای خودسازماندهی عبور میکنند، با همین وضعیت روبهرو میشوند. تیمی که تازه خودسازمانده شده، اکنون قدرت دارد جهت حرکت خود را بسیار کارآمد تغییر دهد. و Product Owner که در دل چنین تیمی قرار گرفته، قدرت تعیین آن جهت را دارد.
اریک برای توضیح این وضعیت تشبیه خوبی آورد: آیا تا به حال تیم آتشنشانی را دیدهاید که تمرین میکند شلنگ آتشنشانی را نشانه بگیرد؟ هنگام خاموشکردن آتش فقط به نظر میرسد که شلنگ را به سوی شعلهها گرفتهاند، اما هفتهها یا ماهها تمرین کردهاند تا یاد بگیرند چگونه آن را بهطور مؤثر جابهجا کنند و چگونه با یکدیگر ارتباط برقرار کنند تا همگی در یک جهت حرکت کنند. تیم شما قبلاً شبیه یک شلنگ باغچه بود و حالا تبدیل به شلنگ آتشنشانی شده است. شبیه کارتونهایی که شخصیت داستان بهخاطر شلنگ مهارنشده به اطراف پرتاب میشود؛ شما دو نفر تقلا میکنید انتهای شلنگ را نگه دارید و آن را در جهت درست بگیرید. اکنون زمان آن است که یاد بگیرید چگونه با هم حرکت کنید و شلنگ را به سوی آتش بگیرید.
پرسشهای متداول
با وابستگی میان کارها در برنامهٔ پروژه چه کنم؟
همان کاری را انجام دهید که اکنون میکنید: با تیم صحبت کنید و تلاش کنید وابستگیها را کشف کنید.
این پرسش برای مدیر پروژهای که به رویکرد فرماندهی و کنترل (command-and-control)، «نیازمندیهای بزرگ از ابتدا» و ساخت نمودارهای گانت بزرگ در آغاز پروژه عادت دارد بسیار رایج است. ایدهٔ تیم خودسازمانده، که در آن هر عضو درست پیش از آغاز کار، وظیفهٔ بعدی خود را انتخاب میکند، ممکن است غیرواقعی به نظر برسد. دلیلش اغلب این است که مدیر پروژه زمان و انرژی زیادی صرف شناسایی تمام وابستگیهای بین وظایف میکند. حتی کتابهای مدیریت پروژه ــ از جمله کتابهایی که خود نویسندگان این کتاب نوشتهاند ــ بخشهایی برای توضیح انواع وابستگی مانند finish-start و start-start و روش شناسایی و ثبت آنها هنگام برنامهریزی اولیه دارند. بنابراین پرسش از اینکه این تحلیل وابستگی در تیم خودسازمانده کجا قرار میگیرد کاملاً منطقی است.
چرا مدیران پروژه در ابتدای پروژه به این وابستگیها نیاز دارند؟ چون باید کار پروژه را تعریف کنند، آن را به وظایف بشکنند، وظایف را توالیبندی کنند، منابع را تخصیص دهند و زمانبندی پروژه را بسازند. تنها راه انجام این توالیبندی، شناسایی وابستگیهای بین وظایف منفرد است.
فرض کنید عضوی از تیم روی وظیفهای در یک برنامهٔ بزرگ کار میکند و هنگام اجرای آن کشف میکند که به وظیفهٔ دیگری وابسته است. حالا وظایف پاییندستی برنامه همگی عقب میافتند، چون توالی وظایف آن وابستگی ناشناخته را در نظر نگرفته بود. نتیجه میتواند زنجیرهای از تأخیرها باشد؛ یکی از رایجترین علتهایی که برنامههای پروژه مجبور به تغییر میشوند. بدتر اینکه اگر تیم به سوی مهلتی ثابت حرکت کند، مدیر پروژه ناچار میشود تصمیمهای دشوار بگیرد و در اواخر پروژه دربارهٔ حذف بخشی از دامنه گفتوگوهای سختی داشته باشد. تعجبی ندارد که مدیران پروژه روی وابستگیها حساساند.
مشکل اینجاست که تحلیل ظاهراً کامل وابستگیها میتواند حس امنیت کاذب ایجاد کند. تیم تصور میکند ریسکها از قبل شناخته شدهاند و در طول اجرای پروژه کمتر به کشف وابستگیهای تازه توجه میکند. تیمهای خودسازمانده هم وابستگیها را کشف میکنند، اما معمولاً این کار را بهتر انجام میدهند. تفاوت در این است که آنها وابستگی را در «آخرین لحظهٔ مسئولانه» (last responsible moment) بررسی میکنند؛ زمانی که اطلاعات بسیار بهتری دربارهٔ وظایف دارند و میتوانند تحلیل کاملتری انجام دهند.
این در تئوری خوب است، اما در پروژهٔ واقعی هم واقعاً کار میکند؟
نمونهٔ فصل قبل را به یاد بیاورید: Daily Scrum ناکارآمدی که یک مدیر پروژهٔ فرماندهی و کنترل در آن هر روز وظیفهٔ تکتک اعضای تیم را تعیین میکرد. برای اینکه چنین مدیری بتواند وظایف را تخصیص دهد، باید پیش از جلسه تمام وابستگیها را بداند.
این را با تیمی واقعاً خودسازمانده مقایسه کنید. وقتی یک عضو وظیفهای را برای خودش انتخاب میکند، تمام تیم در جلسه آن تصمیم را میبیند و فعالانه به دنبال وابستگیها میگردد؛ نه فقط در همان جلسه، بلکه در جلسههای قبل و بعد نیز. یکی از دلایل وجود سؤال سوم Daily Scrum ــ موانع یا roadblockها ــ همین است. هر مانع میتواند یک وابستگی باشد و همهٔ اعضای تیم هر روز برای کشف این وابستگیها فکر میکنند. در نتیجه بسیاری از تأخیرهای زنجیرهای که پروژههای فرماندهی و کنترل با آن مواجه میشوند پیش از تبدیلشدن به بحران شناسایی میشوند.
چرا این روش جواب میدهد؟ وقتی مدیر پروژه در مرحلهٔ برنامهریزی تحلیل وابستگی انجام میدهد، یکی از ابزارهای اصلی او «قضاوت خبره» (expert judgment) است؛ اصطلاحی در مدیریت پروژه برای گفتوگو با تیم و اتکا به تخصص آنها برای آشکارکردن وابستگیها. یک تیم خودسازمانده نیز هر روز در Daily Scrum همین قضاوت خبره را به کار میگیرد، اما با اطلاعات بسیار بهتر، چون تحلیل را بهصورت جمعی و در حین پیشرفت واقعی پروژه انجام میدهد. این دید بیشتر و کیفیت بالاتر تحلیل «درستبهموقع» (just-in-time) وابستگیها یکی از منابع مهم بهرهوری در تیمهای Scrum مؤثر است.
با مفهوم «آخرین لحظهٔ مسئولانه» کمی راحت نیستم. آیا بهتر نیست از ابتدا برنامهریزی کنیم، حتی اگر بعداً برنامه عوض شود؟
مدیران پروژه معمولاً نقلقولی از دوایت دی. آیزنهاور، رئیسجمهور و ژنرال آمریکایی، را دوست دارند: در آمادهشدن برای نبرد، برنامهها را بیفایده دیدهام اما برنامهریزی را ضروری. نشستن با تیم و برنامهریزی پروژه باعث میشود همه دربارهٔ جزئیات کار و مشکلاتی که باید حل شوند فکر کنند. حتی اگر برآوردها کامل نباشند، پس از یک جلسهٔ برنامهریزی خوب، تیم پروژه را بهتر میشناسد و برای آن آمادهتر است. وقتی تغییر رخ میدهد، تیم میتواند آن را ببیند و از آن یاد بگیرد.
تیمی که در آخرین لحظهٔ مسئولانه برنامهریزی میکند همهٔ این مزایا و حتی بیشتر از آن را دارد. این رویکرد به معنی «هیچ برنامهریزی از قبل» نیست؛ برعکس، برنامهریزی اولیه برای موارد بزرگ انجام میشود، یعنی آیتمهای Product Backlog. Product Backlog شامل آیتمهایی است ــ اغلب User Story ــ که Product Owner و افراد غیر فنی سازمان نیز میتوانند بفهمند. پیش از شروع Sprint نخست، تیم و Product Owner باید دربارهٔ Sprint Backlog توافق کنند و برای این کار لازم است Product Backlog بزرگتری با برآوردهای Story Point داشته باشند. بنابراین Scrum نیز مقدار قابل توجهی برنامهریزی اولیه دارد؛ تفاوت در سطح جزئیات و زمان تصمیمگیری است.
یک نمونهٔ واقعی از Sprint Planning در Scrum میدهید؟
فرض کنید تیمی سنتی روی پروژهای با چند قابلیت جدید و همچنین تعدادی بهبود عملکرد (performance tweaks) کار میکند. در برنامهریزی سنتی معمولاً توسعهٔ قابلیتهای جدید زودتر انجام میشود و بهینهسازی عملکرد به انتهای پروژه میرود. برای توسعهدهنده هم ساخت قابلیت تازه معمولاً جذابتر است، در حالی که یافتن و برطرفکردن مشکل عملکرد میتواند دشوار و خستهکننده باشد.
اما اگر کاربران بهشدت از مشکل عملکرد آسیب میبینند چه؟ اگر کندی نرمافزار مانع انجام کارشان شده باشد و نرمافزار سریعتر بسیار بیشتر از قابلیتهای جدید زندگی کاری آنها را بهتر کند، تیم باید بهبود عملکرد را در اولویت نخست قرار دهد. Product Owner که هر هفته دربارهٔ ارزش آیتمهای backlog با تیم صحبت میکند، شانس بسیار بیشتری دارد که این اولویت واقعی کاربران را در کار تیم منعکس کند.
این مثال چه ارتباطی با تصمیمگیری در آخرین لحظهٔ مسئولانه دارد؟
اگر تمام برنامهریزی از ابتدا انجام شود، بهبودهای عملکرد فقط زمانی جلوتر از قابلیتهای جدید قرار میگیرند که تیم از روز اول بداند این موضوع برای کاربران اولویت دارد. اگر Product Owner عادت نکرده باشد دائماً دربارهٔ ارزش برای کاربران با تیم صحبت کند و تیم نیز عادت نکرده باشد به این بازخورد گوش دهد، وقتی وسط پروژه مشخص شود کاربران واقعاً به بهبود عملکرد نیاز دارند، مدیر پروژه و تیم احتمالاً مقاومت میکنند؛ چون تغییر، برنامه را بههم میریزد. شاید حتی در خلوت شکایت کنند که «کسبوکار همیشه نظرش را عوض میکند» و آرزو کنند پروژهای داشته باشند که تغییر کمتری در آن رخ دهد.
تغییر در نهایت انجام خواهد شد، اما برای چنین تیمی بسیار پرهزینهتر است و پروژه را متلاطم میکند. واقعیت این است که تقریباً همهٔ گروههای کاربری با مسائل و اولویتهایی مواجهاند که در طول زمان تغییر میکنند. تغییر استثنا نیست؛ بخشی از کسبوکار و زندگی است. به همین دلیل تیمهای Agile از عبارت «پذیرفتن تغییر» (embrace change) استفاده میکنند.
ذهنیت خشک «همهچیز را از ابتدا برنامهریزی کنیم» تغییر را به مذاکرهای میان تیم و Product Owner تبدیل میکند؛ در حالی که Agile همکاری با مشتری (customer collaboration) را بر مذاکرهٔ قراردادی (contract negotiation) ترجیح میدهد. در مذاکره معمولاً یک نفر میبرد، دیگری میبازد و همه مجبور به مصالحه میشوند. این روش کارآمدی برای ادارهٔ پروژه نیست و بهرهوری زیادی را هدر میدهد.
در مقابل، با نگرش همکاری با مشتری همه با یکدیگر کار میکنند و همه برندهاند، چون محدودیتهایی را که باید مشترکاً با آنها کنار بیایند طبیعی میپذیرند. برنامهریزی در آخرین لحظهٔ مسئولانه این نگرش را تقویت میکند، زیرا مانع ایجاد محدودیتهای خودسرانهای میشود که بعداً مجبور شوید پیرامون آنها مذاکره کنید. تیم برای تغییر باز میماند و میتواند کار را در حین حرکت برای رسیدن به هدفهای متغیر دوباره مرتب کند؛ بهجای اینکه صرفاً «برنامه را بنویسد و بعد بدون انعطاف همان را اجرا کند». این رویکرد همچنین تعامل دائمی Product Owner با تیم دربارهٔ هدفها را آسانتر میکند.
کارهایی که همین امروز میتوانید انجام دهید
- اگر تیم شما هماکنون جلسهٔ standup روزانه دارد، از همه بخواهید سه سؤال Daily Scrum را پاسخ دهند.
- اگر تیم standup روزانه ندارد، بررسی کنید آیا میتوانید یکی را آغاز کنید.
- با تیم دربارهٔ آخرین لحظهٔ مسئولانه گفتوگو کنید. فهرستی از تصمیمهایی بنویسید که احتمالاً چون بیش از حد زود گرفته شدهاند، دوباره باید به آنها برگردید.
- دربارهٔ آیتمهایی که ممکن است در Product Backlog قرار گیرند صحبت کنید. چه کارهایی را میدانید که هنوز انجام نمیدهید؟ آیا میتوانید فهرستی از آنها تهیه کنید؟
برای مطالعهٔ بیشتر
- برای آشنایی بیشتر با تیمهای خودسازمانده و مدیریت پروژه با Scrum، کتاب Agile Project Management with Scrum نوشتهٔ Ken Schwaber، انتشارات Microsoft Press، سال 2004.
- برای برنامهریزی پروژهٔ Scrum، کتاب Agile Estimating and Planning نوشتهٔ Mike Cohn، انتشارات Addison-Wesley، سال 2005.
- برای قواعد Scrum، The Scrum Guide نوشتهٔ Sutherland و Schwaber، سال 2011، که در Scrum.org منتشر شده است.
نکتههایی برای مربیان Agile
- یکی از دشوارترین بخشهای پذیرش Scrum، یافتن Product Owner مناسب است. اگر تیمی میخواهد Scrum را بپذیرد، کمک کنید فردی را پیدا کند که هم اختیار و هم تمایل تصمیمگیری از طرف کسبوکار را داشته باشد.
- بسیاری از مربیان Agile میبینند تیمهای Scrum فقط یکی از اعضای تیم را بهعنوان Product Owner انتخاب کردهاند. روشن کنید که Product Owner باید اختیار پذیرش قابلیتها از طرف کسبوکار را داشته باشد.
- اگر تیم جلسهای روزانه دارد که نامش را Daily Scrum گذاشته، اما در عمل فقط status meeting است، این فرصت خوبی برای آموزش تفاوت فرماندهی و کنترل با خودسازماندهی است.
- به Scrum Master کمک کنید بفهمد مسئول او این نیست که هر روز به هر عضو بگوید چه کاری انجام دهد یا بررسی کند که آن کار انجام شده یا نه. نقش Scrum Master تضمین رعایت قواعد Scrum و برداشتن impedimentهایی است که مانع اجرای آن میشوند.