Скрам. Основи методології.

  Скрам це процесний підхід, що використовується для комплексного управління процесом.Скрам складається зі:
-  Скрам Команд (Scrum Teams), в яких розподілено відповідні ролі (roles)
- церемоній (events);
- артефактів (artifacts);
- правил (rules).
Скрам ґрунтується на теорії управління емпіричними процесами. В основі управління емпіричними процесами лежать три основні принципи:
- прозорість (transparency): важливі аспекти процесу повинні бути видимі для відповідальних за результат;
- перевірка (inspection): перевірка артефактів, та контрольпрогресу для своєчасного виявлення небажаних відхилень;
- адаптація (adaptation): при відхиленні від допустимих норм - необхідно вносити поправки або у процес, або у робочі матеріали.

Скрам прописує 4 формальні можливості для перевірки та адаптації:- Планування Спринту (Sprint Planning Meeting);- Щоденний Скрам (Daily Scrum);- Огляд Спринту (Sprint Review Meeting);- Ретроспектива Спринту (Sprint Retrospective);

Власник Продукту (Product owner) є відповідальним за досягнення максимальної цінності продукту та роботи, що виконується Командою Розробників. Він - єдина людиною в Команді, що відповідає за Журнал Вимог до Продукту (Product Backlog).
Управління Журналом Продукту включає в себе наступні дії:
- Чітке визначення елементів Журналу Продукту;
- Впорядкування елементів Журналу Продукту для максимального досягнення цілей та поставлених завдань;
- Відповідальність за цінність роботи, що виконується Командою Розробників;
- Забезпечення доступності, прозорості та зрозумілості Журналу Продукту, а також відображення тих елементів, над якими Скрам Команді доведеться працювати найближчим часом.
- Відповідальність за розуміння Командою Розробників вимог Журналу Продукту на належному рівні.
Власник Продукту може виконувати перераховані вище функції сам, або ж довірити їхвиконання членам Команди Розробників. Однак підзвітним вважається саме Власник Продукту.

Команда Розробників (Team members) складається з професіоналів, що виконують роботу із розробки потенційно готового до випуску Інкременту “завершеного” продукту у кінці кожногоСпринту. Інкремент створюють тільки члени Команди Розробників.
Характеристики Команд Розробників:
- Вони самоорганізовані. Ніхто, навіть Скрам Мастер, не може вказувати Команді як правильно перетворювати Журнал Продукту на Інкремент робочої функціональності;
- Команди Розробників є кросфункціональними, тобто володіють усіма навичками, необхідними для розробки Інкремента продукту;
- Скрам не визнає ніяких інших посад у Команді Розробників, окрім Розробника, незалежно від виду роботи, що виконується; у цього правила немає винятків;
- Окремі члени Команди Розробників можуть володіти спеціалізованими знаннями у різних областях, однак відповідальність лежить на усій Команді Розробників, оскільки вона є одним цілим;
- У Команди Розробників немає структурних підрозділів, які б виконували окремі функції, як, до прикладу, підрозділ тестування або ж бізнес-аналізу.
Розмір Команди Розробників: 3 < size < 9
Ролі Власника Продукту і Скрам Мастера не
враховуються при підрахунку кількості членів Команди Розробників, окрім випадків, коли вони виконують роботу із Журналу Спринту.

