قالب Sprint Retrospective + سوالات جلسه

تیم شما اسپرینت را تمام کرده، اما آیا واقعاً «بهتر» شده است؟ اگر بعد از هر اسپرینت بدون مکث سراغ اسپرینت بعدی بروید، اشتباه‌ها دوباره تکرار می‌شوند و روش‌های خوب تثبیت نمی‌شوند. جلسهٔ Retrospective (رترو) دقیقاً همان مکث لازم است: فرصتی برای اینکه تیم بپرسد چه چیزی خوب بود، چه چیزی بد بود و چه کاری را باید تغییر دهیم.

در این مقاله یک قالب Retrospective به‌همراه سوالات پیشنهادی و روش برگزاری درستش به شما می‌دهیم تا هر اسپرینت کمی بهتر از قبلی باشد.

پاسخ سریع

قالب Retrospective چیست؟

قالب Retrospective ساختاری ساده برای جلسهٔ پایان اسپرینت است که در آن تیم سه سؤال را پاسخ می‌دهد: چه چیزی خوب بود، چه چیزی بد بود و چه کاری را باید تغییر دهیم. خروجی آن باید یک یا دو اقدام بهبود مشخص با مسئول باشد که در اسپرینت بعدی پیگیری می‌شود.

چرا جلسهٔ Retrospective باید خروجی داشته باشد؟

مهم‌ترین خطری که جلسهٔ رترو را تهدید می‌کند، «حرف بدون عمل» است. اگر تیم فقط گلایه کند و هیچ اقدامی انتخاب نشود، جلسه به جلسهٔ تخلیهٔ هیجان تبدیل می‌شود و کم‌کم اعضای تیم از آن دل می‌زنند. رترو مفید سه ویژگی دارد:

1. فضای امن: همه بدون ترس از سرزنش حرف می‌زنند.
2. تمرکز بر فرایند: مشکل‌ها به فرایند برمی‌گردد، نه به اشخاص.
3. خروجی مشخص: یک تا دو اقدام کوچک با مسئول و زمان پیگیری.

چه زمانی رترو برگزار می‌شود؟

در تیم‌های چابک، رترو در پایان هر اسپرینت و قبل از شروع اسپرینت بعدی برگزار می‌شود. فاصلهٔ درست آن را اندازهٔ اسپرینت تعیین می‌کند: در اسپرینت‌های دو هفته‌ای، هر دو هفته یک‌بار؛ در اسپرینت‌های یک ماهه، ماهی یک‌بار. اگر رترو را حذف کنید، دقیقاً مکانیزم «بهبود» تیم را حذف کرده‌اید.

قالب Retrospective — نسخهٔ قابل کپی

این قالب را کپی کنید و در پایان هر اسپرینت پر کنید:

Retrospective — اسپرینت [شماره] — تاریخ: [  ]

چه چیزی خوب بود؟
- [مورد ۱]
- [مورد ۲]

چه چیزی بد بود؟
- [مورد ۱]
- [مورد ۲]

چه کاری را تغییر دهیم؟
- اقدام ۱: [توضیح] — مسئول: [نام] — مهلت: [  ]
- اقدام ۲: [توضیح] — مسئول: [نام] — مهلت: [  ]

پیگیری اسپرینت بعد:
- [آیا اقدام‌ها انجام شد؟]

نمونهٔ تکمیل‌شده — اسپرینت ۸

Retrospective — اسپرینت ۸ — تاریخ: ۲۰ آذر

چه چیزی خوب بود؟
- ارتباط روزانهٔ تیم منظم و کوتاه بود
- مستندات فنی به‌روز ثبت شد

چه چیزی بد بود؟
- تأیید کارفرما دیر رسید و توسعه را ۲ روز عقب انداخت
- تخمین فاز تست کمتر از واقعیت بود

چه کاری را تغییر دهیم؟
- اقدام ۱: تعیین ددلاین ۳ روزه برای تأیید کارفرما — مسئول: مدیر پروژه — مهلت: اسپرینت ۹
- اقدام ۲: اضافه‌کردن بافر ۲۰٪ به تخمین تست — مسئول: سرپرست تیم — مهلت: اسپرینت ۹

