استراتژی هایی برای مدیریت کارهای پیش بینی نشده در طول اسپرینت

زهرا نخعی، مدیر کسب و کار در هلدینگ فناوری بنتک

“چطور کارهای برنامه ریزی نشده ای که وسط اسپرینت از راه میرسن رو مدیریت کنم؟” این سوالی است که خیلی وقتها پرسیده میشود و البته پاسخ به آن آنقدرها که تصور میشود ساده نیست.

اولین چیزی که باید خوب درک کنیم این است که کار برنامه ریزی نشده، ذاتا “مشکل” نیست. بلکه معمولا علامتی است از برخی ایشوهای واقعی که از چشمها مخفی مانده. این خیلی مهم است که کشف کنید عامل و ریشه اصلی اینکه کارهای پیش بینی نشده برای شما ایجاد میشود چیست. تنها در این صورت است که میتوانید مساله را برطرف کنید یا حتی به چگونگی زندگی کردن با آن تسلط پیدا کنید (که در بسیاری از موارد منطقی ترین گزینه است).

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

1. اصلاحات سریع

استراترژی هایی که در این دسته بررسی میکنیم، جریان کاری تیم را با هزینه کمی به حالت پایدار برمیگردانند. هدف این استراتژی ها این نیست که مسایلی که در لایه های زیرین وجود دارد را رفع کنند. گاهی اوقات، شما اول باید یک مشکل را با یک راه سریع حل کنید، و بعد تازه فرصت میکنید که به راه عمیق تر و اصولی تر بپردازید.

1.1 پذیرش کار برنامه ریزی نشده

مثال 1 : یک تیم داریم که در میانه اسپرینت است. ناگهان یک یوزر گزارش باگی را برای یک فیچری که اخیرن ریلیز شده گزارش میکند. این باگ خیلی بزرگ نیست ولی خیلی هم ریز نیست. برداشت این است که اگر بلافاصله رفع نشود، در بک لاگ محصول گم خواهد شد. مالک محصول درخواست میکند که در اولین فرصت که کسی از تیم وقت کرد، این باگ را فیکس کند.

مثال 2 : تیم یک یوزر استوری را تمام کرده و آن را به ذینفعان دمو میدهد تا فیدبک بگیرد. مشخص میشود که برخی از جزییات مهم، موقع توصیف داستان دیده نشده بودند. در نتیجه فیچر دقیقا آنچه انتظار میرفته نیست. ذینفعان از تیم درخواست میکنند که قبل از تکمیل استوری، نواقص آن را برطرف کنند.

چه باید کرد؟

کار پیش بینی نشده را بپذیرید و به بک لاگِ اسپرینت اضافه کنید.

کی به کار می آید؟

میدانیم که عدم قطعیت در ذات نرم افزار است. دلیل اصلی دموی زودهنگام فیچرها این است که ناسازگاری هایی شبیه مثال 2 زودتر کشف بشوند. این موارد هرچه زودتر کشف بشوند، رفع آنها ساده تر است. در صورتی که یک تیم واقعا از فرایندهای چابکی تبعیت کند، باید از فرصت بازخورد زودهنگام استقبال و به نفع خودش استفاده کند. نکته دیگری که متدلوژی های چابک به ما می آموزد این است که اگر تیم احساس راحتی میکند، نیازی به اینکه آداب و رسوم اضافه ای بچینیم نیست. ممکن است در مثال 1 رفع باگ گزارش شده برای تیم خیلی راحت تر از این باشد که بخواهد جلسات بررسی اولویت دهی استوری های بک لاگ را برگزار کند. بنابراین، تا وقتی که سایز کار جدید کوچک است، و تیم میتواند بدون اینکه هدف اسپرینت دچار ریسک جدی شود، تغییر scope را بپذیرد، نیاز به کار اضافه نیست.

هزینه ها و خطرات