Скрам Мастер несе відповідальність за те, щоб Скрам був гарантовано зрозумілим всім учасникам та працював. Скрам Мастер стежить за тим, щоб всі учасники Команди дотримувалися теоретичних засад, практик та правил Скраму. Скрам Мастер є слугою-лідером для Скрам Команди. Скрам Мастер також допомагає особам, що не входять до складу Скрам Команди зрозуміти, які з їх взаємодій зі Скрам Командою є корисними, а які ні. Скрам Мастер допомагає внести зміни в такі взаємодії для збільшення цінності продукту, що
розробляється Скрам Командою.
Обов'язки Скрам Мастера щодо Власника Продукту:
Скрам Мастер багато в чому допомагає Власнику Продукту, і зокрема у наступному:
-  Виявляє методи ефективного управління Журналом Продукту;
-  Інформує членів Команди Розробників про бачення, цілі та елементи Журналу Продукту;
-  Вчить Команду Розробників створювати лаконічні та зрозумілі елементи Журналу Продукту;
-  Здійснює довгострокове планування по продукту в емпіричному середовищі;
-  Розуміє та практикує гнучкі методи розробки та управління;
-  На вимогу чи за необхідності виступає ведучим Церемоній Скраму.
Обов'язки Скрам Мастера щодо Команди Розробників: 
- Вчить Команду Розробників самоорганізації та кросфункціональності;
- Вчить та веде за собою Команду Розробників при створенні продуктів із високою цінністю;
-  Усуває перешкоди, що виникають у процесі роботи Команди Розробників;
- За необхідності проводить Церемонії Скраму;
-  Проводить необхідні тренінги для Скрам Команди в тих організаційних областях, в яких Скрам є ще не до кінця впровадженим та зрозумілим.
Обов'язки Скрам Мастера щодо Організації: 
- Спрямовує та тренує організацію при впровадженні Скраму;
-  Планує етапи впровадження Скраму в межах організації;
-  Допомагає співробітникам компанії та зацікавленим особам зрозуміти та впровадитиСкрам та принципи емпіричної розробки продукту;
-  Виступає ініціатором змін, що посилюють продуктивність Скрам Команди;
 - Співпрацює з іншими Скрам Мастерами для оптимізації використання Скраму в межахорганізації

 Церемонії Скраму використовуються у Скрамі для надання процесу розробки регулярності та зведення до мінімуму потреб у нарадах, не приписаних Скрамом. Скрам використовує обмежені в часі церемонії, тому кожна церемонія має свою верхню межу тривалості. Це гарантує те, що планування проводитиметься у спеціально відведений час, для уникнення втрат часу в процесі планування.

Спринт - серце Скраму, з часовими рамками (time boxes) в місяць або менше, в результаті якого створюється “завершений”, цінний та потенційно готовий до випуску
Інкремент продукту. Тривалість Спринту є постійною протягом усього періоду розробки.
Наступний Спринт починається відразу ж по закінченню попереднього.
Спринт складається із Планування Спринту, Щоденних Скрамів, роботи із розробки, Огляду Спринту, а також Ретроспективи Спринту.

Під час Спринту: 
- Не допускається внесення жодних змін, які би вплинули на Мету Спринту (Sprint Goal);
-  Склад Команди Розробників та цілі щодо якості продукту залишаються незмінними;
-  Рамки, в межах яких ведеться розробка у Спринті, можуть бути уточнені та повторно обговорені між Власником Продукту та Командою Розробників по мірі більшого розуміння;
Кожен Спринт може вважатися проектом із часовими рамками в межах одного місяця. Як і інші проекти, Спринт використовується для досягнення певних цілей. Кожен Спринт складається із визначення того, що потрібно розробити, дизайну та гнучкого плану, які є орієнтирами при розробці, роботи та власне продукту, що стане результатом цієї роботи.
Тривалість Спринту обмежена в рамках одного місяця. Якщо часові рамки Спринту є занадто довгими, то може або змінитися саме визначення цілей, або зрости складність завдання, або збільшитися ризик. Спринти вносять прогнозованість у процес розробки, забезпечуючи проведення перевірки та адаптації на шляху до мети, як мінімум, раз на місяць.
Скасування Спринту можливе перед закінченням його часових рамок. Тільки у Власника Продукту є право на те, щоб скасувати Спринт, хоча він може це зробити і під впливом зацікавлених осіб, Команди Розробників або ж Скрам Мастера. Спринт скасовують в тому випадку, якщо його цілі перестають бути актуальними. Це може відбутися внаслідок зміни напрямку роботи компанії, зміни технологій або ж ринкових умов. Загалом, Спринт потрібно скасувати, якщо в силу певних обставин в ньому вже немає необхідності. При скасуванні Спринту всі виконані та “завершені” елементи Журналу Продукту переглядаються. Їх приймають за умови, що вони є потенційно готовими до випуску Інкременту функціональності. Всі незавершені вимоги переоцінюються і повертаються до Журналу Продукту. Виконана над вимогами робота швидко знецінюється, а тому часто потребує перегляду. Скасування Спринту вимагає додаткових ресурсів, тому що всім членам Команди при Плануванні Спринту потрібно перегрупуватися та приступити до нового Спринту.
Скасування Спринту є для Команди доволі неприємним процесом, проте на ділі відміна відбувається досить рідко.
Планування Спринту 
Робота, що її виконують під час Спринту, планується під час наради із Планування Спринту. План дій розробляється при спільній роботі цілої Скрам Команди.
Для Спринту тривалістю в місяць часові рамки зустрічі становлять вісім годин. Для більш коротких Спринтів на планування виділяють менше часу, пропорційно загальній довжині Спринту. Приміром, для двотижневого Спринту планування займе не більше чотирьох годин.
Нарада із Планування Спринту складається із двох частин:
-  Що буде розроблено в Інкременті, що стане результатом роботи наступного Спринту?
-  Як найкраще виконати роботу по створенню Інкременту функціональності?

