Agile – це маніфест розробки програмного забезпечення, або, простіше кажучи, ідея, підхід до створення продуктів шляхом безперервного швидкого постачання цінного робочого функціоналу.

Agile реалізовується методологіями:

  • Scrum – управлінський фреймворк;
  • XP – інженерні практики;
  • Канбан – організація підтрики.

Також є величезна кількість інших методологій, які не настільки популярні але все ще використовуються в певних ситуаціях. Можна назвати декілька з них: Crystal Clear, Dynamic Systems Development Method (DSDM), Agile Unidied Process, Future-driven development, ICONIX.

Цінності Agile:

  • Люди і їхня взаємодія важливіші процесів та інструментів;
  • Готовий продукт важливіший документації по ньому;
  • Співпраця з замовником важливіша жорстких контрактних обмежень;
  • Реакція на зміни важливіша слідуванню плану.

 

Принципи Agile

  1. Наш найвищий пріоритет – це задоволення замовника за допомогою частих і безперервних постачань продукту, цінного для нього.
  2. Ми приймаємо зміни до вимог, навіть на пізніх етапах реалізації проекту.
  3. Гнучкі процеси вітають зміни, що є конкурентною перевагою для замовника.
  4. Постачати повністю робоче програмне забезпечення кожні кілька тижнів, в крайньому випадку, кожні кілька місяців. Чим частіше, тим краще.
  5. Представники бізнесу і команда розробки повинні працювати разом над проектом.
  6. Успішні проекти будуються мотивованими людьми. Дайте їм відповідне навколишнє середовище, забезпечите всім необхідним і довірте зробити свою роботу.
  7. Найефективніший метод взаємодії та обміну інформацією – це особиста бесіда.
  8. Робоче програмне забезпечення – головна міра прогресу проекту.
  9. Гнучкі процеси сприяють безперервному розвитку. Всі учасники проекту повинні вміти витримувати такий постійний темп.
  10. Постійна увага до технічної досконалості і якісної архітектурі сприяють гнучкості.
  11. Простота необхідна, як мистецтво максимізації роботи, яку не слід робити.
  12. Краща архітектура, вимоги, дизайн створюється в самоорганізованих командах.
  13. Команда постійно шукає способи стати більш ефективною, шляхом налаштування і адаптації своїх процесів.

Scrum

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

Вимоги розбийте на невеликі, орієнтовані на користувачів, функціональні частини, які максимально незалежні один від одного, в результаті чого отримаєте беклог продукту. Потім впорядкуйте елементи беклога по їх важливості і зробіть відносну оцінку обсягів кожної історії. Виділіть окрему людину – власника продукту (product owner), який буде відповідати за вимоги і їх пріоритети, замикаючи на себе всіх зацікавлених осіб.

Всю роботу ведіть короткими (від 1 до 4 тижнів) фіксованими ітераціями – спринт, поставляючи в кінці кожного з них закінчений функціонал, який можна при необхідності вивести на ринок – інкремент продукту. Команда, згідно своєї швидкості, набирає завдання на незмінну за часом ітерацію – спринт. Кожен день проводиться скрам-мітинг, на якому команда синхронізує свою роботу і обговорює проблеми. В процесі роботи члени команди беруть в роботу елементи беклога відповідно до пріоритету.

В кінці кожного спринту проводите огляд спринту (demo), щоб отримати зворотній зв’язок від власника продукту, і ретроспективу спринту (retro), щоб оптимізувати ваші процеси. Після цього власник продукту може змінити вимоги і їх пріоритети і запустити новий спринт.

Ролі

  • У Scrum прийнято виділяти три основних ролі: власник продукту, скрам-майстер і команда.
    Власник продукту (Product owner, Менеджер продукту) – це людина, відповідальна за пріоритезацію вимог і часто за їх створення.
  • Скрам-майстер – член команди, який додатково відповідає за процеси, координацію роботи команди і підтримання соціальної атмосфери в команді.
  • Команда – 7 ± 2 осіб, які реалізують вимоги власника продукту.

Артефакти

Беклог продукту (Product Backlog) – пріоритезувати список вимог з оцінкою трудовитрат. Зазвичай він складається з бізнес-вимог, які приносять конкретну бізнес-цінність і називаються елементи беклога (User stories).

Беклог спринту (Sprint Backlog) – частина беклога продукту, з найвищою важливістю і сумарною оцінкою, що не перевищує швидкість команди, відібрана для спринту.

Інкремент продукту – нова функціональність продукту, створена під час спринту.

Процеси

Більшість процесів Scrum носять характер зустрічей, так як дана методологія заснована на якісних комунікаціях.

