خانه / Agile / جلسات اسکرام باید ها و نباید ها

جلسات اسکرام باید ها و نباید ها

جلسات اسکرام باید ها و نباید ها

جلسات اسکرام روزانه که به عنوان Daily Standup هم شناخته میشه جلسات ساده ای است که معمولا هر روز کاری بین اعضای تیم برگزار میشه که معمولا توصیه میشه که مدت زمان این جلسات حدودا 15 دقیقه بیشتر بطول نینجامد(سر پا برگزار کردن جلسه بیشتر به همین دلیل است), در این جلسه غالبا به سه سوال زیر پاسخ داده میشه:

  1. دیروز چه کاری انجام دادم؟
  2. امروز چکاری انجام میدم؟
  3. چه مشکلات و موانعی سر راهم بود؟

اما واقعا مسیر چابک بودن و به سمت Agility رفتن فقط در گرو پاسخ به همین سه سوال نیست. اتفاقا غالبا بعد از مدتی مشاهده میشه که این جلسات به ceremonyها کم خاصیت تبدیل میشه و غالبا هر کدام از اعضای تیم جلسات رو بدون اینکه متوجه هم باشند به جلسه جهت ارائه کار فردی خود می دانند و توجه کمتری شاید به big picture(در اینجا به معنی اسپرینت جاری حداقل) خواهند داشت؛ و در واقع این جلسات بعد از مدتی بیشتر تمرکز به اینکه Daily Scrum به چه صورت پیش میره تمرکز دارند و به چرایی آن کمتر توجه می کنند و بدنبال پاسخ اون نخواهند بود.

در راهنمای اسکرام که توسط آقایان Ken Schwaber و Jeff Sutherland  ارائه شده Daily Scrum بصورت زیر تعریف شده:

… a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.

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

“The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment.”

خوب نکات مهمی در پاراگراف بالا آمده است. اما می پردازیم به سوال اصلی که اصولا چه افرادی می توانند در جلسات روزانه شرکت داشته باشند. در ادامه خواهیم دید که پاسخ به این سوال مهم خود حاوی نکات بسیار مهم در خصوص برگزاری جلسات Daily Scrum هست.

همانطور که در بالا اشاره شده است Scrum Master فقط Development Team memberها رو به جلسه دعوت می کند. خوب بجز توسعه دهنده و افرادی که مستقیم در تیم حضور دارند از جمله تستر ها؛ بحث بر سر حضور و یا عدم حضور شخص PO و البته سار Stack Holder ها و خود Scrum Master(البته در صورتی که جز نقش SM نقش دیگری نداشته باشد) در جلسه اینجا مطرح است که سعی می کنم به نظرات مختلف در اینجا در این باره اشاره کنم.

  • برخی معتقند که از آنجایی که PO حرف و صحبت های فنی Developer ها رو متوجه نمیشه حضور ایشون در این جلسات غیر ضروری است. این مورد درباره سایر ذینفعان از جمله مدیران که دارای خوی “manage something” هستند. پس بهتر است که این دسته افراد حضور نداشته باشند.
  • در مورد شرایطی که خود PO هم از افراد توسعه دهنده هست؛ بیشتر case study ها نشون داده که حضور PO بیشتر جنبه ی منفی داشت و بر جو غالب جلسات نیز تاثیر منفی گذاشته و این جلسات بیشتر به جلسات Reporting به PO(به ناچار) تبدیل می شود.
  • یکی از نقطه نظرات جالب و مهمتر افراد مخالف حضور افرادی غیر از تیم توسعه نیز به این صورت است که برخی نیز معتقند که باید بین جلسات Daily Scrum و سایر بحث های جانبی و جلسات ad hoc که در ادامه ممکن است اتفاق بیافتد بایستی تفاوت قائل شد. در جلسات Daily Scrum فقط تیم توسعه باید حضور داشته باشند و پس از جلسات Daily Scrum نیز ممکن است جلسات کوتاه و مختصر دیگری وجود داشته باشد؛ و در این جلسات PO می تواند حضور داشته باشد. و انتقال و هماهنگی و عدم تداخل این جلسات رو به بعد از Daily روزانه بر عهده ی SM می دونند. به این جلسات ad hoc به اصطلاح  “The after meeting.” نیز می گویند.
  • از اونجایی که در حین اسپرینت تیم توسعه جز جلسات Daily Scrum جلسات دیگری ندارند؛ بهترین موقع جهت رسیدن به self-organizing همین جلسات است؛ حضور سایر افراد بخصوص افرادی که دارای authority مدیریتی هستند و ممکن است بر جو غالب این جلسه خواسته یا ناخواسته تاثیر بگذارد تصمیم درستی و صحیحی نمی باشد. در مورد خود SM به عنوان نقش facilitator جهت یادگیری تیم جهت برگزاری بهتر این جلسات اشاره می شود؛ اما حتی حضور SM به معنی Participant بودن وی نیست.
  • یکی از اهداف اصلی جلسات اسکرام روزانه در واقع “Should be able to” می باشد. و این مورد فقط توسط اعضای تیم ترجمه و معنی میشه و بر عهده اونهاست. اما PO می تونه از تیم بخاد که یک توی یک وقت کوتاه 1 یا 2 دقیقه ای رو جهت توضیح برنامه ریزی احتمالی انجام شده جهت بهتر رسیدن به اهداف اسپرینت؛ تیم برای اون توضیح بده.

 

