اسکرام بان - ویکی‌پدیا، دانشنامهٔ آزاد

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

تاریخچه[ویرایش]

به مرور زمان که روش کانبان در حال عمومیت یافتن بیشتری بود در تلاش‌هایی برای آسان‌تر کردن مفاهیم توسعه نرم‌افزار ناب و کانبان برای تیم‌های موجود اسکرام، روش اسکرام بان متولد شد.[۱]

اولین مقاله دربارهٔ اسکرام بان شامل توصیف سطوح مختلف برای انتقال از اسکرام به کانبان بود.

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

- اسکرام بان از اسکرام بدین شکل متمایز می‌شود که در آن به برخی از اصول و شیوه‌های خاصی تأکید شده‌است که با پایه‌های اصول سنتی اسکرام متفاوت است. از جمله این تفاوت‌ها عبارتند از:

  • با توجه به نقش مهم مدیریت سازمانی (اصل سازمان دهی درونی تیم همچنان به عنوان یک هدف باقی است اما در چارچوب مرزهای خاص).
  • به تشکیل تیم‌های تخصصی و تیم‌های با عملکرد خاص اجازه می‌دهد.
  • اعمال سیاست‌های صریح در مورد راه کار.
  • استفاده از قوانین جریان و تئوری صف.
  • اولویت بندی اقتصادی حساب شده.

- همچنین اسکرام بان از روش کانبان متمایز می‌شود در اینکه:

  • چارچوب فرایند توسعه نرم‌افزار (Scrum) را به عنوان هسته آن معرفی می‌کند.
  • در اطراف تیم‌ها سازمان یافته‌است.
    • در صورت لزوم، ارزش تکرارهای زمان‌بندی شده را به رسمیت می‌شناسد.
  • روش‌های بهبود مداوم را در مراسم خاص قالب بندی می‌کند.

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

یک چارچوب برای تکامل و انقلاب[ویرایش]

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

  • به عنوان چارچوبی که به تیم‌ها و سازمان‌ها کمک می‌کند به‌طور مؤثر اسکرام را به عنوان یک روش توسعه اقتباس و شخصی‌سازی نمایند.
  • به عنوان یک چارچوب که به تیم‌ها و سازمان‌ها کمک می‌کند تا با برطرف کردن چالش‌های مشترک اسکرام در پروژه‌های بزرگ را برطرف کنند.
  • به عنوان چارچوبی که به تیم‌ها و سازمان‌ها کمک می‌کند تا مجموعه‌ای از فرایندها و شیوه‌های مبتنی بر اسکرام را که برای آن‌ها مناسب تر است، به وجود آورند، نه برای رفع نواقص و اختلالات اسکرام، بلکه برای حل آن‌ها به شیوهایی که برای محیط منحصر به فرد آن‌ها مؤثر است.[۲]

روش[ویرایش]

در اسکرام بان، کار تیمی در تکرارهای کوچک سازماندهی شده و با کمک یک صفحه (بورد) بصری، شبیه به بورد اسکرام و نیز بورد کانبان، نظارت می‌شود. برای نشان دادن هر مرحله از کار، تیم‌هایی که در همان فضا کار می‌کنند، اغلب از یادداشت‌های بر روی کاغذ پشت چسب دار یا یک تخته سفید استفاده می‌کنند. در مورد تیم‌های غیرمتمرکز، نرم‌افزار مدیریت تصویری مانند Assembla, Targetprocess, Eylean Board, JIRA یا Agilo for Trac اغلب استفاده می‌شود. جلسات برنامه‌ریزی برگزار می‌شود تا مشخص شود چه داستان‌های کاربر در تکرار بعدی تکمیل می‌شود. داستان کاربر پس از آن به بورد اضافه می‌شود و تیم آن‌ها را تکمیل می‌کند، تیمی که در هر زمان به تعداد کمی از داستان‌های کاربر به عنوان عملی (کار در حال پیشرفت یا محدودیت WIP) کار می‌کند. بدین ترتیب، برای محدود کردن تکرارها، محدودیت‌های WIP مورد استفاده قرار می‌گیرند و یک برنامه‌ریزی برای تیم تعیین می‌شود که زمان برنامه‌ریزی بعدی چه موقع خواهد بود؛ این زمان هنگامی رخ می‌دهد که WIP پایین‌تر از سطح پیش تعیین شده قرار گیرد. هیچ نقش پیش تعیین شده در اسکرام بان وجود ندارد؛ تیم نقش‌هایی را که قبلاً داشته‌اند حفظ می‌کنند.

تکرار[ویرایش]

تکرار کار در اسکرام بان کوتاه است. این تضمین می‌کند که یک تیم به راحتی می‌تواند به سرعت به تغییرات یک محیط تغییرپذیر واکنش نشان دهد. طول تکرار توسط تعداد داستان‌های کاربر در آن تکرار و سرعت تیم (تعداد داستان‌هایی که تیم می‌تواند در تکرار تکمیل کند) اندازه‌گیری می‌شود. طول ایدئال یک تکرار بستگی به روند کاری هر تیم دارد و توصیه می‌شود که تکرار بیش از دو هفته نباشد.

برنامه‌ریزی بر اساس تقاضا[ویرایش]

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

اولویت بندی[ویرایش]

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

برنامه‌ریزی اندازه سطل[ویرایش]

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

بورد[ویرایش]

بورد اسکرام بان از سه ستون تشکیل شده‌است: برای انجام، در حال انجام، و انجام شده. پس از جلسه برنامه‌ریزی، وظایف به ستون To Do اضافه می‌شوند، زمانی که یک عضو تیم آماده کار بر روی یک کار است، آن را به ستون Do انتقال می‌دهد و زمانی که او آن را تکمیل می‌کند، آن را به ستون Done انتقال می‌دهد. بورد اسکرام بان به صورت بصری نمایانگر پیشرفت تیم است. ستون‌های بورد با توجه به پیشرفت کار تیم، انطباق داده و گسترش می‌یابد. عمومی‌ترین ستون‌های افزوده شده به بورد اسکرام بان شامل ستون‌های اولویت در بخش To Do و ستون‌هایی مانند Design, Manufacturing, Testing در بخش Doing است.

محدودیت‌های WIP[ویرایش]

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

محدودیت To Do[ویرایش]

برای انجام جلسات برنامه‌ریزی تولیدی، تعداد وظایف بخش To Do نیز می‌تواند محدود باشد. همانند محدودیت‌های WIP، در بالای بخش To Do یا بالای ستون‌های مربوطه نوشته شده و تعداد وظایف در بخش To Do یا ستون‌های خاص را محدود می‌کند.

یک بورد ساده کانبان

تیم[ویرایش]

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

اصل کشیدن[ویرایش]

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

انجماد ویژگی‌ها (Feature freeze)[ویرایش]

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

تریاژ (Triage)[ویرایش]

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

اصطلاحات[ویرایش]

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

ابزارها[ویرایش]

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

جستارهای وابسته[ویرایش]

منابع[ویرایش]

  1. «نسخه آرشیو شده». بایگانی‌شده از اصلی در ۲۳ اوت ۲۰۱۸. دریافت‌شده در ۶ دسامبر ۲۰۱۷.
  2. Article in Lean Software Engineering
Ladas, Corey. "Scrum-ban". Lean Software Engineering. 

Don, Wells. "Iterative Planning". Agile Process. Retrieved 14 January 2015. "Feature Freeze". OpenStack. OpenStack. Retrieved 14 January 2015.