اسکرام چیست ؟ (آشنایی با Scrum)

با سلام و درود، اسکرام چیست ؟ رویکرد توسعه نرم افزار Agile چیست ؟ توسعه نرم افزار به روش چابک و اسکرام چه زمانی کاربرد دارد؟ در ادامه به این مباحث خواهم پرداخت. تمامی مطالبی که مطرح میشه دارای منبع هستند و ترجمه و ترکیبشون توسط من انجام شده، در انتها لیست مراجع آورده شده.

توضیح و معرفی روش چابک (agile) به پدر بزرگ

فرض کنید یه پدر بزرگ دوست داشتنی داریم که می خواهیم رویکرد Agile رو بهشون معرفی کنیم. در ادامه مکالمه بین من و پدربزرگ را شاهد هستید:

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

ما خانه را «محصول» می نامیم. آره نمیخواد بخندید :)))
- در ابتدا «فقط به جایی برای سکونت می روید»، خانه MVP است. میشه اینطوری گفت که این خانه: حداقل محصول قابل استفاده می باشد.
- خانه با اضافات آن و خانه به همراه ایوان، increment های آن هستند.
- شما صاحب یک محصول (Product Owner) هستید،شما حواستان هست که خانه به چه شکلی در آید.
- همسر زیبای شما ذینفع (Stackholder) هست، نظرات او مهم هست، به خاطر اینکه اون داخل این خانه زندگی خواهد کرد.
- لیستی از اضافات خانه شامل ایوان، طبقه دوم، سقف محکمتر و هر چیز دیگری که قصد دارید بسازید و به خانه اضافه کنید، پس انداز(انبار)- BackLog هستند.
- زمانی که شما و همسرتون نشسته اید و تصمیم می گیرید که چه کنید، شما انبار خود را آراسته می کنید (groom the backlog).
من — حال پدر بزرگ به من بگید، چطور می خواهید خانه خود را بسازید؟
پدربزرگ — خُب من خودم سازنده ی ضعیفی هستم، اما من یک تنظیم کننده خوبی هستن، بنابراین می توانم تو یه کارخانه کار کنم. از برادر و عمویم میخواهم که خانه ام را بسازند. برادرم فرد مفیدی هست و عمو نیز آدم باهوشیه، اون میتونه تمام نقشه ها و محاسبات را انجام بده. جفتشون کارگر های خوبی هستند. نهایتا از همسایه ام می خوام که سه بار در روز به آنها غذا بده و در صورت بحثی بینشون، صلح بینشان برقرار کند.
من — عالیه پدربزرگ، حالا به این موارد توجه داشته باشید:

برادر و عموی شما تیم توسعه دهنده – Developer Team هستند.
قدرت آنها در این هست که بتونند جایگزین همدیگر شوند. در نتیجه اونها افراد تی-شکل T-Shape هستند: هر دوی آنها یک کار خاص را می توانند به خوبی انجام دهند، اما در هر چیز دیگری می توانند به همدیگر کمک کنند. همسایه شما استاد اسکرام – Scrum Master می باشد. کار اصلی اون این هست که روحیه تیم را حفظ کند

من — چطور اطمینان حاصل می کنید که اونها همه چیز را درست انجام می دهند؟ و مصالح ساختمانی به پایان نمی رسد؟
پدر بزرگ — در ابتدای هر هفته من مذاکره می کنم که چه مواردی برای ۱ الی ۲ هفته پیش رو نیاز است. در صبح، قبل از اینکه عازم کار شوم، من با آنها به همراه همسایه قهوه می نوشم. به دقت متمرکز می شم که چه چیزی را کامل کرده اند و چه چیزی را خواهند ساخت. هر از چندگاهی احتمالا همه با هم مست می شیم و بعد هر کس شاکی میشه که دیگری بدتر و کمتر کار می کند. اما پس از آن آشتی می کنیم.
من — خیلی خُب پدر بزرگ، بنا براین:

بحث و گفتگوی شما در ابتدای هر هفته برنامه ریزی اسپرینت – sprint planning می باشد
قهوه صبح شما حالت ایستاده – stand up دارد.
مست کردن و شروع به مشاجره کردن یک پس نگری – بازنگری – retrospective می باشد.