Частина перша: Що планується зробити в цьому Спринті? 

Мета: планування функціональності, що буде розроблена під час Спринту. 

Власник Продукту надає Команді Розробників впорядковані в 

Журналі Продукту вимоги, і вся Скрам Команда намагається досягти єдиного розуміння 

щодо роботи, яку потрібно виконати протягом Спринту. 

Вхідними для цієї зустрічі є Журнал Продукту, останній розроблений Інкремент продукту, 

можливості Команди Розробників та останній показник її продуктивності. Кількість елементів із Журналу Продукту (реальний обсяг роботи), які Команда здатна виконати до закінчення Спринту, визначається самою Командою.

Після того, як Команда Розробників спрогнозує елементи Журналу Продукту, які вона виконає в поточному Спринті, Скрам Команда приступає до формування Цілі Спринту. 

Ціль Спринту – це мета, якої буде досягнуто в результаті Спринту завдяки реалізації Журналу Продукту, і яка вказує Команді Розробників чому вона працює саме над цим Інкрементом функціональності.

Частина друга: Як буде виконано обрану роботу? 

Мета: визначити, яким чином протягом Спринту втілити окрему функціональність у “завершений” Інкремент продукту. Елементи Журналу Продукту, обрані для виконання під час найближчого Спринту, разом із 

планом їх розробки називають Журналом Завдань Спринту (Sprint Backlog). Як правило, Команда Розробників починає планувати систему і роботу, завдяки якій Журнал Продукту можна перетворити на працюючий Інкремент продукту. Робота може відрізнятись за трудомісткістю та складністю. Проте зазвичай під час Планування Спринту 

Команда Розробників планує такий обсяг роботи, який вона в змозі виконати за Спринт. До закінчення цієї зустрічі робота, запланована Командою Розробників на перші дні Спринту, 

розбивається на вимоги, які можна виконати за день або ж менше. Команда Розробників сама організовує свою роботу, плануючи поетапність виконання вимог із Журналу Спринту як під час наради із Плануванню Спринту, так і, за необхідності, протягом усього Спринту. 

Власник Продукту може бути присутнім на другій частині Планування Спринту, щоби мати можливість пояснити завдання із Журналу Продукту і, за необхідності, допомогти знайти альтернативи. Якщо ж Команда Розробників вирішує, що у неї надто багато, чи надто мало роботи, вона може повторно обговорити з Власником Продукту вимоги з Журналу Спринту. Команда може запросити людей зі сторони, щоб вони порадили щось із технічної або ж експертної точки зору. До закінчення наради із Планування Спринту Команда Розробників повинна вміти пояснити Власнику Продукту і Скрам Мастеру яким чином вона працюватиме в якості самоорганізованої команди, з метою досягнення Цілей Спринту і створення очікуваного 

Інкременту продукту. 

Ціль Спринту:  реалізація певної функціональності та технології. Якщо ж робота виявляється складнішою, ніж очікувалося, тоді Команда Розробників домовляється з Власником Продукту про зміну обсягу Журналу Спринту для поточного Спринту. Ціль Спринту може бути важливим етапом на шляху до більш високої цілі в розробці 

