اسکرامبان چیست؟ (بخش دوم)

در بخش اول این مقاله به این که چرا تیم‌ها اسکرامبان را انتخاب می‌کنند پرداخته شد. در ادامه و بخش دوم این مقاله جزئیات بیشتری در خصوص کانبان ارائه می‌گردد.

کانبان روشی برای تغییر و بهبود فرایند تیم

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

روش کانبان اولین بار توسط دیوید جی اندرسون برای توسعه نرم­افزار تدوین شد، این روش مبتنی بر ایده‌ها و تجربه‌هایی است که او در کوربیس (Corbis) و مایکروسافت استفاده کرده و در کتاب خود با عنوان «کانبان» توضیح داده است. اندرسون، شرح خلاصه‌ای از کانبان را در پیشگفتار کتاب «کانبان و اسکرام: استفاده بیشینه از هر دو» نوشته کنیبرگ (Kniberg) و اسکارین (Skarin) این‌گونه بیان می­‌کند:

«آن‌چه که در مورد کانبان متوجه شده‌ایم این است که کانبان رویکردی برای مدیریت تغییر است. کانبان، فرایند یا چرخه عمر توسعه نرم‌افزار یا مدیریت پروژه نیست. بلکه رویکردی برای مواجه با تغییر در چرخه عمر توسعه نرم‌افزار فعلی یا متدولوژی مدیریت پروژه است. قاعده کانبان این است که با کاری که هم اکنون در حال انجام آن هستید شروع ‌کنید. فرایند فعلی خود را با نگاشت جریان ارزش (Mapping the value stream) درک ‌کنید و سپس در مورد سقف‌های WIP  (کار در حال انجام) هر مرحله‌ از فرایند توافق ‌کنید. در نهایت هنگام تولید سیگنال‌‌های کانبان، با کشیدن یک کار، گردش کار را درون سیستم به راه بیاندازید».

 

عناصر مهم کانبان

توضیحات اندرسون در مورد کانبان شامل چهار عنصر مهم است:

• با کاری شروع کنید که تیم هم اکنون در حال انجام آن است.
• فرایند فعلی را درک کنید.
• سقف­‌های WIP را برای هر مرحله از فرایند تنظیم کنید.
•  یک سیستم کششی مبتنی بر سیگنال‌های کانبان ایجاد کنید.

هر چهار عنصر کانبان، به اسکرامبان مرتبط است.

با کاری شروع کنید که تیم هم اکنون در حال انجام آن است

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

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

فرایند فعلی را درک کنید

اولین گام برای بهبود یک فرایند، درک آن است. اندرسون در توضیحات خود در مورد کانبان که قبلا بیان شد، اشاره می‌کند که می‌توانید فرایند فعلی خود را توسط نگاشت جریان ارزش درک کنید. همان‌طور که شکل 2 نشان می­‌دهد، یک راه معمول برای انجام این کار ایجاد «نقشه جریان ارزش» است، یا نمایش تصویریِ جریان کاملی که یک ویژگی یا قلم‌کاری خاص از مرحله مفهوم تا تحویل دنبال می­‌کند.

شکل 2 مثالی از نگاشت جریان ارزش از کتاب یادگیری چابک.

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

نگاشت جریان ارزش برای تیم اسکرامی

برای تیم اسکرامی که به ‌دنبال پذیرش اسکرامبان است، نگاشت جریان ارزش معمولا شامل رویدادهای شناخته‌شده‌ای از اسکرام است: انتظار در «بک­‌لاگ محصول» تا وقتی که ویژگی در «اسپرینت» گنجانده شود؛ تحلیل شدن در طول جلسه «برنامه‌ریزی اسپرینت (Sprint Planning)»؛ انتظار در «بک‌­لاگ اسپرینت»؛ و انجام کار روی آن توسط تیم.

اما شروع جریان ارزش از بک­‌لاگ اسپرینت نیست، و پایان آن هم زمانی‌که ویژگی در «بازنگری اسپرینت (Sprint Review)» نمایش داده می‌شود یا در «بازاندیشی (Retrospective)» مورد بحث قرار می­‌گیرد نمی‌باشد. جریان ارزش باید همچنین فعالیت‌های «مالک محصول» و ذینفعان، همانند گفتگو با کاربران یا بازنگری­ مدیران تیم‌‌های محصول، را دربرگیرد. این جریان باید ویژگی را تا محیط عملیاتی دنبال کند؛ برای مثال، شاید اسکریپت‌هایی برای استقرار وجود داشته باشند، و شاید نیاز باشد ویژگی مورد نظر تا زمانِ انتشار برنامه‌­ریزی شده بعدی، منتظر بماند.

سقف‌های WIP را برای هر گام در فرایند تنظیم کنید

دو ایده اصلی کانبان، «تصویرسازی گردش کار (Workflow Visualization)» و «محدود کردن WIP» است. گردش کار معمولا با استفاده از «تابلو کانبان (Kanban Board)» تصویرسازی می‌شود، که وضعیت‌های فرایند را به صورت ستون‌های عمودی نشان می­‌دهد. قلم­‌های کاری درون این ستون­‌ها با تیکت­­­‌ها (در تابلو الکترونیکی) یا برگه­‌های یادداشت یا کارت‌های فهرست‌نویسی (Index Carts) (در تابلو فیزیکی) نشان داده می‌شوند، همان­‌گونه که شکل 3 نشان می­‌دهد در سراسر تابلو از چپ به راست «جریان» دارند. هر یک از ستون‌های روی تابلو گام متفاوتی را در فرایند نشان می‌دهند که هر قلم کاری باید از آن عبور ‌کند. این ستون‌ها به گام‌­های واقعی در فرایند اشاره می‌کنند، و معمولا مطابق با وضعیت‌هایی از فرایند هستند که طی نگاشت جریان ارزش کشف شده­‌اند.