من — پدربزرگ، اما در مورد همسر شما چه؟ اون هم احتمالا علاقه به مشارکت در ساخت و ساز خانه دارد.
پدربزرگ — هر دو هفته او را همراه خودم می برم. فقط برای اینکه ممکن چیزی اشتباه پیش رفته باشد.
من — پس ببینیم چه چیزی داریم:

هر دو هفته، قبل از اینکه همسر شما ساختمان را ببیند، این دوهفته طول اسپرینت – sprint شما می باشد.
زمانی که همسر شما می رسد، زمان یک مروری بر اسپرینت – sprint review است، شما می توانید اسپرینت رو طوری برنامه ریزی کنید که همیشه چیزی برای ارائه به همسرتان داشته باشید.
مهمانی تکمیل خانه شما، زمان راه اندازی محصول – Product launch می باشد.

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

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

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

اسکرام چارچوبی از تعاملات، عملیات و نقش هایی است که برای انعطاف پذیری نیاز است.

از چابک استفاده کنیم یا نکنیم ؟

من — پدربزرگ، اگر پول و زمان کافی برای ساخت یک خانه ی بزرگ و مقاوم به روش درست داشتید، چه می کردید؟

پدربزرگ — با یک خانه کوچک خودمو اذیت نمی کردم و یک پیمانکار ساخت استخدام می کردم تا خانه را سریع آماده بکند. روی یک برنامه و نقشه توافق می کردیم و قرارداد امضا می کردیم. چندین بار به ساخت و ساز مراجعه می کردم که بررسی کنم ساخت وساز چطور پیش میره، اما بیشتر از سر کنجکاوی، چرا که اونها هر چیزی را مطابق نقشه پیش خواهند رفت.

من — اما پدربزرگ ساخت یک خانه بزرگ به روش درست، زمان زیادی خواهد گرفت. شما نمی تونید ماه سپتامبر نقل مکان کنید.

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

من — اگر مطمین نبودید که میخواهید در یک آپارتمان زندگی کنید یا خانه چه ؟؟

پدربزرگ — در این صورت، ابتدا یک خانه ی کوچک می ساختم. پولم رو برای چیزی که هنوز اطمینان ندارم بهش نیاز دارم یا خیر، خرج نمی کردم.

آشنایی جزیی تر با اسکرام

در ادامه با ترجمه ی کامل کتاب یا جزوه ی The Scrum Guide The Definitive Guide to Scrum:The Rules of the Game نوشته ی ایجاد گنندگان اسکرام، Ken Schwaber وJeff Sutherland در خدمتتون هستم، سعی کردم از مطالب دیگه ای هم در مواردی که نیاز به توضیح بیشتر بود استفاده کنم. کلیه منابع در پایان همین مقاله آورده شده است.

تعریف اسکرام – Scrum

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

اسکرام :

سبک وزن – Lightweight
ساده برای درک
سخت برای ماهر شدن

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

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

قوانین و قواعد اسکرام، نقش ها، رویدادها و مصنوعات را با هم پیوند می دهد و حاکم بر روابط و تعامل بین آنها است. قوانین و قواعد اسکرام رو در ادامه بهشون خواهیم پرداخت (همین مقاله و مقالات بعدی)

موارد استفاده اسکرام

اسکرام در ابتدا برای مدیریت و توسعه محصولات توسعه داده شد. از اوایل دهه ۹۰ میلادی، اسکرام به صورت گسترده در سراسر جهان مورد استفاده قرار گرفت:

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

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

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

اسکرام به ویژه در انتقال دانش تکراری (iterative) و افزایشی (incremental) موثر بوده است.

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

زمانی که لغات توسعه و توسعه دادن در راهنمای اسکرام استفاده می شود، آنها به کارهای پیچیده اشاره دارند که انواعش را بالاتر ذکر کردیم.

تئوری اسکرام – Scrum Theory

اسکرام بر اساس تئوری «کنترل فرآیند تجربی» یا تجربه گرایی پایه گذاری شده است. تجربه گرایی ادعا می کند که دانش از تجربه و تصمیم گیری بر مبنای چیزی که می دانید، بدست می آید. اسکرام از یک رویکرد تکراری، افزایشی (iterative, incremental approach) برای بهینه سازی پیش بینی پذیری و کنترل ریسک استفاده می کند.

در هر پیاده سازی از کنترل فرآیند تجربه گرا، سه ستون تقویت می شوند: شفافیت (transparency)، بازرسی (inspection) و وفق پذیری (adaptation).

شفافیت (transparency)

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

برای مثال:

یک زبان مشترک برای فرآیند باید تعریف شود که بین تمامی مشترکان (همکاران) به اشتراک گذاشته شود و کسانی که کار را انجام می دهند و آنهایی که نتایج increment را بازرسی می کنند، همگی باید تعریف مشترکی از «انجام شده-done» داشته باشند.

بازرسی (Inspection)

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

وفق پذیری (Adaption)

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

اسکرام چهار رویداد رسمی را برای بازرسی و وفق پذیری مقرر کرده است که در بخش رویدادهای اسکرام در ادامه توضیح داده شده است:

برنامه ریزی اسپرینت
اسکرام روزانه (Daily Scrum)
مرور اسپرینت (Sprint Review)
بازنگری اسپرینت (Sprint Retrospective)

ارزش های اسکرام

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

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

تیم اسکرام

تیم اسکرام شامل صاحب محصول (Product Owner)، تیم توسعه دهنده(Development Team)، و استاد اسکرام(Scrum Master) می شود. تیم های اسکرام خود سازمان ده (self-organizing) و چند منظوره (cross-functional) هستند. تیم های خود سازمان ده به جای آنکه کسی بیرون از سازمان مستقیما به آنها بگوید چه کنند، خود انتخاب می کنند که چطور به بهترین نحو کار خود را انجام دهند. تیم های چند منظوره همه صلاحیت های لازم برای انجام کار را بدون وابستگی به بخش های دیگر تیم را دارند. مدل تیم در اسکرام طراحی شده تا انعطاف پذیری، خلاقیت و بهره وری را بهبود بخشد.

تیم های اسکرام محصولات را به صورت تکراری و افزایشی ارائه می دهند، که فرصت های بازخورد نشان دادن را افزایش می دهند. ارائه های افزایشی از محصول «انجام شده-done» همواره اطمینان حاصل می کند که یک نسخه مفید از محصول در دسترس باشد.

صاحب محصول – Product Owner

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

صاحب محصول تنها شخصی است که مسئولیت مدیریت Backlog محصول را دارد. مدیریت Backlogمحصول شامل موارد زیر می شود:

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

صاحب محصول ممکن است خودش این کارها را انجام دهد یا تیم توسعه آن را انجام دهد. با این حال صاحب محصول همچنان پاسخگو می باشد.

صاحب محصول یک نفرمی باشد، نه یک کمیته. صاحب محصول ممکن است خواسته های یک کمیته در Backlogمحصول را ارائه دهد، اما اگر آنها خواهان این هستند که اولویت آیتم های Backlog محصول را تغییر دهند، باید به صاحب محصول مراجعه کنند.

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

تیم توسعه دهنده

تیم توسعه دهنده شامل افراد حرفه ای است که برای ارائه increment قابل انتشار از محصول «انجام شده -Done» در پایان هر اسپرینت فعالیت می کنند. نیاز است که یک افزایش «انجام شده – Done» در مرور اسپرینت (Sprint Review) وجود داشته باشد. تنها افراد تیم توسعه، increment می سازند.

تیم های توسعه توسط سازمان ساختار می یابند و قدرت می گیرند تا کارهای آنها را سازماندهی و مدیریت کنند. همکاری و هم افزایی ایجاد شده کارایی کلی و اثربخشی تیم توسعه را بهبود می بخشند.

تیم های توسعه، ویژگی های زیر را دارند:

آنها خود سازماندهی می شوند. هیچ کس (حتی استاد اسکرام – Scrum Master) به تیم های توسعه نمی گوید که چگونه Product Backlog را به افزایش های بالقوه دارای عملکرد قابل انتشار تبدیل کنند.
تیم های توسعه چند منظوره هستند، تمام مهارت هایی که تیم برای ساخت یک افزایش از محصول ضروری می داند را دارا می باشند.
اسکرام برای اعضای تیم توسعه با توجه به کاری که انجام می دهند، عنوانی در نظر نمی گیرد.
اسکرام صرف نظر از دامین هایی که نیاز به در نظر گرفتن است مانند تست کردن، معماری، عملیات یا آنالیز بیزینس و …، هیچ تیم فرعی را نمی شناسد.
اعضای تیم توسعه به صورت فردی ممکن است مهارت های تخصصی داشته ودر زمینه ای تمرکز داشته باشند، منتهی مسئولیت شان در کل با تیم توسعه است.

سایز تیم توسعه