تیم ممکن است همه آن چه برای یک اسپرینت برنامه ریزی کرده را نتواند تحویل بدهد. با این وجود این موضوع در دراز مدت مشکلی ایجاد نمیکند. اگر تیم، داده های مربوط به اسپرینتهای قبلی خود را تحلیل کند، میتواند اطلاعات خوبی درباره کارهای برنامه ریزی نشده پذیرفته شده خودش به دست بیاورد. فقط کافی است اندکی از “ظرفیت” خود برای اسپرینت های بعدی کم کند. فرایند برنامه ریزی به صورت خودکار این مساله را مدیریت میکند و در مقیاس چند اسپرینت اثر نامطلوبی نخواهد گذاشت.

1.2 تکمیل بک لاگ فعلی و برنامه ریزی ایشوی جدید برای اسپرینت بعدی

مثال 1 : مانند مثال دوم بخش قبل، تیم یک یوزر استوری را کامل میکند و به ذینفعان دمو میدهد. در حین دمو تیم متوجه میشود که یک بخش بزرگ از فیچرها جامانده که برای نسخه دادن حیاتی است. مجددن ذینفعان از تیم خواهش میکنند که قسمت از قلم افتاده را هم پیاده سازی کنند.

چه باید کرد؟

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

 

کی به کار می آید؟

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

 

هزینه ها و خطرات

اندازه بزرگ یک نیازمندی، معمولا نشان دهنده این است که این بخش جدید، چیز مهمی است! و ارائه دادن استوری اولیه احتمالا برای یوزر زیاد با ارزش نخواهد بود. ذینفعان دلخور خواهند شد اگر متوجه شوند که فیچر مورد نظرشان تا اسپرینت بعدی به تاخیر افتاده است. هرچند حالتهایی هم وجود دارد که استوری های بزرگ آنچنان هم حیاتی نیستند و میشود یکی دو اسپرینت دیگر برایشان صبر کرد. در هر صورت، این وظیفه مالک محصول است که انتظارات ذینفعان را مدیریت کند

 

1.3 جایگزین کردن

مثال 1 : تیم در هفته دوم اسپرینت است. یک باگ مهم گزارش میشود. تیم متوجه میشود که فیکس کردن آن ساده نیست و زمان قابل توجهی برای رفع آن نیاز است. اما چاره ای هم نیست. باگ مهمی است. پس تیم به ناچار شروع به کار برروی رفع کردن آن میکند.

مثال 2 : در میانه اسپرینت مالک محصول یا یک فیچر جدید می آید و معتقد است که این استوری اولویت بالایی دارد و متقاضی است که به اسپرینت اضافه شود.

 

چه باید کرد؟

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

 

کی به کار می آید؟

استفاده از این استراتژی  خیلی سرراست است. وقتی که یک نیاز است که یک قطعه بزرگ کاری به اسپرینت اصافه شود، باید معادلش را از اسپرینت خارج کنید. ممکن است سوال شود که به چه جور نیازی میشود گفت “بزرگ” ؟ جواب این سوال را باید تیم توسعه دهنده بدهد.

 

هزینه ها و خطرات

از آنجایی که برای استوری های خارج شده احتمالا تعهداتی به ذینفعانی داده ایم، یک فرایند مدیریت ذینفعان در این حالت ضروری میشود.

1.4 بافر

مثال 1: تیمی داریم که مدتهاست دارای یک سیستم back-end است و به مرکز تخصصی همه سوالات مربوط به back-end تبدیل شده است. در هر اسپرینت، وقت زیادی از اعضا صرف پاسخ دهی سوالات بقیه تیمها در خصوص آن back-end میشود

چه باید کرد؟

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

کی به کار می آید؟

بافر را زمانی استفاده کنید که شرایط غیر قابل برنامه ریزی، تکرار شونده و غیر قابل اجتناب بوده و سایز استوریهای پیش بینی نشده قابل توجه باشد. مثالهایی که میشود برای این شرایط زد

