Scrum

Scrum e итеративна, инкрементална рамка за управление на проекти, често при Гъвкава методология; вид софтуерно инженерство.

Макар че подходът на Scrum е първоначално предложен за управление на проектите за разработване на продукти, той се фокусира с времето върху управлението на софтуерни проекти и може да бъде използван, за да задвижва екипи за софтуерна поддръжка или като общ подход за проектов / програмен мениджмънт. Тази методология е променила възприятията за типичното управление на проекти, като ясно показва предимствата на гъвкавите пред „waterfall“ или неитеративните, негъвкави методологии.

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

SCRUM е разработен за тези компании, чиято верига на стойността (изобразяваща процеса от началото до края на продукта и всяка стъпка, на която се добавя стойност) прави дългосрочното планиране на продукта доста трудно. За разлика от типичния мениджмънт чрез контрол и командване, тук се набляга на обратната връзка и се дава повече власт в ръцете на хората, които извършват операциите по процесите.

Етимология

Подходът е създаден през 1987 и името му произлиза от scrum, scrummage – „спорна топка“ на английски и по-точно - идеята за играта ръгби в случая, и един холистичен подход, по идеята за рестартирането на играта след кратки прекъсвания за нарушения.

Scrum роли

1. Ключови роли или самият SCRUM екип.

Product Owner / Собственик на продукта: Собственикът на продукта е отговорното лице за това организацията да добавя стойност (към продукти и услуги) за клиентите. Той е гласът на клиента и прави всякакви неща свързани с него. Той общува с клиента, задава приоритети на задачите и вписва всичко в „product backlog”- а. В SCRUM екипа такава роля трябва да има само един човек. Ролята на продуктния собственик не се препоръчва да се смесва с тази на SCRUM ръководителя. От друга страна той може да бъде човек от екипа за разработка.
Scrum Master / Scrum ръководител: Ръководителя е отговорен да бъдат премахвани пречките при изпълнението на договорените в спринта задачи и да постигне желаните за спринта цели. Той не е лидер на екипа, а нещо като служещ на екипа лидер. Следи за изпълнение на правилата и за това нещата да се случват по концепциите на SCRUM. Ръководителят се грижи за това екипът да не бъде разсейван със странични фактори и за това всичко да е подчинено на целите на спринта.
Development Team / Екип разработка: Екипът, който създава продукта, върши „черната работа“ – анализира, прави архитектурата, пише код, тества го, извършва работа по техническа комуникация, документира и т.н. Състои се от 3 до 9 души, които имат различни и сходни умения по множеството работа. Той има задачата да доставя увеличен брой или подобрени парчета софтуер на края на всеки спринт. Тези парчета трябва да са по някакъв начин подходящи за изпращане или продажба. Така във всеки един момент проектът може да бъде спрян и продаден. Екипът за разработка се самоорганизира, дори и това да налага сътрудничество с отдел/организация за управление на проекти.

Product Owner, Scrum Master и Team образуват заедно т.нар. Scrum Team.

2. Помощни роли

а) Stakeholders / Клиенти или Вендори

б) Managers /Мениджъри

Матрицата помага да се планират всички заинтересовани лица от проекта. По-конкретно се планира какви да бъдат те по време на всяка от фазите (при по-детайлния план – на всяка от дейностите) на проекта: Responsible, Accountable, Consultant, Informed и Facilitate.

Scrum терминология

Спринтът е най-малката единица време за разработване. Спринтовете са с постоянна дължина от 1 седмица до 1 месец. Всеки спринт е опит за подобрение вкаран във фиксирани времеви рамки.

Преди всеки спринт има среща за планиране на спринта. На нея се поставят измеримите цели за спринта и се идентифицират задачите, които ще бъдат свършени в неговите рамки. По време на всеки спринт екипът създава завършени парчета от даден продукт. Дейностите за всеки спринт се описват и взимат от „продуктовата опора“ или на английски „product backlog” (пример на фиг. 3). Често тези дейности са описани като характеристики, които продукта трябва да има и да бъдат постигнати за спринта. Т.е. product backlog е приоритизиран списък на изискванията. Какво от списъка да влезе в даден спринт се решава на планиращата среща преди спринта. Продуктовият собственик уведомява екипа кои части от списъка с изисквания иска да бъдат свършени на предстоящия спринт. Развойният екип преглежда, обсъжда, решава и записва в Sprint Backlog кои от тези изисквания и цели ще успее да изпълни на предстоящия спринт. Sprint Backlog е собственост на развойния екип. Целите, вписани в този документ, не трябва да бъдат променяни по време на спринта. За разработването се определя фиксирана продължителност, такава, че спринтът да свърши навреме. Изискванията, които не бъдат удовлетворени за спринта се изключват и връщат към product backlog. След като спринтът е изпълнен, екипът демонстрира как се използва софтуерът.

SCRUM позволява организирането на самоорганизиращи се екипи като стимулира всички членове на екипа да се намират на едно и също място и да си комуникират на живо.

Ключов принцип на SCRUM е това, че се приема още в самото начало на проекта, че изискванията няма как да са пълни и напълно разбрани. Т.е. очакват се нововъведения от клиента – промяна на желанията му. SCRUM се фокусира върху способността на екипа да доставя бързо и да е готов да отговори бързо на неочакваните промени. Това е положителна черта за SCRUM, защото резките промени не могат да бъдат добре оборени с традиционните отгатващ или планиращ методи.

