
Scrum یا Kanban؛ نصفشدن زمان تحویل هنوز حکم عمومی نیست

اگر تیم میتواند هدفی مشترک برای اسپرینت تعیین کند و با وجود تغییرات روزمره آن را حفظ کند، Scrum انتخاب مناسبی است. اگر کار فوری پیوسته اولویتها را عوض میکند، Kanban با پذیرش کار بر پایهٔ ظرفیت، گزینهٔ مناسبتری برای بررسی است. در پژوهش موردی Software Innovation، از میان دادههای بیش از ۱۲ هزار قلم کار، موارد با طولانیترین زمان از محاسبه کنار گذاشته شدند و میانگین زمان عبور از وضعیت «بعدی» تا «آمادهٔ انتشار» پس از گذار از Scrum به Kanban تقریباً نصف شد. این شاخص زمان دریافت نسخه توسط مشتری را اندازه نمیگرفت و نتیجهٔ یک شرکت، وعدهای برای همهٔ تیمها نیست.
انتخاب به الگوی ورود کار، امکان حفظ هدف دورهای، مقدار کار نیمهتمام و کیفیت خروجی بستگی دارد. تیمی که بیشتر وقت خود را صرف ساخت یک قابلیت مرتبط میکند، از بازبینی منظم نتیجه سود میبرد؛ تیمی که باید به خطاها و درخواستهای زمانحساس پاسخ دهد، به قاعدهای روشن برای ورود کار تازه نیاز دارد. هیچکدام از این وضعیتها با نام چارچوب بهتنهایی توصیف نمیشود.
چه زمانی هدف اسپرینت قابل حفظ است؟
راهنمای رسمی Scrum اسپرینت را دورهای با طول ثابت و حداکثر یک ماه تعریف میکند. برنامهریزی، گفتوگوی روزانه، بازبینی و بازنگری درون همین دوره انجام میشوند. هدف اسپرینت جهت مشترک کار است؛ تیم میتواند با آموختن نکتهای تازه، دامنهٔ اقلام انتخابشده را با مالک محصول دوباره تنظیم کند، به شرط آنکه هدف را به خطر نیندازد.
این سازوکار برای کاری مناسب است که اقلام آن به نتیجهای قابل بررسی وصل میشوند. برای مثال، اگر تیم محصول در حال ساخت یک قابلیت مشخص است، بازبینی پایان دوره فرصتی برای دیدن حاصل کار و اصلاح اولویتهای بعدی میدهد. پرسش تعیینکننده این است که آیا درخواستهای تازه معمولاً میتوانند منتظر بمانند یا در چارچوب همان هدف جا بگیرند. وقتی بیشتر درخواستها هدف را کنار میزنند، کوتاه کردن اسپرینت بهتنهایی تعارض میان برنامه و ورودی کار را رفع نمیکند.
ورود کار فوری چه اثری بر انتخاب دارد؟
در پشتیبانی محصول، رسیدگی به خطا و برخی کارهای عملیاتی، زمان ورود درخواست و فوریت آن از پیش معلوم نیست. جریان پیوسته به تیم اجازه میدهد پس از تعیین اولویت و آزاد شدن ظرفیت، کار بعدی را آغاز کند. در این وضعیت، انتظار برای شروع اسپرینت بعدی ممکن است با نیاز واقعی درخواست سازگار نباشد؛ در مقابل، آغاز فوری همهٔ درخواستها نیز صفی از کارهای نیمهتمام میسازد.
بنابراین پیش از انتخاب Kanban باید معنی «فوری» روشن شود: چه درخواستی اجازه دارد از صف عادی جلو بزند، چه کسی این تصمیم را میگیرد و کدام کار جاری در نتیجه عقب میافتد. اگر بیشتر وقفهها را میتوان تا برنامهریزی بعدی نگه داشت، همان ورودیهای نامنظم دلیل کافی برای کنار گذاشتن Scrum نیستند. اگر وقفهها مکرر و زمانحساساند، سیاست پذیرش کار باید بخشی از روش روزانهٔ تیم باشد، نه تصمیمی که هر بار از نو گرفته میشود.
محدودیت کار در جریان چه مسئلهای را حل میکند؟
راهنمای Kanban از تیم میخواهد نقطهٔ شروع و پایان کار، وضعیتهای میان آنها، قواعد جابهجایی و شیوهٔ کنترل کار در جریان را تعریف کند. کار در جریان، اقلامی است که شروع شدهاند اما هنوز به نقطهٔ پایان نرسیدهاند. وقتی ظرفیت تعیینشده پر است، آزاد شدن جا علامت آغاز کار بعدی میشود. محدودیت WIP از این راه توجه تیم را به پایان دادن به کار باز و رفع مانعهای صف برمیگرداند.
فرض کنید کارهای توسعهیافته پیش از آزمون جمع شدهاند. افزودن کار تازه به توسعه، مشکل ظرفیت آزمون را حل نمیکند و ممکن است انتظار اقلام باز را طولانیتر کند. تیم میتواند پیش از شروع مورد بعدی، مانع آزمون یا بازبینی را برطرف کند. مقدار مناسب محدودیت برای همهٔ تیمها یکسان نیست؛ اندازهٔ اقلام و توان هر مرحله در آن اثر دارد. داشتن اسپرینت نیز به معنی شروع همزمان همهٔ اقلام انتخابشده نیست.
هزینهٔ جلسه را در برابر تصمیم حاصل از آن بسنجید
رویدادهای Scrum زمانی ارزش دارند که تصمیمی را ممکن کنند: برنامهریزی هدف را مشخص کند، بازبینی نتیجه را به نظر ذینفعان پیوند دهد و بازنگری به تغییر شیوهٔ کار برسد. وقتی جلسهها فقط وضعیت اقلام را تکرار میکنند، زمان هماهنگی مصرف میشود بیآنکه ابهامی برطرف شود. در عین حال، حذف اسپرینت نیاز به بازخورد محصول، رسیدگی به کارهای مانده و اصلاح سیاستهای ورود را از میان نمیبرد.
جریان Kanban به تقویم رویدادهای Scrum وابسته نیست، اما باید فرصتی برای دیدن کارهای متوقفشده و تصمیم دربارهٔ اولویتها داشته باشد. ممکن است تیمی بازبینی منظم با ذینفعان را حفظ کند و فقط شیوهٔ پذیرش و تکمیل کار را تغییر دهد. همچنین تیمی با اسپرینتهای مفید میتواند محدودیت کار در جریان بگذارد. هزینهٔ واقعی تغییر روش، افزون بر زمان جلسهها، شامل توافق دوباره بر قواعد ورود، مسئولیت تصمیمها و معنای «تمامشده» است.
زمان عبور و کیفیت را با تعریف یکسان بسنجید
کاهش میانگین زمان عبور فقط وقتی برای تصمیمگیری مفید است که نقطهٔ شروع و پایان، نوع کار و شیوهٔ محاسبه روشن باشند. در همان مطالعهٔ موردی، محاسبهٔ زمان عبور به پایان کار در وضعیت «آمادهٔ انتشار» میرسید؛ مشتری ممکن بود نسخه را دیرتر دریافت کند. اقلام دارای زمانهای بسیار طولانی نیز از آن محاسبه حذف شده بودند. پس نمیتوان عدد بهدستآمده را بیتوضیح با زمان ثبت درخواست تا تحویل به مشتری در تیمی دیگر مقایسه کرد.
کنار زمان عبور، شمار اقلام تکمیلشده، سن کارهای هنوز باز و خطاهای پس از تکمیل را هم ببینید. اگر اقلام تازه کوچکتر شده باشند، میانگین زمان میتواند بهتر شود بیآنکه ظرفیت تیم برای کارهای دشوار افزایش یافته باشد. اگر کار زودتر تمام شود اما خطاهای بیشتری به استفادهکننده برسد، سرعت ظاهری بخشی از هزینه را به بعد منتقل کرده است. کیفیت در این مقایسه یک معیار همراه است، نه نتیجهای که از کوتاه شدن زمان بهطور خودکار به دست آید.
مسیر انتخاب برای تیم
- هدف مشترک پایدار است؟ اگر بیشتر اقلام به یک نتیجهٔ محصولی خدمت میکنند و درخواست فوری استثناست، Scrum مبنای معقولی است. تیم باید بتواند هنگام تغییر دامنه، همچنان توضیح دهد که اسپرینت برای رسیدن به چه نتیجهای ادامه دارد.
- کار زمانحساس مرتب برنامه را قطع میکند؟ اگر پاسخ مثبت است، Kanban را با قاعدهٔ صریح اولویت و پذیرش کار بررسی کنید. این انتخاب زمانی معنا دارد که تیم بتواند ظرفیت آزاد را تشخیص دهد و اقلام باز را تا پایان دنبال کند.
- مشکل اصلی انباشت کار نیمهتمام است؟ تغییر چارچوب ممکن است لازم نباشد. راهنمای Kanban برای تیمهای Scrum بهصراحت امکان بهکارگیری تابلو، محدودیت WIP و سنجههای جریان را در کنار اسپرینت توضیح میدهد.
- دادهٔ قابل مقایسه ندارید؟ پیش از نسبت دادن تغییر عملکرد به یک روش، برای هر نوع کار نقطهٔ شروع و پایان یکسان تعیین کنید. روند زمان عبور و کیفیت همان تیم، همراه با تغییر ترکیب کارها، مبنای قابلاتکاتری از نتیجهٔ عددی یک شرکت دیگر برای انتخاب است.
بیشتر بخوانید:
مقالات مرتبط


Bitwarden یا 1Password؛ قیمت کمتر با تجربهٔ روانتر رقابت میکند

عاملهای OpenAI داخل AWS اجرا میشوند؛ پیشنمایش فقط در سه منطقه است

پیام بدهیم یا جلسه بگذاریم؟ قانون سه رفتوبرگشت تصمیم را روشن میکند

آمریکا و چین کانال بحران AI میسازند؛ هنوز تعریف «حادثه» روشن نیست

GitHub Copilot یا Cursor؛ نوع کار مهمتر از قیمت ماهانه است
عضویت در خبرنامه
تازهترین اخبار Web3، هوش مصنوعی و رمزارز را مستقیم در صندوق ایمیل خود دریافت کنید.