مقدمه
همانگونه که احتمالا میدانید نسخه 2017 راهنمای اسکرام مدتی است منتشر شده که نسبت به نسخه قبل حاوی تغییرات بزرگ و کوچکی بوده است. در اغلب مقالات منتشر شده در خصوص تفاوت این دو نسخه تنها به موارد مهم تر اشاره شده و از نکات ریز صرف نظر شود. نکاتی که گاه در حد تغییر یک کلمه هستند اما با این حال قابل توجه اند و دیدگاه های خالقان اسکرام را در این خصوص منعکس می نمایند. در این نوشته سعی شده بررسی دقیقی در مورد تغییرات و تفاوتها میان نسخه 2016 و 2017 انجام شود. در مورد هر بخش از راهنمای اسکرام بصورت مقایسه ای تغییرات عنوان شده و توضیحاتی مختصر نیز ارائه گردیده است.
Purpose of the Scrum Guide
2016:
Scrum is a framework for developing and sustaining complex products. […]
2017:
Scrum is a framework for developing, delivering, and sustaining complex products. […]
توضیح:
در نسخه 2017 علاوه بر توسعه و نگهداری محصولات پیچیده، تحویل آنها نیز بعنوان یکی از اهداف چارچوب اسکرام برشمرده شده است. به نظر می رسد این مساله در راستای تاکید بر افزایش کاربردهای اسکرام از چارچوبی صرفا برای توسعه نرم افزار به چارچوبی برای غلبه بر انواع پیچیدگی ها بوده است.
Definition of Scrum
2016:
[…]
Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.
2017:
[…]
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
توضیح:
در این پاراگراف چند تغییر دیده می شود:
- عبارت “کار روی محصولات پیچیده” جایگزین “مدیریت توسعه محصولات پیچیده” شده است. بدین ترتیب اسکرام هرگونه کاری روی محصول نه فقط توسعه آن را شامل می شود.
- تاکید شده که اسکرام یک فرایند، تکنیک یا روش تعریف شده نیست و عبارت “روش تعریف شده” در نسخه اخیر اضافه شده است. این تغییر به قصد تاکید این موضوع است که روش انجام کارها در اسکرام تعریف نشده است.
- در راستای بسط کاربردهای اسکرام عبارت “شیوه های توسعه” به “فنون کاری” تغییر کرده است.
- بهبود به “بهبود مستمر” تغییر داده شده . همچنین حوزه های بهبود نیز ذکر شده است : محصول، تیم و محیط کاری.
2016:
[…]
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.
2017:
[…]
The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.
توضیح:
بطور کلی در مستند اخیر اسکرام هرجا که مولفه های اسکرام (نقش ها، رویدادها و مصنوعات) نام برده شده است، اولین مولفه “نقش ها” هستند. شاید هدف از این کار تاکید بر اهمیت بیشتر نقش های اسکرام بوده، شاید هم خواسته شده ترتیب مولفه ها مطابق معرفی آنها در راهنمای اسکرام باشد. (مشابه این تغییر در قسمت Scrum Values نیز وجود دارد)
Uses of Scrum
این بخش کلا در مستند اخیر اضافه شده است. هدف از آن توضیح این مساله است که اسکرام نه فقط در توسعه نرم افزار که در بسیاری حوزه های دیگر که از پیچیدگی برخوردار هستند بکار گرفته شده و کارایی خود را نشان داده است. همچنین در این بخش اشاره شده که ” مقصود از کلمات توسعه و توسعه دادن اشاره به کارهای پیچیده نظیر موارد ذکر شده است”
برای مطالعه جزییات بیشتر به این بخش در راهنمای اسکرام مراجعه شود.
Transparency
2016:
[…]
-Those performing the work and those accepting the work product must share a common definition of “Done”.
2017:
[…]
-Those performing the work and those inspecting the resulting increment must share a common definition of “Done”.
توضیح:
در بخش مثالهایی که برای شفافیت ذکر شده عبارت “آنهایی که فراورده های حاصل شده را بازرسی میکنند” جایگزین “آنهایی که محصول کاری را میپذیرند” شده است. بازرسی Increment حاصل، فعالیت منطقی تر و مناسب تری در قبال انجام کار است.
The Scrum Team
[…] The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.
توضیح:
این جمله در نسخه 2016 وجود نداشته است. به نظر می رسد اضافه شدن آن به نسخه اخیر پاسخی است به کسانی که به ترکیب و خصوصیات تیم اسکرام نقد داشته اند. از این رو تاکید شده که کارایی تیم اسکرام در کارهای پیچیده امتحان خود را پس داده است.
The Product Owner
2016:
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.
2017:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
توضیح:
در تعریف مسئولیت مالک محصول این تغییر داده شده که “مالک محصول مسئول به حداکثر رساندن ارزش محصولی است که از کار تیم توسعه حاصل می شود است (بجای به حداکثر رساندن ارزش محصول و کار تیم توسعه). در تعریف قبلی گویی محصول و کار تیم توسعه دو موجودیت مستقل بودند. اما در تعریف جدید ارزش محصول بعنوان اصل مورد تاکید قرار گرفته است و کار تیم توسعه را در راستای توسعه محصول قابل توجه دانسته است.
2016:
[…]
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
2017:
[…]
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
توضیح:
در نسخه قبل دو جمله مجزا بدین صورت وجود داشت:
- هیچ کس مجاز نیست که از تیم توسعه بخواهد که روی مجموعه دیگری از نیازمندی ها (غیر از بک لاگ محصول) کارکند.
- تیم توسعه مجاز نیست که بر اساس گفته کسی دیگر (غیر از مالک محصول) عمل کند.
در نسخه اخیر این گزاره ها و الزام موجود در آنها تلطیف شده اند. بدین صورت که ذکر شده:
کسی نمی تواند تیم را مجبور به کار روی مجموعه دیگری از نیازمندی ها (غیر از بک لاگ محصول) کند.
معنای تغییر اخیر این است که تیم توسعه در صورت خواست خود مجاز به کار روی مجموعه نیازمندی غیر از بک لاگ محصول هست. این تغییر راه را برای ورود کارهای ضروری مثلا موارد بهبود که در جلسه بازاندیشی اسپرینت تعیین می شود باز می کند.
The Development Team
2017:
[…] “A “Done” increment is required at the Sprint Review.” […]
توضیح:
این جمله به نسخه اخیر اضافه شده و بر این تاکید دارد که بدون فرآورده “تکمیل شده” اصلا Sprint Review در کار نخواهد بود.
همچنین در ذکر مشخصات تیم های توسعه نیز تغییرات زیر اعمال گردیده است:
2016:
[…]
-Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
2017:
[…]
-Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
توضیح:
درنسخه جدید در خصوص عنوان اعضای تیم توسعه دو تغییر مشاهده می شود. اول اینکه عبارت “غیر از توسعه دهنده” حدف شده که این مساله به دلیل گسترش دامنه استفاده اسکرام است. همچنین جمله “هیچ استثنایی برای این قاعده وجود ندارد” نیز حذف شده. که لابد معنی اش این است که در موارد خاص این قانون استثناپذیر است.
2016:
[…]
-Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
2017:
[…]
-Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
توضیح:
همچنین درخصوص اینکه تیم های فرعی در تیم های توسعه قابل تعریف نیست نیز تغییرات زیر اتفاق افتاده. اول اینکه عبارت “حوزه های خاص” به “حوزه ها” تغییر کرده است. دیگر اینکه علاوه بر تست و تحلیل کسب و کار، معماری و عملیات نیز مورد تاکید قرار گرفته اند. همچنین استثناناپذیر نبودن این قانون نیز حذف شده است.
Development Team Size
2016:
[…]
Large Development Teams generate too much complexity for an empirical process to manage.
2017:
[…]
Large Development Teams generate too much complexity for an empirical process to be useful.
توضیح:
در خصوص مطلوب نبودن تعداد بیش از 9 نفر در تیم توسعه، در نسخه قبل بعنوان دلیل ذکر شده بود که “تیم های توسعه بزرگ پیچیدگی خیلی زیادی برای مدیریت کردن یک فرایند تجربی ایجاد میکنند”. اما در این نسخه چنین ذکر شده: ” تیم های توسعه بزرگ پیچیدگی خیلی زیادی برای مفید بودن یک فرایند تجربی ایجاد میکنند”.
این تغییر به این معنا است که در صورت بزرگ بودن تیم نه تنها مدیریت سخت تر است بلکه اساسا روش های تجربی حتی دیگر مفید هم نخواهند بود.
The Scrum Master
2016:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
2017:
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
توضیح:
از تغییرات انجام شده در تعریف مسئولیت اسکرام مستر بدین شرح است:
- از نسخه 2016 اینطور برداشت می شود که اگر اسکرام فهمیده شد و بدان عمل شد، مسئولیت اسکرام مستر تمام است. اما در نسخه جدید بر توسعه و ترویج اسکرام توسط اسکرام مستر تاکید شده. به نظرم نسخه جدید واقع بینانه تر و سازنده تر است که طبق آن مسئولیت اسکرام مستر همواره پابرجا است و تمام شدنی نیست.
- در نسخه اخیر بجای “اطمینان از پیروی از اسکرام توسط تیم اسکرام” ، “کمک به همه در جهت فهم اسکرام” ذکر شده است که اشاره به خارج کردن دایره فهم اسکرام از تیم اسکرام دارد.
- همچنین به مبانی نظری، روش ها و قوانین اسکرام، ارزش های اسکرام نیز که احتمالا از تغییرات نسخه قبل جا مانده بوده اضافه شده است.
Scrum Master Service to the Product Owner
[…]
-Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
توضیح:
این بند در نسخه 2017 اضافه شده است و هدف از آن تاکید بر این نکته است که همه اعضای تیم اسکرام هدف، دامنه و حوزه محصول را تا جای ممکن درک کرده باشند.
The Sprint
2016:
[…]
Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
2017:
[…]
Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
توضیح:
یک بار دیگر تاکید بر “هدف” بجای صرفا “تعریف کار” در نسخه 2017. همچنین واژه “فرآورده” نیز جایگزین محصول شده که آن نیز جایگزینی ظریف و بجایی است.
Topic One: What can be done this Sprint?
2016:
[…]
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
2017:
[…]
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
توضیح:
در نسخه قبل تعیین هدف اسپرینت موکول شده بود به بعد از اینکه آیتم های بکلاگ اسپرینت مشخص شد. اما در نسخه اخیر تقدم و تاخری در این خصوص ذکر نشده و صرفا ذکر شده که در طول جلسه برنامه ریزی اسپرینت، تعیین “هدف” باید انجام شود.
Daily Scrum
2016:
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
[…]
2017:
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.
[…]
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
[…]
توضیح:
و اما یکی از تغییرات مهم و بسیار اساسی نسخه اخیر در تعریف اسکرام روزانه اتفاق افتاده است. در نسخه 2016 همان سه سوال معروف بعنوان پرسش هایی قطعی که باید در جلسه به آنها پاسخ داده شود مطرح شده بود. در حالی که در نسخه اخیر این سه سوال تنها بعنوان یک مثال از روشی که تیم ها در دیلی در پیش می گیرند ذکر شده است. طبق نسخه 2017 تیم های توسعه در تعیین ساختار و نحوه هدایت جلسات روزانه (مشروط بر اینکه همچنان بر پیشرفت به سمت هدف اسپرینت تمرکز داشته باشد) آزادی عمل دارند و می توانند از طریق پرسش یا روشهای تشریحی تر جلسه را برگزار نمایند.
2016:
[…]
The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.
2017:
[…]
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
توضیح:
در نسخه اخیر در خصوص اینکه چه کسانی مجاز به شرکت در جلسه روزانه هستند و چه کسانی اجازه اظهار نظر دارند شفاف سازی شده. طبق این راهنما جلسه روزانه، جلسه داخلی تیم توسعه است، اما منعی برای حضور سایرین در این جلسه به شرطی که خللی در آن ایجاد نکند، وجود ندارد.
Sprint Review
2016:
[…]
This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box.
2017:
[…]
This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the timebox.
توضیح:
در نسخه 2017 در این خصوص رفع ابهام شده که مفهوم time-boxed اشاره به حداکثر زمان رویداد دارد. اما اگر هدف رویداد در زمان کوتاهتر حاصل شد، امکان اتمام آن قبل از رسیدن به زمان مشخص شده وجود دارد.
2016:
[…]
-The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);
2017:
[…]
-The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
توضیح:
این هم یک اصلاح ظریف دیگر. اینکه در جلسه بازبینی اسپرینت در صورت نیاز مالک محصول بجای “تاریخ های تکمیل” به “تاریخ های هدف و تحویل” اشاره کند که به نظر ابهام کمتری دارد.
2016:
[…]
-Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.
2017:
[…]
-Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
توضیح:
بجای “نسخه بعدی پیش بینی شده محصول” در نسخه 2017 “نسخه بعدی پیش بینی شده قابلیت ها یا کارکردهای محصول” ذکر شده است.
Sprint Retrospective
2016:
[…]
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
2017:
[…]
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.
The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
توضیح:
دو تغییر مهم در تعریف جلسه بازاندیشی اسپرینت انجام شده. اولا تاکید بر این مفهوم که time-boxed اشاره به حداکثر زمان دارد و اتمام جلسه قبل از زمان مقرر در صورت دستیابی به هدف جلسه امکان پذیر است. همچنین تاکید شده که اسکرام مستر باید نسبت به مثبت و سازنده بودن جو جلسه اطمینان حاصل نماید.
2016:
[…]
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
2017:
[…]
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.
توضیح:
در نسخه جدید برای افزایش کیفیت علاوه بر بروزرسانی و تطبیق DoD بر بهبود فرایندهای کاری (در صورتی که با استانداردهای سازمانی و محصول مغایرت نداشته باشد) نیز تاکید شده است.
Product Backlog
2016:
The Product Backlog is an ordered list of everything that might be needed in the product
2017:
The Product Backlog is an ordered list of everything that is known to be needed in the product.
توضیح:
در تعریف بک لاگ محصول بجای “هرچیزی که ممکن است در محصول مورد نیاز باشد” گفته شده “هرچیزی که نیاز آن در محصول تشخیص داده شده است”
2017:
[…] Product Backlog items often include test descriptions that will prove its completeness when “Done.”
توضیح :
همچنین در نسخه اخیر این نکته مورد تاکید قرار گرفته که “معمولا اقلام بک لاگ محصول دارای شرحی از نحوه تست یا آزمون نیز هستند که گواهی بر تکمیل شدن آنها است”.
Sprint Backlog
To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
توضیح:
این هم یکی از تغییرات مهم و اساسی نسخه 2017 است. اینکه به راهنما اضافه شده است که “برای اطمینان از بهبود مستمر، دست کم یک مورد بهبود فرآیند اولویت دار که در جلسه بازاندیشی پیشین شناسایی شده است نیز به بکلاگ اسپرینت اضافه میشود”.
این بیانگر این موضوع است که موارد بهبود فرایند نیز می توانند به بک لاگ اسپرینت وارد شوند و بدین ترتیب انجام آنها بعنوان یکی از کارهای تعریف شده در اسپرینت مود تاکید دوچندان قرار می گیرد و در Velocity تیم نیز لحاظ می شوند.
Increment
2016:
[…]
It must be in useable condition regardless of whether the Product Owner decides to actually release it.
2017:
[…]
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
توضیح:
در نسخه اخیر در خصوص اهمیت فرآورده در روش تجربی و اینکه باید در وضعیت تکمیل شده و قابل استفاده باشد، تاکید بیشتر شده است.
Definition of “Done”
2016:
[…]
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team,
2017:
[…]
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team,
توضیح:
یک اصلاح ظریف دیگر در راستای تبیین اینکه DoD ممکن است (و نه لزوما) که در تیم های اسکرام مختلف متفاوت باشد.
2016:
[…]
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.
2017:
[…]
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.
توضیح:
در نسخه 2017 این موضوع اضافه شده که در پی اعمال تغییرات در DoD در راستای افزایش معیارهای کیفی ممکن است کارهای جدیدی در مورد فرآورده های تکمیل شده قبلی ایجاد شود.
خاتمه
2016:
2017:
توضیح:
و در خاتمه یک تفاوت جالب توجه دیگر (حداقل برای من) اینکه در نسخه 2016 تصاویر جداگانه از خالقان اسکرام وجود داشت. اما نسخه اخیر یک عکس مشترک در حالتی که کن شوئبر دست بر شانه جف ساترلند گذاشته دیده می شود. این عکس از یک جنبه برای من جالب توجه بود. اینکه همیشه این تصور برایم وجود داشت (تصور کاملا ذهنی و بدون هیچ سند و منبع) که کن شوئبر حداقل در سالهای اخیر در خصوص مسائل مربوط به اسکرام نقش فعال تری داشته است و شاید دیگر مانند اوایل معرفی اسکرام توافق و هماهنگی بین خالقان اسکرام وجود ندارد. این عکس به نظرم می تواند نوعی پاسخ به این تصور تلقی شود و حاوی این پیام از سوی خالقان اسکرام باشد: “نه، ما هنوز در مورد اسکرام توافق کامل داریم و هر دو پشتیبان آن هستیم”!
منابع
نسخه های 2016 و 2017 راهنمای اسکرام
نسخه ترجمه فارسی راهنمای اسکرام نسخه 2017
آذر 1396