KNOW INTUIT, Лекция, Scrum етапи и събития

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

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

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

Подобренията трябва да бъдат заснети и добавени към натрупания продукт. След това те се оценяват в съответствие със съществуващите бизнес приоритети в целия обхват на съществуващите задачи. Следващият спринт получава задачи с най-висок приоритет.

Всеки спринт е малък "водопад". По време на спринта се извършва цялата работа за събиране на изисквания, разработване и тестване на продуктовото увеличение. Количеството работа, включено в спринта (назад в спринта), трябва да бъде фиксирано. Това позволява на екипа да се ангажира с количеството работада се направи в спринт. Това означава, че изоставането в спринта не може да бъде променено от никой друг освен от отбора.

Sprint има свой собствен жизнен цикъл, който, както бе споменато по-горе, е подобен на класическия подход за разработка на софтуер в миниатюра:

Първо, цялостното планиране на спринта се извършва на два етапа.

Планирането на спринта се състои от две последователни ралита:

а)

Първият митинг. Дефиниране на целите на спринта.Участници: екип, собственик на продукта, Scrum master. Целта на тази среща е да се определи целта на спринта и да се запълни изоставането му.

б)

Второ рали.Определяне как да се изпълнят задачите, взети в изоставането в спринта. Участници: екип, Scrum master. Целта на това рали е да се определи как точно ще се развива функционалността, за да се постигне целта на спринта и да се синхронизира разбирането на всички разработчици какво точно ще се прави. Именно на тази среща се използва техниката Planning Poker за оценка на сложността и продължителността на задачите. Ако по време на изпълнението на задачите се окаже, че членовете на екипа може да нямат време да изпълнят планираното, проследено на диаграмата за изгаряне на задачите, тогава ръководителят на Scrum, собственикът на продукта и екипът се срещат и откриват как да намалят работата и все пак да постигнат целта на спринта.

Развитие на спринтовото прираст.

Активни членове: екип. Пасивни участници: Scrum master, product owner. Целта е да се разработи продукт от екип. Това е основният процес, в който екипът заема активна позиция, от която ще зависи резултатът от дейността му. Scrum Master и Product Owner са на разположение, за да помогнат и да отговорят на въпроси, ако е необходимо.

След спиркатаспринт, трябва да се проведе среща на отбора, за да се обсъдят причините за спирането. След това жизненият цикъл на спринта трябва да се повтори, започвайки с планирането.

По време на периода на спринта всеки ден е необходимо да се провежда кратка среща, наречена "ежедневна", така че всички членове на екипа да разберат кой какво прави в конкретния момент. Продължителността на деня е максимум 15 минути. Неговото внедряване има за цел да адресира очевидни и потенциални проблеми. Домакинът на тази среща е Scrum Master, който задава три въпроса на всеки член на екипа в кръг:

Какво е направено от предишния ежедневник?
Какво смяташ да правиш днес?
С какви проблеми се сблъскахте?

Всички останали въпроси и дискусии да бъдат извадени от митинга и обсъдени между заинтересованите от неговото решение.

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

След приключване на спринта е необходимо да се демонстрира внедрената функционалност и последващ анализ на спринта. Демо дейността се нарича "демо", а спринтовият анализ се нарича "ревю" или "ретро".

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

В ретро екипът и собственикът на продукта обсъждат напредъка на процеса, отбелязват неговите предимства и недостатъци, вземат решения за възможникоригиране на процеса, за да го подобрим. Scrum Master е директният организатор на тези събития и отговаря за цялостната подготовка за тях. Екипът му помага да напише ajenda и да планира график за изпълнение. Подготовката за ралито не трябва да отнема на отбора много време (като правило - не повече от два часа). Забранено е използването на инструменти като Power Point за демонстрацията. Функционалността трябва да бъде демонстрирана директно в работещия софтуерен продукт. Подготовката за ралито също не трябва да отнема на отбора повече от 2 часа. В следващите глави ще продължим по-подробно дискусията, свързана с разглеждането на отделните етапи и дейности. Тук е необходимо да се съсредоточим върху толкова важна концепция за процесите на гъвкава разработка на софтуер като целта на спринта.

Повечето екипи днес са фокусирани върху изпълнението на планирани задачи за спринт, които са били договорени със собственика на продукта. Така възниква един цех за изпотяване, чийто основен критерий за успех са напълно изпълнените и демонстрирани задачи.

Ако някоя история не е направена - вечният срам на разработчиците, които са отговорни за това, пълният провал на спринта, катастрофата от универсален мащаб и продължаващата скръб, инициирана от клиентите на произведението.

В отговор на това се появява екстремистката реакция на самия Scrum екип. Има мнение, че не могат да се правят промени в обхвата на спринта, след като спринтът е започнал, и това съответно ограничава клиента. Но ако премахнем рамката на спринта по отношение на времето и обема на задачите, тогава се "плъзгаме" в класическия, водопаден модел на развитие на информационните системи.

И първата, и втората ситуация изобщо не са "гъвкави". Вярно, както често се случва в 100% от ситуациите,някъде по средата. За да се постигне тази средна точка, концепцията за целта на спринта се появи в Scrum. Това е екипна настройка, която определя защо ще изразходваме времето и ресурсите за спринта, какво искаме да постигнем по отношение на нарастващата стойност за клиента. И това не е просто набор от различни изисквания. Целта ни позволява и ни инструктира да бъдем по-гъвкави и толерантни, както към малка промяна в обхвата на спринта, така и към неочаквани причини, които не ни позволиха да изпълним това или онова изискване в спринта. Успешен спринт е спринт, който е постигнал целта си. Ако сме реализирали очакванията на клиента, дошъл на демото, то това е успех.

Целта на спринта е инструмент, който ни дава гъвкавостта да управляваме очакванията на клиентите и ефективността на екипа в рамките на спринта. Единственото условие е целта на спринта да не се променя в рамките на самия спринт.