кінцевого продукту. 

Щоденні Скрами - це 15-хвилинні наради для Команди Розробників з метою синхронізації дій та створення плану роботи на найближчі 24 години. Це робиться для того, щоб 

перевірити, що було зроблено з часу проведення попереднього Щоденного Скраму та запланувати роботу, яку можна виконати за наступні 24 години. 

Питання для кожного члена команди:

-  Що було зроблено з часу минулої зустрічі? 

-  Що планується зробити до наступної зустрічі? 

-  Що йому заважає у виконанні запланованих завдань? 

Члени Команди Розробників використовують Щоденні Скрами для оцінки прогресу просування до Цілі Спринту, а також оцінки прогресу у виконанні роботи із Журналу 

Спринту. Скрам Мастер несе відповідальність за те, щоб Команда Розробників не пропускала такі наради, однак відповідальність за проведення Щоденного Скраму лежить на Команді Розробників. Скрам Мастер вчить Команду розробників утримувати час проведення Щоденного Скраму в межах 15-хвилин. Скрам Мастер забезпечує дотримання того, щоби в Щоденних Скрамах брали участь лише члени Команди Розробників. Щоденний Скрам не є статусною нарадою, радше нарадою для членів Команди, що працює над перетворенням вимог із Журналу Продукту на Інкремент готового продукту. 

Огляд Спринту проводиться в кінці Спринту для перевірки Інкременту та, за необхідності, 

адаптації Журналу Продукту. Оглядається вже виконана роботі та подальші завдання. Це не офіційна зустріч, а швидше презентація Інкременту, спрямована на отримання відгуку та оптимізацію співробітництва.

Тривалість: для місячного Спринту ~4 год., для двотижневого ~2год., тощо.

Огляд Спринту включає в себе наступні елементи: 

- Власник Продукту визначає, що є “завершеним” елементом, а що ні; 

-  Команда Розробників згадує, що пройшло добре під час Спринту і з чим виникли труднощі, а також те, як вона з ними впоралася; 

-  Команда Розробників проводить демонстрацію того, що було зроблено, і відповідає на запитання щодо Інкременту; 

-  Власник Продукту обговорює стан Журналу Продукту. Він робить припущення щодо можливої дати закінчення проекту, беручи до уваги швидкість просування роботи над 

ним; 

-  Вся Команда приймається за обговорення того, що робити надалі для того, щоб поточний Огляд Спринту являв собою важливу вхідну інформацію для наступної наради із Планування Спринту. 

Результатом Огляду Спринту є переглянутий та виправлений Журнал Продукту, що визначає елементи Журналу Продукту, які є імовірними для внесення до наступного Спринту. Журнал Продукту також може бути переглянутим для того, щоб відповідати новим обставинам. 

Ретроспектива Спринту  відбувається після Огляду Спринту, перед подальшим Плануванням Спринту. Надає  Скрам Команді можливість перевірити себе та створити план покращень, які можна було б внести під час наступного Спринту. 

Тривалість: для місячного Спринту ~3 год., для двотижневого ~1,5год., тощо.

Мета: 

- Перевірка того, наскільки успішно пройшов Спринт, беручи до уваги злагодженість роботи Команди, процеси та використані інструменти; 

- Визначення та впорядкування тих елементів роботи, які були виконані успішно, і тих, які могли б бути виконані краще; 

-  Розробка плану із впровадження покращень у процес роботи Скрам Команди.
Під час кожної Ретроспективи Спринту Скрам Команда шукає шляхи для покращення якості продукту, що розробляється, за необхідності уточнюючи визначення “завершеності”. Перед завершення Ретроспективи Спринту Скрам Команда повинна визначити практичні та дієві чинники покращення процесу роботи, які вона реалізує у наступному Спринті. Впровадження цих змін у наступному Спринті якраз і є адаптацією до перевірки самої Скрам Команди. Хоча зміни можуть бути внесені в будь-який час, Ретроспектива Спринту є спеціалізованою нарадою, присвяченою виключно перевірці та адаптації. 

