Гъвкава методология Scrum

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

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

Основни принципи на организация на работа в Scrum екипи

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

   Backlog е документ, който съдържа списък на всички изисквания към проекта (визия на проекта, списък на това, което трябва да се изпълни). Елементите от списъка са подредени по важност. С напредването на проекта списъкът и приоритетите може да се променят в зависимост от нуждите на клиента, новите идеи или променящите се условия.

2. Ние разделяме изискванията на малки, ориентирани към потребителя, функционални части, които са възможно най-независими една от друга, което води до продуктово изоставане. След това подредете своите натрупани елементи по важност и направете относителна оценка на размера на всяка история. Изберете отделно лице - собственик на продукта, който ще отговаря за изискванията и техните приоритети, обхващайки всички заинтересовани страни.
3. Извършваме цялата работа за кратки, от 1 до 4 седмици, фиксирани итерации – спринтове, предоставяйки пълна функционалност в края на всеки от тях, която може да бъде пусната на пазара, ако е необходимо – продуктово увеличение. Екипът според скоростта си събира задачи за непроменлива във времето итерация – спринт. Всеки ден се провежда Scrum среща, на която екипът синхронизира работата си и обсъжда проблемите. Докато работят, членовете на екипа поемат натрупаните елементи според приоритета.
   

   спринт – кратък етапразвитие на проекта. Функциите, които трябва да се изпълняват при всеки спринт, са фиксирани и не могат да се променят по време на спринта. Те са разделени на задачи, а задачите имат оценки и приоритети. В класическия Scrum се приема, че продължителността на спринта е фиксирана и варира от 2 до 4 седмици, в зависимост от опита на екипа.

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

Какво е Scrum. Същността на техниката

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

Методологията Scrum, разработена от Джеф Съдърланд и Кен Швабер, е предназначена да разреши всички тези проблеми. Scrum— Това е обратното на класическия подход стъпка по стъпка, възприет за изпълнение на проекта. Методологията на Scrum е възприета от много компании, както от технологичните индустрии, откъдето идва, така и от традиционните и дори нестопански. Подходът, който е в основата на методологията Scrum, може да се приложи към различни дейности, които изискват работа в екип.

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

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

1. Първо трябва да изберете« Собственик на продукта» — човек с визия за това, което ще създадете или постигнете.

2. След това трябва да съберете"Отбор" , което ще включва хора, които пряко изпълняват работата. Те трябва да притежават уменията и знанията, за да помогнат за реализирането на визията на собственика на продукта.

3. Трябва да изберете „Scrum Master“ - някой, който ще следи напредъка на проекта, ще улесни кратки срещи и ще помогне на екипа да премахне пречките пред постигането на целта.

4. Когато започнете работа, трябва да създадете най-пълния списък с всички изисквания за продукта или целта. Елементите в този списък трябва да бъдат подредени по приоритет. Списъкът се нарича„Натрупан продукт“ . Той може да се развива и променя през целия живот на проекта.

5. Членовете на екипа трябва да оценят всеки елемент, използвайки своя собствена система за оценяване за трудността и разходите, които ще бъдат необходими за завършването му.

6. След това участниците Scrum Master и собственикът на продукта трябва да проведе първияскръм среща , където ще планират спринта— определено време за изпълнение на част от задачите. Продължителността на спринта не трябва да надвишава един месец. За всеки спринт отборът печели определен брой точки. Отборът трябва постоянно да се стреми да надхвърли броя на точките, натрупани за предишния спринт в новия спринт, т.е. неговата цел— постоянно надвишавате собствените си резултати— « увеличаване на динамиката на производителността» .

7. За да могат всички участници да са наясно със състоянието на нещата, трябва да създадетесхватка дъска с три колони:« Трябва да се направи или изостава" ; „В ход“; "направен" . Участниците поставят стикери със задачи на дъската, които се местят една по една от колоната, докато работят.„Назад“ в колоната „в процес“ и след това в колоната „готово“.

8. Провежда се ежедневноскръм среща . Според Джеф Съдърланд« това е пулсът на целия Scrum процес» . Същността му е проста— Всеки ден, в движение, петнадесет минути за всеки да отговори на три въпроса:« » , « » , « » .

9. В края на спринта екипът го преглежда— провежда среща, на която участниците обсъждат свършеното по време на спринта.

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

Недостатъци на традиционния подход за управление на проекти

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

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

Защо? Както отбелязва Джеф Съдърланд, Хенри Гант изобретил такива диаграми през 1910 г. Те получават широко разпространение през Първата световна война. Въпреки това,« всеки, който е изучавал историята на тази война, знае, че нито обучението на жива сила, нито системата на организация някога са били нейни силни страни. Не мога да разбера защо концепцията за Първата световна войнастава де фактоинструмент за аналитичен дизайн и се използва дори през 21 век. Ние изоставихме принципите на окопната война, нонякак си "окоп" организационните идеи остават популярни и до днес» .

IN съвременни условиятази схема е неподходяща и подобна на модела на Политбюро на ЦК на КПСС, който"повярвал" доклади, получени в навечерието на катастрофата съветски съюзи което нямаше много общо с реалното състояние на нещата.

Scrum философия

Методологията Scrum отразява страстта на автора към японските бойни изкуства. Според него в Япония« Scrum не се третира като мода. Японците разглеждат Scrum като подход за решаване на проблеми, като начин на действие, като начин на съществуване — изобщо като начин на живот. Когато уча хората на тази техника, често говоря за дългогодишния си опит в японското бойно изкуство Айкидо. » .

Общото между Айкидо и Скръм е, че могат да бъдат усвоени само в процеса на работа, когато« вашето тяло, вашият ум и вашият дух се обединяват като едно чрез постоянна практика и стремеж към съвършенство. Практикувайки айкидо, ние разбираме концепцията за шухари (Шу Ха Ри) — това е както концепция за бойни изкуства, така и показател за ниво на умения » .

Същността на екипната работа в Scrum

Scrum - Това е преди всичко екипната работа. Авторът идентифицира три характеристики на най-добрите отбори:

безкрайното търсене на съвършенство;

• автономия - способност за самоорганизиране;
• мултифункционалност. Наличие на различни специалисти и култура на взаимодействие и взаимопомощ.

