Ми публікуємо тут оригінальний переклад Скрам Гайду, затверджений Scrum.org. Ми не маємо права вносити власні корективи, навіть якщо дуже хочеться 😶

Щиро ваша, команда BrainRain

Мета посібника

Ми розробили Скрам (Scrum) на початку 1990‐х років. Ми написали першу версію посібнику зі Скраму у 2010, щоб допомогти людям у всьому світі краще розуміти Скрам. З тих пір посібник еволюціонував завдяки серії невеликих оновлень. Ми разом стоїмо за цим.

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

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

Шаблони, процеси, ідеї відповідні до Скрам фреймворку описані в даному документі, їх можна застосувати, винайти та адаптувати за власними потребами. Їх детальний опис виходить за рамки даного Посібника по Скраму тому що контекст їх використання дуже відрізняється в залежності від випадку використання Скрам. Тактики використання Скрам фреймворку дуже різноманітні та описані у інших джерелах.

Кен Швабер та Джефф Сазерленд , Листопад 2020

Визначення Скрам

Скрам (Scrum) це простий фреймворк який допомагає людям, командам та організаціям генерувати цінність через адаптивні рішення складних проблем.

В цілому, Скрам вимагає від Скрам Мастера (Scrum Master) створення середовища в якому:

  1. Власник Продукту (Product Owner) додає у певному порядку роботу для вирішення складної проблеми у Беклог Продукту (Product Backlog).
  2. Скрам Команда (Scrum Team) перетворює вибірку робіт в Інкремент (Increment), який додає цінність продукту, протягом Спринта (Sprint).
  3. Скрам Команда (Scrum Team) та зацікавлені сторони інспектують результати роботи та коректують наступний Спринт.
  4. Повторення.

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

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

Один з найкращих тренінгів, що дозволяє новачкам зрозуміти інструкції до скраму на практиці, — PSM від Scrum.org

Теорія Скрам

Скрам ґрунтується на емпіризмі та ощадливому мисленні. Емпіризм стверджує, що знання приходить з досвідом, а прийняття рішень має відбуватись на підставі того, що вже є відомим. Ощадливе мислення зменшує витрати та зосереджується на найнеобхіднішому.

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

Скрам поєднує чотири формальні події для перевірки та адаптації у рамках Спринта (Sprint). Ці події працюють, оскільки вони впроваджують емпіричні опори на яких базується Скрам: прозорість, перевірка та адаптація.

Прозорість

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

Прозорість надає можливість для перевірки. Перевірка без прозорості є оманливою та непотрібною.

Перевірка

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

Перевірка надає змогу адаптуватись. Перевірка без адаптування немає змісту. Події Скрам розроблені, щоб спровокувати зміни.

Адаптація

У випадку коли будь‐які аспекти процесу відхиляються від допустимих меж, або якщо отриманий продукт є неприйнятним, потрібно скорегувати застосовуваний процес або продукт, що виробляеться. Коригування потрібно зробити якомога швидше, щоб мінімізувати подальші відхилення.

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

Цінності Скрам

Успішне використання Скрам залежить від того, наскільки вміло люди втілюють наступні п’ять принципів:

Почуття обов’язку, зосередженість, відкритість, повага та сміливість (Commitment, Focus, Openness, Respect, and Courage)

Скрам Команда (Scrum Team) зобов’язується досягати своїх цілей та підтримувати один одного. Їх основна увага зосереджена на роботі Спринта (Sprint), щоб досягти якнайкращого прогресу до цих цілей. Скрам Команда та її зацікавлені сторони відкрито ставляться до роботи та проблем. Члени Скрам Команди поважають один одного та почуваються самодостатніми та незалежними, і тим самим мають таке ж ставлення від людей з якими працюють. Члени Скрам Команди беруть на себе сміливість зробити правильну річ, працюючи над складними проблемами.

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

Спробуйте вивчити Scrum за допомогою тренінга PSM. Окрім знань, ви ще й отримаєте сертифікацію, яку не потрібно поновлювати

Скрам Команда

Основна одиниця Скраму — це невелика команда людей яку називають Скрам Командою (Scrum Team). Скрам Команда складається з Скрам Мастера (Scrum Master), Власника Продукту (Product Owner), і Розробників (Developers). У Скрам Команди немає підгруп або ієрархій. Це згуртована група професіоналів, орієнтованих на одну ціль, Ціль Продукту (Product Goal).

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

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

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

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

Розробники

Розробники (Developers) — це люди в Скрам Команді які прагнуть створити будь‐який аспект корисного інкременту кожного Спринта.