Както в другите гъвкави методологии за управление на проекти, SCRUM може да се имплементира чрез различни видове инструменти. Най-много се използват спредшийтове (екселски таблици или еквивалента им в Google Docs). В тях се правят така наречените SCRUM „артефакти“ като sprint backlog-а. Други организации прилагат SCRUM с помощта на бели дъски, лепящи се листчета и хартиени документи.

Product Backlog: Както е упоменато по-горе, това е приоритетно подреден списък с изисквания, редактируем от всеки, но отговорност на продуктния собственик. При приоритизирането последния взема предвид рискове, добавена стойност, разходи, зависимости, дата на предаване на клиента и т.н. Характеристиките се добавят в този документ следвайки форматът на история: „As a <user type> I want to <do some action> so that <desired result>“.

Sprint Backlog: Списък с работата, която развойният екип (собственик на документа) трябва да свърши. В нея по време на ежедневните SCRUM срещи се вписват идентифицирани задачи. Те обаче не се задават на никого конкретно. Програмистите сами си избират задачи от там спрямо приоритети. Често се използва дъска / таблица, в която се вписва статусът на задачите – „да бъде свършено“, „в процес на работа“, „свършено“.

Задачите се идентифицират като развойния екип си избира истории от product backlog-a. После той разбива тези истории. Пита се „можем ли да направим и това?“ и така докато екипът почувства, че е взел достатъчно работа за спринта.

Story Point: Абстрактна величина, използвана за оценка на времето, необходимо за изпълнение на дадена задача.

Scrum Poker: Използва се за по-точна оценка на времето, което отнема реализирането на дадена задача. Всеки член на тима получава комплект карти с различни числа (използват се числата на Фибоначи, обикновени числа, степени на числото 2 и др.). Всяка конкретна задача се предлага за обсъждане в тима и след приключването на това обсъждане, всеки участник показва една карта с броя на Story Points, необходими според него за цялостното завършване на задачата. Ако всички са единодушни, това число се записва в backlog-а. При разногласия, участникът дал най-голямо число и участникът с най-малко излагат аргументите за своите решения пред тима и се пристъпва към ново гласуване. Процедурата се повтаря докато има различия.

Increment: Това е сумата от всички задачи свършени на спринтовете до даден момент. Накрая на спринта инкрементът трябва да е готов във форма годна за някаква употреба.

Burndown chart: Отразява текущия напредък по време на спринта. Графичен еквивалент на Scrum backlog-а и е достъпен за Product Owner-а. Актуализира се ежедневно, непосредствено след приключване на Daily Scrum.

Backlog изчистване: време за истории (Backlog grooming: storytime):

По време на спринта, екипът трябва да прекара време за доизясняване на sprint backlog-а. Преценява се съществуващият backlog, доизясняват се критериите за приемане за отделните клиентски задания, разбиват се големите истории на по-малки. - Срещите не трябва да са по-дълги от час. - Не се включва разбиване на заданията на отделни задачи. - Екипът има свободата да реши колко срещи са нужни за една седмица.

Най-често използваният метод е покер планиране.

Ежедневен Scrum

По време на спринта, всеки ден се провеждат т.нар. правостоящи срещи (stand-up meetings). Тези срещи продължават от 5 до 15 минути и се провеждат ежедневно в определен час. На срещата всеки от екипа абсолютно неформално разказва за три неща:

какво е работил предишния ден,
какво планира за предстоящия ден
какви проблеми е срещнал, които му пречат да работи.

Главни атрибути на срещата са:

Срещата започва точно навреме.
Мястото и часът са едни и същи всеки ден.
Срещата трябва да се вмести точно в 15 минути.
Може всички, но главно говорят основните роли в екипа.

На срещата се обновява и backlog-ът като се отбелязва свършената работа.

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

Специфични практики

Ежедневни правостоящи срещи (Stand-up meetings)
Backlog: списък със задачите за текущия спринт и тяхното състояние
Самоорганизиращ се екип: екипът не следва предварително раздадени задачи, а всеки негов член се стреми да допринася за постигне целите на спринта – всеки ден всеки си взима задачи, за които отговаря
Работни срещи и обсъждания с клиента и с екипа след всеки спринт

Срещи след спринта

Среща за обзор на спринта

Преглежда се и работата, която е била свършена, и тази която не е.

Представя се свършената работа на клиентите (показва се демо).
Несвършената работа няма как да бъде представена, но се описва.
Срещата трябва да се вмести в 4 часа.

Спринт Ретроспекция

Всички членове на екипа си припомнят и обсъждат миналия спринт.
Правят се продължителни подобрения по процесите.
Задават се 2 основни въпроса:

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

Срещата трябва да се вмести в 3 часа.

Инструменти за управление на проекти, които поддържат SCRUM

Banana Scrum
CollabNet ScrumWorks Pro
Hansoft
Kunagi
IBM Rational Team Concert
Ice Scrum
JIRA using Green Hopper plugin
Mingle by ThoughtWorks Studios
OneDesk
PangoScrum
Pivotal Tracker
Planbox
Rally Software
Redmine and ChiliProject, with a plug-in (several are available)
ScrumDo
ScrumPad Pro
Scrumwise
Scrumy
Sprintometer
VersionOne
Visual Studio 2010, Microsoft Team Foundation Server
Yodiz

Източници

Scrum Архив на оригинала от 2009-01-04 в Wayback Machine.

Допълнителна литература

Kim H. Pries, Jon M. Quigley, Scrum Project Management, CRC Press, 2010