Какъв размер трябва да бъде екипът? Джеф Съдърланд препоръчва малки групи— около седем души. Той цитира данни, че ако една група се състои от повече от девет души, тогава скоростта на нейната работа пада.

Освен това авторът припомня „закона на Брукс“:

« Ако проектът не е навреме, добавянето на още труд ще го забави още повече. » .

Шеф на екипа- това е Scrum Master . Негов дълг— поддържайте срещите кратки и открити, помагайте на групата да премине през препятствията, които пречат на работата, водете екипа по пътя на непрекъснатото усъвършенстване« и редовно търсете отговора на въпроса« Как можем да направим още по-добре това, което вече правим добре?» .

Без многозадачност

Авторът предупреждава срещу многозадачност— всъщност няма такъв, нашият мозък не може да извършва две действия едновременно, той просто превключва между задачи и общо времеизпълнението на всеки от тях се увеличава в сравнение с това, ако ги изпълняваме един по един. Методологията на Scrum предполага, че трябва да изпълнявате всички задачи една по една, а не« управлява пет проекта едновременно по балансиран начин» .

« Актьорство традиционен метод, тоест опитвайки се да направи всичко наведнъж, групата ще завърши трите си проекта преди края на юли. Ако екипът подходи с гъвкава стратегия като Scrum и работи върху всеки проект един по един, минимизирайки времето и усилията, свързани с превключването на контекста, това може да бъде направено до началото на май. » .

Същността на работата е поток

Scrum ви помага да стигнете до"поток" - състояние на най-висока концентрация, когато правите това, което трябва, без да изразходвате усилия за това, без да се насилвате или да се натискате. Авторът смята, че основното за успешна работа — постигане и управление на това състояние.« В работата си трябва да постигнете основното— безпроблемно управление на потока. В бойните изкуства или медитационните практики постигаме усещане за единство в движението, което не изисква усилия,— това е енергия, която протича безпрепятствено през нас. Когато гледате страхотни танцьори или певци, усещате как се подчиняват на тази енергия. Ние трябва да се стремим да постигнем такова състояние в нашата работа.» .

Как да го постигнем? Зад състоянието на потока стои вътрешната дисциплина,

« Никакво движение не трябва да се губи » .

Scrum и щастие

Хората искат да бъдат щастливи. Но Джеф Съдърланд е сигурен, че щастието— Това не е неактивна растителност, а ярък, богат и активен живот. Scrum допринася за щастлив живот, защото ви помага да работите и да действате продуктивно.

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

Елементи на Scrum

Спринтове

Както беше отбелязано по-горе, в началото на спринта и за да осигурите откритост и видимост, трябва да създадете специална дъска и да я разделите на три колони:„Изоставане“; „В ход“; "направен" . Преди всеки спринт членовете на отбора се нареждат в колона"Назад" лепящи се бележки със задачи, които смятат, че могат да изпълнят в спринт. По време на спринта всеки член на екипа, поел задача, залепва отново стикера от секцията„Назад“ в колоната „В процес на изпълнение“. . След изпълнение на задачата— в колоната „Готово“. . По този начин всеки може да види върху какво работят другите участници в момента.

Има обаче една важна забележка— « нищо не се прехвърля в колоната"направен" докато тази част от проекта не бъде тествана от клиента» .

« Друг важен аспект на спринта: след като екипът одобри списъка с изисквания, задачите от този списък „ са блокирани“ . Никой няма право да ги променя или допълва » . Авторът препоръчва товазащото че всяка намеса ще забави работата на екипа.

Ежедневни срещи

Въпросът е, че те трябва да се провеждат прави, всеки ден, по едно и също време, продължителността им не трябва да надвишава петнадесет минути, а участниците трябва да задават едни и същи три въпроса:« Какво направихте вчера, за да помогнете на отбора да завърши спринта?» , « Какво ще направите днес, за да помогнете на отбора да завърши спринта?» , « Какви препятствия стоят на пътя на отбора?» .

Направете го до края

В Scrum е важно да се научите да усещате ритъма на екипа. В най-лошия случай — когато в края на спринтанещо остава наполовина готово. Тогава е по-добре изобщо да не започвате този бизнес.

« Похарчени са ресурси, усилия, време, пари, но не е получен напълно работещ продукт » .

Планиране в Scrum

Как протича процесът на планиране в Scrum? Първо трябва да направите списък на всички неща, които влияят на вашата цел. След това ги приоритизирайте. Ако не спазвате времевите и финансовите ограничения, тогава можете по-лесно да премахнете последните елементи от списъка.

Какво да правя след това? Всеки елемент от списъка трябва да бъде оценен за това колко усилия, време и други ресурси ще са необходими за изпълнението. Как се прави оценка? Авторът предлага скала за относителни оценки. Например можете да сравнявате задачи"при кучета". Този проблем - дакел или ретривър? Или може би немски дог?

Но във всеки случай е по-удобно да задавате числени стойности. Например,« Дакел— мерна единица; Немски дог— тринадесет; лабрадорът стана петица, а булдогът — три» .

Авторът също така предлага използването на интересна техника за планиране на покер. Нейната същност— Всеки участник в процеса на планиране получава тесте карти с числата на Фибоначи— 1, 2, 3, 5, 8, 13 и така нататък. Всеки елемент от списъка, единица работа, която трябва да бъде оценена, е поставен на масата.

Изискванията са истории

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

« Представете си, че се гримирате „ Потребителска заявка на Amazon.com “ . Пробната версия изглежда така: „ Като потребител искам най-голямата книжарница в света, където мога да купя всяка книга по всяко време “ .Това описание пасва добре на характера на Amazon, но историята е твърде неясна, за да бъде полезна. нещонаправи. Трябва да фрагментираме историята си. Направете го наистина много специфичен и функционален. Ето няколко примерни потребителски истории, които можете да напишете, имайки предвид книгата. онлайн магазин :Като потребител обичам да търся книги по жанр, за да намеря бързо тези, които обичам да чета. Като потребител, когато избирам книги за закупуване, искам да сложа всяка една в количката си наведнъж , искам да мога да следя покупките на нашите клиенти, за да съм наясно какви книги могат да им бъдат предложени » .

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

Как да планирате спринт