Конкретні навички які необхідні Розробникам, часто є широкими і можуть відрізнятися залежно від сфери роботи. Однак Розробники завжди несуть відповідальність за наступне:

  • Створення плану для Спринта ‐ Спринт Беклог (Sprint Backlog);
  • Інтегрування якості, шляхом дотримання Визначення Виконаної Роботи (Definition of Done);
  • Кожного дня пристосовувати свій план до Цілі Спринту (Sprint Goal);
  • Звітують один перед одним як професіонали.

Власник Продукту

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

Власник Продукту також відповідає за ефективне управління Беклогом Продукту (Product Backlog), що включає наступне:

  • Розробити та точно прокомунікувати Цілі Продукту (Product Goal);
  • Створити та чітко прокомунікувати елементи Беклогу Продукту;
  • Впорядкувати елементи Беклог Продукту;
  • Переконатись, що Беклог Продукту є прозорим, доступним і зрозумілим.

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

Щоб Власник Продукту успішно виконував свої обов’язки, всі члени організації повинні поважати його рішення. Усі рішення Власника Продукту відображаються у вмісті та впорядкуванні Беклогу Продукту, а також у перегляді Інкременту під час Рев’ю Спринту.

Власник Продукту — це одна людина, а не група людей. Власник Продукту може представляти потреби багатьох зацікавлених сторін у Беклозі Продукту. А ті, хто бажає змінити пріоритетність вимог у Беклозі Продукту, повинні звернутись до Власника Продукту та переконати його.

Скрам Мастер

Скрам Мастер (Scrum Master) відповідальний за дотримання Скраму саме таким чином, як визначено у Посібнику зі Скраму. Він допомагає, як членам Скрам Команди, так і усій організації, зрозуміти теоретичні засади і практики Скраму.

Скрам Мастер відповідає за ефективніть Скрам Команди. Він робить це, дозволяючи Скрам Команді вдосконалювати свої практики в рамках Скраму.

Скрам Мастери є справжніми лідерами, які служать Скрам Команді та усій організації.

Скрам Мастер активно допомагає Скрам Команді з наступним:

  • Вчить членів команди бути самоорганізованими та крос‐функціональними;
  • Допомагає Скрам Команді фокусуватися на створенні високоякісних Інкрементів що відповідають Визначенню Виконаної Роботи (Definition of Done);
  • Усуває перешкоди, які виникають у роботі Скрам Команди;
  • Впевнюється, що всі Скрам події відбуваються в позитивній і продуктивній манері та виконуються згідно відведеного часу.

Скрам Мастер тісно співпрацює з Власником Продукту в наступному:

  • Допомогає шукати методи для ефективного визначення Цілі Продукту та управління Беклогом Продукту;
  • Допомагає Скрам Команді зрозуміти необхідність чітких та лаконічних елементів Беклогу Продукту;
  • Допомагає встановлювати емпіричне планування продуктів у складних умовах;
  • Допомагає співпраці з зацікавленими сторонами при необхідності.

Скрам Мастер також активно допомагає організації наступним чином:

  • Спрямовує, тренує та коучить організацію при впровадженні Скраму;
  • Планує та консультує з питань впровадження Скраму в організації;
  • Допомагає працівникам та зацікавленим особам зрозуміти та застосувати емпіричний підхід до складної роботи;
  • Усуває бар’єри між зацікавленими особами та Скрам Командами.
Ази скраму для новачків даємо на короткому інтенсиві Scrum Injection

Події в Скрам

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

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

Спринт

Спринти (Sprints) є основою Скраму, адже саме в них прості ідеї перетворюються на цінність.

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

Вся робота, необхідна для досягнення Цілі Продукту (Product Goal), включаючи Планування Спринту (Sprint Planning), Щоденні Скрами (Daily Scrums), Рев’ю Спринту (Sprint Review) та Спринт Ретроспективу (Sprint Retrospective), відбувається під час Спринтів.

Під час Спринту:

  • Не допускається внесення жодних змін, які б ставили під загрозу досягнення Цілі Спринту;
  • Вимоги до якості продукту залишаються незмінними;
  • Беклог Продукту (Product Backlog) уточнюється за необхідності;
  • Об’єм роботи можна уточнити та повторно обговорити з Власником Продукту під час процесу розробки.

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

Існують різні практики прогнозування прогресу, такі як графіки типу “скільки залишилось” (burn‐downs), “скільки зроблено” (burn‐ups) або кумулятивні діаграми (cumulative flows). Хоча вони є корисними, проте не можуть замінити важливість емпіричного підходу. В складних умовах те, що станеться ‐ невідомо. Тільки з огляду на те, що вже сталося, ми можемо приймати перспективні рішення.

Спринт можна скасувати, якщо Ціль Спринту стає неактуальною. Лише Власник Продукту має право скасувати Спринт.

