Ken Schwaber и Jeff Sutherland

Scrum Ръководство
Основополагащото Ръководство за Scrum: Правилата наИграта

Ноември 2020Предназначение на Scrum Ръководството
Разработихме Scrum в началото на 90‐те години. Написахме първата версия на ScrumРъководството през 2010 г. за да помогнем на хората по света да разберат Scrum. От тогава
усъвършенстваме Ръководството чрез малки, функционални обновления. Заедно, ние заставамезад него.
Scrum Ръководството съдържа дефиницията на Scrum. Всяка част от платформата има специфично
предназначение, което е от съществена важност за крайната стойност и резултатите, реализирани
чрез Scrum. Промяната на основния дизайн или идеите на Scrum чрез премахване на негови
елементи или не спазване на неговите правила, води до прикриване на проблеми и ограничаванена ползите от Scrum. Това дори може да направи Scrum безполезен.
Следим нарастващата употреба на Scrum в един непрекъснато разширяващ се, сложен свят.
С удивление наблюдаваме как Scrum се прилага в множество сфери, които извършват комплексна
работа, извън разработката на софтуерни продукти, откъдето Scrum води началото си. Сразпространението на употребата на Scrum, се разпространява и практикуването му отразработчици, изследователи, анализатори, учени и други специалисти. В Scrum използваме
думата “разработчици“ не за да разграничаваме, а за да опростим. Ако извличате полза от Scrum,чувствайте се включени.
Чрез употребата на Scrum различни модели, процеси и познания, които си съответстват със Scrumплатформата, както е описана в този документ, могат да бъдат намерени, приложени иизработени. Техните дефиниции не са обект на Scrum Ръководството, защото се различават едни иот други в зависимост от контекста на употребата на Scrum. Подобни тактики за употреба като частот Scrum платформата варират и са описани другаде.
Ken Schwaber и Jeff Sutherland, Ноември 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share‐Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share‐Alike license of Creative Commons.

1Предназначение на Scrum Ръководството................................................................................................ 1Определение на Scrum ............................................................................................................................... 3
Scrum Теория ............................................................................................................................................... 3Прозрачност (Transparency).................................................................................................................... 4Инспекция (Inspection) ............................................................................................................................ 4Адаптация (Adaptation) ........................................................................................................................... 4
Scrum Ценности ........................................................................................................................................... 4
Scrum Екипът (Scrum Team) ........................................................................................................................ 5Разработчици (Developers) ..................................................................................................................... 6
Product Owner (Продуктовият Собственик) .......................................................................................... 6
Scrum Master ............................................................................................................................................ 7
Scrum Събития (Scrum Events) .................................................................................................................... 7Спринтът (The Sprint) ............................................................................................................................... 8Планиране на Спринт (Sprint Planning) .................................................................................................. 9Ежедневен Scrum (Daily Scrum) ............................................................................................................ 10Ревю на Спринта (Sprint Review) .......................................................................................................... 10Ретроспекция на Спринта (Sprint Retrospective) ................................................................................. 11
Scrum Артефакти (Scrum Artifacts) ........................................................................................................... 11
Product Backlog ...................................................................................................................................... 11Ангажимент: Продуктова Цел (Product Goal)............................................................................. 12
Sprint Backlog ......................................................................................................................................... 12Ангажимент: Спринт Цел (Sprint Goal)........................................................................................ 12Инкремент (Increment) ......................................................................................................................... 13Ангажимент: Дефиниция на Готово (Definition of Done) .......................................................... 13Заключение ................................................................................................................................................ 14Благодарности ....................................................................................................................................... 14Хора ............................................................................................................................................... 14История на Scrum Ръководството ............................................................................................... 14Превод ........................................................................................................................................................ 14Промени в Scrum Ръководството между 2017 г. и 2020 г. ........... Error! Bookmark not defined.

