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

Refinement یک جلسه ضروری برای کل تیم اسکرام است.

آیا «Product Backlog refinement» یک رویداد تکراری در برنامه اسپرینت شماست که در یک روز ثابت در طول اسپرینت اتفاق می‌افتد؟ آیا توسعه دهندگان تیم به سختی و با بی حوصلگی خود را به این جلسه می رسانند و اکثر افراد (تظاهر می‌کنند) که گوش می دهند؟ اگر چنین است، پس این مقاله برای شماست.

Product Backlog refinement مطمئناً بخشی ضروری از چارچوب اسکرام است. اما بیشتر اوقات، به شکل تیمی است که به صورت منفعل دور میز جلسه می نشیند در حالی که فقط بعضی از افراد تیم در مورد موارد آینده با جزئیات دردناک بحث می کنند. وقتی refinement به این صورت برگزار می شود، قابل درک است که تیم‌ها سعی می‌کنند تا حد امکان زمان کمتری را صرف آن کنند – که یکی از دلایل کلیدی مانع از عالی شدن تیم‌های اسکرام است.

در این مقاله، ما افسانه‌ای را از بین می‌بریم که باعث میشود که این فعالیت برای بسیاری از تیم‌های اسکرام کار سختی به نظر برسد: این باور که «Product Backlog refinement» باید به‌عنوان یک یا چند «جلسه» ضروری انجام شود که باید همه در آن شرکت کنند. همچنین برخی از رویکردهای جایگزین را ارائه می دهیم که به طور طبیعی با “روند توسعه” مطابقت دارند.

راهنمای اسکرام چه می گوید؟

راهنمای اسکرام Product Backlog refinement را به عنوان فعالیتی برای اضافه کردن جزئیات، تخمین ها و موارد سفارش در Product Backlog توصیف می کند. همچنین در ادامه توضیح می دهد که این یک همکاری مداوم بین مالک محصول و تیم توسعه است و تیم اسکرام به عنوان یک واحد تصمیم می گیرد که چگونه و چه زمانی کارها را انجام دهد.

راهنمای اسکرام پنج جلسه ضروری با زمان بندی مشخص را در طول اسپرینت (شامل خود اسپرینت) مشخص می کند: Sprint Planning در شروع اسپرینت برای انتخاب آنچه تیم روی آن کار خواهد کرد، Daily Scrum برای همگام‌سازی کار هر 24 ساعت، و Sprint Review و Sprint Retrospective در پایان اسپرینت برای بررسی نتایج حاصل از اسپرینت و نحوه همکاری تیم در طول اسپرینت. رویداد پنجم خود اسپرینت است.

بنابراین کاملاً واضح است که refinement یک رویداد در اسکرام نیست. ممکن است این جمله بازی با کلمات به نظر برسد. اما تأثیر قابل توجهی بر نحوه انجام آن در دنیای واقعی دارد. راهنمای اسکرام تاکید می کند که Product Backlog refinement کاری است که تیم های توسعه به عنوان بخشی طبیعی از توسعه انجام می دهند. این چیزی نیست که لزوماً در یک زمان ثابت در طول اسپرینت و با حضور کل تیم اسکرام اتفاق بیفتد. با این حال، گاهی اوقات این تمایز ظریف از بین می رود و یکی از دلایلی است که Product Backlog refinement برای بسیاری از تیم های اسکرام به یک کار طاقت فرسا تبدیل شده است.

قبل از پرداختن به گزینه‌های جایگزین، اجازه دهید ابتدا هدف Product Backlog refinement را با جزئیات بیشتری بررسی کنیم.

هدف Product Backlog refinement در اسکرام

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

Product Backlog تمام کارهای مورد نیاز شناخته شده برای محصول را نشان می دهد. برخی از موارد به اندازه کافی کوچک و واضح هستند و در یک اسپرینت کامل می شوند. در حالی که موارد دیگر خیلی بزرگ و یا خیلی نامشخص هستند. برای به حداکثر رساندن یادگیری (مثلاً از بازخورد ذینفعان و یا صرفاً با انجام کار) و برای کاهش خطر ساخت محصول اشتباه، می‌خواهیم موارد را تا جایی تجزیه و شفاف کنیم که نسبتاً مطمئن باشیم که می‌توانیم آنها را در یک اسپرینت کامل کنیم.