اندازه بهینه برای تیم توسعه به اندازه کافی کوچک است که چابک و زیرک باشد و به اندازه کافی بزرگ است تا کارهای مهم را در یک اسپرینت انجام دهد. تیم های توسعه کمتر از ۳ عضو، تعامل را کاهش می دهد و منجر به بهره وری کمتر می شود. تیم های توسعه کوچک ممکن است در طول یک اسپرینت، با محدودیت های مهارتی مواجه شوند که منجر شود تیم توسعه نتواند یک افزایش بالقوه قابل ارائه را تحویل دهد. داشتن اعضای بیش از ۹ نفر نیز به هماهنگی های بیشتری نیاز دارد. تیم های توسعه بزرگ، برای قابل استفاده بودن یک فرآیند تجربه گرا، پیچیدگی بیش از حدی را ایجاد می کنند. نقش های «صاحب محصول» و «استاد اسکرام» در این تعداد نفرات شمارش نمی شوند مگر اینکه آنها نیز کار Sprint Backlog را انجام دهند.

استاد اسکرام – The Scrum Master

استاد اسکرام همان طور که در راهنمای اسکرام گفته شد، مسئولیتش ارتقا و پشتیبانی اسکرام می باشد. استاد اسکرام این کار را با کمک کردن به هر کسی برای درک تئوری اسکرام، تمرینات، قوانین و ارزش ها انجام می دهد.

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

خدمت استاد اسکرام به صاحب محصول

استاد اسکرام به صاحب اسکرام به چندین روش خدمت می کند:

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

خدمات استاد اسکرام به تیم توسعه دهنده

استاد اسکرام در چندین روش به تیم توسعه دهنده خدمت رسانی می کند:

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

خدمات استاد اسکرام به سازمان

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

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

رویدادهای اسکرام

رویداد های تجویز شده برای حداقل رساندن نیاز به ملاقات های تعریف نشده در اسکرام و ایجاد نظم، در اسکرام استفاده می شوند. تمامی رویدادها رویدادهای محصور در زمان هستند (time-boxed – محدوده زمانی تعیین شده برای اجرای یک پروژه )، به گونه ای که هر رویداد حداکثر مدت زمان دارد. با شروع یک اسپرینت، مدت زمانش معین می شود و نمی تواند بلندتر یا کوتاه تر شود. دیگر رویدادهای باقی مانده ممکن است به محض دستیابی به هدف رویداد، خاتمه یابند، اطمینان از مقدار زمان مناسب، اجزاه ی هدر رفت در فرآیند را نمی دهد.

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

اسپرینت – The Sprint

قلب اسکرام «اسپرینت» می باشد، یک جعبه زمانی از یک ماه یا کمتر که در طول آن یک افزایش از محصول قابل ارائه بالقوه، قابل استفاده و«انجام شده -Done» ایجاد می شود. اسپرینت ها در طول تلاش توسعه دادن، دارای طول ثابت هستند. یک اسپرینت جدید بلافاصله بعد از نتیجه گیری اسپرینت قبلی شروع می شود.

اسپرینت ها شامل و مرکب از برنامه ریزی اسپرینت، اسکرام های روزانه، کار توسعه، مرور اسپرینت و بازنگری اسپرینت (Sprint Retrospective) می باشد.

در طول اسپرینت:

هیچ تغییری که هدف اسپرینت را به خطر بیاندازد انجام نمی شود.
اهداف کیفی نباید کاهش یابد
حوزه (scope) ممکن است با کسب اطلاعات بیشتر بین صاحب محصول و تیم توسعه دهنده مجدد مذاکره و روشن شود.

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

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

لغو یک اسپرینت

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

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

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

برنامه ریزی اسپرینت

کاری که دراسپرینت باید انجام شود در برنامه ریزی اسپرینت برنامه ریزی می شود. این برنامه ریزی با همکاری مشترک تمامی تیم اسکرام انجام می شود.

برنامه ریزی اسپرینت محدوده زمانی تعیین شده (time-box) برای انجامش، حداکثر ۸ ساعت برای اسپرینت یک-ماهه می باشد. برای اسپرینت های کوتاهتر این رویداد کوتاه تر می باشد. استاد اسکرام اطمینان حاصل می کند که این رویداد برگذاری می شود و شرکت کنندگانش هدف آن را درک کرده اند. Scrum Master به تیم اسکرام می آموزد که آن را در محدوده زمانی تعیین شده، حفظ کنند.

