جلسه ریفاینمنت یک جلسه کلیدی در اسکرام است. این جلسه کمک می‌کند با مشارکت اعضای تیم، به تعریف بهتری از مسئله حال حاضر دست یابیم. جلسه‌های ریفاینمنت معمولا یکی از این سه نوع هستند:
1- قبل از شروع پروژه یا در مراحل ابتدایی برای تعریف مفاهیم اولیه، این جلسه تشکیل می‌شود.
2- در داخل یک اسپرینت و به طور منظم این جلسه تشکیل می‌شود تا آنچه باید انجام شود مشخص شود.
3- جلساتی که به طور پراکنده در داخل اسپرینت برگزار می‌شوند.
در ادامه این مطلب بیشتر به تشریح موضوع در دو نوع 2 و3 می‌پردازیم.
بعضی از اوقات خیلی از تیم‌های اسکرامی مطرح می کنند که زمانی برای تعریف این جلسه کلیدی ندارند، چون تمرکز تیم روی انجام کارهای روزانه است. در نتیجه تا زمانی که با مساله ی جدیدی درگیر شوند به آن فکر نکرده‌اند و وقتی می‌خواهند روی مساله‌ای که تعریف واضحی از آن وجود ندارد کار کنند با ابهام و پیچیدگی روبرو می‌شوند و در مواردی بدون اینکه مساله شفاف شده باشد شروع به انتخاب و اعمال راه حلی می‌کنند که به نظر خودشان درست است و نتیجه‌ی این کار می‌تواند ناخوشایند باشد. این مساله معمولا در تیم‌هایی به وجود می‌آید که مالک محصول کم‌تجربه تری دارند، سازمان‌هایی که دانش کمتری در خصوص چابکی دارند و یا سازمان‌هایی که به صورت همگن چابک نیستند. (بخشی از سازمان به شکل سنتی و بخشی به شکل چابک کار می‌کند.)
بعضی از مواقع، علت نپرداختن به موضوع ریفاینمنت، عجله برای تولید و تحویل محصول از سمت خود تیم است و در سایر موارد، این فشار از جانب مالک محصول یا سایر ذینفعان است. نکته‌ی خوبی که در اینجا کمک می‌کند این است که منبع این سیگنال‌ها که به تیم می‌رسد را پیدا کنیم. این موضوع به انتخاب راه‌حل مناسب کمک می‌کند.
- ریفایمنت به شکل دوره‌ای
وقتی در فواصل منظم زمانی جلسه ریفاینمنت را برگزار می‌کنیم، سعی می‌کنیم مساله ارایه شده را مجدد تحلیل کنیم و مطمئن شویم مشتری چه می‌خواهد، چطور باید برای حل مساله تلاش کنیم و چه زمانی این مساله حل شده فرض می‌شود. نکته مهم این است که در این جلسه در مورد حل مساله از نظر فنی بحث نمی‌کنیم. حل مساله فنی به تیم و همان زمان اجرا محول خواهد شد.
در پاسخ به این سوال که چه تعداد جلسه دیفاینمنت باید داشت و ساختار آن چیست (مثال خودم با توجه به تجربه‌ای که دارم را می‌زنم)، خوب است موارد زیر را مد نظر قرار دهیم:
- اگر مالک محصول جدید است یا تیم تجربه اسکرامی کمی دارد 3 جلسه حداکثر 45 دقیقه‌ای در هفته احتمالا مناسب است.
- اگر مالک محصول و تیم با تجربه هستند و به اندازه معقولی روی یک محصول کارکرده‌اند و دارای مهارت‌های فنی هستند (مثل نوشتن کدهای استاندارد، TDD ، ATTD ، روابط درون تیمی خوب و ...) 2 جلسه 30 دقیقه‌ای در هفته احتمالا کافی است.
مهم است که در نظر داشته باشید ریفاینمنت یک زمان خاص مختص به تیم است که در آن تیم گرد هم می‌آیند تا روی یک مساله تمرکز کنند. مالک محصول بعد از اتمام جلسه، در ادامه روز یا هفته باید به بازنگری و پالایش بک لاگ بپردازد.
حالا فکر کنید یک اتاق جلسه برای ریفاینمنت رزرو کرده‌اید. (خیلی از شرکت‌ها مشکل اتاق و تجهیزات برای شروع جلسات اسکرام دارند.) و همه برای شروع جلسه آماده هستید.
- در جلسه اول باید چه اتفاقی بیفتد؟
اولین قدم این است که تیم اصول خودش برای اداره جلسه را مشخص کند. اینکه چه چیزهایی در جلسه پذیرفته می‌شود یا نمی‌شود. (مثلا همراه داشتن تلفن همراه یا رایانه مگر در مواقع ضروری، همراهی با هم، حضور به موقع و ...)
همچنین توصیه می‌شود روی یک پیش نویس برای تعریف "آماده کار بودن" (Definition of Ready) کار کنید.
هیچ کس نمی‌خواهد یک داستان کاربری (user story) چند دقیقه قبل از برنامه ریزی (planning)و بدون آمادگی و خبر قبلی ظاهر شود. این امر باعث کاهش روحیه تیم و از بین رفتن اعتماد به نفس می‌شود و اثرات نامطلوبی را در کوتاه مدت و میان مدت می‌گذارد.
چند مثال از DOR :
- داستان کاربری به خوبی تعریف شده است.
- معیارهای پذیرش شفاف و مورد توافق همه تیم است.
- وابستگی‌های شدید همانند ریسک‌ها شناسایی شده‌اند.
- تیم ایده‌های خیلی خوبی در مورد تجربه کاربری فعلی و تجربه کاربری مطلوب دارد.
- یک داستان کاربری اندازه مشخصی دارد.
- تیم احساس می‌کند برای حل مساله‌ای که مشتری دارد تلاش می‌کند.
- حداقل 2 ریفاینمنت قبل از جلسه‌ی برنامه‌ریزی اسپرینت انجام شده است. (اختیاری)
- داستان کاربری دارای یک امتیاز ارزش کسب و کار (Business Value Points)است. مشخص است که یک یوز استوری چقدر و چرا برای شرکت ارزش ایجاد می‌کند.
دقت کنید استوری ساده شده و اندازه آن بیشتر از 5 یا 6 پوینت نباشد و روی بهبود و ساده‌تر شدن هم در فواصل زمانی مشخص کارکنید.
در بقیه جلسات چه اتفاقی می‌افتد؟
در جلسات بعدی مالک محصول باید داستان‌های کاربری یا ایده‌هایی در مورد اینکه چه مشکلاتی باید حل شوند، چه چیزی به کاربر آسیب می‌زند و چطور می‌تواند کاربر را خوشحال‌تر کند ارائه دهد. در تجربه من همیشه رویکرد خوب این است که مالک محصول همه داستان‌های کاربری را روی پست‌ایت داشته باشد و آنها را روی دیوار نصب کند. استفاده از ابزارها (مثل ترلو، جیرا و .. ) ممکن است باعث آسیب رساندن به تعاملات اجتماعی اعضای تیم شود. یک پست‌ایت را می‌توان جابجا کرد، زیر آن خط کشید، پاره کرد و .... و چون دارای اندازه مشخص برای نوشتن است شما را مجبور می‌کند " اصل" یا سادگی چیزی را که می‌خواهید حل کنید حفظ کنید.
وجود اسکرام مستر در اینجا ضروری است زیرا او از قبل برای تسهیل جلسه و اطمینان از اینکه مالک محصول همه چیزهای لازم را دارد و دستورالعمل‌هایی برای اینکه همه آنچه انتظار می‌رود را به جلسه بیاورد، آمادگی دارد.
مهم است که برای گفتگو در مورد هر داستان کاربری یک محدوده زمانی مشخصی تعیین شود و تیم به ترتیب سراغ موارد بعدی برود. تنها در این صورت است که می‌توانیم تضمین کنیم که تیم در سیاهچاله مربوط به یک داستان کاربری نمی‌افتد. وظیفه‌ی اسکرام مستر این است که هم مراقبت از زمان هم مشارکت اعضای تیم را مدیریت کند.
خیلی متداول است که اعضای یک تیم که در گذشته رهبر فنی تیم بوده‌اند، بیشتر در تصمیم‌گیری‌ها مشارکت و تاثیرگذاری داشته باشند. در این موارد می‌توانیم جهت ایجاد تعادل از نقشه تعاملی برای متعادل کردن گفتگوها استفاده کنیم.
باید توجه داشته باشیم اعضا در اینجا نباید روی جزییات فنی تمرکز کنند، بلکه باید روی مشکلی که حل می‌شود و یا فرضیه و سفر کاربر خاص تمرکز داشته باشند.
اگر داستان کاربری با DOR تعریف شده مطابقت داشته باشد، تیم باید در فواصل زمانی منظم تجزیه و تحلیل کند و در غیر این صورت باید ببیند که چه اقداماتی برای بهبود آن لازم است.
در طول فرایند توصیه می‌شود یک سایز مشخص به داستان اختصاص دهید. اینجا triangulation techniquesکه توسط اسکرام مسترها استفاده می‌شود گزینه‌ای عالی است. این یک تمرین ساده برای انتخاب داستان کاربری مرجع و مشخص کردن اندازه آن است. داستانی که برای کل تیم واضح باشد و خیلی کوچک یا خیلی بزرگ نباشد. (متناسب با آن به سایر داستان‌های کاربری اندازه اختصاص داده می‌شود.) استوری پوینت یا سایز (S.M.L.XL) .
در تیم‌های با تجربه‌تر ممکن است تعیین اندازه ضروری نباشد اما به یاد داشته باشید این ایده خوبی است که هر داستان کاربری دارای امتیاز ارزش کسب و کار باشد.
مثال:
سایز 8، ارزش تجاری 400
به عنوان یک مشتری Autoparking می‌خواهم بتوانم هزینه‌ی پارکینگ را بدون نیاز به پیاده شدن پرداخت کنم. تا هر روز از زمان خودم حداکثر استفاده را ببرم.
ملاک پذیرش:
حداقل 10 درصد از کاربران را پوشش دهد.
پرداخت کمتر از 10 ثانیه انجام شود.
مشتری بتواند زمان باقی مانده را بداند.
لازم است به یاد داشته باشیم که ما در اینجا در مورد انجام کار از نظر فنی صحبت نمی‌کنیم. بلکه تمرکز بر تلاش برای تعیین اعتبار مساله یا فرضیه یا آنچه می‌خواهید حل کنید و وابستگی‌ها و ریسک‌های سطح بالای آن است.
وابستگی‌ها را می‌توان روی هر کارت مستند کرد یا حتی اگر بین دو یا چند مورد از استوری‌ها باشد می‌توان از یک نخ برای گره زدن آنها، فلش‌ها یا هر تکنیک دیگری که برای اعضا منطقی است استفاده کرد.
چند نمونه از وابستگی‌های سطح بالا عبارتند از:
- برای تایید داستان کاربری باید با افراد تماس گرفته شود.
- دانش کسب و کار در حال حاضر در دسترس نیست.
- دانش فنی در حال حاضر در دسترس نیست.
- برخی از اطلاعات از دست رفته است.
- بعضی از داستان‌های کاربری به تیم‌های دیگر بستگی دارد.
معمولا تیم‌های نرم‌افزاری برای حل مساله (چگونگی) شروع به تلاش می‌کنند. (مثلا در طول جلسه مطرح می‌شود: ببینید باید از جاوا اسکریبپت، سرور، موبایل و ... استفاده کرد.) مهم است درک کنید به این موضوعات باید بعدا پرداخته شود. پرداختن به راه‌حل فنی در اینجا در اغلب موارد باعث عدم تمرکز و منجر به انعطاف کمتر در رسیدن به راه حل می‌شود.
بسیاری از شرکت‌ها اصطلاح Technical User Story را ایجاد می‌کنند که بتوانند در طول ریفایمنت درباره کارهای فنی /غیرعملکردی صحبت کنند. این اصطلاح وجود ندارد. باید اسمش را کار فنی گذاشت و وقت انجام آن هم الان نیست. هدف ریفاینمنت، همسو کردن تیم با مساله/فرضیه و دانستن ریشه اصلی مساله است. دیدن وابستگی‌ها و ایجاد فضایی برای تمرکز روی راه‌حل و گفتگوهای مناسب.
در طول جلسه بسیاری از داستان‌های کاربری یک به یک خوانده می‌شود و از اعضای تیم انتظار می‌رود در مورد اینکه آیا آنها را درک می‌کنند، خوب نوشته شده است، از نظر محدوده مشخص است و ... نظر دهند.
حتی ممکن است از متخصصان کسب و کار دعوت شود تا سوال بپرسند یا اطلاعات مرتبطی ارائه دهند. اگر تیم جدید است ممکن است در این مرحله به یک مربی فردی با مهارت نوشتن داستان کاربری نیاز داشته باشد.
یک مدل دیگر که در هنگام ریفاینمنت ممکن است استفاده شود Spikes است. این مدل شامل کارهای تحقیقاتی است که در آن نتیجه اطلاعات یا دانش برای تصمیم‌گیری ایجاد می‌شود، اما نباید آن را با پیاده سازی فنی که شامل حل مسائل تکنیکی است اشتباه گرفت.
- دانستن تعداد افرادی که اگر Xوجود نداشته باشد تحت تاثیر قرار می‌گیرند.
- دانستن اینکه این امکان وجود دارد JQuery در نرم افزار پارکینگ استفاده شود.
اینها هم بخشی از ریفاینمنت هستند. توصیه می‌شود معیار پذیرش داشته باشند و دقت کنید در طول اسپرینت حل وظایف Spikes نباید بیشتر از 4 تا 6 ساعت زمان بگیرد.
بعد از پایان جلسه مالک محصول یادداشت برداری می‌کند، مراحل قبلی در جلسه بعدی تکرار می‌شوند، همچنین برای بهبود مستمر می‌توان در فواصل منظم از شرکت کنندگان بازخورد گرفت. به یادداشته باشید کل تیم صاحب جلسه ریفاینمنت است و نه یک فرد خارجی.
- ریفاینمنت پراکنده محصول
بسیاری از تیم‌ها می‌پرسند پس کی مسائل فنی مورد بحث قرار می‌گیرد؟
این موضوع ممکن است گاهی اوقات تیم توسعه را عصبانی کند. بعضی از متخصصان پیشنهاد می‌کنند این کار در جلسه برنامه ریزی اسپرینت انجام شود. اما این ایده خوبی نیست. به نظر من ریفاینمنت های‌فنی هم ضروری هستند و باید همیشه به آنها زمان اختصاص داد. ایده این است که اعضای تیم به طور اتفاقی/ غیررسمی و روزانه شروع به صحبت در مورد راه‌حل‌ها و مشکلات و مسائل احتمالی کنند.
این همان چیزی است که آن را گفتگوی حیاتی می‌نامیم که به دور از برنامه‌ریزی ساختار یافته صورت می‌گیرد.
- پیتر: جان استوری X را دیده‌ای؟ من فکر می‌کنم جاوا اسکریپت جایگزین خوبی است، اگر از آن در برنامه پارکینگ موبایل استفاده می‌کردم این همه مشکلات وجود نداشت.
- جیم: درسته اما ما تا حالا از اون استفاده نکردیم. البته یادم اومد که الفونسو قبلا ازش استفاده کرده و تجربه زیادی داره، امروز عصر می‌تونیم باهاش صحبت کنیم و اگر اینطور باشه حجم کار کم می‌شه و اندازه استوری کوچک‌تر می‌شه.
- پدرو: عالی! بیایید این کار رو انجام بدیم و بعد با تیم صحبت کنیم.
این نوع ریفاینمنت که روی How صحبت می‌کند باید روزانه وجود داشته باشد. این گفتگو به مکالمه‌ای تبدیل می‌شود که امکان هماهنگ کردن و ارتباط اعضا با یک ایده یا فرضیه و راه‌حل‌‌های احتمالی و همچنین محدودیت‌های دانش یا فن‌آوری و سایر ریسک‌ها را فراهم می‌کند. همینطور این موضوع می‌تواند به مکالمه‌ای با سایر بخش‌های شرکت، معماری‌های متفاوت و ... تبدیل شود. پس تیم می‌تواند یافته‌های خود را در جلسه ریفاینمنت به صورت برنامه‌ریزی شده ارائه دهد.
وقتی زمان و جلسه‌ای برای این نوع ریفاینمنت‌های پراکنده وجود نداشته باشد، تیم سعی می‌کند در طول جلسه ریفاینمنت یا در جلسه برنامه‌ریزی اسپرینت در مورد مباحث فنی صحبت کند که این مسئله جلسه را طولانی و بدون پایان می‌کند.
در نهایت اگر بیش از یک تیم روی یک محصول کار کنند (مقیاس پذیری) برخی از ریفاینمنت‌های برنامه‌ریزی شده هم باید انجام شوند یا حداقل اعضایی از هر دو تیم در جلسه حضور داشته باشند. به یاد داشته باشید که دومی نباید با تیم‌های جدید انجام شود، کوچک شروع کنید و سپس رشد کنید.
اگر می‌خواهید در مورد توانمندسازی تیم‌های اسکرام و چابک بیشتر مطالعه کنید می‌توانید کتاب Leading Exponential Change را بخوانید.
ترجمه و تلخیص: سیما لبیبی
منبع:
https://www.linkedin.com/pulse/running-great-refinement-session-scrum-erich-r-b%C3%BChler/