В Scrum процесът на планиране се случва в началото на всеки нов спринт и се извиква— « планиране на спринта» . « Всички се събират, разглеждат списъка с потребителски истории, които вече са в опашката за изпълнение; разберете колко задачи може да поеме всеки член на групата; внимателно преценяват дали ще успеят да доведат избраните задачи до пълна готовност по време на този спринт; ще могат ли да демонстрират завършени единици работа на клиента и да му покажат завършените функции на продукта; Ще могат ли да си кажат в края на спринта, че са се справили с всичко? » .

След това екипът казва в унисон:„Напред! „— и се захваща за работа

Но какво е работата? Рутина, задължение? От гледна точка на Scrum, работа— това е история. Какво означава? Това означава, че трябва да представите някой, който има нужда от това, което правите; след това какво представлява и накрая защо хората се нуждаят от него.

Екипите трябва да опознаят добре своята динамика— колко работа може да свърши в един спринт. Това ще й помогне да работи по-интелигентно и ще премахне всички препятствия по пътя си.

« Динамика х време = резултат. Знаейки колко бързо се движите, ще ви помогне да разберете кога ще стигнете до финалната линия » .

Откровеност във всичко

Scrum предполага прозрачност на всички действия и процеси.

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

« Секретност— аз Нищо не може да остане в тайна. Всеки трябва да знае всичко, включително финансовите данни. Объркването е необходимо само за тези, които търсят собствената си изгода. » .

Собственик на продукта

Scrum поема три роли: Scrum екип - изпълнители на конкретни проекти; Scrum Master - това е този, който следи напредъка на проекта и помага на екипа да решава проблемите, и собственикът на продукта— този, който решава проблемите с продуктовата концепция и компилира изоставането.

« Scrum Masterи екипът са отговорни за темпото на тяхната работа и колко бързо завършват проекта. Собственикът на продукта е отговорен за това ефективната екипна работа да се превърне в печеливши резултати. » . Собственикът на продукта трябва да има задълбочени познания за пазара и трябва да има власт да взема решения.

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

Минимизиране на рисковете в Scrum

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

« Методологията Scrum е полезна за бизнеса, защото бързо отговаря на въпроса: можем ли да спечелим пари, ако направим това или онова?“

Не е нужно да харчите много пари, преди да разберетенещо не работи.

« Цинизмът е отговорът на нашето съзнание на чувството на отчаяние».
Джеф Съдърланд

Колко силна е алтернативата на PM?

Действайки като топ мениджър и ръководител на проекти, се натъкнах на концепцията за Scrum като вид екзотична алтернатива на класическото управление на проекти. Исках да разбера какви са идеологическите и технологични характеристики на този подход и каква всъщност е революцията на метода? Прочетох няколко монографии. Честно казано, след първата среща не видях много дълбочина. Методологията на Scrum изглеждаше донякъде пристрастна и неясна.

С второ, по-задълбочено изследване на метода Scrum, започнаха да се осъзнават функции, които според мен все още заслужават внимателно внимание от страна на бизнес общността. Дори изглежда, че този метод е интересен не само за търговската и производствената сфера, но и за други институции на нашето общество. Методът е приложим при проектиране на модели на образование, НИРД, държавно и общинско строителство. Въпреки това, както при всяко ново нещо, важно е:

• изключват абсолютизирането и рецептурната безупречност на въпросната технология;
• осъзнават, че методът Scrum е идеологически груб и може просто да „не пасва на нашата почва“ с неговите начини и традиции;
• вижте конфликтните точки, които носи този метод;
• разберете, че методът Scrum изисква прозрачна идеология на държавата и бизнеса по отношение на „правилата на играта“ с персонал, участващ в разработката.

Дали съвременната парадигма за управление на проекти, международни и национални стандарти (ANSI PMbok Guide, PM ICB IPMA, NTK) са продукт, който се използва от потребителите: държавата, нейните институции, бизнес? Да, разбира се. Какви проблемни области съществуват в съвременната дизайнерска практика въз основа на методологията на работа? Има няколко от тях, но основните две са: неспазване на сроковете на проекта и надвишаване на бюджета на проекта.

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

Това свойство на проектите е особено остро в области, които изискват иновативен подход. Методът Scrum може значително да смекчи тези проблеми. В началото на 2000-те години това е резултат от работата на двама новатори Д. Съдърланд и К. Швабер (САЩ). В своето развитие авторите на метода са използвали елементи от теорията на Х. Такеучи и И. Нонака, както и идеите на системата на Тойота (Тайичи Оно). И как революционен методуправление на проекти, моделът Scrum вече получи признание в западните страни и днес практиката на прилагането му не се ограничава само до бизнеса.

Терминология на метода

Авторите на метода с основание критикуваха класическия модел на планиране на проекти, който се използва от около 100 години въз основа на подхода на Г. Гант. Всъщност нищо не може да се противопостави на твърдението, че визуалната диаграма на Гант е по същество еднократна употреба. Не само че работата по него отнема много време, почти веднага след започване проектантска работаМоделът водопад в повечето случаи се оказва безполезен.

Причината е много проста: умствените конструкции по отношение на съдържанието и продължителността на операциите никога не съвпадат с реалните събития на проекта. Като алтернатива на каскадното планиране на проекти, методологията Scrum предлага гъвкав механизъм за планиране. Ще го разгледаме малко по-късно, но засега ще анализираме основните концепции, върху които работи методът Scrum.

1. Собственик на продукта. Тази цифра е отговорна за това екипната работа да дава резултати, които носят печалба на компанията. Той трябва да разбира отлично същността на продукта, възможностите на екипа и приоритетите на пазара.
2. Scrum Master. Метафорично, това е много интересна роля. „Лидер-слуга“, „капитан на отбора“, „треньор треньор“. Основната му задача е да води екипа по пътя на непрекъснатото усъвършенстване, премахвайки препятствията и причините за пречките.
3. Scrum дъска. Обикновена офисна дъска, разделена на части: „назад“, „на работа“, „в процес“, „за разглеждане“, „готово!“. По него се движат стикери със задачи.
4. Scrum среща. Финална среща в края на спринта.
5. Спринт. Времеви период от 1 до 4 седмици, който установява работния ритъм на дейностите на Scrum екипа за създаване на нова функционалност.
6. Срещи в движение или ежедневен Scrum. Кратки срещи на екипа на проекта за отговор на въпроси от Scrum Master за резултати, планове за деня и текущи пречки.
7. Назад (назад). Списък с текущи изисквания-задачи за създаване на функционалността на продукта на проекта.
8. Диаграма за изгаряне на задачи. Диаграма, показваща количеството свършена работа и оставащата работа в рамките на дадена задача.
9. Ред на Фибоначи. Математически модел, присъщ на природата на нашата Вселена, в който действа специален ред на числата. Тази последователност е много подходяща за алтернативно оценяване на продължителността на работата на проекта, чрез използването на така наречения "покер за планиране". По-долу е визуален модел на числова последователност.
10. Шухари (Шу Ха Ри). Шухари е една от концепциите на японските бойни практики (например айкидо), която е включена в принципите на метода Scrum като метафора за възможността за постепенно (итеративно) постигане на съвършенство на екип по проекта.
11. OODA. Принципът на метода Scrum на циклично изпълнение: наблюдавайте, навигирайте, решавайте, действайте.