2Определение на Scrum
Scrum е лека платформа, която помага на хора, екипи и организации да създават стойност
(generate value) чрез адаптивни решения на комплексни проблеми.
Накратко, Scrum изисква един Scrum Master да създаде среда, в която:1. Product Owner подрежда работата по комплексен проблем в Product Backlog.
2. Scrum Екипът (Scrum Team) превръща подбрана част от работата в полезен Инкремент
(Increment) по време на Спринт (Sprint).
3. Scrum Екипът и техните заинтересовани лица инспектират резултатите и се коригират заследващия Спринт.
4. Повторение на по‐горе изложеното.
Scrum е прост. Изпробвайте го, както е описан, и установете дали неговата философия, теория иструктура ви помагат да постигате цели и да създавате полза. Scrum платформата е умишлено
неизчерпателна, като единствено определя частите, необходими за нейното приложение. Scrumсе развива чрез колективното знание на хората, които го използват. Вместо да предлагат
подробни инструкции, правилата на Scrum ги напътстват в техните взаимоотношения ивзаимодействия.
Различни процеси, техники и методи могат да бъдат приложени в рамките на платформата. Scrumили се обвива около съществуващи процеси, или ги изобличава като ненужни. Scrum разкрива
относителната ефикасност на текущите управление, среда и работни похвати, за да можете да гиподобрите.

Scrum Теория
Scrum е основан на базата на емпиризъм и Lean (Гъвкав / Стегнат) подход. Емпиризмът твърди, чезнанието идва от опита и че вземането на решения трябва да се базира на това, което е известно.
Lean подходът минимизира излишъка, загубите и разхищението на ресурси и се фокусира върху
основните аспекти.
Scrum използва итеративен, инкрементален подход за оптимизиране на предсказуемостта иконтрол на риска. Scrum ангажира групи от хора, които колективно притежават необходимите
умения и експертиза да извършват работата и да споделят или придобиват тези умения.
Scrum съчетава четири официални събития за инспекция и адаптация в едно съдържащо гисъбитие, Спринта. Тези събития са ефективни, защото прилагат основополагащите стълбове наемпиризма в Scrum – прозрачност, инспекция и адаптация.

3Прозрачност (Transparency)Пораждащите се процеси и работа трябва да бъдат видими както за тези, които извършват
работата, така и за тези, които я получават. В Scrum важните решения се взимат на базата навъзприетото състояние на неговите три официални артефакта. Артефакти, които имат слаба
прозрачност, могат да доведат до решения, които намаляват стойността и увеличават риска.
Прозрачността дава възможност за инспекция. Всяка инспекция без прозрачност е подвеждаща иразхищаваща (wasteful).

Инспекция (Inspection)
Scrum артефактите и прогресът към съгласуваните цели трябва да бъдат инспектирани често иприлежно, за да се разкриват потенциално нежелателни отклонения или проблеми. За да помогнес инспекцията, Scrum осигурява редовност (cadence) под формата на петте си събития.
Инспекцията дава възможност за адаптация. Инспекция без адаптация се счита за безсмислена.
Scrum събитията са създадени, за да провокират промени.

Адаптация (Adaptation)Ако инспекцията установи, че един или повече аспекти на един процес са извън допустимите
норми и че крайният продукт ще бъде неприемлив, процесът или обработваният материал трябвада бъдат коригирани. Една корекция трябва да се направи възможно най‐рано, за да се сведат доминимум по‐нататъшните отклонения.
Адаптацията е затруднена, когато екипът не е овластен и не е самоуправляващ се. От Scrum Екипасе очаква да се адаптира в момента, в който научи нещо ново чрез инспекция.

Scrum Ценности
Успешната употреба на Scrum зависи от умението на хората все по‐изкусно да олицетворяват петценности:Отдаденост, Съсредоточеност, Откровеност, Уважение и Смелост

Scrum Екипът се отдава на това да постига целите си и да подкрепя членовете си. Те на първо
място са съсредоточени върху работата в самия Спринт, за да могат да постигат най‐добрия
възможен напредък към тези си цели. Scrum Екипа и заинтересованите му лица са откровени заработата и предизвикателствата ѝ. Членовете на Scrum Екипа се уважават взаимно като способни