شاید وسوسه شوید که تمام کارهای مربوط به Product Backlog را برای جا شدن آن در یک اسپرینت تجزیه کنید. اما یک استفاده بسیار بهتر از زمان،  این است که فقط مواردی را که قرار است کار روی آنها را شروع کنیم، تجزیه و شفاف سازی کنیم (مثلاً اسپرینت بعدی). زمان صرف شده برای تحلیل و شفاف سازی مواردی که اولویت بالایی در Product Backlog ندارند تا حد زیادی اتلاف منابع است، زیرا ما ملزم به یادگیری چیزهایی هستیم که دیدگاه ما را در مورد نحوه اجرای کار تغییر می‌دهد.

به عنوان یک فعالیت، Product Backlog refinement اهداف زیر را در اسکرام دنبال می کند:

• شفاف کردن موارد موجود در Product Backlog که برای شروع کار بسیار نامشخص هستند. ترجیحاً این کار را همراه با افرادی که آیتم ها را برای آنها می سازید (ذینفعان) انجام دهید.
• شکستن مواردی که خیلی بزرگ هستند و نمی‌توان آن‌ها را در یک اسپرینت انجام داد. (که معمولاً به این معنی است که آنها خیلی نامشخص هستند).
• اولویت بندی مجدد Product Backlog در صورت نیاز برای اینکه اسپرینت های آتی تا حد امکان روان و ارزشمند شوند.
• افزودن یا حذف اقلام از Product Backlog با ظهور بینش های جدید
• تخمین تلاش مورد نیاز برای اجرای موارد خاص. این مورد نباید به اندازه اختصاص دادن Story Point (یک روش اختیاری در اسکرام) که استفاده می‌کنید «رسمی» باشد. داشتن حس درونی (“بله، ما به اندازه کافی می دانیم که چه کاری باید انجام شود و در یک اسپرینت انجام پذیر است”) نیز خوب است.

موارد موجود در Product Backlog اساساً یادآور «مکالماتی هستند که در آینده باید داشته باشیم». refinement به معنای انجام مداوم آن مکالمات است. گاهی اوقات به معنای صحبت با ذینفعان در مورد برخی از موارد است که ممکن است بخشی از Sprint بعدی باشد، در حالی که در مواقع دیگر می تواند موردی باشد که بخشی از Sprint فعلی است. اما برای بسیاری از تیم ها جلسات رسمی که (فقط) در طول اسپرینت برگزار می شود، جای این مکالمات که به طور طبیعی از توسعه ناشی می شود را گرفته است.

الگوی همگرایی-واگرایی را امتحان کنید

در بسیاری از سازمان‌ها، “جلسات” به استانداردی برای تبادل اطلاعات در تیم‌ها و تصمیم‌گیری تبدیل شده‌اند. در یک جلسه، تا جایی که می‌توانیم ذهن‌ها را برای مدت زمان معینی در اتاق متمرکز می کنیم تا به یک هدف برسیم. فرض این است که این بهترین (یا حتی تنها) راه برای استفاده از خرد و خلاقیت تیم ها و به اشتراک گذاشتن دانش است. با این حال:

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

ما معتقدیم که بسیاری از تیم ها می توانند از الگوی واگرایی-همگرایی بهره مند شوند. به عنوان یک تیم، تصمیم بگیرید که کدام موارد نیاز به شفاف سازی یا تفکیک دارند و چه کسی می خواهد/نیاز دارد که درگیر این موضوع شود. سپس گروه‌های کوچک‌تر این کار را در طول اسپرینت یا در طول «Breakout ها» (واگرایی) انجام می‌دهند و نتایج خود را در بعدآ در طول اسپرینت با تیم اسکرام به اشتراک می‌گذارند تا در مورد مراحل بعدی با هم تصمیم بگیرند (همگرایی). سایر فعالیت‌ها، مانند تخمین یا اولویت بندی مجدد Product Backlog را می‌توان با هم بر اساس آنچه در طی refinement آموخته ایم، انجام داد. چرخه های چندگانه واگرایی-همگرایی بسته به پیچیدگی چیزی که باید Refine شود، می تواند در طول یک اسپرینت اتفاق بیفتد.

هر کاری که انجام می دهید، مطمئن شوید که refinement یک تلاش جمعی تیم است. اگرچه همه مجبور نیستند همزمان این کار را انجام دهند، اما همه باید درگیر آن باشند. اینکه فقط تحلیلگران یا توسعه دهندگان به Refine بپردازند، یک ضدالگوی قوی است زیرا نمی توان از خرد کل تیم استفاده کند.

