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

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

مقدمه

اسکرامبان (Scrumban) ترکیبی از «اسکرام» (Scrum) و «کانبان» (Kanban) است. اسکرامبان، مدیریت پروژه و تحویل محصول که تمرکز اسکرام­ هستند را با سیستم­‌های کششی (Pull system)، تصویرسازی گردش کار و بهبود فرایندِ کانبان ترکیب می‌کند. طبق گزارش ارائه شده توسط State of Agile در سال 2018، هشت درصد از تیم‌های نرم‌افزاری گزارش داده‌­اند که اسکرامبان را به کار می‌­گیرند.

تیم‌هایی که اسکرامبان را پیاده‌­سازی می‌کنند به­‌طور اثربخشی تحویل محصولِ اسکرام را با بهبود فرایند و مدیریت گردش کار کانبان ترکیب می‌کنند تا از مزایای هر دو بهره­‌مند شوند. اسکرامبان به تیم‌ها کمک می‌کند تا توانایی خودشان را برای تحویل محصولات با ارزش به کار گیرند.

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

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

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

چرا تیم‌ها به اسکرامبان توجه می­‌کنند

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

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

در این گزارش، مشکلات را براساس ریشه این نشانه‌ها بررسی می‌کنیم و توضیح می‌دهیم که چرا اسکرامبان می­‌تواند، اگر به درستی به کار رود، به حل مشکلات اساسی کمک کند.

اسکرام و کانبان: عناصر اسکرامبان

«اسکرام» چارچوبی برای توسعه، تحویل و نگهداری محصولات پیچیده است. اسکرام توسط جف سادرلند (Jeff Sutherland) و کن شووبر (Ken Schwaber) ایجاد شد، و به وضوح متداول‌ترین رویکرد چابک است که امروزه توسط تیم‌ها به کار گرفته می‌شود. تیم‌ها، اسکرام را برای مدیریت کار در پروژه‌های پیچیده و تحویل محصولات ارزشمند به افرادی که به آن‌ها نیاز دارند، به کار می­‌گیرند.

«کانبان» روشی چابک برای بهبود فرایند است، برپایه­‌ی ایده‌ها و تکنیک‌های متحول­‌کننده «تولید ناب» (Lean manufacturing) است که در شرکت تویوتا در دهه 1950 تا 1960 ایجاد شد، و توسط دیوید جی اندرسون (David J. Anderson) در کوربیس (Corbis) و مایکروسافت در اوایل دهه 2000 برای توسعه نرم‌­افزار اقتباس شد. اندرسون در سال 2010 راهنمای معتبر و کاملی را برای کانبان در توسعه نرم‌­افزار منتشر کرد.

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

اسکرام چارچوبی برای توسعه محصول 

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

«سه نقش اصلی در یک پروژه اسکرام وجود دارد: مالک محصول، استاد اسکرام، و تیم توسعه».

«مالک محصول با تیم کار می‌کند تا بک‌لاگ محصولِ متشکل از ویژگی‌ها و نیازمندی­‌هایی که باید ساخته شوند را نگهداری و اولویت‌بندی کند».

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

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

«استاد اسکرام پیشرفت پروژه را از طریق همکاری با تیم حفظ می­‌کند تا بر موانعی که در گذشته شناسایی و درخواست کمک کرده­‌اند فائق آیند. در بازنگری اسپرینت، نرم‌افزار قابل استفاده به مالک محصول و ذینفعان در پایان اسپرینت نمایش داده می‌شود، و تیم یک بازاندیشی برگزار می‌کند تا درس‌هایی که آموخته­‌اند را مشخص کنند، طوری‌که می­تواند روش اجرای اسپرینت­‌ها و ساخت نرم‌افزار را در آینده بهبود دهد» [1].

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

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

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

تجربه‌های اسکرام که به‌­طور گسترده پذیرفته شده­‌اند

بسیاری از تیم‌های اسکرام تجربه‌هایی اسکرام را که به‌­طور گسترده پذیرفته شده‌­اند (Generally Accepted Scrum Practices) انتخاب می‌کنند، اصطلاح GASP معرفی شده توسط مایک کوهن (Mike Cohn) به منظور توصیف تجربه‌هایی است که به­‌طور رسمی بخشی از اسکرام نیستند اما توسط بسیاری از تیم‌های اسکرام پذیرفته شده و به کار گرفته می­‌شوند. دو مورد از رایج‌ترین تجربه‌هایی که به­‌طور گسترده پذیرفته شده‌­اند تابلوهای وظیفه (Task boards) و داستان­‌های کاربر هستند.

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

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

شکل 1: مثالی  از تابلو وظیفه الکترونیکی با استفاده از جیرا (منبع: اطلسین)

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

ویراستار: علیرضا قاقالو

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

نویسنده: آندرو استلمن

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

[1] یادگیری چابک نوشته استلمن (Stellman) و گرین (Greene)