Артефакти Скраму представляють собою роботу чи цінність у тому, наскільки вони є корисними у забезпеченні прозорості та можливостей для інспекції та адаптації. Визначені Скрамом Артефакти є спеціально спроектовані таким чином, щоб забезпечити максимальну ясність ключової інформації, необхідної для того, щоб Скрам Команда досягла успіху в поставці “завершеного” Інкременту. 

Журнал Продукту – це впорядкований список усього, що повинно бути притаманно 

продукту. Відповідальність за Журнал Продукту несе Власник Продукту, включно з його вмістом, доступністю та впорядкуванням. Початкова версія містить із самого початку відомі та найбільш зрозумілі вимоги. Журнал Продукту постійно оновлюється по мірі оновлення самого продукту та середовища, в якому він розробляється. Він існує рівно стільки ж, скільки існує і сам продукт. Журнал Продукту містить всі властивості, функції, вимоги, вдосконалення та інформацію з удосконалення та виправлення дефектів, тобто ті дані, які визначають зміни, і які потрібно зробити у наступних випусках продукту. Елементам Журналу Продукту повинен присвоюватися короткий опис, порядковий номер та оцінка обсягів роботи. В Журналі Продукту вимоги часто впорядковані за цінністю, ризиком, пріоритетністю та необхідністю. Найбільш важливі вимоги обробляються в першу чергу. 

Елементи Журналу Продукту з вищим пріоритетом повинні бути більш зрозумілими та містити більше деталей, ніж менш пріоритетні. Ті вимоги Журналу Продукту, над якими Команда розробників працюватиме під час поточногоСпринту, є деталізованими і

розбитими на частини таким чином, що будь-яка із цих вимог може бути виконаною та“завершеною” в рамках одного Спринту. Вимоги Журналу Продукту, які можна виконати і “завершити” протягом одного Спринту, вважаються “готовими” та “виконуваними” для того, щоб їх внесли в план під час наступного Планування Спринту. 

Досить часто трапляється так, що над одним продуктом працюють кілька Команд. Проте все одно використовується лише один Журнал Продукту, щоб визначити роботу на найближчий період. При цьому до елементів Журналу Продукту вводиться додатковий атрибут, що дозволяє згрупувати запити по Скрам Командам. Підтримка Журналу Продукту – це діяльність по додаванню деталей, оцінок очікуваних затрат часу та впорядкування елементів. Це безперервний процес, під час якого Власник Продукту та Команда Розробників деталізують вимоги Журналу Продукту. Під час обробки елементи перевіряють та переглядають. Однак Власник Продукту в будь-який час може 

змінити статус цих вимог. Підтримка Журналу Продукту є частиною діяльності під час Спринту, що виконується Власником Продукту і Командою Розробників. Часто Команди Розробників володіють знаннями в потрібній галузі і самі можуть здійснити обробку вимог із Журналу. Як і коли провести обробку вимог вирішує лише Скрам Команда. Зазвичай обробка вимог займає не більше 10% часу Скрам Команди. 

Команда Розробників несе всю відповідальність за оцінку обсягів роботи. Власник Продукту може допомогти Команді осмислити вимоги та вибрати альтернативи, проте кінцева оцінка залежить лише від Команди. 

Власник Продукту відстежує кількість роботи, що залишилася до виконання, як мінімум, для кожного Огляду Спринту. Власник Продукту порівнює поточну кількість роботи із тим, що залишилося під час попереднього Огляду Спринту для того, щоб оцінити прогрес в роботі і те, чи встигає Команда досягти Цілі в рамках запланованого часу. Ця інформація є доступною та відкритою для всіх зацікавлених осіб.
Скрам не бере до уваги час, витрачений на роботу над вимогами з Журналу Продукту. Єдиними цінними показниками є кількість роботи, що залишилася до виконання, та кінцевий термін завершенняроботи. Різноманітні графіки типу “скільки залишилось” (burndown) та “скільки зроблено” (burnup) відображають реальне просування, відхилення, та очікуваний рух, а також інші наочніпрактики, що застосовуються для прогнозування прогресу.