تیم یک تخصص منحصر به فرد دارد و باید به دیگران مشورت بدهد *

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

با این وجود، اندازه بافر نباید بیش از 2- تا 30 درصد ظرفیت تیم باشد و تیم باید به سایر استوری های برنامه ریزی شده است دست یابد.

 

هزینه ها و خطرات

بدیهی است که نرخ تحویل موارد نقشه راه، متناسب با اندازه بافر کاهش می یابد. این ممکن است به خودی خود مشکلی نداشته باشد اما یک جنبه تاریک وجود دارد. کار غیرمنتظره غالباً ناشی از ناکارآمدی های سازمانی یا فنی است ، مانند وابستگی های چند تیمی ، کدهای legacy یا کیفیت پایین محصول. وقتی بافرها را معرفی می کنیم، به جای تولید ارزش و رفع مشکلات واقعی، مثل یک آتش نشان، فقط به سرعت آتش را خاموش میکنیم بدون اینکه به علت بروز آتش بپردازیم. دلیل دیگر اینکه موقع استفاده از بافرها خیلی مراقب باشید این است که نگهداری از آنها خیلی سخت است؛ به ویژه هنگامی که تصمیم می گیرید اندازه آن را برنامه ریزی کنید. اندازه بافر برنامه ریزی بر این فرض ضمنی متکی است که تیم می تواند تقاضا را کنترل کند تا وقتی که بافر صفر شود. ولی آنچه در اکثر مواقع اتفاق میفتد این است که تیم حتی بعد از صفر شدن اندازه بافر هم  نمیتواند به طور موثر، فشار کار بدون برنامه ریزی فوری را کنترل کند. و عملا به جای پیش بینی فقط یک متغیر بسیار ناپایدار، اکنون مجبورید دو مورد را پیش بینی کنید.

راستش اگر نمیتوانید استفاده از بافر را به درستی کنترل کنید و در تله آن گیر افتاده اید، بهتر است از لیست زیر به دنبال راه هایی برای اعمال اقدامات بهبود مستمر باشید.

2. بهبود مستمر

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

2.1 اولویت دهی به استوری ها را بهبود دهید

مثال 1: سه روز از شروع اسپرینت نگذشته که مالک محصول ناگهان می آید و یک دسته بزرگ از یوزر استوری ها را با خود می آورد و میگوید که اولویت ها ناگهان تغییر کرده است. در پایان اسپرینت، هیچ کاری تکمیل نشده و چیزی برای تحویل دادن به مشتری نداریم.

مثال 2: پس از چند روز از شروع اسپرینت، مالک محصول درخواست میدهد که یک یوزر استوری به اسپرینت اضافه شود. برخی ذینفعان درخواست پیاده سازی فوری آن را کرده اند. چند روز بعد دوباره مشابه همین درخواست می آید و این بار از ذینفع دیگری. او هم عجله دارد و کارش فوری است. این اتفاق چند بار در طول اسپرینت می افتد و نهایتا تیم به اندازه ظرفیت معمول خودش هم نمی تواند کارهایش را تکمیل کند.

چه باید کرد؟

با مالک محصول کار کنید که چگونه “نه” گفتن را یاد بگیرد. با ذینفعان کار کنید تا انتظارات صحیحی از تحویل فیچرها داشته باشند. توضیح دهید که تیم استوری های “فوری” را باید ندرتا بپذیرد. در صورتی که نیاز است درباره تعریف “فوری” و اینکه هرچند وقت یک بار تیم میتواند پذیرش یک کار “فوری” را مدیریت کند با ذینفعان توافق کنید.

 

کی به کار می آید؟

همانطور که در مثالها دیده شد، مواقعی که کارهای برنامه ریزی نشده، اکثرا استوری های جدید ارجاع شده از سمت مالک محصول یا ذینفعان هستند باید به مساله اولویت دهی خیلی جدی تر فکر شود. خیلی از اوقات آیتمها واقعا آنقدرها که در ابتدا به نظر میرسد فوری نیستند و میتوان با روشهایی آنها را به اسپرینت بعدی موکول کرد.

 