حجم کار بالا چگونه کار در سراسر سیستم را کند می‌کند؟

هنگامی‌که در یک سیستم حجم کار بیش از ظرفیت باشد، کار در سراسر آن بسیار کند جریان می‌­یابد. یک مبنای نظری تحت عنوان «نظریه محدودیت‌ها (Theory Of Constraints)» برای این موضوع وجود دارد، که می‌گوید هر گردش کار دارای اضافه بار، حداقل یک محدودیت دارد. یکی از اهداف کانبان این است که زمان بروز اضافه بار در گردش کار را شناسایی کند و برای بررسی محدودیت‌هایی که ریشه اصلی این اضافه بارها هستند تعدیل انجام دهد. برای تیم‌هایی که اسکرامبان را انتخاب می‌­کنند تصویرسازی گردش کار، مشخص کردن اضافه بارها، و افزودن سقف‌های WIP، گام­‌های حیاتی هستند.

شکل 3 تابلو کانبانی که از برگه­‌های یادداشت استفاده می‌کند.

در تصویر تابلو کانبان در شکل 3، تیم می‌فهمد که قلم‌­های کاری در ستون بازبینی توسط مدیر در حال تلنبار شدن هستند. عدد 10 نوشته شده در بالای ستون «بازبینی مدیر» سقف WIP است: به این معنا که تیم و مدیرانش توافق کرده‌­اند که بیش از 10 قلم‌کاری نمی‌تواند در ستون بازبینی مدیر قرار گیرد.

این نشان‌دهنده تصمیم تیم برای اجرای آزمایشی در تلاش برای رفع اضافه­‌بار فرایند است: آن‌ها مدیران خود را متقاعد کرده­‌اند تا بپذیرند که به محض تلنبار شدن 10 قلم کاری در ستون در انتظار بازبینی، قلم‌­های بیشتری اجازه ورود به این گام را ندارند و تیم باید روی وظیفه‌­های دیگری تمرکز کند تا زمانی‌که حداقل یک قلم‌کاری بازبینی شده و به گام آماده برای انتشار منتقل شود. تیم برای آگاهی از موفقیت‌­آمیز بودن آزمایش می‌تواند میانگین «مدت انجام کار (Lead time)»- یا فاصله زمانی بین ورود یک قلم به گردش کار و خروج از آن را بسنجد تا متوجه شود که آیا سقف WIP، فرایند کلی را بهبود می‌دهد یا خیر. این نمونه‌­ای از آزمایش تکاملی برای بیشینه کردن جریان است، زیرا میانگین مدت انجام کار کوتاه‌­تر به این معنی است که در هر لحظه کار بیشتری در سراسر سیستم در جریان است.

یک سیستم کششی مبتنی بر سیگنال‌های کانبان ایجاد کنید

ایده «سیستم کششی» با سیستم کانبان اولیه آغاز شد، «سیستم تولید تویوتا» یا (TPS) Toyota Production System، یک فرایند تولید است که در دهه‌های 1950 و 1960 در تویوتا توسعه یافت. مهندسان تویوتا دریافتند که حتی اگر تقریباً تمام قطعات مورد نیاز برای مونتاژ خودرو در انبار موجود باشد، کمبود فقط چند قطعه می‌تواند کل خط مونتاژ را متوقف کند. سیستم تولیدی که در آن انبار تعیین می‌کرد چه قطعاتی به خط مونتاژ ارسال شود، علت اصلی بسیاری از تأخیرها بود. مهندسان دریافتند که می‌­توانند با حرکت به سمت یک سیستم «به­‌موقع (Just-In-Time)» که در آن، انبار در هر لحظه فقط چند قطعه محدود را صرفا زمانی‌که کارگرها به آن‌ها نیاز دارند به خط مونتاژ ارسال ‌می‌کند، خودروها را بسیار سریع‌­تر تحویل می‌دهند.

کارگرها از «کارت­‌های کانبان»– کارت‌های کوچکی که روی آن­ها اسامی قطعات نوشته شده– برای سیگنال دادن این­‌که چه قطعاتی کار را کُند می‌کنند، و چه قطعاتی باید به‌­سرعت جایگزین شوند استفاده می­‌کنند («کانبان» در زبان ژاپن به معنی «تابلو اعلانات» یا «تابلو راهنما» است).

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

درک سیستم کششی با مقایسه با سیستم فشاری

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

اما تیم اسکرام می‌تواند با ایجاد یک سیستم «خودسازمانده» این وضعیت را به سیستم کششی تبدیل کند یعنی به­‌جای تخصیص وظیفه‌­ها به اعضای تیم در شروع اسپرینت، وظیفه­‌ها تخصیص نیافته باقی‌ بمانند. در عوض هر عضو تیم وظیفه بعدی خود را تنها پس از اتمام وظیفه‌­های فعلی خود انتخاب می‌کند، یعنی به طور چشمگیری «وظیفه را تنها برحسب تقاضا می­‌کشد». این موضوع به تیم انعطاف‌­پذیری بیشتری می‌دهد: اگر یکی از اعضای تیم زودتر آزاد ­شود می­‌تواند در صورت داشتن مهارت لازم، آن وظیفه را به خود تخصیص دهد. تیمی که به این ترتیب خودسازمانده می‌شود معمولا همه تصمیم‌­ها را در اسکرام روزانه بازنگری می‌کند تا مطمئن شود همه اعضا با معنی‌دار بودن تخصیص کار به خود (Self-assignment) در پروژه موافق هستند.

منتظر قسمت‌های بعدی این مقاله باشید.

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

ویراستار: مهدیه قدسی نژاد

منبع: کتاب اسکرامبان چیست؟