Модел на последователността на Фибоначи

Основният модел на метода Scrum. Източник: Асхат Уразбаев. Кратък преглед Scrum методология

Кратко описание на процеса

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

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

Изпълнението на проекта чрез Scrum процеси се състои от четири големи блока.

1. Попълване на роли в Scrum екип.
2. Образуване на Scrum артефакти.
3. Осъществяване на дейност.
4. Възпроизвеждане на цикъла Scrum.

Визуален модел на процеса на метода Scrum

Ролите в метода Scrum са прости: собственик на продукта, Scrum master и екип. В същия ред се избират хора за тези роли. Собственикът на продукта е най-близо до класическата роля на мениджър на проекти; той е отговорен за създаването и редовната промяна на продуктовото изоставане. След като се образува изоставането, екипът на проекта започва да планира предстоящия спринт. В същото време „покерът за планиране“ се използва активно като по-обективен и балансиран инструмент, базиран на Делфийския метод и последователността на Фибоначи. Това създава локално изоставане за предстоящия цикъл на новия спринт.

Scrum артефактите в метода се разбират като: продуктови и спринтови натрупвания, проектен продукт с нова функционалност. Всеки спринт има за цел създаването на нова функционалност на продукта, макар и малък напредък, но който ще стане очевиден и може да бъде представен на клиента на проекта и други заинтересовани страни. Във вътрешната среда на цикъла на спринта екипът работи автономно, придружен от „текущи срещи“ и движещи се лепящи бележки върху дъската на Scrum. Пример за външния вид на дъската е показан по-долу.

Пример за Scrum борд

Съставът на атрибутите на Scrum борда може да отразява специфичните характеристики на подхода на компанията към дизайна. Освен това могат да бъдат включени диаграми за изгаряне на задачи, декларации за целите на спринта и т.н. След приключване на спринта се провеждат две събития по проекта: среща за преглед на спринта и ретроспективна среща. Резултатът от срещата за преглед е проектен продукт с модифицирана или напълно завършена функционалност. След ретроспективен анализ се появява списък с необходимите подобрения в работата на Scrum екипа. Цикълът е затворен, продуктовото изоставане е коригирано. От него се „изтеглят“ нови задачи и процесът започва отново.

Коментари за попълване на роли

Една от монографиите, с които успях да се запозная, беше книгата на Д. Съдърланд, в която Scrum е представен като нищо по-малко от революционен метод за управление на проекти. Работата е пълна с много примери от личния опит на автора, успешни дизайнерски решения и големи имена. Емоционално оцветяванеаргументацията работи впечатляващо. Като цяло подходът е традиционен за северноамериканската методическа школа. Въпреки леко объркващата логика, методът на проектиране не е труден за разбиране. В Приложението има добра помощ. Първите три стъпки на технологията са съвсем разумно посветени на ролите в Scrum екипа.

Стъпка 1 от алгоритъма на методологията Scrum

При по-внимателно разглеждане изводите и метафорите, дадени за всеки раздел от методологията, се оказаха много ефективни. Освен това моите коментари за секциите на алгоритъма ще се основават на принципа на търсене положителни точки, които благоприятно отличават Scrum от традиционната проектна методология. След това възнамерявам да формулирам въпроси, които предизвикват у мен съмнение или изискват разрешение Руски условияпроектна практика. Сред положителните аспекти на първата стъпка от метода видях:

• семантично компетентна трансформация на ролята на ръководител на проекта в собственик на продукт, от гледна точка на НЛП, прецизно програмиране на лидера за резултата от проектната задача;
• класиране на списъка със задачи (backlog) на проекта според стойностите (за клиента) и рисковете;
• гъвкавост при приемане на промени в стойността на продукта за клиента на проекта;
• точкуване на задачи и възможност за подмяна на задачи по проекта по време на преразпределение на приоритетите и спиране на спринта.

Стъпка 2 от алгоритъма на методологията Scrum

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

Стъпка 3 от алгоритъма на методологията Scrum

Първите осем метафори за следващата стъпка на Scrum могат да се разглеждат като правила за правене на бизнес или друг вид дейност, включително дейности по проекти. Не можете да не се чудите: защо не е възможно да видите това в реалностите на проектната практика? Считам, че за да се отговори на този въпрос, трябва да се изяснят още няколко точки.

1. Ако „лидерът не е шефът“ и Scrum Master е „треньор на играчи“, тогава кой управлява Scrum екипа? Самоуправлението, според мен, не се вписва в концепцията за управление на проекти.
2. Възниква въпросът за мотивацията на собственика на продукта на проекта, Scrum master и Scrum екипа. Методологията описва принципа на откритост на информацията, включително достъп до финансовите данни на проекта. Не е лоша идея, но като се има предвид макиавелистката нагласа, присъстваща в мнозина руски компанииподобна възможност вероятно ще има много противници сред мениджърите.

Въпросът за образуването на артефакти

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

Основното е, че този списък от изисквания на Scrum не се счита за нещо намерено веднъж и непоклатимо. Натрупаният продукт се преоткрива динамично всеки път, когато спринтът приключи. А това е много ценно според мен. Мога да кажа от собствената си практика, че такъв механизъм липсва в класическия модел на управление на проекти.

Стъпка 4 от алгоритъма на методологията Scrum