پیگیری اسپرینت بعد:
- هر دو اقدام در شروع اسپرینت ۹ بررسی می‌شود

سوالات پیشنهادی برای جلسهٔ رترو

قالب پایه سه سؤال دارد، اما می‌توانید بسته به شرایط تیم از این سوالات هم استفاده کنید:

کدام قالب را انتخاب کنیم؟

• اگر تیم تازه‌کار است، قالب سه‌سؤالی ساده بهترین شروع است.
• اگر می‌خواهید روی عواطف تیم تمرکز کنید، Mad / Sad / Glad مناسب است.
• اگر بحث عمل‌گرایانه می‌خواهید، Start / Stop / Continue خروجی‌های ملموس‌تری می‌دهد.
• Sailboat برای تجسم ریسک‌ها و موانع جذاب است، مخصوصاً برای تیم‌های بصری.

چطور جلسهٔ Retrospective را درست برگزار کنیم؟

1. فضای امن بسازید: رترو باید عاری از سرزنش باشد؛ تمرکز روی فرایند، نه مقصر.
2. خوب و بد را جمع کنید: اجازه دهید همه نظرات ثبت شود، حتی نظرات مخالف.
3. اقدام بهبود را انتخاب کنید: به‌جای ده اقدام، فقط یک تا دو اقدام واقعی و کوچک انتخاب کنید.
4. مسئول مشخص کنید: هر اقدام باید یک نفر مسئول داشته باشد.
5. در اسپرینت بعدی پیگیری کنید: اقدام‌ها را در شروع اسپرینت بعدی مرور کنید تا رترو اعتبارش حفظ شود.

نقش تسهیل‌گر

رترو به یک تسهیل‌گر نیاز دارد (اسکرام مستر یا یک عضو چرخشی تیم) که این کارها را انجام دهد: زمان را نگه دارد، مطمئن شود همه حرف می‌زنند، بحث را از سرزنش دور نگه دارد و در پایان، اقدام‌ها را با مسئول ثبت کند. تسهیل‌گرِ خوب، نظر خودش را تحمیل نمی‌کند؛ فقط فضا را برای گفتگوی سالم نگه می‌دارد.

اگر تیم ریموت است

برای تیم‌های دورکار، رترو را می‌توان روی یک بورد دیجیتال یا سند مشترک برگزار کرد. اصل این است که همه هم‌زمان در یک فضای مشترک بنویسند و ببینند؛ ابزار فرقی ندارد، اما «هم‌زمان‌بودن» و «دیده‌شدن نظرات» مهم است.

مثال‌های عددی از Retrospective

مثال ۱ — یک اقدام واقعی: تیم در رترو متوجه شد تأیید کارفرما به‌طور میانگین ۵ روز طول می‌کشد و اسپرینت را عقب می‌اندازد. اقدام انتخاب‌شده: تعیین ددلاین ۳ روزه. در اسپرینت بعدی، میانگین تأیید به ۱ روز رسید.

مثال ۲ — محدودکردن اقدام‌ها: یک رترو ۸ اقدام پیشنهاد داد که هیچ‌کدام انجام نشد چون زیاد بودند. با قانون «فقط ۲ اقدام»، در اسپرینت بعدی هر دو اقدام به‌طور کامل انجام شد.

مثال ۳ — پیگیری مستمر: تیمی تصمیم گرفت در ابتدای هر رترو، فقط ۵ دقیقه به مرور اقدام‌های رترو قبلی بدهد. نتیجه این شد که نرخ انجام اقدام‌ها از حدود ۳۰٪ به بیشتر از ۷۰٪ رسید.

مثال ۴ — تخمین و Velocity: تیمی در چند رترو متوالی متوجه شد تخمین‌هایش مدام خوش‌بینانه‌اند. اقدام: بررسی ۲ اسپرینت گذشته نشان داد Velocity واقعی تیم ۴۵ امتیاز است نه ۶۰؛ با تعدیل بک‌لاگ بر همین مبنا، اسپرینت‌ها دیگر با فشار اتمام‌نشدنی مواجه نشدند.

مزایا، معایب و Trade-off جلسهٔ Retrospective