4и независими хора и са уважавани като такива от хората, с които работят. Членовете на ScrumЕкипа имат смелостта да постъпват правилно, както и да работят по комплексни проблеми.
Тези ценности дават на Scrum Екипа посока за тяхната работа, действия и поведение. Решенията,които се взимат, стъпките, които се правят, както и начина, по който Scrum се използва, трябва даукрепват тези ценности, а не да ги отслабват или уронват. Членовете на Scrum Екипа изучават иизследват ценностите, работейки чрез Scrum събитията и артефактите. Когато тези ценности саолицетворени от Scrum Екипа и хората, с които работят, тогава стълбовете на емпиризма в Scrum ‐прозрачност, инспекция и адаптация ‐ оживяват и изграждат доверие.

Scrum Екипът (Scrum Team)Основополагащата единица на Scrum е малък екип, наречен Scrum Team. Той се състои от единScrum Master, един Product Owner и Разработчици (Developers). В Scrum Екипа няма под‐екипи илийерархии. Той е една сплотена единица от специалисти, съсредоточени върху една текуща цел ‐Продуктовата Цел (Product Goal).
Scrum Екипите са многофункционални, което означава, че членовете притежават всички умения,необходими да създават стойност във всеки един Спринт. Също така те са самоуправляващи се,което означава, че сами решават кой какво върши, кога го върши и как.
Scrum Екипът е достатъчно малък, за да остане пъргав и същевременно достатъчно голям, за даможе да свършва значително количество от работа в рамките на един Спринт. Обикновено есъставен от 10 човека или по‐малко. Като цяло сме установили, че по‐малките екипи комуникират
по‐добре и са по‐продуктивни. Ако Scrum Екипът стане прекалено голям, би следвало да обмисли
преразпределяне в няколко Scrum Екипа, всеки от които е съсредоточен върху продукта. Тогава теби трябвало да споделят една и съща Продуктова Цел, Product Backlog и Product Owner.
Scrum Екипът е отговорен за всички свързани с продукта дейности, като сътрудничество съсзаинтересованите лица, потвърждение, изпълнение, експериментиране, проучване и развитие ивсичко останало, което може да е необходимо. Те са структурирани и овластени от организациятада организират и управляват своята собствена работа. Работата в Спринтове с устойчиво темпо
подобрява съсредоточеността и постоянството на Scrum Team.
Целият Scrum Team е отговорен за създаването на полезен, използваем Инкремент (Increment)във всеки Sprint. Scrum определя три специфични отговорности в Scrum Екипа: Разработчици
(Developers), Product Owner и Scrum Master.

5Разработчици (Developers)Разработчиците са хората от Scrum Екипа, отдадени на създаването на всеки един аспект на единизползваем Инкремент за всеки Спринт.
Специфичните умения, нужни на Разработчиците, могат да бъдат много и варират спрямо сфератана работа. Независимо от това, Разработчиците винаги са отговорни за:Създаването на план за Спринта, т. нар. Sprint Backlog;Внедряването на високо качество, чрез спазването на Дефиницията на „Готово“ (Definitionof Done);Ежедневното адаптиране на техния план за постигане на Sprint Целта; иВзаимно да се държат един друг професионално отговорни.

Product Owner (Продуктовият Собственик)Product Owner отговаря за максимизирането на полезността на продукта в резултат на работата на
Scrum Екипа. Начинът, по който това се постига, може да варира в широки граници при различните
организации, Scrum Екипи и хора.
Product Owner също така е отговорен за ефективното управление на Product Backlog, което
включва:●●●●Изготвянето и ясната формулировка на Продуктовата Цел;Създаването и ясното комуникиране на елементите на Product Backlog;Подредбата на елементите на Product Backlog;Осигуряване Product Backlog да бъде видим, прозрачен и ясен.

Product Owner може сам да извършва гореизброената работа или да я делегира. Независимо оттова, Product Owner е отговорен (accountable) за нея.
За да е успешен един Product Owner, цялата организацията трябва да уважава неговите илинейните решения. Те са видими за всички в съдържанието и в подредбата на Product Backlog,както и в Инкрементът, подлежащ на инспекция по време на Ревю на Спринт (Sprint Review).
Product Owner е един човек, а не цяла комисия. Product Owner може да представя желанията намножество заинтересовани лица в Product Backlog. Желаещите да променят Product Backlog могатда го сторят като опитат да убедят Product Owner.