برنامه ریزی اسپرینت موارد زیر را پاسخ می دهد:

چه چیزی از نتیجه افزایش (Increment resulting)، اسپرینت پیش رو تحویل داده می شود؟
چگونه کار لازم برای این increment انجام می شود؟

موضوع اول: این اسپرینت چه کاری می تواند انجام دهد؟

تیم توسعه دهنده برای پیش بینی عملکردهایی که در طول اسپرینت ایجاد می شود، کار می کنند. صاحب محصول درباره هدفی که اسپرینت باید به آن دست یابد و آیتم هایی از Product Backlog که اگر در اسپرینت تکمیل شوند به هدف اسپرینت دست می یابند، بحث می کند. کل تیم اسپرینت روی فهمیدن کار اسپرینت همکاری می کنند.

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

در طول برنامه ریزی، تیم اسپرینت نیز هدف اسپرینت را طراحی می کند. هدف اسپرینت، هدفی است که از طریق پیاده سازی Product Backlog درون اسپرینت، بدست می آید. و راهنمایی را برای تیم توسعه دهنده فراهم می کند که چرا این Increment را می سازند.

موضوع دوم: کار انتخاب شده چگونه انجام می شود؟

با تنظیم هدف اسپرینت و انتخاب آیتم های Product Backlog برای اسپرینت، تیم توسعه دهنده تصمیم می گیرد چطور این عملکرد را در طول اسپرینت، در یک increment «انجام شده – Done» بسازد. آیتم های Product Backlog انتخاب شده برای این اسپرینت بعلاوه برنامه ریزی برای تحویل آنها، Sprint Backlog نامیده می شود.

تیم توسعه معمولا با طراحی سیستم و کار مورد نیاز برای تبدیل Product Backlog به افزایشی (Increment) از محصول در حال کار، شروع می کنند. کار ممکن است در اندازه های مختلف یا تلاش های تخمین زده شده باشد. با این حال، در طول برنامه ریزی اسپرینت برای تیم توسعه، کار کافی برای آنچه معتقد هستند در اسپرینت پیش روانجام دهند، پیش بینی می شود. کارهایی که در روزهای نخست از اسپرینت توسط تیم توسعه دهنده برنامه ریزی شده اند، در پایان این روز اغلب به واحد های یک روزه یا کمتر تجزیه می شوند. تیم توسعه خود را سازماندهی می کند تا انجام کار درSprint Backlog را متعهد شوند، هم در طول برنامه ریزی اسپرینت و هم در صورت نیاز در سراسر اسپرینت.

صاحب محصول می تواند کمک به روشن کردن/واضح کردن آیتم های Product Backlog انتخاب شده و سبک وسنگین کردنشان کند. اگر تیم توسعه تشخیص دهد که کار خیلی بزرگ یا خیلی کوچک است، ممکن است آیتم های محصول انتخاب شده را با صاحب محصول مجدد مذاکره کنند. تیم توسعه ممکن است افراد دیگری را نیز برای مشاوره جهت فراهم کردن توصیه های فنی دعوت کند. با پایان برنامه ریزی اسپرینت، تیم توسعه دهنده باید بتواند به صاحب محصول و استاد اسکرام توضیح دهد که چطور قصد دارند به عنوان تیم سازماندهی شده، اهداف اسپرینت را به انجام برسانند و increment پیش بینی شده را ایجاد کنند.

هدف اسپرینت

هدف اسپرینت یک مجموعه هدف برای اسپرینت است که می تواند از طریق پیاده سازی Product Backlog برآورده شود. هدف اسپرینت راهنمایی را برای تیم توسعه روی اینکه چرا increment می سازند، فراهم می کند. هدف در طول جلسه برنامه ریزی اسپرینت، ایجاد می شود. هدف اسپرینت به تیم توسعه مقداری انعطاف پذیری راجع به عملکرد پیاده سازی شده توسط اسپرینت می دهد. آیتم های انتخاب شده Product Backlog یک عملکرد منسجم را ارائه می دهد که می تواند هدف اسپرینت باشد. هدف اسپرینت می تواند هر انسجام دیگری باشد که باعث شود تیم توسعه به جای جداگانه کار کردن، با هم همکاری کنند.

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

اسکرام روزانه (Daily Scrum)