Журнал Спринту – це набір елементів Журналу Продукту, вибраних для виконання у поточному Спринті, разом із планом розробки Інкремента продукту та планом досягнення Цілі Спринту. Журнал Спринту – це прогноз Команди Розробників щодо функціональності, 

яка стане частиною наступного Інкременту, а також роботи, яку необхідно для цього виконати. 

Журнал Спринту визначає об’єм роботи, який Команда Розробників повинна виконати для перетворення Журналу Продукту на “завершений” Інкремент. Журнал Спринту візуалізує ту роботу, яку Команда Розробників вважає необхідною для досягнення Цілі Спринту. 

Журнал Спринту – це настільки деталізований план, щоби прогрес у його втіленні можна було побачити на кожному Щоденному Скрамі. Команда Розробників вносить зміни до Журналу Спринту протягом усього Спринту, тож, відповідно, Журнал Спринту постійно змінюється. Такі зміни відбуваються тому, що в процесі роботи Команда Розробників дізнається все нові й нові деталі про роботу, яку потрібно виконати для досягнення Цілі Спринту. 

Якщо виникає необхідність в додатковому обсязі роботи, Команда Розробників додає її до Журналу Спринту. Коли ж роботу виконано, оцінки обсягу роботи, що залишилась до виконання, оновлюються. Якщо деякі пункти плану вважаються вже неактуальними, їх видаляють. Тільки Команда Розробників може змінювати свій Журнал Спринту під час Спринту. Журнал Спринту є найбільш наочним документом, що показує реальну картину роботи, яку Команда Розробників планує завершити до закінчення Спринту, і він належить виключно Команді Розробників. 

Моніторинг прогресу Спринту 

Будь-коли під час Спринту можна підсумувати кількість роботи, що залишилася в Журналі Спринту. Команда Розробників відстежує залишок кількості роботи, як мінімум, під час кожного Щоденного Скраму. Команда Розробників щоденно відслідковує кількість залишку роботи та ймовірність досягнення Цілі Спринту. Завдяки відстеженню кількості залишку роботи під час Спринту, Команда Розробників може впливати на хід подій. Скрам не бере до уваги час, витрачений на роботу над вимогами Журналу Спринту. 

Єдиними цінними показниками є залишок кількості роботи та кінцевий термін завершення роботи.

Інкремент – це сума всіх виконаних вимог Журналу Продукту, реалізованих під час поточного Спринту та всіх попередніх Спринтів. По закінченню Спринту новий Інкремент повинен бути “завершеним”, тобто придатним до експлуатації та відповідати визначенню Скрам Команди поняття “завершеності”. Незважаючи на рішення Власника Продукту випускати цю версію Інкременту чи ні, він повинен бути готовим до використання. 

Визначення “Завершеності” 

Коли елемент Журналу Продукту або ж Інкремент називають “завершеним”, для забезпечення прозорості члени однієї Команди повинні мати спільне розуміння того, що означає, коли робота є виконаною. Саме таке єдине визначення поняття “завершеності” використовується Скрам Командою для оцінки завершення робіт над Інкрементом Продукту. 

Одне і те ж визначення допомагає Команді Розробників у розумінні того, скільки вимог із Журналу Продукту обрати під час Планування Спринту. Метою кожного Спринту є розробка Інкременту потенційно готової до випуску функціональності, що відповідає поточному визначенню Скрам Команди поняття “завершеності”. 

По закінченню кожного Спринту Команда Розробників представляє Інкремент функціональності продукту. Такий Інкремент є придатним до використання, і тому Власник Продукту може вирішити одразу ж його випустити. Кожен наступний Інкремент повинен доповнювати всі попередні Інкременти, а також бути ретельно протестованим для забезпечення стабільної роботи всіх Інкрементів продукту. 

У міру зростання професіоналізму Скрам Команди, поняття “завершеності” може розширятися та включати в себе більш строгі критерії для забезпечення кращої якості продукту. 

За матеріалами посібника, створеного Кеном Швабером та Джеффом Сазерлендом.

Від себе додам, що скрам - це не панацея. Для його використання, як, власне, і для ліків, потрібно правильно поставити "діагноз".