6

Scrum MasterScrum Master е отговорен за установяването на Scrum както е определен в Scrum Ръководството.
Scrum Master постига това, помагайки на всички да разберат теорията и практиката на Scrum,както в Scrum Екипа, така и в организацията.
Scrum Master e отговорен за ефикасността на Scrum Екипа. Scrum Master постига това като дававъзможност на Scrum Екипа да подобри практиките си в рамките на Scrum платформата.
Scrum Masters са истински лидери, които служат на Scrum Екипа и на самата организация.
Scrum Master служи на Scrum Team по няколко начина, включително:●●●●Възпитава (coach) членовете на екипа в самоорганизация и многофункционалност;Помага на Scrum Екипа да се съсредоточи върху създаването на високостойностни
Инкременти, които отговарят на Дефиницията на „Готово“;Отстранява препятствия, който пречат на прогреса на Scrum Екипа;Осигурява провеждането на всички Scrum събития по позитивен и продуктивен начин иследи да не надвишават времевото ограничение (timebox).

Scrum Master служи на Product Owner по няколко начина, включително:●●●●Помага за намиране на техники за ефикасно определяне на Продуктова Цел и ефективно
управление на Product Backlog;Помага на Scrum Екипа да разбере необходимостта от кратки и ясни елементи на ProductBacklog;Помага за установяването на емпиричното продуктово планиране, предназначено закомплексна среда;Подпомага сътрудничеството със заинтересованите лица, когато е помолен или когато енужно.

Scrum Master служи на организацията по няколко начина, включително:● Напътства (lead) и възпитава (coach) организацията в нейното усвояване на Scrum;●●●Планира и напътства имплементациите на Scrum в рамките на организацията;Помага на служителите и заинтересованите лица да следват емпиричен подход към всяка
комплексна работа иПремахва пречки между заинтересованите лица и Scrum Екипите.

Scrum Събития (Scrum Events)Спринтът (Sprint) съдържа всички останали събития. Всяко събитие в Scrum е официална
възможност Scrum артефактите да бъдат инспектирани и адаптирани. Тези събития са специално
7проектирани, за да осигурят необходимата прозрачност. Пропускането на което и да е от тезисъбития води до загубена възможност за инспекция и адаптация. Установените събития сеизползват в Scrum за създаване на регулярност и за минимизиране на необходимостта от други
срещи, които не са дефинирани в Scrum. Най‐подходящо е всички събития да се провеждат поедно и също време и на едно и също място за всички от тях, за да се намали сложността.

Спринтът (The Sprint)Спринтовете са сърдечния ритъм на Scrum, чрез който идеите се превръщат в стойност (value).
Те са събития с ограничен период от време (timebox), с продължителност от един месец или по‐малко, за да се създаде постоянство. Всеки нов Спринт започва веднага след приключването напредишния Спринт.
Цялата работа, необходима за постигането на Продуктовата Цел, включително Планирането наСпринт (Sprint Planning), Ежедневния Scrum (Daily Scrum), Sprint Review и Sprint Ретроспекцията
(Sprint Retrospective) се състоят в Спринтове.
По време на Спринт:


●
●
●
●

Не се правят промени, които биха застрашили Спринт Целта;Целите за качество не намаляват;Product Backlog се усъвършенства (refine) при необходимост; иОбхватът може да бъде доизясняван или предоговорен с Product Owner в резултат отнаученото в процеса на работа.

Спринтовете позволяват предсказуемост като осигуряват инспекция и адаптация на прогреса къмПродуктовата Цел поне веднъж месечно. Когато хоризонтът на един Спринт е твърде дълъг,Спринт Целта може да стане невалидна, сложността може да нарасне и рискът може да сеповиши. По‐кратки Спринтове могат да се използват, за да се създадат повече периоди задобиване на знания и за да се намали риска около разходите и усилията като се сведе до по‐кратки интервали от време. Всеки Sprint може да бъде считан за кратък проект.
Различни проекционни практики като диаграми на оставащата работа (burn‐downs), диаграми насвършената работа (burn‐ups) и кумулативни диаграми на потока (cumulative flows) са ползвани запрогнозиране на прогреса. Доказано е, че те са полезни. Това обаче не замества важността наемпиризма. В една комплексна среда не е известно какво точно ще се случи. Единствено това,което вече се е случило, може да бъде използвано за взимане на решения относно бъдещето.
Един Спринт може да бъде отменен, ако Спринт Целта стане излишна. Само Product Owner имаправото да анулира Спринта.