نکتهٔ Trade-off: اندازهٔ رترو باید با تیم تناسب داشته باشد. برای یک تیم ۳ نفره، یک جلسهٔ ۲۰ دقیقه‌ای کافی است؛ برای تیم ۱۰ نفره، ۶۰ دقیقه. کلید، کیفیت گفت‌وگو و خروجی است، نه طول جلسه.

نمونهٔ دوم — قالب Start / Stop / Continue

برای اینکه قالب‌های مختلف را هم دیده باشید، یک نمونه با قالب Start/Stop/Continue می‌آوریم:

Retrospective — اسپرینت ۱۲ — تاریخ: ۱۵ بهمن

شروع کنیم (Start):
- بررسی خودکار کیفیت کد در هر Pull Request

متوقف کنیم (Stop):
- جابه‌جایی تسک‌ها بدون اطلاع به تیم در میانهٔ اسپرینت

ادامه دهیم (Continue):
- جلسهٔ روزانهٔ کوتاه و منظم ۱۵ دقیقه‌ای

اقدام‌های انتخاب‌شده:
- اقدام ۱: راه‌اندازی بررسی خودکار کیفیت کد — مسئول: سرپرست فنی — مهلت: اسپرینت ۱۳

این قالب برای تیم‌هایی خوب است که می‌خواهند خروجی عمل‌گرایانه‌تر داشته باشند؛ چون هر سه ستون آن مستقیم به «رفتار» اشاره می‌کند، نه فقط به حس کلی.

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

گاهی رترو خشک یا تک‌طرفه می‌شود. این تکنیک‌ها کمک می‌کنند:

• نوشتن بی‌صدا: اول به همه ۳ تا ۵ دقیقه وقت بدهید تا نظرشان را بی‌صدا بنویسند، بعد بحث کنید. این‌طور اعضای کم‌حرف هم شنیده می‌شوند.
• چرخش تسهیل‌گر: هر اسپرینت یک نفر دیگر جلسه را هدایت کند تا همه مالکیت پیدا کنند.
• سؤال کانونی: به‌جای سؤال کلی «بد چه بود؟»، گاهی یک سؤال دقیق بپرسید: «بزرگ‌ترین مانعِ رسیدن به هدف اسپرینت چه بود؟»
• رأی‌گیری برای اقدام: بعد از جمع‌کردن پیشنهادها، بگذارید تیم به مهم‌ترین یک یا دو اقدام رأی دهد؛ به‌جای اینکه تسهیل‌گر خودش انتخاب کند.

اگر گفتگو ساکت شد

اگر کسی حرف نمی‌زند، احتمالاً امنیت روانی جلسه پایین است. به‌جای فشار برای صحبت، اول روی اعتماد کار کنید: تسهیل‌گر خودش با یک نمونهٔ صادق شروع کند، سرزنش را صراحتاً ممنوع کند و از «قانون چتم‌هاوس» استفاده کند (نظرها متعلق به همه است و بدون اسم می‌ماند). رترو فقط وقتی کار می‌کند که آدم‌ها حرف بزنند؛ حرف‌زدن فقط وقتی می‌آید که ترس نباشد.

نشانه‌های یک رتروی خوب

چطور بفهمیم رترو واقعاً کار کرده است؟ این نشانه‌ها را دنبال کنید:

• همه حرف زدند: نه فقط دو سه نفر پرحرف؛ حتی اعضای کم‌حرف هم نظری نوشتند یا گفتند.
• اقدام کم اما واقعی: خروجی جلسه یک یا دو اقدام مشخص است، نه ده اقدام مبهم.
• اقدام قبلی پیگیری شد: جلسه با مرور اقدام‌های رتروی قبل شروع شد.
• بحث دربارهٔ فرایند بود، نه مقصر: جمله‌ها دربارهٔ «چطور کار را بهتر کنیم» بود، نه «کی خراب کرد».
• تیم مشتاق جلسهٔ بعدی است: اگر اعضا رترو را وقت‌تلف‌کردن می‌بینند، یعنی یک‌جای کار می‌لنگد.

اگر رترو «تکراری» شد

