معرفی و تعریف
بهبود مستمر فرایند تیم توانایی مشاهده شیوه واقعی کار تیم، یافتن مسئلههای تکرارشونده و اجرای تغییرهای کوچک و قابلسنجش برای بهتر شدن جریان کار است. هدف این مهارت برگزاری صرف جلسه بازنگری یا رتروسپکتیو (Retrospective) نیست؛ بلکه تبدیل مشاهدهها و بازخوردها به اقدام مشخص، دارای مالک و قابل پیگیری است.
فرد دارای این مهارت میان نشانه و علت تفاوت میگذارد. مثلاً «کارها دیر تمام میشوند» یک نشانه است، اما وابستگی به تأیید یک نفر، کارهای بزرگ یا تغییر مداوم اولویتها میتواند علت باشد. سپس بهجای تغییرهای گسترده و مبهم، یک فرضیه و آزمایش کوچک طراحی میکند.
اسکراممستر، مدیر محصول، سرپرست فنی و اعضای تیمهای محصول و نرمافزار از این مهارت استفاده میکنند. خروجی خوب آن فرایندی بینقص نیست؛ یادگیری مداوم درباره این است که چه تغییری برای همان تیم و در همان شرایط مفید بوده است.
اهمیت و کاربردها
چرا این مهارت مهم است؟
در تیمهای نرمافزاری، مسئلههایی مانند طولانی شدن زمان تحویل، کارهای نیمهتمام، وابستگیهای مبهم و تکرار خطاها فقط با تلاش بیشتر حل نمیشوند. تیم باید بتواند روش کار خود را بررسی کند و تغییرهای مؤثر را از راه آزمون و شواهد تشخیص دهد.
این مهارت برای اسکراممستر نقش محوری دارد، زیرا او به تیم کمک میکند بازنگری را به تصمیم عملی تبدیل کند. مدیران محصول و لیدهای فنی نیز به آن نیاز دارند، چون تغییر اولویتها، گلوگاههای تصمیمگیری و کیفیت همکاری میان نقشها بر خروجی محصول اثر میگذارد.
برای ارائه این مهارت در مصاحبه یا همکاری حرفهای، بهتر است یک نمونه مستند ارائه کنید که شامل موارد زیر باشد:
مسئله اولیه
فرضیه
اقدام دارای مالک
معیار بررسی
نتیجه چرخه بعدی
چنین نمونهای توانایی شما در پیگیری اثر تغییر را روشنتر از شرح نظری مفاهیم اسکرام (Scrum) نشان میدهد.
کاربردها
-
تبدیل خروجی بازنگری اسپرینت به اقدام
تیم یک مسئله را انتخاب میکند، برای اقدام مالک و موعد تعیین میکند و در بازنگری بعدی اثر آن را بررسی میکند.
-
کاهش کارهای نیمهتمام
با بررسی تعداد کارهای همزمان و علت توقف آنها، تیم محدودیت کار در جریان یا روش روشنتری برای رفع وابستگیها آزمایش میکند.
-
بهبود کیفیت آمادهسازی کارها
تیم معیارهای آماده بودن آیتمهای بکلاگ (Backlog) را بررسی میکند تا ابهام نیازمندی یا تغییرهای دیرهنگام کمتر شود.
-
رفع گلوگاه در فرایند تحویل
زمان انتظار میان توسعه، بازبینی کد، تست و انتشار بررسی میشود تا گلوگاه اصلی با یک تغییر محدود آزموده شود.
-
یادگیری از رخدادهای تکرارشونده
پس از خطا، تأخیر یا اختلال، تیم بهجای مقصرجویی عوامل فرایندی را بررسی و یک اقدام پیشگیرانه تعریف میکند.
ابزارهای مرتبط
پیشنیازها
شروع این مهارت با دانستن پیشنیازهای زیر هموارتر میشود.
- تجربه مشارکت در یک تیم و مشاهده یک چرخه کاری واقعی
مسیر یادگیری بهبود مستمر فرایند تیم
-
۶ ساعت
چرخه کار تیم را قابل مشاهده کنید
مفاهیم زیر را یاد بگیرید:
جریان کار
کار در جریان (WIP)
زمان انتظار
تحویل
بازخورد برد واقعی یا نمونه را از زمان ورود کار تا پایان آن ترسیم کنید و محلهای توقف، بازگشت و انتظار را مشخص کنید.
اگر تیم از Jira استفاده میکند، وضعیت و تاریخ جابهجایی آیتمها را از همان برد بررسی کنید. برای بردهای سادهتر، دادهها را در Google Sheets، LibreOffice Calc یا Microsoft Excel ثبت کنید تا شمار آیتمهای نیمهتمام و زمان انتظار پیش و پس از تغییر قابل مقایسه باشد.
برآورد ۴۸ ساعت برای فردی است که این تجربه را دارد و هفتهای ۴ تا ۶ ساعت روی یک برد واقعی تمرین میکند؛ بازه معمول ۳۶ تا ۶۰ ساعت است.
-
۸ ساعت
مسئله فرایندی را دقیق صورتبندی کنید
میان برداشت، نشانه و علت احتمالی تمایز بگذارید. مسئله را با مشاهده مشخص بیان کنید؛ مثلاً بهجای «تیم هماهنگ نیست»، بنویسید «آیتمها پس از شروع توسعه بهدلیل ابهام نیازمندی متوقف میشوند».
-
۱۰ ساعت
بازنگری را به گفتوگوی امن و متمرکز تبدیل کنید
جلسه بازنگری را با دادهها و نمونههای واقعی پیش ببرید، نه قضاوت درباره افراد. تمرین کنید که گفتوگو را به یک یا دو مسئله قابل اثرگذاری محدود کنید و از تیم برای یافتن گزینههای تغییر کمک بگیرید.
-
۱۰ ساعت
آزمایش کوچک و قابلسنجش طراحی کنید
برای هر بهبود، موارد زیر را مشخص کنید:
فرضیه
دامنه
مالک
بازه اجرا
معیار بررسی
نمونه مناسب این است: «اگر بازبینی کد حداکثر تا روز کاری بعد انجام شود، زمان انتظار آیتمها کاهش مییابد.» از اقدامهای مبهم مانند «ارتباطمان را بهتر کنیم» پرهیز کنید.
اقدام و تصمیم مربوط به آن را در Confluence یا یک صفحه مشترک ثبت کنید تا مالک، معیار و دلیل انتخاب آزمایش در چرخه بعدی در دسترس باشد.
-
۸ ساعت
اثر تغییر را با شواهد بررسی کنید
پیش و پس از آزمایش، دادههای سادهای مانند تعداد آیتمهای نیمهتمام، زمان انتظار، تعداد بازگشت کار یا بازخورد اعضای تیم را مقایسه کنید. نتیجه را موفق یا ناموفق مطلق ندانید؛ بررسی کنید فرضیه چه چیزی به تیم آموخته است.
-
۶ ساعت
اقدامها را در چرخه بعدی پیگیری کنید
در بازنگری بعدی، وضعیت اقدام قبلی و اثر آن را مرور کنید. تصمیم بگیرید آزمایش ادامه یابد، اصلاح شود یا متوقف شود و دلیل تصمیم را ثبت کنید. این پیگیری تفاوت اصلی میان بهبود مستمر و فهرستسازی از مشکلات است.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیشزمینه شما میتواند کمتر یا بیشتر باشد.
پروژههای تمرینی
در ادامه، مهمترین موارد این بخش به تفکیک معرفی شدهاند.
-
دفتر اقدامهای بازنگری یک تیم فرضی
توضیح پروژه: برای سه بازنگری فرضی، مسئله، شواهد، اقدام، مالک، معیار بررسی و نتیجه چرخه بعدی را در یک جدول ثبت کنید. دستکم یک اقدام را پس از مشاهده نتیجه اصلاح یا متوقف کنید.
-
تحلیل گلوگاه یک برد کاری
توضیح پروژه: از یک برد Jira یا نمونه مشابه، ده آیتم کاری را بررسی کنید. محل توقف اصلی را شناسایی و یک آزمایش دو هفتهای برای کاهش آن طراحی کنید.
-
تسهیل بازنگری با خروجی قابل پیگیری
توضیح پروژه: یک جلسه بازنگری ۴۵ تا ۶۰ دقیقهای برای تیم تمرینی طراحی و اجرا کنید. خروجی باید حداکثر دو اقدام، مالک هر اقدام و معیار بررسی روشن داشته باشد.
پرسشهای رایج درباره بهبود مستمر فرایند تیم
در این بخش، به تعدادی از پرسشهای رایج درباره این مهارت پاسخ داده شده است.
آیا بهبود مستمر فرایند تیم همان برگزاری رتروسپکتیو است؟
خیر. رتروسپکتیو فقط یکی از موقعیتهای یافتن فرصت بهبود است. بهبود مستمر زمانی رخ میدهد که تیم یک تغییر مشخص را اجرا، اثر آن را بررسی و درباره ادامه یا اصلاح آن تصمیم بگیرد.
برای شروع بهبود فرایند، چند اقدام باید انتخاب کنیم؟
برای بیشتر تیمها، یک یا دو اقدام کوچک در هر چرخه مناسبتر است. اقدامهای زیاد معمولاً مالک و پیگیری روشن پیدا نمیکنند و اثر هر تغییر قابل تشخیص نمیماند.
اگر داده دقیق از عملکرد تیم نداشته باشیم، چگونه بهبود را شروع کنیم؟
با مشاهدههای ساده شروع کنید: تعداد کارهای نیمهتمام، زمان انتظار، علت بازگشت کار یا نمونههای مشخص از تأخیر. سپس یک معیار ساده و ثابت برای آزمایش بعدی ثبت کنید.
آیا اسکراممستر باید همه مشکلات فرایند را حل کند؟
خیر. اسکراممستر معمولاً گفتوگو و آزمایش را تسهیل میکند، اما مالکیت بهبود باید تا حد امکان در خود تیم باشد. برخی موانع بیرونی نیز به همکاری مدیران یا ذینفعان نیاز دارند.
چه زمانی یک آزمایش فرایندی را متوقف کنیم؟
وقتی شواهد نشان دهد اثر مطلوب نداشته، هزینه آن بیش از فایده است یا شرایط مسئله تغییر کرده است. توقف یک آزمایش ناموفق شکست نیست، اگر نتیجه آن ثبت و در تصمیم بعدی استفاده شود.