8Планиране на Спринт (Sprint Planning)Планирането на Спринта дава неговото начало чрез планиране на работата, която ще се извършвапо време на Спринта. Този план се създава в резултат от съвместните усилия на целия Scrum Екип.
Product Owner осигурява присъстващите да са подготвени да дискутират най‐важните елементи на
Product Backlog и как те се вписват в Продуктовата Цел. Scrum Екипът може да покани и трети лицада присъстват на Планирането за да дават съвети.
Планирането на Спринта адресира следните теми:Тема Първа: Каква е ползата (value) от Спринта (Sprint)?
Product Owner излага как продуктът би могъл да увеличи своята стойност и полезност в текущия
Спринт. Целия Scrum Екип си сътрудничи, за да определи Спринт Цел и да съобщи назаинтересованите лица защо е ползотворен Спринта.

Тема Втора: Какво може да бъде свършено в този Спринт?
Чрез дискусии с Product Owner, Разработчиците (Developers) подбират елементи от ProductBacklog, които да включат в текущия Спринт. Scrum Екипът може да усъвършенства тези елементипо време на този процес, което задълбочава разбирането и увереността.
Подбирането на количеството работа, което може да бъде свършено за един Спринт, може дабъде сложно. Въпреки това, колкото повече Разработчиците разбират как са се справили преди,какъв е техния предстоящ капацитет и каква е Дефиницията на Готово, толкова по‐уверени могатда бъдат спрямо техните прогнози за Спринта.

Тема Трета: Как избраната работа ще бъде свършена?
Разработчиците планират работата, необходима за създаването на Инкремент, който отговаря наДефиницията на Готов, за всеки един подбран елемент на Product Backlog. Това най‐често сеосъществява чрез декомпозиране на елементите до единици (units), не по‐големи от един ден.
Единствено Разработчиците могат да определят как се върши това. Никой друг няма правото даим каже как да превърнат елементи от Product Backlog в стойностни Инкременти.
Спринт Целта, елементите на Product Backlog, подбрани за Спринта и планът за тяхното
изработване съвкупно се наричат Sprint Backlog.
Планирането на Спринта е с ограничена продължителност (timebox) до осем часа за едномесечен
Спринт. За по‐кратки Спринтове събитието обикновено е по‐кратко.

9Ежедневен Scrum (Daily Scrum)Целта на Ежедневния Scrum е да се инспектира прогреса към Спринт Целта и да се адаптира Sprint
Backlog, ако е необходимо, регулирайки предстоящата планирана работа.
Ежедневният Scrum е 15‐минутно събитие за Разработчиците от Scrum Екипа. За да се намали
комплексността, Ежедневният Scrum се провежда по едно и също време и на едно и също място
всеки работен ден. Ако Product Owner или Scrum Master активно работят по елементи от Sprint
Backlog, те участват като Разработчици.
Разработчиците могат да подберат каквито техники и структури желаят те, стига техният
Ежедневен Scrum да е съсредоточен върху прогреса към Спринт Целта и да създава действителен
план за предстоящия работен ден. Това дава насока и подобрява самоуправлението.
Срещите Ежедневен Scrum подобряват комуникацията, идентифицират препятствия вразработването, поощряват бързото взимане на решения и следователно елиминират нуждата отдопълнителни срещи.
Ежедневният Scrum не е единственото време, в което Разработчиците могат да коригират техния
план. Те често се събират по всяко време на деня за по‐детайлни дискусии за да се адаптира илипрепланира остатъка от работата по Спринта.

