Scrum

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Цикл розробки
програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація
Архітектура ·  Дизайн
Реалізація ·  Тестування
Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення
DSDM ·  Iterative ·  RAD ·  RUP
Spiral ·  Водоспад ·  XP ·  Scrum
Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування
Документування
Якість ПЗ
Управління проектами
Досвід користування
Інструменти
Компілятор ·  Зневаджувач
Профілювальник
GUI designer ·  IDE

Scrum — методологія управління проектами для гнучкої розробки програмного забезпечення. Скрам чітко робить акцент на якісному контролі процесу розробки.

Історія[ред.ред. код]

Підхід вперше описали Гіротака Такеучі та Ікуджіро Нонака[1] в статті The New New Product Development Game (Гарвардський Діловий Огляд [2], січ-лют 1986). Вони відзначили, що проекти, над якими працюють невеликі, крос-функціональні команди, зазвичай систематично продукують кращі результати, і пояснили це, як «підхід регбі». У 1991 році ДеҐрейс та Шталь у книжці Злі проблеми, справедливі рішення[3] послалися на цей підхід, як на Scrum (штовханина; сутичка навколо м'яча (у регбі)), спортивний термін, згаданий в статті Такеучі і Нонака. Кен Швабер на початку 1990-х використовував підхід який привів Scrum в його компанію. Вперше метод Scrum було представлено на загальний огляд задокументованим, чітко сформульованим та описаним спільно Сазерлендом та Швабером на OOPSLA'96 в Остіні. Швабер та Сазерленд протягом наступних років працювали разом щоб обробити та описати весь їхній досвід та найкращі практичні зразки для індустрії в одне ціле, в ту методологію, що відома сьогодні як Scrum. Швабер об'єднав зусилля з Майком Бідлом[4] в 2001, щоб детально описати метод в книжці Agile Software Development with SCRUM. Не зважаючи на те, що для Scrum нарікли долю управління проектами з розробки ПЗ, він може також використовуватися в роботі команд обслуговувань програмного забезпечення (software maintenance teams), або як підхід управління розробкою і супроводом програм: Scrum of Scrums.

Визначення[ред.ред. код]

Скрам процеси

Scrum — це кістяк процесу, який включає набір методів і попередньо визначених ролей. Головні дійові особи — ScrumMaster, той хто опікується процесами, веде їх і працює як керівник проекту, Власник Продукту, людина, що представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін, та Команду, яка включає розробників.

Протягом кожного спринту [5], 15-30 денного періоду (тривалість визначається командою), працівники створюють функціональний ріст програмного забезпечення.

Набір можливостей, які імплементуються кожного спринту, приходять з етапу, що має назву product backlog (документація запитів на виконання робіт), який має найвищу пріоритетність за рівнем вимог до роботи, що повинна бути виконана. Запити на виконання робіт (backlog items) що визначені протягом наради з планування спринту (sprint planning meeting) переміщуються в етап спринту. Протягом цієї наради Власник Продукту інформує про завдання, які він хоче, аби були виконані. Тоді Команда визначає, скільки з бажаного вони можуть зробити, щоб завершити необхідні частини протягом наступного спринту[6]. Протягом спринту команда виконує визначений фіксований список завдань (т.з. backlog items). Впродовж цього періоду ніхто не має права змінювати перелік запитів на виконання робіт, що слід розуміти, як заморожування вимог (requirements) протягом спринту.

Дійові особи[ред.ред. код]

За методикою Scrum у виробничому процесі є визначені ролі, що розбиті на дві групи — «свиней» та «курей». Ці назви використані через жарт про свиню та курку.[6]

Свиня і курка йшли собі по дорозі. Курка дивиться на свиню і каже «Давай відкриємо ресторан!» Свиня дивиться на курку і відповідає «Добра ідея, а що ми будемо подавати на стіл?» Курка думає і каже: «Чому б не подавати шинку та яйця?». «Я не згодна», відповідає свиня, «тоді я буду повністю зобов’язана (досл. повністю приготована, committed), а ти лише задіяна (involved).»

Отже, свині використовуються для побудови продукту регулярно і часто (повністю задіяні), тоді як будь-які інші — кури, ті, що зацікавлені (і задіяні) в проекті, але не мають прямого стосунку до приготування страви. Потреби, бажання, ідеї та вплив курей беруться до уваги, але їм не завжди дозволяють прямо впливати, видозмінювати або включатися в хід Scrum проекту.

«Свині»[ред.ред. код]

Свині цілком задіяні в проекті, у Скрам процес, так би мовити вони єдині з «власним беконом» на виробничій лінії.

  • Власник Продукту (Product Owner)
  • Керівник (ScrumMaster)
  • Команда (Scrum Team)

«Кури»[ред.ред. код]

  • Користувачі (Users)
  • Клієнти, Продавці (Stakeholders)
  • Експерти-консультанти (Consulting Experts)

Артефакти[ред.ред. код]

Product backlog (беклог)[ред.ред. код]

Product backlog – це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. Product backlog представляє список того, що повинно бути реалізовано. Елементи цього списку називається «історіями» (user story) або елементами backlog-у (backlog items). Product backlog відкритий для редагування усім учасникам Scrum-процесу.

Обов’язкові поля 
  • ID – унікальний ідентифікатор, порядковий номер, який використовується для ідентифікації історій у разі їх перейменування.
  • Назва (Name) – стислий опис історії. Він повинен бути однозначним, щоб і розробники і product owner могли зрозуміти, про що йде мова і відрізнити одну історію від іншої.
  • Важливість (Importance) – ступінь важливості даної історії на погляд product owner ’a. Зазвичай являє собою натуральне число, іноді для цієї цілі використовуються числа Фібоначчі. Чим більше значення, тим більше пріоритет.
  • Попередня оцінка (initial estimate) – початкова оцінка об’єму робіт, необхідного для реалізації історії порівняно з іншими історіями. Вимірюється у story point’ах. Приблизно відповідає числу «ідеальних людино-днів».
  • Як продемонструвати (how to demo) – стисле пояснення того, як завершена задача буде продемонстрована у кінці спринта. Дане поле може представляти собою код автоматизованого приймального тесту.
Додаткові поля 
Іноді, також, використовуються додаткові поля у product backlog, в основному для того, щоб допомогти product owner’у визначитися з його пріоритетами.
  • Категорія (track). Наприклад, «панель управління» чи «оптимізація». За допомогою цього поля product owner може легко вибрати усі пункти категорії «оптимізація» і задати їм низький пріоритет.
  • Компоненти (components) – указує, які компоненти (наприклад, база даних, сервер, клієнт) будуть зачеплені при реалізації історії. Дане поле складається з групи checkbox’ів, які відмічаються, якщо відповідні компоненти потребують змін.
  • Ініціатор запиту (requestor). Product owner може захотіти зберігати інформацію про усіх замовників, зацікавлених у даній задачі. Це потрібно для того, щоб тримати їх у курсі діла про хід виконання робiт.
  • ID у системі обліку помилок (bug tracking ID) – якщо ви використовуєте окрему систему обліку помилок, тоді у описі історії корисно зберігати посилання на всі дефекти, які до неї відносяться.

Sprint backlog[ред.ред. код]

Sprint backlog – містить функціональність, обрану Product Owner із Product Backlog. Всі функції розбиті по задачах, кожна з яких оцінюється командою. Кожен день команда оцінює об’єм роботи, який необхідно провести для завершення задачі.

Burndown chart[ред.ред. код]

Burndown chart – показує, скільки вже виконано і скільки ще залишається зробити.

Зустрічі[ред.ред. код]

Планування спринта (Sprint Planning Meeting)[ред.ред. код]

Проходить на початку нової ітерації Спринта.

  • Із Product Backlog обираються задачі, зобов’язання по виконанню яких за спринт приймає на себе команда;
  • На основі обраних задач створюється Sprint Backlog. Кожна задача оцінюється у ідеальних людино-годинах;
  • Рішення задачі не повинно займати більше 12 годин або одного дня. При необхідності задача розбивається на підзадачі;
  • Обговорюється та визначається, яким чином буде реалізовано цей об’єм робіт;
  • Тривалість наради обмежена зверху 4-8 годинами в залежності від тривалості ітерації, досвіду команди і т.п.;
    • (перша частина наради) Беруть участь Product Owner + Команда: обирають задачі із Product Backlog;
    • (друга частина наради) Бере участь лише команда: обговорюють технічні деталі реалізації, наповнюють Sprint Backlog

Щоденна нарада (Daily Scrum Meeting)[ред.ред. код]

Відбувається кожен день протягом спринта. Є «пульсом» ходу спринта. Нараді властиві наступні обмеження:

  • починається точно вчасно;
  • всі можуть спостерігати, але говорять тільки «свині»;
  • триває не більш ніж 15 хвилин;
  • проводиться в одному і тому ж місці протягом одного спринта.

Протягом наради кожен член команди відповідає на 3 запитання:

  • Що зроблено з моменту попередньої щоденної наради?
  • Що буде зроблено з моменту поточної наради до наступної?
  • Які проблеми заважають досягненню цілей спринта? (Над рішенням цих проблем працює ScrumMaster. Зазвичай це рішення проходить за рамками щоденної наради і у складі осіб, що безпосередньо займаються даною перешкодою.)

Демонстрація (Sprint Review Meeting)[ред.ред. код]

  • Проходить у кінці ітерації (спринта).
  • Команда демонструє внесок функціональності до продукту всім зацікавленим особам.
  • Залучається максимальна кількість глядачів.
  • Усі члени команди беруть участь у демонстрації (одна людина на демонстрацію або кожен показує, що зробив за спринт).
  • Обмежена 4-ма годинами в залежності від тривалості ітерації і змін у продукті.

Ретроспектива (Sprint Retrospective)[ред.ред. код]

  • Члени команди висловлюють свою думку про минулий спринт.
  • Відповідають на два основних запитання:
    • Що було зроблено добре у минулому спринті?
    • Що потрібно покращити в наступному?
  • Виконують покращення процесу розробки (вирішують питання та фіксують вдалі рішення).
  • Обмежена 1-3ма годинами.

Засоби управління проектами, що підтримують Скрам[ред.ред. код]

Примітки[ред.ред. код]

  1. Hirotaka Takeuchi, Ikujiro Nonaka
  2. Harvard Business Review
  3. Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (перше видання) ISBN 0-13-590126-X
  4. Mike Beedle
  5. Sprint — ривок; кидок; біг на коротку дистанцію; спринт
  6. а б Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X

Посилання[ред.ред. код]