Петата стъпка от алгоритъма Scrum е не по-малко интересна. Всъщност не искам да се гмуркам в мистичните аспекти на числата. Но вие и аз имаме обикновена прагматична задача: по най-добрия начиннаправете прогноза за продължителността на работата на проекта, като използвате най-обективната експертна оценка. За съжаление, „отгатването по чаени листа“, за да настроите часовника в MS Project, не е нищо по-мрачно и изтощително, дори и с участието на опитни експерти. Мога да кажа с увереност, че никога не съм виждал по-добър метод от „планиране на покер“ в проектната практика. Методът е широко известен, така че няма да се спираме на него. Само ще отбележа, че комбинацията от метода Делфи и редицата на Фибоначи дава невероятни резултати.

Пример за пасианс на метода „Планиране на покер“.

Има няколко причини да разглеждаме метода Scrum не като настройка на съвременната PM доктрина, а като наистина революционен метод за управление на проекти. Едно от тях е отношението към описване на работата по изпълнение на проектна задача от гледна точка на истории, което е обратното на процесния подход на Д. Чампи и М. Хамър. Хората наистина мислят в картини. От една страна, трудно е да се съгласим, че човек не може да се страхува от загуба на недвусмисленото тълкуване на резултата от работата. От друга страна, ако направите крачка далеч от натиска на задачата и погледнете проблема от гледна точка на един наистина ориентиран към клиента проект, „меките“ истории могат да направят повече, за да получите желаните резултати от задачата.

Стъпка 5 от алгоритъма на методологията Scrum

Като се имат предвид стъпки 5 и 6, механизмите за изчисляване на динамиката на изпълнението, изоставането в спринта, датите на завършване на проекта и възможностите за ускорение са извън съмнение. Всичко е съвсем очевидно. Трудностите в разбирането възникват по отношение на един въпрос: как да постигнем видимо увеличение на функционалността на продукта в края на всеки спринт? По отношение на проекти за разработка на софтуер това е напълно възможно. Но какво да кажем, например, при изпълнението на проект за внедряване на система за бюджетиране чрез метода Scrum, където има много етапи на подготвителна работа, при които няма видимо увеличение на функционалността? Изглежда, че тази част от метода изисква допълнително потапяне.

Стъпка 6 от алгоритъма на методологията Scrum

Въпроси на активни действия по време на процеса

Третият процедурен блок на метода Scrum е изпълнението на дейностите. Под дейности имаме предвид действията на собственика на продукта, Scrum master и целия Scrum екип за постигане на локални резултати за текущия спринт или проекта като цяло. Седмата стъпка от процеса на проектиране е противоречива. От една страна, говорим за напълно работещи инструменти за колективна работа, които осигуряват високо нивопубличност, комуникационна пълнота, видимост. Говорим за използване на Scrum дъска, стикери, диаграми за изгаряне на задачи. От друга страна, не само за мен, но и за много руски мениджъри е доста трудно да възприемат категорията щастие като елемент от управленската технология. Ще посветя цял раздел от статията на този въпрос.

Стъпка 7 от алгоритъма на методологията Scrum

Смятам, че едно от ясните открития на метода Scrum е техниката на ежедневните срещи в движение. Много сбито и ефективно средство за защитавзаимодействие и мотивация на екипа на проекта в рамките на спринта. Големият спортист на 20 век Мохамед Али отдава голямо значение на редовния ритуал за успех във всяко начинание. Ежедневната Scrum среща е предназначена да бъде онзи мощен, редовен ритуал, който подхранва консолидирането на екипа за кратък изблик. Подкрепа за коучинг, единно териториално пространство, липса на разделение по „чинове и титли“ - всичко това работи, за да гарантира, че екипът на Scrum действа за ускоряване на изпълнението на проекта.

Стъпка 8 от алгоритъма на методологията Scrum

На стъпка 9 от алгоритъма на метода Scrum се появява това, което ви притеснява и отново се връща към формулирането на задачите за спринта. Дълги годиниТрябваше да култивирам убеждението, че контекстът на задачите на управлението на проекти предполага недвусмислено формулиране на резултата в разбирането на „постигнато – непостигнато“. В този случай няма значение кой резултат се разглежда: задача от най-високо ниво или декомпозирана. Във всеки случай, авторът на проектното задание и отговорният ресурс трябва да бъдат лишени от възможността да манипулират неяснотата на формулировката.

Стъпка 9 от алгоритъма на методологията Scrum

Цикълът на спринта завършва с десета стъпка, която включва партньорска проверка на завършения спринт. Режимът на коучинг на взаимодействие с екипа на Scrum се активира отново, докато се оценява напредъкът на работата по задачите и се търсят подобрения. Руският манталитет винаги се характеризира с ценностни преценки с негативна конотация за неуспешни резултати и провали. В този случай винаги трябва да се определи „стрелочник” – член на екипа на проекта, по чиято вина са настъпили загубите. Още по-ценни са принципите на приоритета на системната грешка над действията на участниците в процеса на Scrum като субекти на проектна дейност и отказа от персонифициране на вината.

Стъпка 10 от алгоритъма на методологията Scrum

Scrum като код на антицинизма

Харесва ми метафората, представена в подзаглавието. Той е от Джеф Съдърланд и предава дълбоко чувство за цинизъм като значителен недостатък на съвременния бизнес. Като цяло позицията на автора на метода Scrum със сигурност е искрена. Това е завладяващо. И по принцип не е лошо, че Съдърланд въвежда компонента на щастието в управленския контекст. Това се прави по един такъв американски начин. В същото време бих искал да разбера защо думата „щастие“ и всичко свързано с нея в разглежданата доктрина на революционния проект предизвиква вътрешен дискомфорт. Дали това е само субективно и лично възприятие или е някакъв общ културен възглед за предложения подход?

Вие и аз най-вероятно си спомняме какво се случи в Русия в края на 90-те - началото на 2000-те години. „Новоизпечените новобогаташи“ буквално се изсипаха в страната от цял ​​свят и главно от Съединените щати, разпространявайки „истината“ за личния и корпоративния успех. Трябва да се каже честно, че подобни „разкрития“ не минаха без следа, много бизнесмени възприеха ключови аспекти на теориите за управление, донесени от Запада. Конкретно не споменавам курсове за обучение, патентовани теории и известни школи. Тези, които са се сблъсквали с тях, ще разберат.

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