در مقابل نظرات موافق زیادی از حضور PO با شرایطی نیز وجود دارد؛ که در زیر به اونها اشاره می کنم.

  • به عنوان نمونه در صورتی که تیم تصمیم به skip کردن یک story به دلایل مختلف از جمله دلایل فنی داشته باشد؛ یا اینکه مثلا تیم نمی تونه به هر دلیل کل Story رو تا پایان sprint تحویل بده؛ حضور PO می تونه مفید باشد. و در کل این جلسات می تونه به عنوان شفاف سازی بیشتر برای PO باشه – البته این نظر نمیتونه دلیل قوی و قانع کننده ای باشه؛ چرا که PO که همیشه(اکثر اوقات) در دسترس هست؛ رو میشه همیشه جهت طرح همچین مواردی باهاش صحبت کرد و جلسه گذاشت.
  • نکته ی مهم دیگر توجه به کلمه Participant در پاراگراف بالا از راهنمای اجایل هست. این پاراگراف اعلام می کنه که حق Participant بودن فقط برای Development Team محفوظ هست و حضور سایر افراد رو منع نکرده. و سایر افراد از جمله PO و SM نیز می تونن حضور(فقط حضور) داشته باشند.
  • عده ای نیز بر این نظر هستند که جلسات DS نباید فقط حول همین سه سوال بچرخد؛ چون در این صورت این جلسات به جلسات status meeting تقلیل پیدا می کنند. DS در واقع یک Planning meeting کوتاه برای 24 ساعت آینده است. این جلسات می تواند برای PO به عنوان جلسه Inspect and Adopt عمل می کنه که PO متوجه بشه در 24 ساعت گذشته چه اتفاقی بوقوع افتاده و در صورت نیاز Adopt مورد نظر رو جهت بیشترین سود در پایان اسپرینت اعمال کنه.
  • گوشزد نمودن این موضوع که افراد باید در ابتدا بدونند که یک تیم هستند و PO هم عضوی از تیم هست و باید در جلسات شرکت کند؛ نیز یکی از دیدگاه های موافق حضور PO در جلسات DS می باشه.
  • PO می تونه بر روی نظرات اعضای تیم در این جلسات comment بگذاره. البته باید دقت نمود. اگر هر کدام از اعضای تیم حین صحبت سوالی داشته یا نکته ای رو اشتباه برداشت کرده باشند؛ PO می تونه در این مواقع کمک کننده باشد؛ اما بعد از اتمام جلسه.( در واقع این نظر هم موافق و هم مخالف هست J )

از آنجایی که PO هم عضوی از تیم محسوب میشه(اگه بشه) باید حضور داشته باشه و خود او هم به سه سوال بالا پاسخ بده. در این جلسه همه ی افراد در یک سطح حضور دارند و به سوالات پاسخ می دهند هر چند که فعالیت و کار PO متفاوت هست و با سایر صحبت های مطرح شده در جلسه ممکن است تفاوت فاحشی داشته باشد, اما با این کار این حس بوجود می آید که اعضای تیم یکپارچگی تلاش و کارشون رو در موفقیت کل تیم بهتر درک می کنند!!

خوب تا اینجا به برخی از نظرات موافق و مخالف با حضور افرادی از جمله PO در جلسات DS پرداخته شد. در ادامه توصیه هایی جهت اجتناب و دنبال کردن در جلسات DS ارائه میشه.

  1. یه برنامه رو ایجاد و دنبال کنید

همونطور که عنوان شد جلسات DS به مثابه یک Planning meeting برای 24 ساعت آینده برای تیم محسوب میشه و در این جلسات معمولا فرآیند inspect بخصوص برای 24 ساعته گذشته اعمال میشه. سوال بهتر شاید این باشد که انتظار داشتیم در planning قبلا به این موارد برسیم و learning رو بر روی مواردی از برنامه که تکمیل شدند اعمال کنیم.

  1. رادیاتور های اطلاعات رو مرور کنید

بهتر است که به نمودارهای burn down یا task board یا هر رادیاتور اطلاعاتی دیگری جهت پاسخ به این سوال که آیا بر طبق سرعت مورد انتظار و پیش بینی در حال پیشروی هستیم یا خیر نیز نگاهی بیاندازیم.

  1. زیاد وارد جزئیات نشوید.

معمولا وقتی که تیم تلاش می کنه که توضیح بده که برخی چیزی به چه صورت کار می کنن یا سناریوی خاصی رو توضیح بده؛ افراد بسیار بیش از حد وارد جزئیات خواهند شد؛ و جلسات عوض زمان 15 دقیقه 45 یا 60 دقیقه بطول می انجامند.

  1. Problem Solving انجام ندهید.

هر چند Sharing و Collaboration مناسب هستند اما جای آنها بعد از جلسات DS می باشد

5. جلسات راس ساعت و سر وقت برگزار شود.

در صورتی که کسی دیر رسید؛ به وقت بودن و سر تایم بودن برگزاری جلسه اسکرام را فدای منتظر ماندن وی نکنید. مسلما در جلسات بعدی او خود را به شما خواهد رساند

درباره ی masoud@admin

همچنین ببینید

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

The Five Dysfunctions Of The Team

#TheFiveDysfunctionsOfTheTeam #Team #People_Ware_Concern ✍✍✍✍✍✍✍✍✍✍✍   When you start an activity(work,startup,project and so on) with any …

پاسخ دهید

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

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن