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

بهینه سازی جریان

گام بعدی بهینه‌سازی جریان است البته بعد از اینکه تیم سیستم کششی [۱] را ایجاد کرد. معمولاً با استفاده از کار در جریان قسمت‌هایی از سیستم که بیش از حد بارگذاری شده‌اند، شناسایی می‌شوند و سپس محدودیت‌هایی اضافه می‌شوند که هدف آنها نقاط بارگذاری شده است و با اضافه کردن این محدودیت‌ها، سیستم را تنظیم می‌کند. بهینه‌سازی زمانی اتفاق می‌افتد که تیم تأثیر محدودیت‌ها را بر میانگین مدت انجام [۲] کار محاسبه کند. سقف کار در جریان مدام تنظیم می شود تا زمانی‌که تیم مقدار بهینه ای پیدا کند که مدت انجام کار را کاهش می‌دهد. همچنین تیم‌ها میانگین زمان چرخه [۳] و یا بازه زمانی اولین شروع هر قلم کاری تا تحویل آن قلم کاری را بررسی می‌کنند(اما برخلاف مدت انجام کار، معمولاً فاصله زمانی‌که  قلم کاری برای اولین بار درخواست می‌شود تا زمانی‌که کار روی آن شروع ‌شود، را شامل نمی‌شود). تیم این فرآیند را برای هدف قرار دادن حجم کاری اضافی بعدی سیستم تکرار می‌کند.

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

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

فرض کنید یک تیم هر هفته ۱۰ داستان جدید را شروع می‌کند. اگر ورودی ۱۰ داستان کاربر و خروجی ۴ تا ۶ داستان کاربر باشد، تیم دچار اضافه بار می‌شود که باعث چندوظیفه‌گی، بی‌انگیزگی و چیزهای ناخوشایندی دیگریمی‌شود که در آخر منجر به کاهش خروجی و کیفیت پایین می‌شود. این یک شکست است- یک پبیشنهاد بازنده. مثل این‌که سعی کنید کاغذ بیشتری را درون یک چاپگر بگذارید تا سریع‌تر چاپ کند، یا ماشین‌های بیشتری در یک بزرگراه شلوغ قرار دهید. این موارد  به درستی کار باعث خروجی بهتر با سرعت بیشتر نمی‌شود. بلکه اوضاع را بدتر می‌کند. — هنریک نایبرگ (Henrik Kniberg)، “مالک محصول چابک به‌طور خلاصه”

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

در مثال نایبرگ، ظرفیت تیم چهار تا شش داستان در هفته است. شخصی در تلاش است تیم را وادار کند تا روی ۱۰ داستان در هفته کار کند، حتی اگر برای تیم امکان پذیر نباشد. اما اگر تیم از اسکرام استفاده کند، ابزار اصلی تیم برای تصویر‌سازی گردش کار– تابلوی وظیفه‌ها- که برای تشخیص مسئله‌ها کافی نیست. شکل ۴ تابلوی معمولی وظیفه‌های این تیم را نشان می‌دهد. شاید عادی به نظر می‌رسد، چهار تا شش قلم در ستون “در حال انجام” است که می‌تواند برای تیم ناامیدکننده باشد: تابلو قوانین اسکرام را رعایت کرده است و ابزارها نشان می‌دهند که همه چیز خوب است، اما تیم احساس می‌کند بیش از حد بارگذاری شده است و با افزایش فشار برای چندوظیفگی و صرفه‌جویی برای رسیدن به مهلت انجام کار غیرواقعی مواجه است.

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

 اعضای تیمی که از کانبان استفاده می‌کنند از تفکر سیستمی- با نگاهی به مسیری که محصولات طی می‌کنند-[۴] برای تجزیه و تحلیل و درک گردش کار خود استفاده می‌کنند. برای پذیرش موثر اسکرامبان، تیم روی  تفکر سیستمی در نگرش گروهی خود کار می‌کند. در مثال نایبرگ، کاری که در سیستم جریان دارد به صورت داستان‌هایی با اندازه تقریباً یکسان نشان داده شده است. تیم می‌تواند از ابزارهای کانبان برای دیدن کل سیستم استفاده کند و نه فقط بخشی از آن.

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

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

شکل ۵. ایجاد یک تابلوی کانبان که گردش کار کامل‌تری را نشان می‌دهد به ما کمک می‌کند تا مسئله‌ای که در بارگذاری زیاد درستون درخواست‌های ویژگی‌ها است را تصویرسازی کنیم.

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

راه حل اسکرامبان استفاده از تکنیک‌های کانبان برای بهینه‌سازی جریان با شناسایی اضافه بار و محدود کردن گردش کار برای رسیدگی به علت اصلی آن است. تیم می‌تواند این کار را با اعمال محدودیت WIP به مرحله گردش کار ویژگی‌ها انجام دهد. همچنین با انتخاب محدودیت WIP مختلف می‌توانند مدت انجام کار را بررسی کنند- مثلاً با محدودیت 10 ویژگی شروع ‌کند- و تاثیر آن را روی  مدت انجام کارمحاسبه کند. آن‌ها می‌توانند محدودیت WIP را بر اساس تجربه، کم و زیاد کنند و در نهایت حد بهینه‌ای پیدا ‌کنند که منجر به کمترین میانگین مدت انجام کار در هر داستان شود.

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

استفاده از محدودیت WIP برای مالک محصول یک چالش است، او باید سهامداران را متقاعد کند که با  قانون جدید موافقت کنند. اکثر ذینفعان از شنیدن اینکه نمی‌توانند آزادانه ایده‌های جدید را به تیم منتقل کنند، خوشحال نمی‌شوند، به خصوص اگر برای مدتی این کار را انجام داده باشند. اگر مالک محصول بتواند به ذینفعان نشان دهد که این قانون جدید می‌تواند منجر به توسعه سریعتر شود، شاید ذینفعان موافقت کنند که بخشی از این تجربه باشند. در پذیرش موفقیت آمیز اسکرامبان، ذینفعان باتجربه کردن این تغییرموافقت می‌کنند و می‌بینند که میانگین زمان تحویل کاهش می‌یابد، درست همان‌طور که تیم وعده داده بود، و خودشان شروع به مذاکره می‌کنند – گاهی اوقات به این مذاکره «داد ستد هوشمندانه[۶]» می‌گویند – برای بخش‌های محدودشده در صف درخواست ویژگی.

شکل ۶ .این نمودار جریان تجمعی از کتاب Learning Agile [4] اندازه گیری های متفاوت استفاده شده برای بهینه سازی جریان را نشان می‌دهد

“سطح 2 اسکرامبان” و حرکت  فراتر از اسکرام

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

این تیم به ذینفعان دید بهتری نسبت به سیستم  می‌دهد، و همچنین به آن‌ها این امکان را می‌دهد که درخواست‌های خود را برنامه‌ریزی کنند و به مالک محصول کمک می‌کند تا انتظارات خود را مشخص کند. لاداس فکر می‌کند که با بالغ شدن تیم  اسکرامبان، “چرخ‌های آموزشی” اسکرام به آرامی کنار می‌روند:

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

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

[۱] Pulling System

[۲]  مترجم- مدت انجام کار(Lead Time): زمان تکمیل نهایی یک قلم است، که همان فاصله زمانی است که درخواست داده می‌شود تا زمانی که درخواست تحویل نهایی می‌شود.

[۳]Cycle Time

[۴]محصولات از ایده شروع می‌شوند به داستان می‌رسند سپس از داستان به کد می رسند و از کد به محصول تحویل‌شده، و این مسیر یک سیستم کامل است

[۵]مترجم -نقشه جریان ارزش(value stream map):  درتیم کانبان ناب مجموعه ویدیوهایی در این مورد، ترجمه و منتشر شده است.

[۶] مترجم- (Horse trading) : منظور مذاکره ای است که بر اساس چانه زنی زیرکانه است که در آن امتیازاتی واگذار شده و امتیازاتی گرفته می‌شود این امتیازات متناسب و متقابل هستند.

ادامه دارد…

مترجمین: یاسر کازرونی ، حمید خاتمی

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

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