Ревю на Спринта (Sprint Review)Целта на Ревюто на Спринта е да се инспектира резултата от Спринта и да се определят бъдещите
адаптации. Scrum Екипът презентира резултатите от своята работа на основните заинтересовани
лица и прогреса към Продуктовата Цел се дискутира.
По време на Ревюто на Спринта Scrum Екипът и заинтересованите лица преглеждат постигнатотопо време на Спринта, както и промените в тяхната среда. На база на тази информация участниците
съвместно определят какви ще са следващите стъпки. Също е възможно Product Backlog да бъдепроменен като цяло, за да се възползва от новопоявили се възможности. Ревюто на Спринта есъбитие за съвместна работа и Scrum Екипът би следвало да не го ограничава само допрезентацията.
Ревюто на Спринта е предпоследното събитие в Спринта и е с ограничена продължителност
(timebox) до четири часа за едномесечен Спринт. За по‐кратки Спринтове събитието обикновено е
по‐кратко.

10Ретроспекция на Спринта (Sprint Retrospective)Целта на Ретроспекцията на Спринта е да се планират начини за повишаване на качеството иефикасността.
Scrum Екипът инспектира как е протекъл последния Спринт по отношение на хората,взаимоотношенията, процеса, инструментите и тяхната Дефиниция на Готово. Елементите, коитоса инспектирани често варират в зависимост от сферата на работа. Предположения, които са гиподвели, биват идентифицирани и техния произход бива проучен. Scrum Екипът обсъжда коиелементи са протекли добре, какви проблеми са срещнали и как тези проблеми са (или не са)били решени.
Scrum Екипът идентифицира промените, които най‐много биха помогнали да се подобри
ефикасността. Най‐резултатните подобренията се прилагат възможно най‐скоро. Те дори могат дабъдат прибавени към Sprint Backlog за следващия Спринт.
Спринтът приключва с Ретроспекцията. Това е тричасова, ограничена във времето среща заедномесечни Спринтове. За по‐кратки Спринтове събитието обикновено е по‐кратко.

Scrum Артефакти (Scrum Artifacts)Артефактите на Scrum представят работа или стойност (value). Те са проектирани за да направят
всяка ключова информация максимално прозрачна. Така всички, които ги инспектират, имат еднои също основание за адаптация.
Всеки артефакт съдържа ангажимент, за да осигури предоставянето на информация, която
увеличава прозрачността и устрема, спрямо които напредъкът може да бъде измерван:●●●За Product Backlog това е Продуктовата Цел (Product Goal).
За Sprint Backlog това е Спринт Целта (Sprint Goal).
За Инкремента (Increment) това е Дефиницията на Готово (Definition of Done).

Тези ангажименти съществуват, за да укрепват емпиризма и Scrum ценностите за Scrum Екипа инеговите заинтересовани лица.

Product Backlog
Product Backlog е постоянно обновяван (emergent) подреден списък от всичко, което енеобходимо за да се подобри продукта. Той е единственият източник на работата, която поема
Scrum Екипа.
Елементите на Product Backlog, които Scrum Екипът може да завърши като Готови в рамките наедин Спринт, се смятат за подготвени (“ready”) за подбор по време на Планирането на Спринт. Те

11обикновено придобиват това ниво на прозрачност в следствие на усъвършенстване.
Усъвършенстването (refinement) на Product Backlog се изразява в разбивката и по‐детайлното
дефиниране на Product Backlog елементите в по‐малки и точни такива. Това е постоянна дейностна добавяне на детайли като описание, подредба и оценка. Атрибутите често варират спрямо
сферата на работа.
Разработчиците, които ще извършват работата са отговорни за оценяването. Product Owner можеда повлияе на Разработчиците като им помага при разбирането и взимането на компромисни
решения при подбора.

Ангажимент: Продуктова Цел (Product Goal)Продуктовата Цел описва едно бъдещо състояние на продукта, което може да служи като мишена,спрямо която Scrum Екипът може да планира. Остатъкът от Product Backlog се поражда, за даопредели какво точно би постигнало Продуктовата Цел.
Продуктът е средство, чрез което се осъществява стойност (value). Той има ясниграници, добре познати заинтересовани лица и добре определени потребители иликлиенти. Един продукт може да представлява услуга, физически продукт или нещо по‐абстрактно.
Продуктовата Цел е дългосрочната цел (objective) на Scrum Екипът. Те трябва да постигнат (илиизоставят) една цел преди да се заемат със следващата.