گاهی رتروها یکنواخت می‌شوند و همان حرف‌های قبلی تکرار می‌شود. راه‌حلش این است که هر چند اسپرینت یک‌بار قالب را عوض کنید (مثلاً از سه‌سؤالی به Start/Stop/Continue)، یا سؤال کانونی تازه‌ای بپرسید، یا روی یک موضوع خاص (مثلاً فقط فرایند تست) عمیق شوید. تغییر کوچک در ساختار، گفتگو را تازه می‌کند.

اشتباهات رایج در Retrospective

1. رترو بدون خروجی: جلسه تمام می‌شود اما هیچ اقدامی انتخاب نمی‌شود.
2. سرزنش فردی: تمرکز روی مقصر به‌جای فرایند.
3. اقدام زیاد بدون مسئول: ده اقدام کلی که هیچ‌کس مسئولش نیست.
4. پیگیری‌نکردن اقدام‌ها: اقدام‌ها ثبت می‌شوند اما در اسپرینت بعدی فراموش می‌شوند.
5. برگزاری‌نکردن: به‌خاطر فشار کار، رترو حذف می‌شود.
6. تبدیل رترو به گزارش وضعیت: رترو جای مرور پیشرفت نیست؛ جای بهبود فرایند است.

قالب کاغذی یا ابزار آنلاین؟

رترو را می‌شود روی یک تخته یا فایل ساده برگزار کرد، اما وقتی اقدام‌ها در ابزار مدیریت پروژه ثبت شوند، به تسک‌هایی با مسئول و مهلت تبدیل می‌شوند و پیگیری‌شان در اسپرینت بعدی خودکار و آسان است. به این ترتیب، خروجی رترو از یک یادداشت به یک تعهد قابل ردیابی تبدیل می‌شود.

در دوایتفای می‌توانید اقدام‌های رترو را مستقیماً به تسک با مسئول و مهلت تبدیل کنید، آن‌ها را به بک‌لاگ اسپرینت بعدی اضافه کنید و در گزارش‌های تیمی وضعیت‌شان را دنبال کنید. شفافیت: دوایتفای محصول تیم ماست و این قالب رایگان است؛ روش این مقاله با هر ابزار دیگری هم اجرا می‌شود.

رترو و ارتباطش با بقیهٔ رویدادهای اسکرام

رترو در کنار بقیهٔ رویدادهای اسکرام معنا پیدا می‌کند: Sprint Planning کارها را می‌چیند، Daily وضعیت را هماهنگ می‌کند، Sprint Review خروجی را به ذی‌نفعان نشان می‌دهد و Retrospective فرایند تیم را بهبود می‌دهد. به‌عبارت دیگر، سه رویداد اول «انجام کار» را مدیریت می‌کنند و رترو «خودِ تیم» را بهتر می‌کند. اگر رترو را حذف کنید، تیم فقط «تولید» می‌کند و هرگز «یاد نمی‌گیرد».

خروجی رترو کجا ثبت می‌شود؟

خروجی رترو (اقدام‌های بهبود) باید به‌جایی برود که در اسپرینت بعدی دیده شود — معمولاً به بک‌لاگ اسپرینت بعدی یا به یک تسک مشخص با مسئول و مهلت. اگر اقدام فقط در یک یادداشت بماند، فراموش می‌شود. پس بلافاصله بعد از رترو، اقدام‌ها را به تسک تبدیل کنید تا چرخهٔ بهبود واقعاً بسته شود.

جمع‌بندی

قالب Retrospective خوب، بد و اقدام تغییر را در پایان هر اسپرینت ثبت می‌کند و تیم را در مسیر بهبود مستمر نگه می‌دارد. فضای امن بسازید، فقط یک تا دو اقدام کوچک با مسئول انتخاب کنید و در اسپرینت بعدی پیگیری‌شان کنید. یادتان باشد: رترو برای بهبود است، نه سرزنش — و بدون اقدام، فقط یک جلسهٔ حرف است.

اگر موضوع قالب Retrospective برایتان مفید بود، پیشنهاد می‌کنیم نرم افزار مدیریت هزینه پروژه ها و نرم افزار مدیریت مالی پروژه را هم بخوانید.