یک جلسه بررسی/مرور اسپرینت (Sprint Review) رویدادی هست که پایان یک اسپرینت باید برگزار بشه و طی اون، تیم تمام مسائل «انجام شده» (Done) برای اون دوره رو بررسی می‌کنه. هدف از مرور اسپرینت اینه که ببینیم آیا هدفی که برای اسپرینت تعریف کرده بودیم، به دست اومده و دمویی هم از آخرین نسخه‌ی محصول رو که اصطلاحاً توسعه‌های جزئی بالقوه قابل تحویل از محصول (potential shippable working product increments) نامیده میشه رو به تیم و ذینفعای محصول ارائه بدیم.
بد نیست نگاهی به تعریف ذینفع توی متد اسکرام داشته باشیم: یک ذینفع شخصی خارج از تیم هستش که علاقه و شناخت خاصی از محصولی دارد که برای کشف تدریجی مورد نیاز است. ذینفع توسط مالک محصول نمایندگی میشه و به طور فعال با تیم توی جریان جلسه مرور اسپرینت همکاری می‌کنه.
پایان هر اسپرینت، تیم یک نرم‌افزار تست‌شده و قابل استفاده رو باید تولید کرده باشه. این محصول، مبنای بازرسی (inspect) و تطابق (adapt) هست که از کلیدی‌ترین مباحث و رفتارهای اجایل بودنه. عمدتاً خود این به اصطلاح product increment چیزی هست که باید inspect کنیم و بک‌لاگ محصول چیزی هست که باید تطبیق بدیم (adapt کنیم).
یک نکته‌ای که معمولاً باعث دغدغه و نگرانی میشه، تأکید روی دمو هست. باید توجه داشته باشیم که ارائه‌ی دمو (demo) بخش مفیدی از جلسه‌ی مرور اسپرینت محسوب میشه اما هدف از این رویداد نیست. مهمترین جنبه‌ی مرور اسپرینت، گفتگو و همکاری عمیق بین شرکت‌کنندگان هستش طوری که امکان سازگاری و تطبیق رو به وجود بیاره. نمایش اونچه در واقع ساخته شده صرفاً یک روش بسیار کارآمد برای انرژی بخشیدن به آن گفتگو پیرامون چیزی خاص و مشهود و قابل اندازه‌گیری هستش. هیچ چیزی به خوبی یک دمو از محصول واقعی نمی‌تونه امکان تمرکز گفتگوی تیم رو فراهم کنه.
به تصویر زیر دقت کنید. این تصویر روی این موضوع تأکید داره که رویداد مرور اسپرینت نباید روی دمو دادن متمرکز باشه.
به جای تأکید و تمرکز روی کد نوشته شده، یوزر استوری و فقط برگزار شدن جلسه، باید روی ارزشی که با done شدن استوری‌ها و مسائل برای کسب‌وکار ایجاد میشه، اهداف تعریف شده و محقق شده، گفتگو و تعامل با ذینفعای محصول متمرکز بشیم و دستاوردها رو جشن بگیریم.
مزیت‌های جلسه‌ی مرور اسپرینت
- تعامل با ذینفعان رو افزایش می‌ده (بازخورد زودهنگام و مکرر)
- پاسخگویی به مشتریان را به حداکثر می‌رسونه
- به تیم‌سازی و همکاری بهتر منجر میشه
- امکان بهتر و آماده‌تر کردن بک‌لاگ رو فراهم می‌کنه
- برنامه‌ی انتشار محصول رو به روز می‌کنه
- به افزایش درک محصول بین تیم‌ها منجر میشه
- ارزش جلسات برنامه‌ریزی اسپرینت رو هم افزایش می‌ده
- به نوعی، باعث آموزش تدریجی ذینفعای محصول میشه
باعث ایجاد حس تعلق توی کاربرای محصول (که توی این جلسه حضور دارن) میشه
کارهایی که معمولاً توی مرور اسپرینت انجام میشه
- مدیر/مالک محصول موارد «انجام شده» (Done) از بک لاگ محصول رو مرور می‌کنه
- تیم توسعه در مورد چیزهایی که توی این اسپرینت به خوبی پیش رفت، مشکلاتی که باهاش روبرو شدن و اینکه چطوری مشکلات رو حل کردن یا اینکه چطوری میشه مشکلات رو حل کرد، بحث می‌کنن
- تیم توسعه کاری رو که «انجام شده» (Done) دمو می‌دن و به پرسش‌هایی در مورد نسخه جدید (increment یا توسعه‌ی جزئی که توی محصول انجام شده و کار می‌کنه) پاسخ می‌دن
- تیم (شامل هم تیم تولید و هم مالک محصول و سایر ذینفعای داخلی و بیرونی) در مورد اقدامات بعدی با هم گفتگو می‌کنن، طوری که بر اساس نتایج گفتگوهای این جلسه، اطلاعات ارزشمندی برای جلسات بعدی پالایش (refinement) بک‌لاگ و برنامه‌ریزی اسپرینت فراهم بشه.
- بررسی جدول زمانی پروژه، بودجه، قابلیت‌های بالقوه برای انتشار بعدی محصول هم معمولاً توی جلسه‌ی مرور انجام میشه
نکاتی که می‌تونه منجر به جلسه‌ی بهتری برای مرور اسپرینت بشه
- تمرکز روی چیزهایی که Done شدن: تمرکز روی معیارهای پذیرشی که مطابق با Definition of Done هستن. برای این کار، میشه توی شروع جلسه، از روی بُردِ تیم، استوری‌ها و مسائل Done شده را نشون بدیم.
بعد از این کار، یک نگاهی به پیش‌بینی‌ها و تخمین‌هایی که داشتید، بیاندازید. پیش‌بینی‌ها و تخمین‌هاتون رو با اونچه در واقع انجام شده، مقایسه کنید. این کمک می‌کنه تیم بتونه تعهداتش رو ردگیری کنه و مطمئن بشه که به صورت پایداری می‌تونه کار رو ادامه بده و از اونچه انجام داده، می‌تونه یاد بگیره. خوبه که این آمار و گزارش رو از قبل آماده کنیم و توی جلسه یک نگاهی به اون بیاندازیم تا وضعیت تعهدات تیم براشون روشن بشه. این اقدامی برای به اصطلاح بازرسی و تطبیق (inspect & adapt) محسوب میشه.
میشه بلافاصله بعد از این اقدام، تیم یک نگاهی به بک‌لاگ بیاندازه و با اونچه از بررسی تجربه‌اش در مورد تسک‌ها و استوری‌های این اسپرینت به دست آورده، تخمین‌هاش رو برای استوری‌ها و آیتم‌های بک‌لاگ، البته برای موارد اولویت‌دار اسپرینت بعدی، در صورت لزوم، به روز رسانی کنه. این طوری، بک‌لاگ بهتر و آماده‌تری خواهیم داشت.
- باید توجه داشته باشیم که این یک جلسه‌ی گزارش‌دهی نیست بلکه یک جلسه‌ی غیررسمی هستش که فرصتی هست برای دریافت بازخورد (feedback) با مشارکت همه‌ی تیم و ذینفع‌های محصول/پروژه. بهتره که این جلسه از نظر زمانی به خوبی مدیریت بشه و می‌تونه تایم‌باکس زیر رو براش درنظر گرفت:
- برای اسپرینت یک هفته‌ای، یک ساعت
- برای اسپرینت دو هفته‌ای، دو ساعت
- برای اسپرینت چهار هفته‌ای، چهار ساعت
- غیر رسمی تلقی شدن جلسه‌ی مرور اسپرینت به این معنی هست که تلاش نمی‌کنیم مثل خیلی از جلسه‌های رسمی، پاورپوینت بسازیم! بیشتر از دو ساعت هم برای آماده‌شدن برای این جلسه نباید وقت بگذاریم! این جلسه نباید باعث بشه تیم دچار انحراف از مسیر اصلی کارش بشه و استرس بی خودی ایجاد کنه؛ اینکه باید به تدریج و توی همه‌ی اسپرینت‌ها این اتفاق بیافته هم برای همینه که تیم با کلی کار انجام شده و روی هم انباشته شده مواجه نشده که یک دفعه مجبور بشه با کلی استرس، برای دموی محصول آماده بشه؛ داشتن دموهای آهسته و پیوسته، کوچیک و قابل مدیریت بهتره! این جلسه، باید نتیجه‌ی طبیعی اسپرینت تلقی بشه نه یک کابوس!
- تمرکز روی کاربر: همه‌ی دموهایی که انجام میشه رو روی تجربه واقعی کاربر و ارزشی (value) که برای کسب‌وکار ایجاد میشه، متمرکز نگه دارید (و نه فقط مرور فانکشنالیتی).
- توی جلسه‌ی مرور اسپرینت، معمولاً مالک محصول، خودِ تیم، اسکرام مستر، مدیریت، مشتریان و توسعه‌دهندگان سایر پروژه‌ها و سایر تیم‌ها مشارکت دارن.
- توی جلسه‌ی مرور اسپرینت، تیم محور ارائه‌ها و دریافت بازخوردها هست؛ قرار نیست فرد یا افراد خاصی بازخواست بشن! یا بخوان گزارش بدن. توی این جلسه قراره مهم‌تر از هر چیز، بازخورد از کار انجام شده دریافت کنیم. تخمین‌هامون رو بهتر کنیم و بیشتر یاد بگیریم.
- خوبه که قبل از دمو، حتماً گفته بشه که چه چیزهایی ارائه خواهد شد و چه چیزهایی جزء این دمو نخواهد بود. این کار رو بهتره مدیر/ مالک محصول انجام بده. دمو رو هم می‌تونه مالک محصول ارائه بده (خصوصاً اگه با یک ذینفع یک کم بدقلق روربرو باشیم) و هم میشه یکی یا چند نفر از اعضای تیم ارائه بدن. حتی میشه هر کسی کار خودش رو دمو بده و به هر صورت، میشه تجربه کرد که کدوم مدل کجا بهتر کار می‌کنه.
- توی این جلسه معمولاً دمویی از فانکشنالیتی‌های جدید ارائه میشه. بعد از دمو، پرسش‌هایی مطرح میشه برای بجث و گفتگو درباره‌ی اونچه انجام شده و یا مسائل و استوری‌های پیش رو. مهم اینه که این گفتگو یک تسهیلگر داشته باشه که در اینجا یا مدیر محصول یا اسکرام مستر می‌تونن این نقش رو ایفا کنن.
توی جلسه‌ی مرور، میشه (و خوبه که) آیتم‌های آینده‌ی بک لاگ محصول رو هم نگاهی بیاندازیم. این کار معمولاً آخر این جلسه انجام میشه و طی اون، مدیر/مالک محصول آیتم‌های بالقوه‌ی آینده رو مرور می‌کنه و با چیزهایی که توی این جلسه در موردشون گفتگو شد، سعی می‌کنه دورنمایی (البته خیلی هم دور نه!) از اون چه که می‌تونه در ادامه توی اولویت قرار بگیره رو با تیم درمیون می‌گذاره و حتی می‌تونه اگر فرصت باشه، بازخوردی نسبت به تخمین و استنباط تیم نسبت به اون آیتم‌ها هم دریافت کنه. میشه این موارد رو یادداشت کرد و در آخر جلسه اون‌ها رو یک بار برای تیم مرور کرد و یا اینکه اگه امکانش وجود داشته باشه، همون‌جا ایتم‌های بک‌لاگ پالایش بشه و حتی اولویت‌بندی‌ها مورد بازنگری قرار بگیره.
پاسخ به برخی نگرانی‌ها و پرسش‌ها در مورد جلسه‌ی مرور اسپرینت
- در مورد فشاری که دمو روی تیم می‌گذاره باید این نکته رو یادمون باشه که اتفاقاً یاد کاری کنیم که این فشار توی اسپرینت‌ها پخش بشه و جمع نشه که یک دفعه کلی کار مجبور باشیم انجام بدیم و به نوعی باعث بشه کار از اون پایداری (sustainability) دور بشه و از نفس بیافتیم! توسعه‌ی یک محصول یک مارتونه و باید انرژی‌مون رو حفظ کنیم برای تمام این مسیر.
- ذینفعان یک محصول / پروژه هم داخلی هستن و هم بیرونی. مثلاً توی پروژه سرمد، کاربرای محصول و مدیران اون پروژه از سمت کارفرما (سرمد) ذینفع بیرونی ما و مثلاً افرادی از مدریک (که قرارداد پروژه با اون‌هاست) مثل PMO شون، ذینفع داخلی محسوب میشه که هر چقدر امکان داشته باشه همشون (البته، حسب کارکردی که ایجاد میشه، ارزشی که ارائه میشه و بازخوردی که نیاز داریم) مشارکت داشته باشن، بهتر.
- اینکه ذینفعای محصول / پروژه باید با اجایل و ریتم کاری ما آشنا بشن، کاملاً صحیح هست و باید حتماً این کار رو انجام بدیم.
- این نگرانی که ممکنه موقع دمو به مشکل بخوریم و با خطا مواجه بشیم همیشه وجود داره و چه خوب که بتونیم زودتر و به صورت پیوسته با تحلیل دلایل این اتقاق محتمل، کاری کنیم که احتمال وقوعش کم و کم تر باشه. خب، حتی در بهترین شرایط هم ممکنه باز یک چیزی درست نباشه و قانون مورفی کنار دستمون باشه! پس، تیم باید با اعتماد به نفس و شجاعت از کار انجام‌شده که مطابق با معیارهای پذیرش هست، دفاع کنه و بتونه کنترل ارائه رو به دست بگیره. باید به ذینفعای محصول / پروژه هم تأکید کنیم که این جلسه برای دریافت بازخوردشون و در جریان گذاشتشون نسبت به پیشرفت و سمت و سوی کار هستش. بنابراین، تیم نباید نگران باشه ولی نباید هم این طور باشه که این جلسه جدی گرفته نشه. این جلسه خیلی خیلی مهمه برای خود تیم که بتونه ببینه چی کار کرده و خودش رو با بازخوردهایی که دریافت می‌کنه تطبیق بده. اگه چیزی اشتباه شده بهتره که زودتر بفهمیم و تصحیح کنیم. اگر پیش فرضی غلطه زودتر اون رو به محک ارزیابی قرار بدیم.
- واقعیت اینه که به هر صورت، دمو و ارائه‌ی کار بی استرس نیست. اما با مدیریت فضای این جلسه میشه ازش برای هدف درستش بهره‌برداری کرد. تیم باید کاملا مشتاق و باز باشه برای دریافت این بازخوردها، هر چه میشه سریع‌تر و هر چی ممکنه از ذینفعای بیشتر.
- انجام و نوشته‌شدن تست و قابل اتکا بودن سیستم هم که خیلی مهمه و اتفاقاً ضرورت دموها باعث میشه که کم کم و قدم به قدم توی هر اسپرینت روی این موضوع تمرکز کنیم و محصول رو قابل اعتمادتر کنیم. جریان CI/CD هم که کاملاً روی کیفیت و مدیریت مؤثر این مسیر تأثیرگذاره و باز هم به نظرم، خود همین ضرورت داشتن دموهای stable و پیوسته، اهمیت و ضرورت این جور کارها رو باید بیشتر آشکار کنه.
- در مورد منابع و زیرساخت مورد نیاز برای استقرار محصول هم باید حتماً اقدام مناسبی انجام بدیم. در این مورد، یک سرور مستقل برای هر محصول مجزایی که باید تحویل بشه (از جمله سرمد) فراهم خواهد شد.
- در مورد این نگرانی که ذینفع‌ها متوجه باگ‌ها بشن اولا باید به این دقت کنیم که باگ‌های شناخته شده‌ی اولویت‌دار باید حل شده باشن؛ مواردی هم که باز مونده رو باید شفاف توی جلسه مرور کرد و دید. هیچ ایرادی نداره که ذینفعای ما بدونن که باگ وجود داره مهم اینکه که ما خودمون اشراف داشته بشیم نسبت به وجود این باگ‌ها و نواقص؛ قراره که صرفاً کارهای Done شده رو ارائه بدیم. معمولاً هم تمرکز روی کل فانکشنالیتی‌ها نیست و فقط فانکشنالیتی‌ها و موارد جدید دمو می‌شن که با کمی آمادگی، میشه شرایطی به وجود آورد که باگ‌های نامربوط که به سایر بخش‌ها ربطه دارن، آشکار نشن و تمرکز فقط روی کارکردهای جدید و بهبودها باشه.