Sprint Backlog
Sprint Backlog е съставен от Спринт Целта (защо), подбраните за Спринта елементи на ProductBacklog (какво), както и действителен план за осъществяването на Инкремента (как).
Sprint Backlog е план, направен от и за Разработчиците. Той е ясно видима, текуща картина наработата, която Разработчиците планират да завършат по време на Спринта, за да постигнат
Спринт Целта. Следователно Sprint Backlog се обновява през целия Спринт в резултат от наученотов процеса на работа. Той трябва да е достатъчно детайлен, за да могат Разработчиците даинспектират своя напредък по време на Ежедневния Scrum.

Ангажимент: Спринт Цел (Sprint Goal)Спринт Целта e единствения обект (objective) на Спринта. Въпреки че Спринт Целта е ангажимент,поет от Разработчиците, тя позволява гъвкавост от гледна точка на точната работа, необходима запостигането ѝ.
Спринт Целта също създава съгласуваност и устрем, които насърчават Scrum Екипа да работи
заедно, вместо дейността да се разпределя в различни инициативи.

12Спринт Целта се създава по време на срещата за Планиране на Спринта и тогава се прибавя към
Sprint Backlog. В процеса на работа Разработчиците мислят за Sprint Целта. Ако работата се окаже,че е различна от очакваното, те си сътрудничат с Product Owner, за да договорят обхвата на Sprint
Backlog в рамките на Спринта, без да променят Спринт Целта.

Инкремент (Increment)Един Инкремент е конкретен етап от постигането на Продуктовата Цел. Всеки Инкремент еадитивен към всички предходни Инкременти и е старателно тестван, гарантирайки че всички
Инкременти работят заедно. За да може да осигури стойност (value), той трябва да бъдеизползваем.
По време на един Спринт е възможно да бъдат създадени няколко Инкремента. Сборът от тезиИнкременти се представя в срещата Ревю на Спринт в духа на емпиризма. Въпреки това, единИнкремент може да бъде доставен на заинтересованите лица преди края на Спринта. Ревюто наСпринта никога не бива да бъде считано за стъпка, пречеща на пускането на стойност вексплоатация.
Работата не може да бъде считана за част от един Инкремент, ако не отговаря на Дефиницията наГотов.

Ангажимент: Дефиниция на Готово (Definition of Done)Дефиницията на Готово е официално описание на състоянието на Инкремента, когато посрещне
мерките за качество необходими за продукта.
Инкремент се ражда в момента, в който един елемент на Product Backlog отговаря наДефиницията на Готово.
Дефиницията на Готово създава прозрачност като дава на всички уеднаквено разбиране заработата, която е свършена като част от Инкремента. Ако елемент на Product Backlog не отговаряна Дефиницията на Готово, той нито може да бъде пуснат в експлоатация, нито може да бъдепреставен в срещата Ревю на Спринт. Вместо това, той се връща в Product Backlog за бъдещо
преразглеждане.
Ако Дефиницията за Готово на един инкремент е част от стандартите на организацията, всички
Scrum Екипи трябва да я следват като минимум. Ако не е стандарт на организацията, Scrum Екипа
трябва да определи Дефиницията за Готово, адекватна за съответния продукт.

13Разработчиците са задължени да следват Дефиницията за Готово. Ако има няколко Scrum Екипа,работещи заедно по един продукт, те трябва заедно да определят и да спазват една и същаДефиниция за Готово.

Заключение
Scrum е безплатен и е представен в това ръководство. Scrum платформата, както е представен тук,е неизменима. Въпреки че е възможно прилагането само на части от Scrum, резултатът няма дабъде Scrum. Scrum съществува единствено в цялата си пълнота и функционира добре катоконтейнер за други техники, методологии и практики.

Благодарности
ХораОт хилядите хора, които са допринесли към Scrum, би трябвало да споменем тези, които сасложили основите в самото начало: Jeff Sutherland, работейки с Jeff McKenna, и Ken Schwaber,работейки с Mike Smith и Chris Martin и всички те работейки заедно. Много други допринесоха
през следващите години и без тяхната помощ Scrum не би бил толкова стабилен, какъвто е днес.