اسکرام روزانه یک رویداد محدود به ۱۵ دقیقه برای تیم توسعه دهنده می باشد. اسکرام روزانه هر روز از اسپرینت برگذار می شود و در آن، تیم توسعه دهنده کارهای ۲۴ ساعت آینده را برنامه ریزی می کنند. این کار همکاری و کارایی تیم را با بازرسی کردن کار در اسکرام روز گذشته بهینه می کند و کار اسپرینت پیش رو را پیش بینی می کند. اسکرام روزانه هر روز در یک زمان و مکان مشخص برگذار می شود تا از پیچیدگی ها بکاهد.

تیم توسعه از اسکرام روزانه برای بررسی پیشرفت در رسیدن به هدف اسپرینت و برای بررسی چگونگی روند پیشرفت به سمت تکمیل کار در Sprint Backlog استفاده می کنند. اسکرام روزانه احتمال اینکه تیم توسعه به هدف اسپرینت برسد را بهینه می کند. هر روز تیم توسعه دهنده باید بفهمد که چگونه قصد دارد به عنوان تیم خود سازماندهی با هم کار بکنند تا به هدف اسپرینت دست یابند و Increment پیش بینی شده را در پایان اسپرینت ایجاد کنند.

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

من دیروز چه کاری کردم که در رسیدن تیم توسعه به هدف اسپرینت کمک کرد؟
من امروز چه کاری باید انجام دهم که در رسیدن تیم توسعه به هدف اسپرینت کمک کند؟
آیا من مانعی را دیدم که من یا تیم توسعه را از برآورده شدن هدف اسپرینت باز دارد؟

تیم توسعه یا اعضای تیم اغلب بلافاصله بعد از اسکرام روزانه، برای بحث و گفتگوهای مفصل، یا برای تطبیق دادن یا برنامه ریزی مجدد با هم جلسه دارند.

استاد اسکرام مطمین می شود که تیم توسعه جلسه داشته باشد، اما تیم توسعه مسئولیت انجام اسکرام روزانه را بر عهده دارد. استاد اسکرام به تیم توسعه آموزش می دهد که اسکرام روزانه را در محدوده زمانی ۱۵ دقیقه رعایت کنند.

اسکرام روزانه یک جلسه ی داخلی برای تیم توسعه دهنده می باشد. اگر دیگران حضور داشته باشند، استاد اسکرام مطمین می شود که خللی در جلسه ایجاد نکنند.

اسکرام روزانه منجر می شود : ارتباطات بهبود یابند، کنار گذاشتن دیگر جلسات اضافی، شناسایی موانع توسعه جهت حذف کردنشان، برجسته سازی و ارتقای تصمیم گیری-سریع، و بهبود سطح دانش تیم توسعه.

مرور/بررسی اسپرینت – Sprint Review

مرور و بررسی اسپرینت در پایان اسپرینت جهت بازرسی ارتقا (increment) و در صورت نیاز تطبیق Product Backlog. در طول بررسی/مرور اسپرینت، تیم اسکرام و ذینفعان در مورد چیزی که دراسپرینت تنجام شده (Done) همکاری می کنند. مبتنی بر آن و هر تغییری که در Product Backlog در طول اسپرینت صورت گرفته، حاضران در جلسه، روی چیزی که می تواند در آینده انجام شود (Done) تا ارزش را بهبود بخشد، همکاری می کنند. این یک جلسه ی غیر رسمی می باشد، جلسه ی status meeting نمی باشد، و ارائه ی Increment به منظور ایجاد و استرخاج بازخورد و تقویت همکاری می باشد.

این جلسه اغلب ۴ ساعت برای اسپرینت های یک ماهه می باشد. برای اسپرینت های کوتاه تر، رویداد معمولا کوتاهتر برگذار می شود. استاد اسکرام باید از برگذاری جلسه و درک حاضران از هدف جلسه، اطمینان حاصل کند.

جلسه مرور/بررسی اسپرینت شامل موارد زیر می باشد:

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

نتیجه مرور اسپرینت یک Product Backlog تجدید نظر شده (اصلاح شده) می باشد که آیتم های احتمالی Product Backlog برای اسپرینت بعدی را تعریف می کند. Product Backlog ممکن است به طور کلی تنظیم شود تا فرصت های جدید را برآورده کند.

بازنگری در اسکرام – Sprint Retrospective

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

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

هدف بازنگری اسکرام این است که :

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

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

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

مصنوعات اسکرام – Scrum Artifacts

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

