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

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

همان‌طور که در بخش اول مقاله گفته شد، تیم توسعه در ابتدا کار خود را با یک رویکرد آبشاری (Waterfall) شروع کرد. با این وجود، پس از شروع توسعه، کار‌ها به رویکرد [1] Ad-hoc  شکسته شد و تغییرات کنترل نشده‌، مستند بزرگ نیازمندی‌های زودهنگام (Up-front Requirements) را بی‌اعتبار کرد. از این‌رو طولی نکشید تا مسیری که از کد به نیازمندی‌ها برمی‌گشت، ناپدید و در نهایت پاک شود.

روش تخصیص کار، یک سیستم فشاری [2] کلاسیک با دسته‌های (Batch) بزرگ بود. به‌ این‌صورت که تیم تحلیل، مستند نیازمندی‌های حجیمی را در اختیار تیم توسعه قرار می‌داد. تیم توسعه کدهای اصلی زیادی را به انضمام فراورده‌های نیازمندی‌ که در تیم تحلیل ایجاد شده بود، برای تیم آزمون می‌فرستاد. وقتی آزمون نقص‌ها (Defects) را پوشش نمی‌داد؛ مدیر، نقص‌ها را به توسعه‌دهنده‌های‌ مشخصی می‌سپرد. وقتی نقص‌ها بر طرف می‌شد، مدیر آن‌ها را در اختیار آزمونگرهای مشخصی برای راستی‌آزمایی (Verification) قرار می‌داد.

این رویکرد باعث اتلاف (Waste) زیادی شد:

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

اندازه دسته را کاهش دهید

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

تلاش برای پیش بردن چنین محصول‌های کاری بزرگی باعث شد که هر تیم گلوگاهی (Bottleneck) برای تیمی باشد که می‌بایست وظیفه‌های بعدی را انجام دهد. در انتها، این کار به وظیفه‌ی بیهوده‌ای تبدیل شد که محصول‌های کاری را به طور عقب‍‌گرد، از آزمون به توسعه و از توسعه به تحلیل بازمی‌گرداند. و این فرایند تکرار می‌شد. به عبارت دیگر، کل کار از پیش انجام‌شده برای نیازمندی‌های نهایی، اتلافی کامل بود؛ چون به محض ظهور نقص‌ها، اعضای تیم مجبور بودند از خودشان بپرسند: “حالا ، قرار بود این وظیفه چه کاری انجام دهد؟” حتی پرسیدن این سوال بی‌فایده است.

به عنوان یک تیم کار کنید

شکستن چرخه مخرب و رساندن تیم به وضعیتی که آن‌ها واقعا ‌بتوانند اقلام کاری (Work Item) را ببندند و آن‌ها را بسته نگه‌دارند، به معنای تغییر ساختار تیم و تغییر اساسی در نحوه‌ای که تیم اقلام کاری را از “در انتظار” (Pending) به “انجام‌شده” (Done) منتقل می‌کرد. در واقع، این کار به معنای تغییر در تعریف آن‌ها از کار “انجام‌شده” بود.

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

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

از سیستم فشاری تا سیستم کششی

کار بعدی ما این بود که از مدیران پروژه اختیار «وظیفه دادن» را گرفتیم–تا مدیران دیگر نتوانند بیش از این کاری را با فشار به تیم وارد کنند. همان‌طور که گفته شد، تیم با یک روش وقفه‌گرا [3] عمل می‌کرد، جایی که مدیر وظایف اعضای تیم را به صورت Ad-hoc تعریف می‌کرد، که باعث می‌شد وظیفه قبلی با احتمال کمتری انجام شود.

برای قرار دادن برخی ساختارها، در تلاش برای توسعه و بستن راه خروج نقص‌های دیده‌نشده در توسعه، ما یک سیستم کششی (Pull System) با استفاده از کانبان را معرفی کردیم. رویکرد کانبان تیم را وادار می‌کند تا با دسته‌هایی (در اندازه‌های) کوچک‌تر کار کند. در ابتدا، این روشِ آسانی بود زیرا همه اقلام کاری که می‌بایست تکمیل می‌شد، نقص‌ها بودند که معمولا برای شروع بسیار کوچک هستند. همچنین ما را مجبور کرد که کلمه “انجام‌شده” را تعریف کنیم.

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

هر ستون، نمایانگر کاری است که برای پیش‌برد کارت‌ها در ستون‌ها باید انجام شود. برای کاهش هزینه‌های هماهنگی وابسته به ارتباطِ وظیفه‌های تکمیل شده، وضعیت‌های آماده را اضافه کردیم تا نشان دهد که وظیفه قبلی «انجام‌شده» و وظیفه بعدی «آماده اجرا» است. برای نمونه، زمانی‌که آزمون‌های پذیرش توسعه داده شد، قلم کاری آماده کد‌نویسی است. تابلو کانبان یک ساز و کار ساده و تصویری (Visualize) فراهم می‌کند که فرایند‌های قلم کاری مورد نیاز را برای حرکت در خود ‌دارد [4]. همچنین تابلو کانبان روشی فراهم می‌کند تا پیشرفت وضعیت هر قلم کاری را در یک نگاه ببینید.

تابلوی ما

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

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

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

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

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

گلوگاه‌ها را حذف کنید

ما هم‌چنین سقف کار در جریان (WIP) را برای کنترل سرعت هر یک از اقلام کاری که می‌توانست در مسیر وضعیت‌های کانبان حرکت کند، ایجاد کردیم. ما فهمیدیم که تحلیلگرها نتوانستند «آزمون‌های پذیرش» را با سرعت یکسانی با توسعه دهندگان آماده کنند. از آن‌جایی‌ که توسعه دهندگان نمی‌توانستند توسعه روی وظیفه‌ها را بدون نقض کردن سقف‌های WIP  ادامه دهند، تحلیلگرها در سیستم، یک گلوگاه شدند. این امر تیم را مجبور کرد با هم کار کنند تا بفهمند چطور توزیع کار یکنواخت باشد و از جریان مداوم اقلام کاری مطمئن شوند. گاهی توسعه‌دهندگان مجبور بودند آزمون‌های پذیرش (Acceptance Test) را بنویسند و صحت‌سنجی کنند (اما نه برای کار توسعه خودشان). ما مجبور بودیم که تحلیلگرها و آزمونگرهای بیشتری به تیم اضافه کنیم. در برخی موارد، سقف‌های WIP را تنظیم کردیم تا وضعیت‌های انتظار غیرعادی را حل کنیم.

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

توضیحات

[1] اصطلاحی لاتین است به معنی «برای این [منظور]» و معمولاً بیانگر رهیافت‌هایی است که برای حل یک مشکل یا وظیفهء ویژه به‌کار برده می‌شوند و نمی‌توان برای دیگر کارها از آنها بهره برد. (منبع: ویکی پدیا)

[2]عبارت سیستم فشاری از حوزه لجستیک و زنجیره تامین بوجود آمده است، که در آن براساس پیش بینی تقاضا، کالا تولید و انبار می شود. در زنجیره تامین یکی از مشکلات اصلی این رویکرد، تولیدات مازادی است که به دلیل پیش بینی نادرست تقاضا در انبار ایجاد می شود. رویکرد مقابل سیستم فشاری، سیستم کششی است. (منبع: https://www.leaneast.com/push-and-pull)

[3] Interrupt- driven

[4] Encapsulate

[5] VersionOne

[6] Build

[7] Mechanism

[8] Spreadsheet

بخش سوم و پایانی این مقاله را در پست بعدی مطالعه کنید.

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

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

منابع:

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