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

«این مطالعه موردی تشریح می‌کند که چگونه بکارگیری تکنیک‌های کانبان و توسعه ناب یک پروژه در حال شکست را نجات می‌دهد.»

پیش زمینه

این پروژه خاص، یک پروژه توسعه شخصی برای یک مشتری بزرگ بود، که به مدت یک سال به طول انجامید. تعداد اعضای تیم توسعه بین 10 تا 15 متغیر بود.

تیم، پروژه را با به‌کارگیری یک مدل توسعه آبشاری [1] رایج شروع کرد. فاز تحلیل (Analysis) قبل از فاز توسعه (Development) انجام شد. قرار بود فاز تحلیل دو الی سه ماه طول بکشد اما بیشتر از آن مدت طول کشید. درطول فاز تحلیل، محدوده (پروژه) فراتر از درک اولیه مشتری و تیم توسعه رشد کرد. زیرا مشتری اصرار داشت نیازمندی‌ها را “برطرف کند” و “پایان بخشد“، بنابراین در نهایت، تقریبا شش ماه طول کشید تا فاز تحلیل کامل شود.

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

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

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

بدست گرفتن کنترل

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

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

تجربه به من ثابت کرده است که برای شروع غلبه بر احساسات در این نوع شرایط بهترین روش، کار با داده‌ها و حقایق (Data and Facts) است. به منظور دستیابی به بهترین شیوه پیشرفت، شناخت علت‌های اصلی مسبب این شرایط مهم است، اما ارائه راهکارهایی که در همان ابتدا تیم باید با توجه به  آن‌ها متفاوت عمل کند کمک نمی‌کند. این‌کار تنها باعث تشدید این شرایط بد می‌شود.

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

ایجاد فرهنگ کیفیت

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

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

این امر به پدیده‌های زیر منجر شد:

_ برنامه نویس‌ها مجبور بودند نیازمندی‌های (Requirements) درج شده در یک مستند ۲۰۰-۳۰۰ صفحه‌ای را هضم و تفسیر کنند.

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

_ این مساله موجب شد که توسعه از تاریخ‌های اتمام برنامه‌ریزی شده اولیه فراتر برود.

_ پس از این‌که تمام کارهای توسعه “انجام شده” تلقی گردید، آزمون در پایانی‌ترین بخش انجام شد. از آنجایی‌که تمام مهلت‌های انجام کار گذشته بود، آزمون باید با عجله انجام می‌شد.

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

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

به‌وضوح  روشی که تیم توسعه با آن کار می‌کرد کیفیت را در درجه اول قرار نداده بود. در واقع، این‌کار کیفیت را از بین ‌برد. از آنجایی‌که تحلیلگرها، برنامه‌نویس‌ها و آزمون‌گرها برای انجام وظیفه‌های خاص خود در پروژه به صورت ماتریسی (Matrix) قرار داده شده بودند، آن‌ها هرگز به‌طور واقعی یاد نگرفتند که چه‌طور به صورت یک واحد منسجم که احساس مسئولیت مشترک (Collective Responsibility) و مالکیت کیفیت سیستم (Ownership of System Quality) را دارد، کار کنند. وقتی مشکلات به وجود آمد، آنها با انگشت اتهام به دیگری اشاره ‌کردند. به‌طور خلاصه، آن‌ها در توسعه و پذیرش فرهنگ کیفیت شکست خوردند.

راه حل پیشنهادی

مهمترین تصمیمی که برای کنترل کیفیت گرفتیم، نیاز به ایجاد آزمون‌های پذیرش برای موارد کار قبل ازکد نویسی برنامه‌نویس‌ها بود. این روش توسعه “آزمون پذیرش محور[ATDD) [3)” نام دارد. با این روش به معنای واقعی کلمه کیفیت را اولین گام قرار دادیم.

روشی که برای اجرای ATDD در این پروژه استفاده شد این بود که مقرر شد به ازای هر مورد کاری در بک‌لاگ (Backlog) مجموعه‌ای از آزمون‌های پذیرش (Acceptance Tests) اختصاص یابد. این‌کار به طور موثر نیازمندی‌هایی را مستند کرد که به‌واسطه کدنویسی نارضایتی ایجاد کرده بودند. همچنین این‌کار آزمونگر  و توسعه‌دهنده  را ملزم کرد قبل از این‌که کدنویسی شروع شود، اتفاق نظر باشند. کار توسعه‎دهنده‌ها این شد که روی پذیرش آزمون‌های شکست خورده تمرکز کنند. شفاف‌سازی این موضوع مهم است که آزمون‌ها برای هر قلم کاری (Work Item) ایجاد شده اند، نه برای یک دسته از موارد کاری به‌طور هم زمان.

این رویکرد “کار حدسی ” [4] است که آیا کد نوشته شده به درستی کار می‌کند یا خیر. آزمون پذیرفته و یا رد می‌شود. بله یا خیر. درست یا غلط. از آنجایی‌که توسعه‌دهنده در هر لحظه روی یک مورد کاری تمرکز داشت، آن‌ها دیگر مجبور نبودند مانند قبل تعداد زیادی از آزمون‌های پذیریش موجود در کل سند تحلیل را درک کنند.

وضعیت‌های انتقال برای یک آزمون پذیرش:

_ رد شده  (Failed)- آزمون در ابتدا رد می‌شود زیرا هنوز کدی توسعه داده نشده است که در آزمون پذیرفته شود.

_ توسعه داده شده (Developed)- کد برای پذیرش در آزمون توسعه داده شده است. توسعه دهنده به محض این‌که کد را پیاده‌سازی کرد، این تغییر(انتقال) را شناسایی می‌کند.

_ قبول شده (Passed)- آزمونگرها تایید می‌کنند که کد ایجاد شده آزمون را قبول شده است.

بکارگیری رویکرد ATDD به تنهایی بیشترین تاثیر مثبت قابل تغییر را روی کیفیت محصول (Product Quality) داشت.

در هشت هفته اول بکارگیری ATDD، ما پروژه را از یک پروژه‌ی فاقد پوشش آزمون (Test Coverage) مستند، به پروژه‌ای تبدیل کردیم که کتابخانه‌ای از آزمون‌ها (Tests) و یک تاریخچه‌ مستند (Documented History) از آزمون‌های پذیرفته شده داشت که کیفیت کلی کدهای تولید شده را تایید می‌کرد‌.

[1] Waterfall development model

[2] Interrupt driven

[3] Acceptance-test-driven development (ATDD)

[4] Guesswork approach

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

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

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

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

منابع:

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