بک لاگ محصول – Product Backlog

Product Backlog لیستی مرتب از هر چیزی است که به عنوان مورد نیاز در محصول، شناخته شده اند. تنها منبعی از الزامات برای هر تغییری که درمحصول قرار است انجام شود. صاحب محصول مسئولیت Product Backlog، شامل محتویات درون آن، دردسترسی پذیری و ترتیب آن را دارد.

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

Product Backlog تمامی ویژگی ها، فانکشن ها، الزامات، پیشرفت ها و اصلاحاتی که تغییرات را در انتشار بعدی محصول ایجاد می کند، شامل می شود. آیتم های Product Backlog دارای مشخصه هایی از توضیحات، ترتیب، تخمین، و ارزش می باشد. آیتم Product Backlog اغلب شامل توضیحات تست که تکمیل «انجام شده – Done» را اثبات می کند، می باشد.

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

ممکن است چند تیم اسکرام با هم روی یک محصول کار کنند. یک Product Backlog استفاده می شود تا کارهای پیش روی محصول را توضیح دهد. یک Product Backlog آیتم های گروهی که ممکن است در آن استفاده شوند را نسبت می دهد.

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

آیتم های Product Backlog رتبه بالا معمولا واضحتر و با جزییات بیشتری نسبت به Product Backlog های سطح پایین هستند. تخمین های دقیقتری بر اساس وضوح بیشتر و جزییات بیشتر بدست می آید. آیتم های Product Backlog ای که تیم توسعه دهنده را برای اسپرینت پیش رو مشغول خواهند کرد، تصفیه شده اند، بنابراین هر کدام از آنها را می توان در محدوده زمانی معقولی انجام داد. آیتم های Product Backlog ای که می توانند توسط تیم توسعه دهنده در یک اسپرینت انجام شوند (Done) ، جهت انتخاب در برنامه ریزی اسپرینت، به عنوان «آماده» در نظر گرفته می شوند. ایتم های Product Backlog معمولا این سطح از شفافیت را به هنگام فعالیت پالایشی که در بالا اشاره شد بدست می آورند.

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

نظارت بر پیشرفت به سوی اهداف

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

برا پیش بینی پیشرفت، تمرین و روش های مختلف پیش بینی با توجه به روندی که در حال استفاده است، به کار گرفته می شود، مانند burndowns، burn-ups یا cumulative flows. اینها اثبات شده است که کاربردی و مفید می باشند. با این حال اینها جایگزین تجربه گرایی نیستند. د رمحیط های پیچیده، چیزی که رخ می دهد ناشناخته است. فقط چیزی که در حال حاضر رخ داده، ممکن است برای تصمیم گیری آینده نگر مفید باشد و استفاده شود.

اسپرینت بک لاگ – Sprint Backlog

Sprint Backlog مجموعه ای از آیتم های Product Backlog انتخاب شده برا اسپرینت می باشد بعلاوه نقشه ای برای تحویل دادن Incrementهای محصول و تحقق هدف اسپرینت. Sprint Backlog توسط تیم توسعه دهنده درباره اینکه چه عملکردهایی باید در اسپرینت بعدی باشد و کار مورد نیاز برای تحویل این عملکردها در Incremnt بعدی به صورت «انجام شده – Done» پیش بینی می شود.

Sprint Backlog تمام کارهایی که تیم توسعه دهنده برای رسیدن به هدف به عنوان ضروری تشخیص شان می دهد را قابل مشاهده می کند. جهت اطمینان از بهبود ادامه دار، حداقل یک بهبود فرایند با اولویت بالای شناسایی شده در جلسه بازنگری قبلی را شامل می شود.

Sprint Backlog نقشه ای با اطلاعات کافی می باشد که تغییرات در پیشرفت را می توان در جلسه اسکرام روزانه درک کرد. تیم توسعه دهنده Sprint Backlog را در طول اسپرینت اصلاح می کند و Sprint Backlog در طول اسپرینت پدیدار می شود. این پدیدار شدن زمانی رخ می دهد که تیم توسعه دهنده با توجه به نقشه کار می کنند و در مورد کارهایی که برای رسیدن به هدف اسپرینت نیاز است می آموزند.

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

نظارت بر پیشرفت اسپرینت

