اسکرام

اسکرام چیست؟

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

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

چارچوب (framework)

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

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

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

مصنوعات (artifacts) اسکرام

اصطلاحا مصنوعات به چیز‌هایی گفته می‌شوند که ما برای حل مشکلات آن‌ها را می‌سازیم.اسکرام ۳ مصنوع دارد شامل :Product Backlog ،Sprint Backlog، Sprint Goal

Product Backlog لیست اصلی کارهایی است که باید توسط صاحب محصول (Product Owner) تحویل گرفته شود. یک لیست پویا از ویژگی های جدید، نیازمندی‌ها و اصلاحات است که به عنوان ورودی اسپرینت خواهد بود. در واقع این لیست، لیست “انجام کار” تیم است. Product Backlog دائماً مورد بازبینی، اولویت‌بندی مجدد و نگهداری توسط صاحب محصول قرار می گیرد، زیرا بدلیل شناخت بیشتر یا با تغییر بازار، ممکن است برخی از مواردی که در ابتدای این لیست قرار دارند و دارای بیشترین اولویت هستند، به جایی پایین‌تر در لیست انتقال داده شوند و مواردی با اولویت بالاتر در ابتدای لیست قرار گیرند.

Sprint Backlog لیستی شامل User Story ها یا باگ های ثبت شده ای است که توسط تیم توسعه برای اجرا در چرخه اسپرینت فعلی انتخاب شده است. قبل از هر اسپرینت، در جلسه برنامه‌ریزی اسپرینت (که بعداً در مقاله بحث خواهیم کرد) تیم، لیست کارهای مربوط به اسپرینت را از لیست Product Backlog انتخاب می کند. یک Sprint Backlog می‌تواند لیستی انعطاف پذیر باشد و در طول sprint تکامل یابد. با این حال، هدف اصلی اسپرینت – آنچه تیم می خواهد از اسپرینت فعلی به دست آورد – نباید به خطر بیفتد.

Sprint Goal محصول نهایی قابل استفاده حاصل از یک اسپرینت است. معمولاً ماحصل بدست آمده از یک اسپرینت (که مطابق با هدف اسپرینت است) را در انتهای اسپرینت و طی یک جلسه Demo به نمایش می‌گذارند ،جایی که تیم نشان می دهد چه کارهایی در اسپرینت به پایان رسیده است. معمولا آنچه از یک اسپرینت بدست می‌آیند را Increment می‌نامند. چگونگی تعریف Incrementفقط به این بستگی دارد که تیم های شما “کارهای انجام شده” را چه تعریف می‌کند و شما اهداف اسپرینت خود را چگونه تعیین می‌کنید. به عنوان مثال ، برخی از تیم‌ها تصمیم می‌گیرند که در پایان هر اسپرینت نسخه‌ای را برای مشتریان خود منتشر کنند.

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

رخداد‌ها و جلسات اسکرام

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

لیستی از تمام رخدادهای اصلی که یک تیم اسکرام می تواند از آن ها استفاده کند در ادامه ذکر شده است.

