تاریخچه تغییرات سند Scrum Guide
سند Scrum Guide یا راهنمای اسکرام سندی است برای تعریف رسمی چارچوب اسکرام. این سند شامل نقشها، رویدادها و artifactهای اسکرام به همراه قوانینی است که آنها را به هم وصل و مرتبط می کند. این سند خود طی سالها تکامل یافته و دارای نسخه های مختلف است. در این نوشتار قصد داریم تا به تغییرات آن در نسخه های مختلف بپردازیم.
تغییرات بین نسخه های 2016 و 2017 سند Scrum Guide
1- اضافه شدن بخش موارد استفاده اسکرام:
اسکرام بدوا برای مدیریت و توسعه محصولات استفاده می شد. لیکن از اوائل دهه 1990 بصورت گسترده ای در موارد زیر مورد استفاده قرار گرفته است:
- تحقیق و شناسایی بازارهای مناسب، تکنولوژیها و قابلیتهای محصولات
- توسعه محصولات و بهبود آنها
- انتشار محصولات و بهبودهای آنها تا حتی چندین بار در روز
- توسعه و نگهداری محیطهای ابری (آنلاین، امن، مبتنی بر تقاضا) و سایر محیطهای عملیاتی برای استفاده از محصولات
- نگهداری و بازتولید محصولات
اسکرام برای توسعه نرم افزار، سخت افزار، نرم افزارهای embedded ، شبکه های تعاملی، اتومبیلهای خودران، مدارس، دولتها، بازاریابی، اداره سازمانها و تقریبا هر چیزی که ما در زندگی روزانه خود از آن استفاده می کنیم، چه فردی و چه اجتماعی مورد استفاده قرار گرفته است.
همانگونه که تکنولوژی، بازار، پیچیدگیهای محیطی و تعاملات آنها با سرعتی زیاد افزایش یافته است، قابلیت اسکرام در مواجهه با پیچیدگیها هم بصورت مستمر اثبات شده است. اسکرام ثابت کرده که در انتقال دانش در قالب تکرار و تکامل تدریجی کارا است. در حال حاضر اسکرام به شکلی وسیع در محصولات، خدمات و مدیریت سازمانهای مادر استفاده می شود. اساس اسکرام تیمی کوچک از افراد است. یک تیم تنها در سطح بالایی منعطف و تطبیق پذیر است. این نقاط قوت در شرایط داشتن یک، چند و حتی شبکه ای از تیمها که کار توسعه، انتشار، عملیات و نگهداری محصولات را انجام می دهند و خروجیهای آنها نتیجه کار هزاران نفر است هم بخوبی عمل می کنند. آنها با یکدیگر همکاری و از طریق معماریهای توسعه پیچیده و محیطهای انتشار هدف تعامل می کنند.
هر جا که از کلمه “توسعه” در سند Scrum Guide استفاده شده معنی آن کارهای پیچیده است. به عنوان مثال مواردی که در بالا ذکر شدند.
2- تغییر جمله بندی بخش اسکرام مستر با هدف شفاف تر نمودن این نقش بصورت زیر:
اسکرام مستر مسئولیت ترویج و پشتیبانی از اسکرام را همانگونه که در سند Scrum Guide تعریف شده، برعهده دارد. اسکرام مستر این مسئولیت را از طریق کمک به دیگران برای فهمیدن تئوری اسکرام، روشها، قوانین و ارزشهای آن انجام می دهد.
اسکرام مستر یک رهبر-خدمتگذار برای تیم اسکرام است. همچنین او به افراد خارج تیم کمک می کند تا بفهمند که کدامیک از تعاملات آنها با تیم مفید است و کدامیک نیست. او به این افراد کمک می کند تا این نوع تعاملات را با هدف ماکزیمم کردن ارزش خلق شده توسط تیم، تغییر دهند.
3- اضافه شدن این جمله به بخش خدمات اسکرام مستر به مالک محصول:
اطمینان از فهمیده شدن هرچه بهتر اهداف، محدوده و دامین محصول توسط اعضای تیم اسکرام
4- بروزرسانی پاراگراف اول بخش Daily Scrum:
Daily Scrum یک رویداد 15 دقیقه ای برای تیم توسعه است. این رویداد در هر روز اسپرینت برگزار می شود. طی آن تیم توسعه برای کارهای 24 ساعت آینده خود برنامه ریزی می کند. این رویه، همکاری تیم و عملکرد آنها را از طریق بررسی کارهای انجام شده از Daily Scrum قبلی و پیش بینی کارهای پیش روی اسپرینت بهینه می کند. این رویداد با هدف کاهش پیچیدگی هر روز در زمان و مکانی ثابت برگزار می شود.
5- بروزرسانی بخش Daily Scrum با هدف شفاف سازی اهداف این رویداد شامل متن زیر:
فرمت برگزاری این جلسه توسط تیم توسعه تعیین می شود و می تواند به شکلهای مختلفی برگزار شود مادامی که بر روی پیشرفت به سمت هدف اسپرینت متمرکز باشد. بعضی از تیمهای توسعه از سوالات استفاده می کنند و برای برخی دیگر بیشتر بصورت مباحثه است. اینجا نمونه ای از چیزی که ممکن است استفاده شود آورده شده:
- من دیروز چه کاری انجام داده ام که به تیم برای رسیدن به هدف اسپرینت کمک کرده است؟
- من امروز چه کاری انجام خواهم داد که به تیم برای رسیدن به هدف اسپرینت کمک کند؟
- آیا مانعی دیده ام که جلوی من و یا تیم توسعه را برای رسیدن به هدف اسپرینت بگیرد؟
6- شفاف سازی بیشتر مفهوم time-box:
بکارگیری واژه “حداکثر” برای جلوگیری از بروز هر سوالی بطوریکه time-box هر رویداد حداکثر زمان آن را مشخص می کند ولی آن رویداد می تواند کوتاهتر هم باشد.
7- اضافه شدن این جمله به بخش Sprint Backlog:
برای اطمینان از بهبود مستمر، بک لاگ اسپرینت حداقل شامل یک مورد مهم ارتقا فرآیند کاری تیم که در جلسه Retrospective قبلی تعیین شده، می باشد.
8- شفاف تر شدن بخش Increment:
یک Increment لیستی از کارهای تمام شده قابل بررسی و ارزیابی است که از تجربه گرایی در انتهای اسپرینت پشتیبانی می کند. یک Increment یک قدم به سمت یک چشم انداز و یا یک هدف است.
تغییرات بین نسخه های 2013 و 2016 سند Scrum Guide
اضافه شدن بخشی برای ارزشهای اسکرام. زمانی که ارزشهای تعهد، شجاعت، تمرکز، بازبودن و احترام توسط اعضای تیم اسکرام زندگی شوند ستونهای اسکرام شامل شفافیت، ارزیابی و تطبیق فرصت بروز و ظهور پیدا می کنند و بستر اعتماد را برای همه می سازند. اعضای تیم اسکرام این ارزشها را از طریق کار کردن با رویدادها، نقشها و artifactهای اسکرام یاد گرفته و کاوش می کنند.
استفاده موفق از اسکرام بستگی به سطح مهارت تیم در بکارگیری این ارزشها و زندگی با آنها دارد. افراد تیم هر کدام شخصا به دستیابی به اهداف تیم اسکرام تعهد دارند. اعضای تیم اسکرام شجاعت دارند که کار درست را انجام دهند و روی مسائل سخت کار کنند. هر عضو روی کار اسپرینت و اهداف تیم اسکرام متمرکز می شود. تیم اسکرام و ذینفعان توافق می کنند که در مورد همه جوانب کار و چالشهای انجام آن باز باشند. اعضای تیم اسکرام به یکدیگر احترام می گذارند تا افرادی توانا و مستقل باشند.
اگر می خواهید اسکرام را به معنای واقعی و درست آن یاد گرفته و بطور موثر استفاده کنید می توانید در دوره حضوری “بکارگیری موثر اسکرام” مدرسه اسکرام شرکت کنید.
تغییرات بین نسخه های 2011 و 2013 سند Scrum Guide
1- یک قسمت برای شفافیت Artifact اضافه شده است. اسکرام برپایه شفافیت استوار است. تصمیمات برای بهینه کردن ارزش خلق شده و کنترل ریسک بر اساس وضعیت درک شده از Artifactها اتخاذ می گردند. هر چه میزان این شفافیت کامل تر باشد تصمیمات پایه بهتری دارند. و به هر اندازه ای که این شفافیت کمتر باشد، تصمیمات ممکن است نامناسب باشند، ارزش خلق شده کمتر باشد و ریسک کار افزایش یابد.
2- Sprint Planning حالا دیگر یک رویداد است. دو موضوع در آن مشخص می شوند. چه چیزهایی قرار است در این اسپرینت انجام شوند و چگونه انجام شوند. پس از آنکه تیم توسعه کارها را برای اسپرینت انتخاب نمود، تیم اسکرام هدف اسپرینت را تعیین می کند. هدف اسپرینت در کار تیم توسعه انسجام ایجاد می کند، چیزی که نمی توانست در تک تک کارها بصورت جدا بدون داشتن یک هدف مشترک وجود داشته باشد. به ظرفیت و پتانسیل یک هدف اسپرینت توجه داشته باشید.
3- بک لاگ محصول پالایش می شود. آیتمهای پالایش شده شفاف، بخوبی و کافی قابل فهم و به اندازه کافی کوچک هستند که بتوان آنها را به عنوان ورودی جلسه Sprint Planning درنظر گرفت و برای اسپرینت انتخاب کرد. PBIهای با این سطح شفافیت، PBIهای “آماده” نامیده می شوند. آماده بودن و تمام شدن کار دو وضعیت هستند که شفافیت را تقویت می کنند.
4- اسکرام رویدادهای خود را برای داشتن جلساتی منظم تجویز می کند تا نیاز به جلسات دیگر که در اسکرام تعریف نشده اند کم شود. همه رویدادهای اسکرام time-box هستند بگونه ای که هر جلسه یک حداکثر زمان برای خود دارد. یک اسپرینت یک رویداد است که خود ظرفی برای مابقی رویدادهاست با طول زمانی ثابت که نه می تواند کمتر شود و نه بیشتر. مابقی رویدادها می توانند زودتر از زمان خود تمام شوند اگر به اهداف رویداد رسیده شده باشد و تضمین می کنند که میزان مناسبی از زمان برای اهداف آن رویداد، بدون هدر دادن منابع در پروسه توسعه، صرف می شود.
5- اهمیت رویداد Daily Scrum به عنوان یک رویداد برنامه ریزی تقویت شده است. در موارد زیادی دیده می شود که از آن به عنوان یک جلسه اعلام وضعیت استفاده می شود. هر روز تیم توسعه باید بداند که چگونه قرار است با یکدیگر به عنوان یک تیم خود سازمانده کار کنند تا بتوانند به هدف اسپرینت برسند و Increment پیش بینی شده را خلق کنند. ورودی این رویداد باید این باشد که تیم چگونه برای رسیدن به هدف اسپرینت در حال کار کردن است و خروجی آن باید یک برنامه جدید یا تجدید نظر شده باشد که تلاشهای تیم برای رسیدن به هدف اسپرینت را بهینه کند. در این راستا سه سوال تعریف شده اند تا بجای اشخاص روی تیم تاکید شود:
- من دیروز چه کاری انجام داده ام که به تیم برای رسیدن به هدف اسپرینت کمک کرده است؟
- من امروز چه کاری انجام خواهم داد که به تیم برای رسیدن به هدف اسپرینت کمک کند؟
- آیا مانعی دیده ام که جلوی من و یا تیم توسعه را برای رسیدن به هدف اسپرینت بگیرد؟
6- مفهوم ارزش تقویت شده تا در جلسه Sprint Review استفاده گردد. طی این جلسه، تیم اسکرام و ذینفعان در مورد بررسی کارهایی که طی اسپرینت انجام شده اند با یکدیگر همکاری می کنند. بر پایه آن و تغییراتی که طی اسپرینت روی بک لاگ محصول رخ داده است، آنها متفقا تلاش و همکاری می کنند تا کارهای بعدی برای اسپرینت بعدی را که می تواند برای بهینه سازی ارزش انجام شود، تعیین کنند.
تغییرات بین نسخه های 2010 و 2011 سند Scrum Guide
1- تیم های توسعه تعهد نمی دهند که کارهایی که در جلسه Sprint Planning برای اسپرینت برنامه ریزی کرده اند را حتما تمام می کنند. بجای آن تیم توسعه یک پیش بینی از کارهایی که معتقد است می تواند طی اسپرینت تمام شود را ایجاد می کند. لیکن این پیش بینی طی اسپرینت وقتی چیزهای بیشتری از کار فهمیده می شود، تغییر خواهد کرد.
2- اسکرام استفاده از Burn-down چارت را برای پایش پیشرفت الزامی نمی کند. اسکرام فقط الزام می کند که:
- میزان کار باقیمانده اسپرینت باید بصورت روزانه خلاصه شده و تیم وضعیت آن را بداند.
- روند تکمیل کارهای اسپرینت، طی اسپرینت نگهداری و پایش می شود.
3- Release Planning وقتی از اسکرام استفاده می شود یک کار ارزشمند است ولی الزامی نیست.
4- Sprint Backlog شامل PBIهای انتخاب شده برای اسپرینت است به علاوه برنامه ای برای تولید و تحویل آنها. دیگر داشتن مفهومی بنام Sprint Backlog Items الزامی نیست اگرچه این تکنیک می تواند برنامه ای خوب ایجاد کند. یک تیم توسعه خودسازمانده همیشه یک برنامه دارد.
5- بک لاگ محصول بجای اینکه اولویت بندی شود، مرتب می شود تا انعطاف پذیری لازم را به مالک محصول جهت بهینه نمودن ارزش در شرایط خاص بدهد.
6- اضافه شدن Product Backlog Grooming
7- حذف بسیاری از نکات، روشهای انتخابی و تکنیکها
8- تیمی از افراد که کار خلق Increment را انجام می دهند تیم توسعه را تشکیل می دهند. مستقل از کاری که هر عضو تیم انجام می دهد، هر کدام از آنها یک توسعه دهنده هستند.
9- حذف مفهوم Chickens and Pigs (مترجم: از این مفهوم برای ایجاد تمایز بین اعضای تیم اسکرام به عنوان Pigs و سایر افراد سازمان به عنوان Chickens استفاده می شد)
10- حذف مفهوم کار تمام نشده
منبع:
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.