Има бързо отрезвяване и на държавно ниво, и на ниво бизнесмени. И те започват да разбират, че някои от въведените решения, начини за правене на бизнес, изграждане на взаимоотношения с персонала не са просто полезни, те служат на враждебни и разрушителни цели, водещи до разпадане на нашата национална култура, включително културата на управление на бизнеса. Ще дам един единствен пример за противопоставянето на две идеологии: „Разделяй и владей!“ и „Думата на търговеца е по-ценна от договора!“

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

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

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

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

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

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

Планиране

В началото на спринта екипът на Scrum провежда планиране на спринта за:

• Комуникация за определяне на обхвата на работата, която се очаква да бъде извършена по време на този спринт;
• Избиране на продукти Backlog елементи, които могат да бъдат завършени в един спринт;
• Подготовка на спринта, идентифициране на работата, необходима за завършване на някои елементи от Product Backlog;
• Определяне на времеви кутии - четиричасови ограничения за двуседмични спринтове (пропорционална продължителност за други спринтове);
  • През първото полувреме целият екип на Scrum (това е екипът за разработка, Scrum Master и собственикът на продукта) избира работни задачи от Backlog, които могат да бъдат постигнати в този спринт;
  • През втората половина екипът за разработка декомпозира работата (задачите), необходима за доставяне на тези елементи от Backlog на продукта, което води до валидиране на спринта;
    • Някои елементи от Backlog на продукта може да бъдат разделени или префокусирани, ако идентифицираната работа не е постижима в този спринт.

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

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

• Ежедневен Scrum. Всички членове на екипа за разработка трябва да се подготвят. Ежедневен Scrum…
  …започва навреме, дори ако някои членове на екипа липсват;
  ...трябва да започва всеки ден на едно и също място и по едно и също време;
  ... ограничен до петнадесет минути.
• Външни лица могат да присъстват, въпреки че обикновено само екипът на Scrum обменя мнения текущо състояние;
• Специална характеристика на ежедневната Scrum среща е, че всеки член на групата отговаря на 3 кратки и прости въпроса:
  • Моите изпълнени задачи от вчера? Как помогнах на екипа за разработка да постигне целта за спринта?
  • Какви задачи си поставям днес, за да постигнем заедно целта за спринта?
  • Виждам ли някакви ограничения, които пречат на мен или на екипа за разработка да постигнем целта на спринта?

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

Рецензии и ретроспективи

Отборът провежда две събития в края на спринта: преглед и ретроспекция на спринта.

Действия на отбора по време на прегледа на спринта:

• Преглед на свършената работа и планиране на несвършената работа;
• Представено готови работиза заинтересовани страни (например демо)

Насоки за преглед на спринта:

• Недовършената работа не може да бъде демонстрирана;
• Препоръчителна продължителност: два часа за двуседмичен спринт (пропорционално за други дължини на спринта)

В ретроспекцията на спринта отборът:

• Отразява последния спринт;
• Определя и съгласува процес за непрекъснато подобряване на дейностите.

Насоки за ретроспективи на спринта:

• В ретроспекцията на спринта има само два основни въпроса: какво се получи добре по време на спринта? Какво може да се подобри в следващия спринт?
• Препоръчителна продължителност – 1-1,5 часа за двуседмичен спринт (пропорционално за други продължителности на спринта)
• Това събитие е присвоено на Scrum Master

Допълнително

Следните дейности обикновено се извършват на практика, въпреки че не се считат от всички за основна част от методологията на Scrum:

Усъвършенстване на изоставането

Усъвършенстването на Backlog (някои наричат ​​Backlog Grooming) е постоянен процес на преглед на Backlog елементи и гарантиране, че Backlog е правилно приоритизиран и структуриран по начин, който показва, че задачите са достатъчно ясни и изпълними за екипа.

Неизпълнени елементи:

• може да се раздели на няколко по-малки;
• критериите за приемане могат да бъдат изяснени;
• зависимости, последователи и подготвителна работаможе да се определи и съгласува с техническо одобрение.

Въпреки че не е основна Scrum практика, усъвършенстването на Backlog е прието като начин за управление на качеството на Backlog елементите, с препоръчително количество до 10% от времето за Sprint.

Скръм на схватките

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

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

Работата е структурирана подобно на Daily Scrum срещата и всеки представител подготвя своите отговори на следните четири въпроса:

• Какви рискове, ограничения, зависимости и предположения направи вашият Scrum екип от последната ни среща?
• Какви рискове, ограничения, зависимости и предположения ще направи вашият екип, преди да се срещнем отново?
• Има ли нови рискове, препятствия, зависимости и предположения, които забавят вашия екип или ви пречат?
• Ще въведете ли нов риск, пречка, зависимост и предположение, което ще попречи на другия отбор?

Както Джеф Съдърланд коментира,

Тъй като първоначално дефинирах Scrum като Scrums (Кен Швабер беше в IDX с мен по това време), мога да кажа със сигурност, че Scrum of Scrums не е „Meta Scrum“. Scrum of Scrums, както го използвах, отговаря за доставянето на работещи версии на софтуер от всички екипи в края на спринта или за издания по време на спринта. Scrum Master е отговорен за това. Така че Scrum of Scrums е механизъм за по-бързо доставяне на софтуер.

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

Научете основните, но важни термини, използвани в процеса на Agile Scrum, заедно с пример от реалния живот на целия процес.

SCRUM е гъвкав процес, който е комбинация от итеративни и инкрементални модели.

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

Някои от основните характеристики на SCRUM са:

• Организиран и целеустремен екип
• Няма изисквания към документите, достатъчно е да имате точни текстове по същество.
• Функционалният екип работи като едно цяло.
• Тясна връзка с потребителя, помагаща за разбиране на функциите.
• Има точна времева ос от максимум 1 месец.
• Вместо да прави всичко наведнъж, Scrum прави по малко от всичко за определен период от време.
• Преди да предприемете каквото и да е действие, се вземат предвид характеристиките и наличието на ресурси.

За да разберете добре тази методология, е важно да разберете ключовите термини на SCRUM.

Важни условия на SCRUM:

1. Scrum екип

Scrum екипът е екип от 7 +/- 2 члена. Членовете на екипа са комбинация от компетентни разработчици, тестери, хора с бази данни, поддържащи оператори и т.н., както и собственик на продукта и scrum master. Всички тези хора работят в тясно сътрудничество през даден рекурсивен период, за да разработят и изпълнят определените функции.