در هر زمانی در اسپرینت، کل کار باقیمانده در Sprint Backlog می تواند خلاصه شود. تیم توسعه دهنده کل کار باقیمانده را حداقل یک بار برای هر اسکرام روزانه رهگیری می کند تا احتمال دستیبابی به هدف اسپرینت را پیش بینی کند. با پیگیری کارهای باقی مانده در سراسر اسپرینت، تیم توسعه دهنده می تواند پیشرفت آن را را مدیریت کند.

افزایش – Increment

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

شفافیت مصنوعات – Artifact Transparency

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

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

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

تعریف «انجام شده – Done»

زمانی که یک آیتم از Product Backlog یا یک Increment به عنوان Done توضیح داده می شود، هر کسی باید بداند که Done به چه معنایی است. اگرچه ممکن است به طور قابل توجهی به ازای هر تیم اسکرام متفاوت باشد، اعضا باید یک فهم مشترک از کاری که کامل می شود داشته باشند، تا از شفافیت اطمینان حاصل شود. این تعریف Done در تیم اسکرام است و استفاده می شود تا تعیین کند چه زمانی کار در یک Increment از محصول کامل شده است.

تعریف یکسان، تیم توسعه دهنده را در شناختن اینکه چه تعداد آیتم های Product Backlog می توان در طول برنامه ریزی اسپرینت انتخاب کرد، راهنمایی می کند. هدف از هر اسپرینت تحویل یک Increment از عملکردهای قابل انتشار بالقوه می باشد که پایبند به تعریف فعلی DONE از تیم اسکرام باشد.

تیم های توسعه در هر اسپرینت یک Increment از عملکرد محصول تحویل می دهند. این Increment قابل استفاده می باشد، بنابراین صاحب محصول ممکن است تصمیم بگیرد که سریع منتشر شود. اگر تعریف Done برای یک Increment قسمتی از یک کنوانسیون، استاندارد یا دستورالعمل هایی از سازمان توسعه باشد، تمام تیم های اسکرام باید حداقل از آن پیروی کنند.

اگر DONE برا یک Increment کنوانسونی از سازمان توسعه نباشد، تیم توسعه از تیم اسکرام باید تعریفی از DONE مناسب محصول تعریف کند . اگر چندین تیم توسعه وجود دارد که روی سیستم یا انتشار محصول کار می کنند، تیم های توسعه در تمام تیم های اسکرام باید متقابلا تعریفی برای Done معرفی کنند.

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

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

آیا اسکرام بهترینه !؟

اسکرام بهترین چیز در کل جهانه 🙂

اگر داخل آمازون رو برای کتاب های انگلیسی زبان با کلیدواژه «اسکرام» جستجو کنید، حداقل ۸۶۰ کتاب را نمایش خواهد داد 😐 یوتیوب نیز پر شده از ویدیوهای اسکرام. اسکرام همون طور که گفته شد از دهه ۹۰ میلادی ارائه شده، فکر نکنید چیز تازه ای هست (یه خاطره جالب اینکه با یه رییس منابع انسانی جلسه داشتم که خیلی مدعی بود که منابع انسانی چند تا از شرکت های بزرگ تکنولوژی ایران را دانجام داده، وسط حرف هاش بحث اسکرام کشیده شد وسط و گفت که بعضی مسائل جدید و محدود به یکی دو سال هستند، مثل اسکرام، دهن من وا مووووند :دی ، و ادامه داد تو همین یکی دو سال که مطرح میشن شغل های جدیدی تعریف میشه و بعدش این شغل ها ناپدید می شند، نمیخوام بگم حرفش اشتباه بوده، چرا که قدمت دلیلی بر طول عمر بالای یه روش، چارچوب یا رویکرد نمیشه، ولی رییس منابع انسانی باید اطلاعاتش بیشتر از اینها باشه که بخواد بگه اسکرام به تازگی مطرح شده، مخصوصا منابع انسانی که در شرکت های تکنولوژی فعالیت می کند )

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

با تمام تفاسیر بالا، امکان داره به افرادی بر بخورید که بگند «اسکرام جواب نمیده !»، چرا اتفاقا جواب هم میده و کاربردی هم هست. بدون شک از ۱۰۰درصد اسکرام استفاده نکرده بودند که میگویند قابل اجرا نیست.

حتما در مورد اسکرام مطالب بیشتری خواهم نوشت و داخل بلاگ به اشتراک خواهم گذاشت. تا همین جاش هر نظری دارید خوشحال میشم زیر همین مطلب به اشتراک بگذارید

منابع :