بازنگری در اسکرام

واژه “بازنگری” را با کمک یک دوست عزیز توانستم معادل واژه گرانبهای Retrospective پیدا نمایم .{ بدلیل اینکه معادل فارسی مناسب و معنی رسان نیست از خود کلمه Retrospective استفاده خواهد شد} .

Retrospective یکی از مهم ترین و مقدسترین واژه ها در فرهنگ Agile می باشد به صورتی که در آیه دوازدهم بیانیه چابک به صورت واضح به اهمیت این مسئله اشاره شده است . در این آیه چنین می خوانیم :

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly

بیانیه چابک – Agile Manifesto – اصل دوازدهم

در این پست قصد دارم این اصل راتفسیر و تشریح نمایم .  اگر پست اسکرام ساده شده را کامل خوانده باشید خواهید دانست که در این پست تا آنجا رسیدیم که Sprint planning را انجام دادیم و شروع به کار کردیم . حالا زمانی که Sprint تمام شد و دمو به مشتری ارائه شد باید کار مهمی به نام Retrospective انجام شود . http://blog.irscrum.com/wp-content/uploads/2010/04/retro.jpg?w=475

Retrospective چیست ؟

به عبارت ساده یعنی نگاه به عملکرد تیم در sprint قبلی و بررسی عملکرد ها و نتیجه گیری برای بهبود بخشی به عملکردها و تغییر رفتار نسبت به نتیجه گیری انجام شده در Sprint های بعدی .

از قدیم یک مثل معروف بود که وقتی شب می خواهید بخوابید یک کلاه پیدا کنید . اگر کلاه نداشتید جوراب هم می شود . جوراب و یا کلاه را  پیش روی خودتان بگذارید و پست قاضی را به او بدهید . بعد پیش این قاضی اعتراف کنید که امروز چه کارهای خوبی و یا چه کارهای بدی انجام داده اید . اگر چه کارهایی را انجام می دادید خوب بود و اگر چه کاری کارهایی را انجام نمی دادید خوب تر بود ؟ بعد برای خود یک مدل رفتاری که اگر آنگونه رفتار کنید بهتر خواهید بود مشخص کنید و فردا آن رفتار را داشته باشید  و فردا  شب بازهم Retrospective بکنید و باز هم یک سری دیگر از  تصمیمات را اتخاذ نمایید . اگر بتوانید انجام بدهید این یعنی یک بهبود و پیشرفت کامل و شما مجوز بهشت را دریافت کردید .

البته فقط اشتباهات مد نظر نیست . یعنی انسان ها آنقدر هنوز پست نشده اند که بدانند اشتباه می کنند و باز هم اشتباه  کنند . منظور اصلی بهبود بخشی و بهتر کردن اوضاع و عملکرد نسبت به گذشته است . یعنی ما شاید با تغییر کوچکی در رفتار خود بتوانیم more effective شویم .

اصل مورد نظر از 3 بخش تشکیل شده است : بخش اول : At regular intervals یعنی در فواصل معین . همانطور که گفته شد فاصله ما بعد از ارائه دمو به مشتری و آخر هر اسپرینت می باشد. پس ما در اسکرام خودمان برای انجام Retrospective  یک فاصله معین داریم .

بخش دوم : the team reflects on how to become more effective به این معنی که تیم می فهمد که چگونه می تواند عملکرد خود را بهبود ببخشد همان بخش کلاه و جوراب و قاضی ما می شود .

بخش سوم : then tunes and adjusts its  behavior accordingly به این معنی که رفتار خود را در اسپرینت های بعدی نسبت به تصمیماتی که گرفته شد همسو و همساز می سازیم.

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

Retrospective چگونه انجام می شود ؟

Retrospective همانند همه جلسات دیگر اسکرام انجام خواهد شد به صورتی که تمام اعضای تیم توسعه و Product Owner و شخص Scrum Master هم باید حضور داشته باشد . شروع جلسه با اسکرام مستر خواهد بود .او خلاصه ای از اسپرینت انجام شده و تصمیمات مهمی که طی این اسپرینت گرفته شد بیان خواهد کرد .  اساس کار برروی Sprint Backlog خواهد بود . هر یک از اعضای تیم فرصت این را خواهند داشت که در مورد Story ها صحبت کنند .  برای بحث بهتر ما یک وایت برد را تبدیل به یک Retrospective Board می کنیم : (مانند عکس زیر)

http://blog.irscrum.com/wp-content/uploads/2010/04/retroboard.jpg?w=592

همانطور که گفته شد اساس برپایه Sprint Backlog خواهد بود . یک  Story از Sprint Backlog برداشته خواهد شد و بر اساس نظرات تیم در یکی از ستون های Retrospective Board قرار خواهد گرفت  و همین طور تا آخر. ستون اول آنهایی هستند که مشکل خاصی نداشتند و همه راضی هستند . ستون سوم آنهایی هستند  که مشکل دار می باشند و باید حتما مشکل آنها مورد آنالیز قرار گرفته شود و نتیجه گیری انجام شود(مثلا مواردی که پیاده سازی آنها بیش از برآورد انجام گرفته طول کشیده است) . مواردی که نه در ستون اول و نه در ستون سوم قرار ندادید را به ستون دوم انتقال بدهید .ستون دوم بعد از اینکه پر شد باید دوباره خالی شود بدین صورت که  با یک نظرخواهی از گروه موارد ستون دوم را به ستون اول و یا ستون سوم منتقل کنید .

پس از اینکه تمام موارد بر روی Retrospective Board انتقال داده شد باید تمام موارد در ستون سوم مورد بحث و آنالیز قرار بگیرد و در آخر گزارشی توسط تیم در مورد بازبینی تهیه شود که ملت باخواندن آن متوجه شوند فلان مشکل قبلا اتفاق افتاده است و نباید برای من اتفاق بیفتد . در واقع یک داستان ناموفق می نویسیم که اعضای تیم ما و یا تیم های دیگر با خواندن آن عبرت می گیرند .

یک مسئله اساسی که شما هم به آن اشاره نمی کنید این است که اگر ما مسائل فنی تیم خودمان را در Retrospective بازبینی و اصلاح می کنیم چرا باید Product Owner حضور داشته باشد ؟ زیرا امکان دارد و بسیار هم امکان دارد ما از دل جلسات Retrospective به ایده های جدید و اصلا به نیازهای جدید دست پیدا کنیم . یعنی در آنالیز ما می فهمیم که باید فلان نیازمندی هم باشد که به اطلاع Product Owner رسانده می شود و او با بررسی نیازمندی  می تواند به نیازمندی مربوطه با توجه به نیازهای قبلی که در Product Backlog لیست شده اند , اولویت بدهد. علاوه بر این  تیم برروی این نیازمندی برآوردی انجام می دهد و  پس از برآورد و اولویت بندی , نیازمندی مربوطه به درون Product Backlog انتقال داده می شود تا در یکی از Sprint ها پیاده سازی شود .

امیدوارم بتوانید و بتوانیم Retrospective های خوبی داشته باشیم .

یاشیاسیز

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

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

5 دیدگاه

  1. Pingback: 20 نکته در باب Scrum « دنیای چابک

  2. Pingback: Agile شدن در 4 مرحله « دنیای چابک

  3. Pingback: دنیای چابک » Agile شدن در 4 مرحله

  4. Pingback: دنیای چابک » 20 نکته در باب Scrum

پاسخ دهید

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