Scrum

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене
Процесът на Scrum

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

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

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

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


Етимология[редактиране | edit source]

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

Scrum роли[редактиране | edit source]

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

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

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

2.Помощни роли а) Stakeholders / Клиенти или Вендори б) Managers /Мениджъри

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


Scrum терминология[редактиране | edit source]

Спринтът е най-малката единица време за разработване. Спринтовете са с постоянна дължина от 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[редактиране | edit source]

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

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

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

Специфични практики[редактиране | edit source]

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

Срещи след спринта:[редактиране | edit source]

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

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

Спринт Ретроспекция
- Всички членове на екипа си припомнят и обсъждат миналия спринт.
- Правят се продължителни подобрения по процесите.
- Задават се 2 основни въпроса:
  • Какво мина добре по време на спринта?
  • Какво може да бъде подобрено за следващия спринт?
- Срещата трябва да се вмести в 3 часа.


Инструменти за управление на проекти, които поддържат SCRUM:[редактиране | edit source]

  • 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
  • Tinypm
  • VersionOne
  • Visual Studio 2010, Microsoft Team Foundation Server
  • Yodiz

Източници[редактиране | edit source]

Допълнителна литература[редактиране | edit source]