Скрам-мітинг

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

  1. Що було зроблено з попереднього скрам-мітингу?
  2. Які є проблеми?
  3. Що буде зроблено до наступного скрам мітингу?

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

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

  • всі елементи беклога повинні мати унікальну числову важливість;
  • найважливіші елементи беклога повинні бути уточнені і зрозумілі всій команді і власнику продукту;
  • власник продукту повинен чітко уявляти, що буде реалізовано в рамках кожного елемента беклога.

Огляд спринту

Огляд спринту (також часто використовується термін «демонстрація» або скорочено «демо») – показ власнику продукту (і зацікавленим особам) працюючий функціонал продукту, зробленого за спринт. Основне завдання проведення огляду спринту полягає в отриманні зворотного зв’язку.

Ретроспектива

У довгостроковому плані ретроспективи (або скорочено «ретро») є найважливішою практикою Scrum: адже саме вони дозволяють адаптувати і кастомізувати Scrum, роблячи з нього по-справжньому гнучкий фреймворк для управління проектами.

Також, традиційним є формат зі збору даних, який полягає у відповідях кожного учасника на три питання:

  1. Що було зроблено добре?
  2. Що можна поліпшити?
  3. Які поліпшення будемо робити (Action items)?

Канбан

Для того щоб використовувати канбан, досить слідувати всього трьом правилам. Таким чином, канбан є найбільш «Не директивною методологією». Це може бути як плюсом, так і мінусом, тому впроваджувати і використовувати канбан добре після Scrum, а ще краще не відмовлятися від корисних практик цього гнучкого фреймворка.

Таким чином, канбан – це високо адаптивний інструмент, який вимагає від команди, яка вирішила використовувати його, відповідного рівня самоорганізації і дисципліни:

  1. Візуалізуйте виробничий процес – для цього зазвичай використовують дошку, розмічену по етапах роботи над завданням. Звичайно, більш просунутим варіантом буде використовувати плазму / проектор, і виводити туди стан трекера.
  2. Обмежуйте кількість незавершеної роботи (WIP, Work In Progress) –  у кожного стовпця-стану команда вказує максимальну кількість завдань, які можуть в ньому перебувати. Таким чином, мінімізується перемикання між завданнями і пов’язані з цим втрати при виробництві.
  3. Оптимізуйте процес – основа оптимізації виробництва в рамках канбана. Необхідно відстежувати середній час завдання і зменшувати його.

XP (Екстремальне програмування)

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

Основні практики:

  • Безперервна інтеграція (Continuous Integration) – використання спеціального програмного забезпечення, яке отримує свіжу версію вихідного коду проекту, і виконує побудову ПЗ. У разі наявність проблем виводиться і розсилається відповідне повідомлення. В збірку проекту обов’язково входить запуск автоматичних тестів.
  • Розробка через тестування (Test Driven Development) – спочатку пишемо автоматичні тести, а потім функціонал який забезпечує проходження цих тестів. Про TDD я писав уже багато і можна прочитати статтю Unit tests – початок. Частина 1.
  • Парне програмування (Pair programming) – код пишеться двома розробниками за одним комп’ютером, причому один з розробників грає роль «пілота», а другий роль «штурмана». Це суттєво піднімає якість коду.
  • Колективне володіння кодом (Collective code ownership) – забезпечує кроссфункціональність самих учасників команди і дозволяє реалізовувати цю важливу властивість Scrum. Важливою перевагою такого підходу є швидке поширення знань між учасниками команди. Для реалізації цієї практики необхідно використовувати стандарти кодування, щоб код, написаний різними учасниками команди, був однаковий з точки зору оформлення. Перевірку на відповідність стандартам найкраще здійснювати на етапі побудови проекту в автоматичному режимі. Також процедура Code review допомагає досягнути цієї практики XP.
  • Стандарт кодування (Coding standard or Coding conventions) – набір правил написання коду. Кожен розробник в команді повинен їм слідувати.
  • 40-годинний робочий тиждень (Sustainable pace, Forty hour week) – це гарантія для команди від перевантажень, одного з виду втрат в ощадливому виробництві. Треба дуже чітко розуміти, що кількість відпрацьованих годин не дорівнює кількості зробленого функціоналу, як і в будь-якій інтелектуальній та інженерній діяльності.
  • Рефакторинг (Design Improvement, Refactor) – це зміни вихідного коду без зміни функціональності для поліпшення внутрішньої якості (простота коду, гнучкість архітектури і так далі). Рекомендую прочитати Що таке “Чистий код”?

В XP є ще кілька важливих практик які повсякденно використовуються в роботі по Agile/Scrum: Гра в планування (Planning game), Замовник завжди поруч (Whole team, Onsite customer), Часті невеликі релізи (Small Releases), Простота (Simple design), Метафора системи (System metaphor).

У Вікіпедії добре описані дані практики – Екстремальне програмування.

Більше теорії Agile можна подивитись в презентації Бориса Вольфсона.

Також рекомендую прочитати “Гибкие методологии разработки” Вольфсон Борис

Схожі статті