هزینه ها و مخاطرات

نیازمند یک مربی برای مالک محصول و مذاکره با ذینفعان هستید که ممکن است خیلی هم پرچالش باشد. چراکه درگیر یک چالش انسانی میشوید که یک فرد باید انتظاراتش از دریافت نتیجه سریع را تغییر دهد.

2.2 کیفیت را بهبود دهید

مثال 1: یک تیم تعداد زیادی باگ را در طول یک اسپرینت دریافت میکند. خیلی از آنها حیاتی هستند و باید بلافاصله رفع شوند. این اتفاق در همه اسپرینت ها یا اکثرشان رخ میدهد و جریان کاری تیم تکمیل ایشوهای اسپرینت را خدشه دار میکند. اسپرینت ها بی نظم است. اثر این اتفاق در نمودارهای burn down chart و velocity کاملا مشهود است. تیم احساس کنترل بر آنچه انجام میدهد را از دست داده است.

 

چه باید کرد؟

ریشه کیفیت پایین را تحلیل کنید. آیا این به این دلیل است که تیم تحت فشارِ رساندن فیچرهای کسب و کار است و برای رسیدن به ددلاین ها سناریوهای فرعی و corner threshold ها را بررسی نمیکند؟ آیا تستهای خودکارتان کافی نیست و پوشش کد قابل قبولی ندارد؟ آیا یک مساله زیرساختی وجود دارد که باعث میشود برنامه هر چند وقت یک بار خراب شود؟ وقتی ریشه مشکل پیدا شد، حتما به اندازه کافی وقت بگذارید و آن را برطرف کنید. معمولا بیش از یک دلیل برای بروز مشکل وجود دارد و باید راهکارهای مختلفی استفاده کنید تا به نتیجه برسید.

کی به کار می آید؟

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

 

هزینه ها و مخاطرات

پیدا کردن ریشه باگها چندان کار ساده ای نیست. از آن سخت تر پیاده سازی اصلاحات مورد نیازش است. وقتی به شرایط بد کیفیت که در بالا توصیف شد میرسیم، یعنی خیلی کار داریم تا اوضاع را درست کنیم. صرف زمان زیاد برای رفع کردن ریشه باگها به معنی این است که فعلا نمیتوانیم فیچر جدید تحویل بدهیم و این گاهی خیلی دردناک میشود. آیا واقعا میخواهیم سرمایه “ظرفیت تیم” را صرف این کنیم که فقط محصول موجود را قابل نگهداری نماییم؟ آیا کند شویم به این امید که بعدن سریعتر خواهیم شد؟ این تصمیم چه اثرات و عواقبی برای ما خواهد داشت؟ در چنین شرایطی، تیم باید برای trade-off تصمیم بگیرد.

2.3 وابستگی ها را از بین ببرید

 

مثال 1: تیم متخصصی داریم که یک سامانه backend دارد. یک تیم دیگر هست که اخیرن توسعه یک میکروسرویس را آغاز کرده است. این میکروسرویس، از سامانه backend استفاده و متدهای آن را فراخوانی میکند. آنها متوجه میشوند که backend برخی چیزهایی که نیاز دارند را ندارد. بنابراین درخواستهای زیادی دائما به سمت تیم backend میرود که آیتمهایی را اضافه نمایند.

چه باید کرد؟

باید تا جای ممکن وابستگی تیم B را به تیم A از بین ببرید. برای این کار هر مجوز یا دسترسی به کد که امکانش را دارید به آنها بدهید. مسوولیت ها و تصمیم گیری ها را به خودشان بسپرید. مثلا اجازه دهید یک زیرسیستم ایجاد کنند و نیازهای خود را در آن ایجاد نمایند. به آنها آموزش دهید تا در کد مشترک، کد بزنند و برای این کار فرایندهای “مرور کد” را سفت و سخت تر بگیرید تا کیفیت افت نکند. ممکن است یک نفر از تیم A به تیم B ملحق شود تا بتواند شکل گیری طراحی جدید را تسریع کند.

 

