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

باورهای رایج غلط در مورد اسکرامبان

تیم‌هایی که اسکرامبان را به کار می‌گیرند، اغلب مشخص نیست که چه چیزهایی از اسکرام و کانبان را برای «قابل قبول بودن» اسکرامبان انتخاب می‌کنند. هیچ مرجع تایید کننده یا مدل جاافتاده ای وجود ندارد که تیم‌ها بتوانند از آن کمک بگیرند و وضعیت اسکرامبان “رسمی” را از آن پیگیری کنند. و حتی با وجود اینکه کتاب‌ها و مقالاتی وجود دارد، هیچ «راهنمای اسکرامبان» واحدی یا «بیانه‌ی اسکرامبان»، برای هدایت تیم‌ها وجود ندارد. از زمان نگارش این مقاله، صفحه ویکی‌پدیا برای اسکرامبان هشداری دارد که در ژانویه 2017 ثبت شده است که نشان می دهد این صفحه ویکی پدیا «حاوی حتوایی است که مانند یک آگهی نوشته شده است». محیط آموزشی اسکرامبان برای تیم ها دشواراست، وسایل آموزشی و نتایج جستجو بر روی پیاده سازی ابزارهای خاص یا فرآیندهای خاص ارائه شده، و تعداد کمی از منابع بی‌طرف برای کمک به تیم‌ها در استفاده موثر از اسکرامبان در عمل، وجود دارد که محیط یادگیری اسکرامبان برای تیم ها را دشوار می‌کند. یکی از اهداف این گزارش کمک به تیم‌ها برای شناسایی باورهای غلط و ارائه راهی بالقوه برای تیم‌ها است تا از موانع یادگیری عبور کنند.
دو مورد از رایج ترین تصورات غلط در مورد کانبان و اسکرامبان در زیر آورده شده است:

• اسکرامبان فقط ابزاری برای سازماندهی و کارآمدتر کردن کاراست .
•  اسکرامبان فقط اسکرام بدون تکرار است.

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

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

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

تصور غلط استفاده از اسکرامبان برای مدیریت پروژه اغلب منجر به این باور اشتباه می‌شود که اسکرام و کانبان اساساً یک چیزهستند یا اینکه کانبان فقط شکل پیشرفته تری برای مدیریت پروژه است. این اشتباه در اولین جمله از مقاله ویکی‌پدیا در مورد اسکرامبان مطرح شده است و چندین سال است که همچنان ادامه دارد:

اسکرامبان یک روش مدیریت چابک است که ترکیبی از اسکرام و کانبان می باشد و در ابتدا به عنوان راهی برای حرکت از اسکرام به سمت کانبان طراحی شد.
-توضیح نادرست اسکرامبان در مقاله “اسکرامبان” ویکی پدیا (از آگوست 2015 تا سپتامبر 2019)
اسکرامبان در ابتدا به عنوان راهی برای حرکت از اسکرام به کانبان طراحی نشده بود. حرکت از چارچوبی برای مدیریت کار و تحویل محصولات به سمت روشی برای بهبود فرآیند!! که این بی معنی است.

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

تصور غلط: اسکرامبان اساساً اسکرام «کمتر تکرار» است
کوری لاداس برای اولین بار در مقاله خود در سال 2008، “Scrum-ban”، اصطلاح اسکرامبان را ابداع کرد. اولین رخداد اصطلاح “اسکرامبان” در مقاله به صراحت یک فرآیند تکراری را توصیف می کند:
ما اینجا یک سیستم کششی کانبان ساده را اجرا می کنیم. ما هنوز چرخه برنامه ریزی و تکرار در محدوده زمانی خود را داریم، بنابراین شاید بتوانیم آن‌را سیستم اسکرامبان بنامیم!
علیرغم توصیف لاداس، این تصورغلط که اسکرامبان تکرار ندارد و تصور غلط رایجی هم هست، همچنان ادامه دارد.

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

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

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

•  ذینفعان تیم را برای ساختن نرم افزاری که نیازهای آنها را برآورده نمی کند سرزنش می کنند.
•  توسعه دهندگان ذینفعان را برای تغییر نظرشان سرزنش می کنند.
•  مدیران از تیم می خواهند که ضرب الاجل هایی را رعایت کنند که غیرواقعی هستند، زیرا قبل از اینکه تیم و ذینفعان متوجه شوند که الزامات نیاز به تغییر دارند، با آنها موافقت شده بود.

هنگامی که تیم ها با تکرارهایی مواجه می شوند که کار نمی‌کند و دلیل آن محیطی است که در آن سرزنش زیاد است، ایده حذف تکرارها از اسکرام بسیار جذاب می شود. و هنگامی که آنها با این ایده اشتباه مواجه می شوند که اسکرامبان «اساساً اسکرام بدون تکرار است»، به نظر آن‌ها راه حل ایده آلی یافته اند. ولی در حقیقت، اسکرام “بدون تکرار” می تواند بسیار مشکل ساز باشد.

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

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

ادامه دارد…

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

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

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