Планування Спринту

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

Власник Продукту (Product Owner) повинен переконатись, що учасники готові обговорити найважливіші елементи Беклогу Продукту та визначити чи ці елементи відповідають Цілі Продукту (Product Goal). Скрам Команда може також запросити інших спеціалістів взяти участь у Плануванні Спринту щоб мати змогу з ними проконсультуватись.

Планування Спринту розглядаються наступні теми:

Перша Тема: Чому цей Sprint цінний?

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

Друга Тема: Що можна зробити під час цього Спринту?

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

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

Третя Тема: Як буде виконуватись робота?

Для кожного обраного елементу з Беклогу Продукту, розробники планують роботу необхідну для створення Інкременту, який буде виконано. Це часто робиться шляхом декомпозиції елементів з Беклогу Продукту в менші робочі завдання для виконання яких потрібен лише один день або менше. Все це робиться на власний розсуд Розробників. Ніхто інший не говорить їм як перетворити елементи з Беклогу Продукту в ціннісні Інкременти.

Ціль Спринта (Sprint Goal), елементи вибрані для Спринта з Беклог Продукту (Product Backlog), а також план їх розробки — усе це називають Беклог Спринту (Sprint Backlog).

Планування Спринту має тривати максимум вісім годин протягом Спринту тривалістю один місяць. Для коротших Спринтів Планування Спринту зазвичай займає менше часу.

Щоденний Скрам

Метою Щоденного Скраму (Daily Scrum) є перевірка прогресу досягнення Цілі Спринту та, якщо виникла така потреба, адаптація Беклогу Спринту, щоб відкоригувати заплановану роботу.

Щоденний Скрам — це 15‐хвилинна нарада для Розробників Скрам Команди. Для полегшення співпраці команди, нараду проводять в один і той же час та місці кожного дня Спринту. У випадку, коли Власник Продукту або Скрам Мастер активно працюють над елементами з Беклогу Спринту, вони беруть участь в команді у якості Розробників.

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

Щоденний Скрам покращує спілкування, виявляє перешкоди, сприяє швидкому прийняттю рішень і, отже, усуває потребу в інших нарадах.

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

Рев’ю Спринту

Метою Рев’ю Спринту (Sprint Review) є перевірка результатів Спринту та визначення адаптацій в подальшій роботі. Скрам Команда представляє результати своєї роботи зацікавленим особам та обговорює прогрес по досягненню Цілі Продукту (Product Goal).

Протягом наради Скрам Команда та зацікавлені особи переглядають, що було досягнуто у Спринті та що змінилося в їхньому середовищі. На основі цієї інформації всі присутні співпрацюють над тим, що робити далі. Беклог Продукту (Product Backlog) також можна скоригувати для того, щоб він відповідав новим можливостям. Рев’ю Спринту (Sprint Review) — це робоча сесія, тому Скрам Команда не повинна обмежувати себе лише презентацією виконаної роботи.

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

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

Метою Ретроспективи Спринту (Sprint Retrospective) є планування способів підвищення якості та ефективності роботи.

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

Скрам Команда визначає найбільш корисні зміни для підвищення своєї ефективності. Ці найбільш ефективні покращення розглядаються якомога швидше. Вони навіть можуть бути додані до Беклогу наступного Спринта.

Ретроспектива Спринта (Sprint Retrospective) завершує Спринт. Ця нарада обмежена в часі до трьох годин максимум для Спринту, що триває місяць. Для коротших Спринтів ця нарада зазвичай коротша.

Трьохвечірній скрам для початківців: Scrum Core 2.0

Артефакти Скраму

Артефакти Скраму (Scrum Artifacts) представляють собою роботу або цінність роботи. Вони спеціально спроектовані таким чином, щоб забезпечити максимальну чіткість ключової інформації. Тому кожен, хто їх переглядає, має однакову основу для адаптації.

Кожен артефакт включає в себе зобов’язання забезпечити надання інформації, що підвищує прозорість та фокус, і на основі яких можна виміряти прогрес:

  • Для Беклогу Продукту (Product Backlog) це Ціль Продукту (Product Goal).
  • Для Беклогу Спринта (Sprint Backlog) це Ціль Спринта (Sprint Goal).
  • Для Інкременту (Increment) це Визначення “Виконаної” Роботи (Definition of Done).

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

Беклог Продукту

Беклог Продукту (Product Backlog) — це сформований і впорядкований список усього, що потрібно для того щоб покращити продукт. Це єдине джерело роботи для Скрам Команди.

