اسکرام بان
اسکرام بان یک متدولوژی (روش‌شناسی) مدیریت چابک است که توصیف‌کننده هم‌زمان اسکرام و کانبان است و در اصل به عنوان یک راه حل برای‌گذار از اسکرام به کانبان طراحی شده‌است. امروزه، اسکرام بان یک چارچوب مدیریتی است که وقتی تیم‌های مختلف، اسکرام را به عنوان روش انتخابی خود برمی‌گزینند، از روش کانبان به عنوان یک دریچه برای مشاهده، درک و بهبود مداوم چگونگی انجام کار استفاده می‌کنند.
به مرور زمان که روش کانبان در حال عمومیت یافتن بیشتری بود در تلاش‌هایی برای آسان‌تر کردن مفاهیم توسعه نرم‌افزار ناب و کانبان برای تیم‌های موجود اسکرام، روش اسکرام بان متولد شد.
اولین مقاله دربارهٔ اسکرام بان شامل توصیف سطوح مختلف برای انتقال از اسکرام به کانبان بود.
اساساً اسکرام بان یک چارچوب مدیریتی است که وقتی تیم‌های مختلف، اسکرام را به عنوان روش انتخابی خود برمی‌گزینند، از روش کانبان به عنوان یک دریچه برای مشاهده، درک و بهبود مداوم چگونگی انجام کار استفاده می‌کنند.
- اسکرام بان از اسکرام بدین شکل متمایز می‌شود که در آن به برخی از اصول و شیوه‌های خاصی تأکید شده‌است که با پایه‌های اصول سنتی اسکرام متفاوت است. از جمله این تفاوت‌ها عبارتند از:
- همچنین اسکرام بان از روش کانبان متمایز می‌شود در اینکه: شاید مهم‌تر از همه، اصول و شیوه‌های تعبیه شده در اسکرام بان منحصر به فرایند توسعه نرم‌افزار نیستند. آن‌ها می‌توانند به راحتی در بسیاری از زمینه‌های مختلف کاربرد داشته باشند، زبان مشترک و تجربه مشترک را در میان اعمال مختلف کسب و کار مرتبط با یکدیگر به اشتراک می‌گذارند. این به نوبه خود، نوعی سازگاری سازمانی را تقویت می‌کند که یکی از ویژگی‌های اصلی موفقیت است.
هنگامیکه «کوری دالاس» جهان را به اسکرام بان در کتاب مبنی بر نام آن معرفی کرد، آن را به عنوان یک روش انتقال برای انتقال تیم‌های توسعه نرم‌افزار از اسکرام به چارچوب توسعه نرم‌افزاری «تکامل یافته تر» تعریف کرد. با این حال، اسکرام بان در عمل خود به شکلی تکامل یافته‌است که تبدیل به یک خانواده از اصول و شیوه‌هایی شده‌است که قابلیت‌های مکملی که ایجاد کرده‌است منحصر به خودش است و از اسکرام و کانبان منحصر به فرد است. این قابلیت‌ها منجر به سه ظهور متمایز شده‌است:
در اسکرام بان، کار تیمی در تکرارهای کوچک سازماندهی شده و با کمک یک صفحه (بورد) بصری، شبیه به بورد اسکرام و نیز بورد کانبان، نظارت می‌شود. برای نشان دادن هر مرحله از کار، تیم‌هایی که در همان فضا کار می‌کنند، اغلب از یادداشت‌های بر روی کاغذ پشت چسب دار یا یک تخته سفید استفاده می‌کنند. در مورد تیم‌های غیرمتمرکز، نرم‌افزار مدیریت تصویری مانند 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 معمولاً برابر با تعداد افراد در تیم است، اما می‌تواند براساس مشخصات کار گروهی گسترش یابد.
برای انجام جلسات برنامه‌ریزی تولیدی، تعداد وظایف بخش To Do نیز می‌تواند محدود باشد. همانند محدودیت‌های WIP، در بالای بخش To Do یا بالای ستون‌های مربوطه نوشته شده و تعداد وظایف در بخش To Do یا ستون‌های خاص را محدود می‌کند.
اسکرام بان به تعداد خاصی از اعضای تیم یا نقش‌های تیم نیاز ندارد. نقش‌هایی که تیم قبل از اتخاذ اسکرام بان وجود داشته‌است به همان تعداد در هنگام اجرای اسکرام بان نگه داشته می‌شود. تک تک اعضاء تیم توسط دیگر اعضای تیم مجبور به انتخاب وظایف برای تکمیل خود هستند. نقش تیم در اسکرام بان بیشتر تخصصی است و کمتر مانند آنچه که در تیم اسکرام انتظار می‌رود به صورت چند وظیفه‌ای است.
در اسکرام بان وظایف، به اعضای تیم، توسط رهبر تیم یا مدیر پروژه اعطا نمی‌شود. هر عضو تیمی انتخاب می‌کند که کدام وظیفه را از قسمت To Do قرار است که انجام دهد. این روند جریانی یکنواخت را تضمین می‌کند، به‌طوری‌که همه اعضای تیم همواره به‌طور مساوی مشغول هستند.
انجماد ویژگی در اسکرام بان هنگامی که مهلت پروژه در حال نزدیک شدن است استفاده می‌شود. این بدان معنی است که تنها ویژگی‌هایی که تیم برای توسعه در حال فعالیت بر روی آن‌ها است هنوز هم می‌تواند توسط تیم بر روی آن‌ها کار انجام شود و هیچ ویژگی اضافی را نمی‌توان اضافه کرد.
تریاژ معمولاً بلافاصله پس از یخ زدن ویژگی اتفاق می‌افتد. با نزدیک شدن مهلت پروژه، مدیر پروژه تصمیم می‌گیرد که کدام ویژگی‌های در حال توسعه را کامل کند و کدامیک ناتمام باقی بماند. این تضمین می‌کند که تیم می‌تواند بر روی پایان دادن به ویژگی‌های مهم قبل از پایان مهلت پروژه تمرکز کند و موارد کم‌اهمیت تر را فراموش کند.مانند سایر روش‌ها، اسکرام بان می‌تواند با کمک ابزارهای مختلف اجرا شود. اساسی‌ترین پیاده‌سازی اسکرام بان یک تخته سفید فیزیکی با یادداشت‌های چسبنده (اسکرام) است. راه حل‌های الکترونیکی، شبیه به اسکرام و تابلوهای الکترونیکی کانبان نیز در دسترس هستند. آن‌ها یک اتوماسیون کامل از بورد را ارائه می‌دهند، جایی که فقط باید توسط اعضای تیم به روزرسانی شود. تابلوهای الکترونیکی اغلب همچنین گزارش خودکار، امکان پیوست و بحث در مورد وظایف، ردیابی زمان و نیز ادغام با سایر نرم‌افزارهای مدیریت پروژه معمولی را نیز ارائه می‌دهند. 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.
__نمایه__