کی به کار می آید؟

این استراتژی مربوط به موقعیت هایی است که یک تیم برای برخی از کارهای خود به یک تیم دیگر وابسته است و درخواستهایش موجب وقفه جدی در کار آن تیم میشود.

هزینه ها و مخاطرات

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

2.4 فرایند را عوض کنید

مثال 1: تیم بارها در طول اسپرینت با اینتراپت مواجه میشود. اهداف و بک لاگ اسپرینت چندین بار تغییر میکنند و استوری های قبلی منتفی میشوند. کارهای برنامه ریزی نشده معمولا از سمت مالک محصول می آیند. بررسی ها و تحلیل ها نشان میدهد که واقعا نمیشود برای تغییر این شرایط کاری کرد. واقعیت امر این است که تیم در حال تولید محصول در حوزه ای است که در آن رقابت شدید است. تاخیر در یک ویژگی مهم، حتی برای چند روز، ممکن است شرکت را از رقابت در این کسب و کار خارج کند.

مثال 2: تیم روی یک محصول خیلی قدیمی با legacy code base کار میکند. آنها هر best practice شناخته شده ای را به کار میبرند و سخت برای بهبود تلاش میکنند. علی رغم همه اینها، حجم بدهی های فنی و بزرگی محصول اجازه نمیدهد که حتی یک یوزر استوری کوچک را در اسپرینت تکمیل کنند. حل مشکل، از توان تیم خارج شده است. برخی از تأثیرات مثبت قابل مشاهده است، اما پیشرفت بسیار کند است. تیم متوجه می شود که به این زودی ها موفق نخواهد شد و باید با شرایط موجود کنار بیاید.

 

چه باید کرد؟

باید به روش متفاوتی فکر کنید و طرحی نو در اندازید! اجرای اسپرینت ها یا Scrum تنها راه موجود برای توسعه نرم افزار نیست. آن را کنار بگذارید و از یک فرایند دیگر (مثلا Kanban) استفاده کنید. بعنوان یک پیشنهاد، برای انتقال به Kanban میتوانید با کوتاه تر کردن بازه زمانی اسپرینت شروع کنید. یا هر روش دیگری که متناسب با شرایط سازمان خودتان باشد.

کی به کار می آید؟

تمرکز اصلی این استراتژی سازگاری با واقعیت عینی است. وقتی کار غیر برنامه ریزی شده ذاتاً اجتناب ناپذیر باشد و به دلیل شرایط بیرونی خارج از کنترل شما باشد بهتر است متناسب با شرایط فرایندهای خود را تغییر دهید. این یک اقدام موقتی است که به شما کمک می کند برای اجرای فرایندهای اصولی تر مدتی زمان بخرید.

 

هزینه ها و مخاطرات

دلیلی وجود داشته که این استراتژی را بعنوان آخرین استراتژی معرفی کردیم . با وجودی که این راهکار ممکن است راه حل واقعی مشکل شما باشد، اما باید آنرا با آگاهی عمیق و کاملی انتخاب کنید و به کار ببندید. باید کاملا مطمئن شوید که واقعا شرایط بیرونی خارج از کنترل دارید. قبل از تلاش برای تغییر فرایند، تجزیه و تحلیل کاملی از وضعیت انجام دهید و سایر استراتژی های این لیست را امتحان کنید. مواظب باشید در این دام نیفتید که به جای حل اصولی مشکلات خودتان، صورت مساله را پاک کنید.

 

 

ترجمه ای از مقاله : https://medium.com/agilelab/strategies-for-handling-unplanned-work-during-sprint-2f89697509ff