2. Спринт

Спринтът е стандартен период от време, в който работата трябва да бъде завършена и готова за преглед или пускане на продукт. Обикновено този период отнема от две седмици до месец. Когато казваме, че правим 1 спринт на месец, това означава, че работим един месец по задачи и ги подготвяме за преглед до края на същия месец.

3. Собственик на продукта

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

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

4. Scrum майстор

Scrum Master е координаторът на Scrum екипа. Той/тя гарантира, че скръм екипът е продуктивен и прогресивен. В случай на някаква намеса, Scrum Master намира и разрешава проблема за екипа.

5. Потребителска история

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

как<тип пользователя>

аз искам<доступная цель>

за постижение<результат/причина>

Например:

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

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

Всяка потребителска история има критерий за приемане, който трябва да бъде ясно дефиниран и разбран от екипа. Критериите за приемане описват подробно историите на потребителите и предоставят подкрепени документи. Това позволява историите на потребителите да бъдат детайлизирани. Всеки член на екипа може да напише критерии за приемане. Екипът за проверка базира своите тестови случаи/условия на тези критерии.

6. „Епос“

Епосите са неясни потребителски истории. Или можем да кажем, че това са потребителски истории, които не са дефинирани и се съхраняват за бъдещи спринтове. Просто се опитайте да свържете това с живота, представете си, че отивате на почивка. Тъй като заминавате следващата седмица, имате всичко планирано: хотелски резервации, разглеждане на забележителности, опаковане чанта за пътуванеи т.н. Но какво да кажем за почивката ви следващата година? Имате само бегла представа, че можете да отидете на място XYZ, но нямате подробен план.

„Epic“ е като вашата ваканция догодина: знаете, че можете да отидете, но къде, кога и с кого – все още няма мисли по този въпрос.

По същия начин има функции, които трябва да бъдат внедрени в бъдеще, но техните подробности все още не са известни. Обикновено една възможност започва с „епичен“ и след това се разбива на истории, които могат да бъдат реализирани.

7. Дневник на желания продукт

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

8. Спринт списък с желания

Една потребителска история се взема наведнъж от дневника на желания продукт. Екипът на Scrum обмисля, определя осъществимостта и решава върху коя история да работи по време на даден спринт. Общият списък на всички потребителски истории, върху които Scrum екип работи по време на даден спринт, се нарича спринтово изоставане.

9. Точки за историята на потребителя:

Тези точки са числено представяне на сложността на потребителската история. На базата на тези резултати се определя резултатът и натоварването на една история. Точките не са абсолютни, те са относителни. За да сме сигурни, че нашите усилия и оценки са правилни, трябва да проверим дали потребителските истории са големи. Колкото по-малка и по-ясна е потребителската история, толкова по-точна ще бъде оценката.

На всяка потребителска история се присвоява оценка на Фибоначи (1, 2, 3, 5, 8, 13, 21). Колкото по-високо е числото, толкова по-сложна е историята.

За да бъдем по-точни, тогава

• Ако заложите 1/2/3 точки, това означава, че историята е кратка и има ниска трудност.
• Ако дадете 5/8 точки, това е средна трудност и
• 13 и 21 точки – историята е много сложна.

Трудността тук е в разработката и обема на тестовата работа

За да реши колко точки да даде, екипът на Scrum започва мозъчна атака и колективно решава. Може да се случи, че екипът за разработка ще даде 3 точки на конкретна история, защото за тях това може да са 3 реда код за замяна, но екипът за тестване ще даде 8 точки, защото смятат, че тази замяна на кода ще има повече въздействие върху модулите, така че количеството работа ще бъде повече по време на тестването. Но независимо колко точки давате, трябва да обосновете решението си. Така се провежда мозъчна атака и екипът решава колко точки да постави.

Всеки път, когато решавате колко точки да заложите, вземете предвид следните фактори:

• Връзка на историята с други приложения/модули,
• Набор от умения за ресурси
• Сложността на историята
• Наративно обучение,
• Критерии за приемане на потребителска история

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

10. Диаграма за изгаряне на задачи

Диаграмата за изгаряне на задачи представя графика, която показва прогнозните v/s на действителните усилия на задачите за схватка.

Това е механизъм за проследяване на конкретен спринт. Всеки ден задачите се проследяват, за да се провери дали историите напредват към завършване или не.

Пример: За да разберете това, погледнете снимката:

Аз избирам:

• Двуседмичен спринт (10 дни)
• 2 ресурса за действителната работа на спринта.

"История" ->колоната показва потребителските истории, взети за спринта. "Задача" ->колоната показва списък със задачи, свързани с потребителски истории.

“Обхват на работа” ->колоната показва количеството работа. Тази мярка сега е общото количество работа за изпълнение на задачата. Той не изобразява количеството работа на конкретен човек.

„Ден 1 – Ден 10“->– колона(и) показва оставащото време до края на историята. Моля, обърнете внимание, че това НЕ е време, което вече е минало, А време, което все още остава.

„Очаквано количество работа“ ->показател за общото количество работа. За „Старт“ това е просто сборът от цялата задача: SUM (C5:C15)

Общото количество работа, което трябва да бъде изпълнено за 1 ден, е 70 / 10 = 7. Така в края на първия ден количеството работа трябва да бъде намалено до 70-7 = 63. По същия начин това се изчислява за всички дни до 10-то число, когато очакваното количество работа трябва да е нула (ред 16)

“Оставащо количество работа” ->Както подсказва името, това е количеството работа, което остава, преди историята да бъде завършена. Може също така да се случи действителното количество работа да стане повече или по-малко от очакваното.

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

Етапи на диаграмата за изгаряне на задачата:

1. Въведете всички истории (колона A5 – A15)
2. Въведете всички задачи (колона B5-B15)
3. Въведете дни (ден 1 – ден 10)
4. Въведете първоначалното количество работа (обобщете задачи C5-C15)
5. Приложете формулата, за да изчислите „прогнозното количество работа“ за всеки ден (от ден 1 до ден 10). Въведете формулата в D15 (c16-$C$ 16/10) и я плъзнете до всички дни.
6. За всеки ден въведете действителното количество работа. Въведете формула в D17 (SUM (D5:D15)), за да сумирате оставащото количество работа и я плъзнете към всички останали дни.
7. Изберете това и създайте диаграма като тази:

11. Отборна скорост

Общият брой точки, които един скръм екип съхранява в спринта, се нарича отборна скорост. Един Scrum екип се оценява по неговата скорост. Трябва да се каже, че трябва да се има предвид, че постигането на максимален брой точки НЕ е целта тук, но резултатите с добро качество повишават нивото на комфорт на scrum екипа.

Например: За определен спринт: общият брой потребителски истории е 8. Всяка от тях има определен брой точки

Така скоростта е сумата от точки = 30

12. Определение за „готов“:

Историята се ПРАВИ в Scrum само когато има развитие, пълно осигуряване на качеството и възможност да влезете в производство.

Дейности в SCRUM:

#1: Среща за планиране

Срещата за планиране е началната точка на SCRUM. Това е среща, на която се събира целият Scrum екип. Собственикът на продукта избира потребителски истории от натрупания продукт въз основа на приоритет и екипът започва мозъчна атака. По време на дискусията екипът на Scrum определя сложността на историята и я измерва според серията на Фибоначи. Екипът определя задачите, както и количеството работа (в часове), която може да бъде извършена, за да завърши внедряването на потребителската история.

„Предварително планиране на среща“ предхожда срещата. Как е това Домашна работа, което екипът на Scrum прави преди да се срещне на официална среща за планиране. Екипът се опитва да запише зависимости или други фактори, които биха искали да обсъдят на срещата.

#2: Изпълнение на целите на спринта

Както подсказва името, работата на екипа на Scrum е да изпълни задачата си и да премести потребителската история в статус „готово“.

#3: Ежедневна Scrum среща (повикване)

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

1. Какво е направил членът на екипа след последната среща?
2. Какво планира да прави членът на екипа днес?
3. Има ли пречки пред отбора?

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

#4: Преглед на резултатите

В края на всеки спринтов цикъл екипът на SCRUM се среща отново и демонстрира внедряването на потребителски истории на собственика на продукта. Собственикът на продукта може да съпостави историите според техните критерии за приемане. Отново отговорност на Scrum Master е да председателства тази среща.

#5: Ретроспективна среща

Ретроспективна среща се провежда след преглед на резултатите. Екипът на SCRUM събира, обсъжда и документира следните точки:

1. Какво се получи добре в предишния спринт (най-добра практика)
2. Какво не беше направено много добре
3. Поуки
4. Елементи на действие.

Екипът на Scrum трябва да продължи да следва най-добрите методиработа, игнорирайте „не най-добри практики” и прилагайте научените уроци в следващите спринтове. Ретроспективната среща помага за непрекъснатото подобряване на процеса на SCRUM.

Как се извършва процесът? пример!

След като прочетох за техническия жаргон на SCRUM, нека се опитам да демонстрирам целия процес с пример.

Етап 1: Нека си представим SCRUM екип от 9 души, състоящ се от 1 собственик, 1 Scrum master, 2 тестера, 4 разработчици и 1 администратор на база данни.

Стъпка 2: Спринт цикъл, например, ще продължи 4 седмици. И така, имаме 1-месечен спринт: от 5 юни до 4 юли.

Стъпка #3: Собственикът на продукта има приоритетен списък с потребителски истории в Backlog на продукта.

• Собственикът на продукта взема 1 история от списъка с желания продукт, описва я и я предава на екипа за мозъчна атака.
• Целият екип обсъжда и отива директно при собственика на продукта, за да обясни подробно потребителската история.
• Други потребителски истории се приемат по същия начин. Ако е възможно, екипът може да продължи и също да измери историите.

След дискусията членовете на екипа се връщат на работните си места и

• Те определят своите индивидуални задачи за всяка история.
• Изчисли точна сумавремето, което ще им е необходимо за работа. Как участникът изчислява това време? Да проверим:

Общо работни часове = 9

Минус 1 час за почивка, минус 1 час за срещи, минус 1 час за имейли, дискусии, отстраняване на проблеми и т.н.
Така че действителните работни часове = 6

Общ брой работни дни по време на спринта = 21 дни.
Общо налични часове = 21 * 6 = 126

Членът е във ваканция 2 дни = 12 часа (това варира за всеки член, някои могат да вземат ваканция, други не.)
Брой реални часове = 126-12 = 114 часа.

Това означава, че участникът обикновено ще бъде на разположение 114 часа по време на този спринт. Затова той ще раздели индивидуалната си спринтова задача по такъв начин, че да бъде постигната за 114 часа.

• Окончателното мнение за потребителската история от продуктовата натрупана история е завършена и историята се премества в спринтовата натрупана история.
• За всяка история всеки член на екипа обявява своята специфични задачи. Ако искате да обсъдите тези проблеми, можете да ги измерите или преоразмерите (помислете за сериите на Фибоначи!).
• Scrum Master или екипът въвежда своите индивидуални задачи и тяхното време за всяка история в програмата.
• След като всички истории са завършени, Scrum Master маркира началната скорост и спринтът официално започва.

Стъпка #6: След като спринтът започне, всеки член на екипа започва да работи по възложените му задачи.

Стъпка #7: Екипът се събира ежедневно за 15 минути и обсъжда 3 въпроса:

• Какво направиха вчера?
• Какво смятат да правят днес?
• Има ли някаква намеса?

Стъпка #8: Scrum Master проследява напредъка ежедневно с помощта на Burndown Chart

Стъпка #9: В случай на някаква намеса, Scrum Master го решава.

Стъпка #10: На 4 юли екипът се събира отново, за да прегледа резултатите. Всеки член на екипа демонстрира внедрената потребителска история на собственика на продукта.

Стъпка #11: На 5 юли екипът се събира отново за ретроспективна среща, на която обсъждат

• Какво мина добре?
• Какво не мина добре
• Елементи на действие.

Стъпка #12: На 6 юли екипът се събира отново за следващата среща за предварително планиране на спринта и цикълът продължава.

(Щракнете, за да увеличите изображението)

Програми, които могат да се използват за SCRUM дейности:

Има много инструменти, които могат да се използват широко за проследяване на Scrum дейности. Ето някои от тях:

• XPlanner
• Първа версия
• Спринтометър
• ScrumNinja

Заключение:

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

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