История на Scrum Ръководството
Ken Schwaber и Jeff Sutherland първи съвместно представят Scrum на OOPSLA конференцията през1995. Това представяне по същество документира това, което Ken и Jeff са научили презпредходните няколко години, прилагайки Scrum. Това е първата официална формулировка на
Scrum.
Scrum Ръководството документира Scrum, какъвто Jeff Sutherland и Ken Schwaber са разработили иподдържали през последните повече от тридесет години. Други източници ще ви предоставят
информация за методи, техники и процеси, които допълват Scrum платформата. Те могат даоптимизират продуктивността, стойността (value), креативността и удоволствието от резултатите.
Историята на Scrum е описана другаде. За да отдадем заслуженото на компаниите, които първи сапрактикували и съответно подобрявали Scrum, трябва да споменем Individual, Inc., Fidelity
Investments и IDX (сега GE Medical).

Превод
Това ръководство е преведено (от английски език) от оригиналната версия на документа,предоставена от Ken Schwaber и Jeff Sutherland. Автор на превода е Георги Анев. Редактор,Вероника Вълева. anev.george@gmail.com

14Промени в Scrum Ръководството между 2017 г. и 2020 г.
Още По‐малко Предписващ
През годините Scrum Ръководството започна да става все по‐предписващо. Новата версия за 2020
г. цели да възвърне Scrum като една минимално необходима платформа, като премахва илисмекчава предписващия език. Например, премахнати са въпросите за Ежедневния Scrum,смекчена е терминологията около елементите на Product Backlog, смекчен е езика, описващ
елементите от Ретроспекцията, които могат да бъдат прибавени към Sprint Backlog, съкратен епасажа за отменяне на Спринт и др.

Един Екип, Съсредоточен върху Един Продукт
Целта е да се премахне идеята за отделен екип в екипа, която води до разделение и между
Product Owner и Разработчиците. Вече има само един Scrum Екип, съсредоточен върху една исъща цел, с три различни вида отговорност: Product Owner, Scrum Master и Разработчици.

Въвеждане на Продуктова Цел (Product Goal)
Scrum Ръководството за 2020 г. въвежда понятието Продуктова Цел за да насочи Scrum Екипа къмедна по‐висша и стойностна цел. С всеки един Спринт продуктът трябва все‐повече да седоближава до цялостната Продуктова Цел.

Подходящо Място за Спринт Целта, Дефиницията на Готово и Продуктовата ЦелПредходните Scrum Ръководства описват Спринт Целта и Дефиницията на Готово без да импридават определена самоличност. Те не бяха артефакти, но бяха някак си свързани сартефактите. С въвеждането на Продуктовата Цел, версията за 2020 г. дава по‐голяма яснота потози въпрос. Всеки един от трите артефакта вече съдържа „ангажименти“. За Product Backlog товае Продуктовата Цел, за Sprint Backlog това е Спринт Целта, а за Инкремента (Increment) това еДефиницията на Готово (вече без кавички). Ангажиментите съществуват за да допринасят запрозрачността и устремеността към напредъка за всеки един артефакт.

Самоуправляващи вместо Cамоорганизиращи
Предходните Scrum Ръководства описват Разработчиците като самоорганизиращи се, като избираткой и как да върши работата. С нейният акцент върху Scrum Екипа, версията за 2020 г. набляга
върху един самоуправляващ се Scrum Екип, който избира кой, как и по какво да работи.

Три Теми за Планиране на Спринт
Освен темите „Какво“ и „Как“ Scrum Ръководството за 2020 г. изтъква трета тема – „Защо“, която
визира Спринт Целта.

15Цялостно Опростяване на Езика за По‐широка Аудитория
Scrum Ръководството за 2020 г. се фокусира към премахването на излишни и сложни изрази, кактои премахването на всички останали препратки към Информационните Технологии (напр. тестване,системи, дизайн, изисквания и т.н.). Scrum Ръководството сега е около 13 страници.

16