Елементи з Беклогу Продукту, які Скрам Команда може виконати протягом одного Спринту, вважаються готовими до вибору в роботу під час наради Планування Спринту (Sprint Planning). Зазвичай команда отримує таку ступінь прозорості після перегляду беклогу. Покращення Беклогу Продукту (Product Backlog refinement) — це акт розбиття Беклогу Продукту на менші, більш точні елементи та їх подальшого опису. Це постійний процес додавання деталей, таких як короткий опис, порядоковий номер та обсяг роботи. Атрибути часто змінюються, в залежності від сфери роботи.

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

Зобов’язання: Ціль Продукту

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

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

Ціль Продукту — це довгострокова мета для Скрам Команди. Вони повинні виконати одну ціль (або відмовитись від неї), перш ніж братись за наступну.

Беклог Спринту

Беклог Спринту (Sprint Backlog) складається з Цілі Спринту (чому ми це робимо?), набору елементів Беклогу Продукту обраних для Спринту (що саме ми робимо?), а також плану дій для розробки Інкременту (як ми це робимо?).

Беклог Спринту — це план створений Розробниками для самих Розробників. Це візуалізований план робіт, який в реальному часі дає уявлення про те, що Розробники планують виконати під час Спринту, щоб виконати Ціль Спринту. Отже, Беклог Спринту оновлюється по мірі того, як команда дізнається про щось нове протягом усього Спринту. Беклог повинен містити достатньо деталей, щоб команда могла перевіряти свій прогрес під час Щоденного Скраму (Daily Scrum).

Зобов’язання: Ціль Спринту

Ціль Спринту (Sprint Goal) ‐ є єдиною метою Спринту. Хоча Ціль Спринту є зобов’язанням Розробників, вона забезпечує гнучкість щодо тієї роботи, яка є необхідною для її досягнення. Також, Ціль Спринту створює злагодженість і тримає фокус Скрам Команди, заохочуючи їх працювати разом, а не окремо.

Ціль Спринту визначають під час Планування Спринту, а потім додають до Беклогу Спринту. Під час роботи над Спринтом, Розробники пам’ятають про Ціль Спринту. Якщо робота виявиться іншою, ніж Розробники очікували, вони узгоджують з Власником Продукту обсяг Беклогу Спринту в рамках Спринту, не впливаючи на саму Ціль Спринту.

Інкремент

Інкремент (Increment) — це конкретна сходинка до Цілі Продукту. Кожен Інкремент додається до всіх попередніх Інкрементів та ретельно перевіряється, щоб гарантувати, що всі Інкременти працюють разом. Для забезпечення цінності, Інкремент повинен бути придатним для використання.

У Спринті можна створити багато Інкрементів. Сума Інкрементів представляється на Рев’ю Спринта (Sprint Review), тим самим підтримуючи емпіричні принципи роботи. Однак Інкремент можна передати зацікавленим особам ще до закінчення Спринту. Рев’ю Спринту ніколи не слід розглядати в якості способу постачання цінності.

Робота не може вважатися частиною Інкременту, якщо вона не відповідає Визначенню Виконаної Роботи (Definition of Done).

Зобов’язання: Визначення Виконаної Роботи

Визначення Виконаної Роботи (Definition of Done) — це формальний опис стану Інкременту досягнувши котрого, він відповідає вимогам якості, які є обов’язковими для продукту.

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

За допомогою Визначення Виконаної Роботи створюється прозоре спільне розуміння того, яка робота була завершена та перетворилась на частину Інкременту. Якщо елемент з Беклогу Продукту не відповідає Визначенню Виконаної Роботи, його не можна випустити або навіть представити на Рев’ю Спринту. Натомість його повертають до Беклогу Продукту для подальшого розгляду.

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

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

Гарячий одноденний інтенсив, що допоможе вам зрозуміти скрам на практиці, — Scrum Intensive

Примітка

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

Подяка

Люди

З тисяч людей, які сприяли розвитку Скрам, слід виділити тих, хто зробив свій внесок на початку: Джефф Сазерленд працював з Джеффом МакКенном та Джоном Скамніоталесом, а Кен Швабер працював з Майком Смітом та Крісом Мартіном, і всі вони працювали разом . Багато інших людей зробили внесок у наступні роки, і без їх допомоги Скрам не був би вдосконаленим так, як сьогодні.

Історія Посібника зі Скраму

Кен Швабер і Джефф Сазерленд вперше представили Скрам на конференції OOPSLA в 1995 році. Їх доповідь задокументувала знання, які Кен та Джеф отримали за попередні кілька років, та оприлюднила перше офіційне визначення Скрам.

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

Повна історія Скраму надається в інших джерелах. Щоб вшанувати перші місця, де Скрам випробували та перевірили, ми відзначаємо Individual Inc., Newspage, Fidelity Investments та IDX (нині GE Medical).

Джерело: scrumguides.org