بکارگیری کانبان برای احیای پروژه‌های در حال شکست بخش سوم

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

جداسازی برنامه‌ریزی و ریتم‌های تحویل

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

پیش از این، به سادگی به تیم توسعه گفته می‌شد که روی چه اقلام کاری، کار کند و کی باید کار تمام شود. علاوه بر مشکلات مرتبط با مدل وظیفه‌ای وقفه‌گرا (interrupt-driven) که پیش از این ذکر شد، توسعه‌دهندگان هرگز مهلت‌های انجام (deadline) کار را جدی نمی‌گرفتند زیرا هیچ حس مالکیتی نسبت به براورد اقلام کاری، نداشتند. مدیر پروژه که به مشتری تعهد می‌داد، درک درستی از زمان اتمام اقلام کاری نداشت. پس چیزی را به مشتری می‌گفت که مشتری دوست داشت بشنود. در نتیجه مهلت‌های انجام کار به ندرت رعایت می‌شد. در نهایت مدیر پروژه همه اعتبار خود را نزد تیم توسعه‌ و مشتری از دست می‌داد. با اعلام اضطراری هر موضوعی، مدیر پروژه محیطی ساخت که در آن به هیچ گونه موضوعی با هر نوع فوریتی رسیدگی نمی‌شد.

در رویکردهای چابک، ضروری است تیمی کار را انجام دهد که اتمام کار را براورد‌ می‌کند. از این رو، باید اطمینان حاصل کنیم که براورد وظیفه، خودش موجب حداقل میزان وقفه در وظیفه‌های توسعه شود.

اولویت بندی کنید

اگر همه چیز مهم است، یعنی هیچ چیز مهم نیست. یکی از کلیدهای ایجاد جریان مستمر(continuous-flow) و سیستم کششی (pull system) مثل کانبان برای هر شخص در تیم، این است که مهمترین قلم کاری بعدی را درک کند و با آن موافق باشد. اگر همه بدانند کدام قلم کاری باید به تابلوی بعدی کشیده شود، تیم نیازی ندارد پیوسته هزینه هماهنگیِ فهمیدن اینکه چه کاری باید بعدا انجام شود را برعهده گیرد.

نقش بک‌لاگ در اولویت بندی

در واقع بک‌لاگ سازوکار اصلی برای مدیریت فهرست کامل اقلام کاری انتخاب شده است. یک فهرست اولویت‌بندی شده از اقلام کاری بالقوه که توسط مالک محصول و کاربران مشخص شده است. داستان‌های کاربر و نقص‌ها (User stories and defects)، انواعی از اقلام کاری هستند. کاربران و دیگر ذینفعان در هر لحظه می‌توانند درخواست یک قلم کاری جدید را دهند. زمانی‌که درخواست‌ها را می‌دهند، اقلام کاری در بک‌لاگ قرار می‌گیرند. افزودن اقلام کاری جدید به بک‌لاگ، روی کاری که بر روی تابلو کانبان در حال انجام و رو به اتمام است، هیچ اثر بدی ندارد. درعوض، بک‌لاگ محلی برای نگهداری اقلام کاری درخواست شده است. درخواست‌ قلم کاری جدید صرفا نشان‌دهنده تعهد تیم توسعه برای گفتگو در مورد تغییر در‌خواست شده با فرد د‌رخواست کننده است.

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

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

براورد کنید

 یکی از قوانینی که وضع کردیم این بود که قلم کاری تا زمانی‌که براورد نشده، نمی‌تواند از بک‌لاگ به تابلو کانبان منتقل شود. دلیل این بود که نمی‌خواستیم توانایی گزارش‌دهی درباره سرعت تیم را به خطر بیندازیم، چراکه توانایی تیم برای دادن تعهدات آینده مبتنی بر عملکرد سابق تیم بود.

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

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

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

ما مشاهده کردیم که یک رابطه پویا بین اولویت‌بندی و براورد (prioritization and estimation ) وجود دارد زیرا ممکن است مالک محصول انتخاب کند که اولویت اقلام کاری را براساس سرعت تکمیل کار، افزایش یا کاهش دهد. برای مثال، داستان کاربری که مشتری فکر می‌کرد اولویت بالایی دارد، ممکن بود هنگامی‌که مشتری می‌فهمید که می‌تواند چهار یا پنج داستان کوچکتر را در همان بازه زمانی حل کند؛ اهمیت خود را از دست بدهد.

جمع بندی

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

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

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

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

کانبان فقط ابزار بازیابی پروژه نیست.

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

درباره نویسنده

استیو اندروز بنیانگذار Fountainhead Solutions،LLC است. چشم انداز وی ایجاد شرکتی بود که با استفاده از روش‌های چابک و تکنیک‌های مهندسی معاصر، روی توسعه راهکارهای نرم‌افزاری نوآورانه متمرکز باشد. آقای اندروز تقریباً 20 سال سابقه رهبری طرح‌های راهکار توسعه را دارد. او متخصص در یافتن راه‌هایی برای به حداکثر رساندن کارایی تیم‌ها و ارائه هرچه سریع‌تر و به صرفه‌تر راهکارهایی برای حل مشکلات توسعه و در عین حال بهبود طول عمر توسعه دهندگان و کاربران است. آقای اندروز دارای مدرک لیسانس در رشته کامپیوتر و ریاضیات از دانشگاه وندربیلت(Vanderbilt) است.

مترجم: وحیده بانیگل

ویراستار: سوگل کرمانی

منابع:

Steve Andrews,Using Kanban to Turn Around Distressed Projects, Lean and Kanban InfoQ eMag Issue10, March 2014.

https://www.infoq.com/articles/kanban-distressed-projects