1. جلسه سازماندهی لیست بک لاگ: گاهی اوقات به عنوان backlog grooming (آراسته سازی لیست بک لاگ) شناخته می شود ،این جلسه برعهده صاحب محصول است. کار اصلی صاحب محصول این است که محصول را به سمت چشم انداز در نظر گرفته شده برای محصول سوق دهد. بنابراین ، وی با استفاده از بازخورد کاربران محصول و هم‌چنین تیم توسعه محصول،به اولویت‌بندی و حفظ یک لیست مرتب و آماده برای کار کمک می کند. می توانید اطلاعات بیشتری در مورد نگهداری یک لیست بک لاگ سالم در اینجا بخوانید.
2. جلسه برنامه ریزی اسپرینت: کارهایی که باید در طول اسپرینت فعلی انجام شود، توسط کل تیم توسعه در این جلسه برنامه ریزی می‌شود. این جلسه توسط Scrum Master مدیریت می شود و جایی است که تیم در مورد هدف اسپرینت تصمیم می گیرد. سپس User Storyهای خاص از بک لاگ به اسپریت اضافه می شوند. این User Storyها لازم است همیشه با هدف اسپرینت منطبق باشند و همچنین تیم اسکرام توافق دارند که اجرای آن در طول اسپرینت امکان پذیر است. در پایان جلسه برنامه ریزی ، هر عضو اسکرام باید آنچه می توان در اسپرینت تحویل داد و نحوه تحویل را مشخص کند.
3. اسپرینت: اسپرینت دوره زمانی واقعی است که تیم اسکرام با هم کار می کنند تا یک هدف را به پایان برسانند. اغلب اسپرینت‌ها دو هفته‌ای در نظر گرفته می‌شود، هرچند که برخی از تیم ها یک هفته (برای راحتی در تحویل محدوده در نظر گرفته شده برای تحویل) یا یک ماه (که برای تحویل یک هدف ارزشمند) برای یک اسپرینت در نظر می‌گیرند. Dave West ، از Scrum.org توصیه می کند که هرچه کار پیچیده تر و ناشناخته تر باشد ، باید اسپرینت آن کوتاه تر باشد. اما این واقعا به تیم شما بستگی دارد، و نباید از تغییر آن بترسید! در این دوره، در صورت لزوم می توان مجدداً در مورد محدوده کاری (Scope) بین صاحب محصول و تیم توسعه مذاکره کرد. این موارد هستند که ماهیت تجربی اسکرام را تشکیل می دهند.
4. جلسات روزانه (Daily Scrum/Daily Stand Up) : یک جلسه فوق العاده کوتاه روزانه است که معمولاً صبح ها برگزار می‌شود. بسیاری از تیم ها سعی می کنند جلسه را در ۱۵ دقیقه به پایان برسانند، اما این فقط یک راهنمایی است. این جلسه همچنین “جلسات ایستاده روزانه” نامیده می شود و تأکید می کند که لازم است یک جلسه سریع باشد. هدف از جلسات روزانه این است که همه افراد حاضر در تیم در یک جا قرار گیرند، با هدف اسپرینت هماهنگ شوند و برای ۲۴ ساعت آینده برنامه‌نامه ریزی کنند.
   جلسات ایستاده زمانی برای ابراز نگرانی های شما در مورد رسیدن به اهداف اسپرینت یا هرگونه مانع در رسیدن به اهداف اسپرینت است.
   یک روش معمول برای جلسات روزانه این است که هر یک از اعضای تیم در زمینه دستیابی به هدف اسپرینت به سه سوال پاسخ دهند:
   • من دیروز چکار کردم؟
   • امروز قصد دارم چه کاری انجام دهم؟
   • آیا موانعی وجود دارد؟

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

5. جلسه بررسی اسپرینت (Sprint review): در پایان اسپرینت، تیم در یک جلسه غیررسمی جمع می‌شوند تا دمو یا بررسی هدف را مشاهده کنند. تیم توسعه موارد بک لاگی را که اکنون “انجام شده” به ذینفعان و هم تیمی‌ها برای دریافت بازخورد نشان می دهد. صاحب محصول می تواند تصمیم بگیرد که آیا این توسعه را انتشار دهید یا نه، اگرچه در بیشتر موارد این توسعه منتشر می شود.
   در این جلسه بررسی، صاحب محصول می‌تواند با دریافت بازخورد از جلسه تصمیم بگیرد که برای اسپرینت بعدی چه بک‌لاگ‌هایی باید وارد اسپرینت شوند. برای اسپرینت یک ماهه، یک جلسه بررسی حداکثر چهار ساعته را در نظر بگیرید.
6. جلسه بازنگری اسپرینت (Sprint retrospective): در این جلسه تیم جمع می شود تا در مورد آنچه که در یک اسپرینت، پروژه، افراد یا روابط، ابزارها و جلسات وجود دارد که به خوبی کار می‌کند و یا برعکس، به خوبی کار نمی‌کند را به بحث بگذارد و اطلاعاتی را جمع آوری کند. علت چنین جلسه‌ای این است که مکانی را ایجاد کنیم که تیم بتواند روی آنچه اتفاق افتاده است و چیزهایی را باید برای دفعات دیگر بهبود بخشد.

نقش‌های اسکرام

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

اسکرام ، کانبان و اجایل

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

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

اسکرام بر تکرارهای با طول کوچکتر تمرکز دارد و پس از نهایی شدن طول اسپرینت، یوزر استوری‌ها یا لیست بک لاگی که می‌توانند در طی چرخه اسپرینت اجرا شوند مشخص می‌شود. اما در کانبان، تعداد کارها یا کارهای در حال انجام (حد مجاز Work In Progress – WIP) که باید در چرخه فعلی اجرا شوند ، مقداری ثابت در نظر گرفته می‌شود. زمان مورد نیاز برای پیاده‌سازی کارهای مشخص شده به صورت رو به عقب محاسبه می‌شود.

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

بنابراین انعطاف پذیری کانبان نسبت به اسکرام بیشتر است، در حالی که اسکرام می‌تواند یک تغییر اساسی در روند فکر و عملکرد یک تیم توسعه تلقی شود.

چرا اسکرام؟

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

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

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