نکات بیشتر برای refine متفاوت

به جای صرف ساعت‌ها دور یک میز، refinement فرصتی عالی برای اسکرام مستر است تا به تیم کمک کند راه‌های مختلفی برای انجام این کار پیدا کند:

• از تیم اسکرام دعوت کنید تا گروه های کوچکتری را تشکیل دهند که مسئولیت Refine موارد خاص را در طول اسپرینت آتی را بر عهده گیرند. اجازه دهید آنها تصمیم بگیرند که چگونه و چه زمانی این کار را انجام دهند و در صورت لزوم با مالک محصول و ذینفعان همکاری کنند. همچنین زمانی را برای به اشتراک گذاشتن ایده ها و بینش هایشان با تیم اسکرام و جمع آوری بازخورد را برنامه ریزی کنید.
• از ابزارهایی (مانند JIRA) در طول refinement استفاده نکنید. انتظار افراد تیم برای وارد کردن جزئیات جدید توسط یک نفر در جیرا باعث می شود تا انرژی و خلاقیت زیادی هدر رود. در عوض، کار را حتی با نقاشی کشیدن Refine کنید و از تیم بخواهید که بعداً آن را وارد ابزار کند. اگر واقعاً نیاز به استفاده از ابزار در حین Refine دارید، مطمئن شوید که همه به آن دسترسی دارند و می توانند به طور مشترک در آن کار کنند.
• ساختارهای رهایی بخش یا سایر تکنیک های تسهیل کننده را ترکیب کنید تا جلسات refinement خسته کننده را به جلسات بسیار تعاملی تبدیل کنید که در آن همه به طور کامل درگیر بحث شوند. اگر موارد چالش برانگیز را تجزیه می کنید، افراد را دعوت کنید تا مشکل را ترسیم کنند. از 1-2-4-ALL برای شناسایی سریع استراتژی های بالقوه یا مشاوره Troika برای ارائه و دریافت کمک استفاده کنید. از استراتژی های دیگر مانند 10 استراتژی بالقوه برای تجزیه کار استفاده کنید.
• از ذینفعان دعوت کنید تا در صورت نیاز در refinement شرکت کنند. برای روشن شدن کارهای آینده و ساختن محصول مناسب، مطمئناً به دیدگاه و دانش آنها نیاز خواهید داشت.
• از اعضای تیم دعوت کنید تا خودشان تصمیم بگیرند که آیا می‌خواهند به جلساتی بپیوندند که هدف آنها تجزیه موارد خاص است. از آنها بخواهید تعیین کنند که آیا می توانند در گفتگو مشارکت داشته باشند یا خیر. اگر این روش منجر به عدم حضور کسی شد، موضوع خوبی برای Sprint Retrospective آینده دارید.
• آنچه برای تیم شما مفید است را آزمایش کنید. برای برخی از تیم ها، انجام refinement با هم بهترین راه است. برای دیگران، راه حل های بالا ممکن است مفیدتر باشد. این بستگی به اندازه و بلوغ تیم و اعضای آن و پیچیدگی دامنه دارد.
• هنگام استفاده از Product Backlog فیزیکی ، به راحتی می‌توانید اطلاعات مرتبط با Refine را اضافه کنید. به عنوان مثال: برچسب هایی با علامت سوال به مواردی که نیاز به توضیح دارند اضافه کنید. یا روی مواردی که ممکن است ریسک داشته باشند یا موارد مهمی برای اصلاح هستند، علامت تعجب بنویسید.
• به جای انجام refinement در طول جلسه، بیرون از محل کار پیاده روی کنید و از پیاده روی خود برای تجزیه کار با کل تیم یا افراد تیم خود استفاده کنید.

در پایان

در این مقاله ما این افسانه را از بین بردیم که Product Backlog refinement باید به عنوان یک یا چند “جلسه” ضروری انجام شود که باید همه اعضای تیم در آن شرکت کنند. ما هدف از refinement را در اسکرام بررسی کردیم، رویکردهای جایگزین برای انجام refinement را ارائه کردیم و نکاتی را برای افزایش اثربخشی مرور کردیم.

نظر شما در مورد این افسانه چیست؟ با خیال راحت هر ایده دیگری برای بهبود refinement دارید را به اشتراک بگذارید، ما همیشه مشتاقیم از شما نیز یاد بگیریم!

منبع: https://www.scrum.org/resources/blog/myth-14-refinement-required-meeting-entire-scrum-team

مترجم: امیر دوراندیش