Agile – це маніфест розробки програмного забезпечення, або, простіше кажучи, ідея, підхід до створення продуктів шляхом безперервного швидкого постачання цінного робочого функціоналу.
Agile реалізовується методологіями:
- Scrum – управлінський фреймворк;
- XP – інженерні практики;
- Канбан – організація підтрики.
Також є величезна кількість інших методологій, які не настільки популярні але все ще використовуються в певних ситуаціях. Можна назвати декілька з них: Crystal Clear, Dynamic Systems Development Method (DSDM), Agile Unidied Process, Future-driven development, ICONIX.
Цінності Agile:
- Люди і їхня взаємодія важливіші процесів та інструментів;
- Готовий продукт важливіший документації по ньому;
- Співпраця з замовником важливіша жорстких контрактних обмежень;
- Реакція на зміни важливіша слідуванню плану.
Принципи Agile
- Наш найвищий пріоритет – це задоволення замовника за допомогою частих і безперервних постачань продукту, цінного для нього.
- Ми приймаємо зміни до вимог, навіть на пізніх етапах реалізації проекту.
- Гнучкі процеси вітають зміни, що є конкурентною перевагою для замовника.
- Постачати повністю робоче програмне забезпечення кожні кілька тижнів, в крайньому випадку, кожні кілька місяців. Чим частіше, тим краще.
- Представники бізнесу і команда розробки повинні працювати разом над проектом.
- Успішні проекти будуються мотивованими людьми. Дайте їм відповідне навколишнє середовище, забезпечите всім необхідним і довірте зробити свою роботу.
- Найефективніший метод взаємодії та обміну інформацією – це особиста бесіда.
- Робоче програмне забезпечення – головна міра прогресу проекту.
- Гнучкі процеси сприяють безперервному розвитку. Всі учасники проекту повинні вміти витримувати такий постійний темп.
- Постійна увага до технічної досконалості і якісної архітектурі сприяють гнучкості.
- Простота необхідна, як мистецтво максимізації роботи, яку не слід робити.
- Краща архітектура, вимоги, дизайн створюється в самоорганізованих командах.
- Команда постійно шукає способи стати більш ефективною, шляхом налаштування і адаптації своїх процесів.
Scrum
Організуйте роботу у вашій організації в невеликих кроссфункціональних командах, які містять всіх необхідних фахівців. Виділіть людину – скрам-майстра, який буде відповідати за дотримання процесів в команді і конструктивну атмосферу.
Вимоги розбийте на невеликі, орієнтовані на користувачів, функціональні частини, які максимально незалежні один від одного, в результаті чого отримаєте беклог продукту. Потім впорядкуйте елементи беклога по їх важливості і зробіть відносну оцінку обсягів кожної історії. Виділіть окрему людину – власника продукту (product owner), який буде відповідати за вимоги і їх пріоритети, замикаючи на себе всіх зацікавлених осіб.
Всю роботу ведіть короткими (від 1 до 4 тижнів) фіксованими ітераціями – спринт, поставляючи в кінці кожного з них закінчений функціонал, який можна при необхідності вивести на ринок – інкремент продукту. Команда, згідно своєї швидкості, набирає завдання на незмінну за часом ітерацію – спринт. Кожен день проводиться скрам-мітинг, на якому команда синхронізує свою роботу і обговорює проблеми. В процесі роботи члени команди беруть в роботу елементи беклога відповідно до пріоритету.
В кінці кожного спринту проводите огляд спринту (demo), щоб отримати зворотній зв’язок від власника продукту, і ретроспективу спринту (retro), щоб оптимізувати ваші процеси. Після цього власник продукту може змінити вимоги і їх пріоритети і запустити новий спринт.
Ролі
- У Scrum прийнято виділяти три основних ролі: власник продукту, скрам-майстер і команда.
Власник продукту (Product owner, Менеджер продукту) – це людина, відповідальна за пріоритезацію вимог і часто за їх створення. - Скрам-майстер – член команди, який додатково відповідає за процеси, координацію роботи команди і підтримання соціальної атмосфери в команді.
- Команда – 7 ± 2 осіб, які реалізують вимоги власника продукту.
Артефакти
Беклог продукту (Product Backlog) – пріоритезувати список вимог з оцінкою трудовитрат. Зазвичай він складається з бізнес-вимог, які приносять конкретну бізнес-цінність і називаються елементи беклога (User stories).
Беклог спринту (Sprint Backlog) – частина беклога продукту, з найвищою важливістю і сумарною оцінкою, що не перевищує швидкість команди, відібрана для спринту.
Інкремент продукту – нова функціональність продукту, створена під час спринту.
Процеси
Більшість процесів Scrum носять характер зустрічей, так як дана методологія заснована на якісних комунікаціях.
Скрам-мітинг
Скрам-мітинг (Scrum meeting, скрам, щоденний скрам, планерка) – збори членів команди (з можливістю запрошення власника продукту) для синхронізації діяльності команди і інформуванням про проблеми. Кожен член команди відповідає на три питання:
- Що було зроблено з попереднього скрам-мітингу?
- Які є проблеми?
- Що буде зроблено до наступного скрам мітингу?
Планування спринту
Для планування спринту необхідно мати якісний беклог, що означає наступне:
- всі елементи беклога повинні мати унікальну числову важливість;
- найважливіші елементи беклога повинні бути уточнені і зрозумілі всій команді і власнику продукту;
- власник продукту повинен чітко уявляти, що буде реалізовано в рамках кожного елемента беклога.
Огляд спринту
Огляд спринту (також часто використовується термін «демонстрація» або скорочено «демо») – показ власнику продукту (і зацікавленим особам) працюючий функціонал продукту, зробленого за спринт. Основне завдання проведення огляду спринту полягає в отриманні зворотного зв’язку.
Ретроспектива
У довгостроковому плані ретроспективи (або скорочено «ретро») є найважливішою практикою Scrum: адже саме вони дозволяють адаптувати і кастомізувати Scrum, роблячи з нього по-справжньому гнучкий фреймворк для управління проектами.
Також, традиційним є формат зі збору даних, який полягає у відповідях кожного учасника на три питання:
- Що було зроблено добре?
- Що можна поліпшити?
- Які поліпшення будемо робити (Action items)?
Канбан
Для того щоб використовувати канбан, досить слідувати всього трьом правилам. Таким чином, канбан є найбільш «Не директивною методологією». Це може бути як плюсом, так і мінусом, тому впроваджувати і використовувати канбан добре після Scrum, а ще краще не відмовлятися від корисних практик цього гнучкого фреймворка.
Таким чином, канбан – це високо адаптивний інструмент, який вимагає від команди, яка вирішила використовувати його, відповідного рівня самоорганізації і дисципліни:
- Візуалізуйте виробничий процес – для цього зазвичай використовують дошку, розмічену по етапах роботи над завданням. Звичайно, більш просунутим варіантом буде використовувати плазму / проектор, і виводити туди стан трекера.
- Обмежуйте кількість незавершеної роботи (WIP, Work In Progress) – у кожного стовпця-стану команда вказує максимальну кількість завдань, які можуть в ньому перебувати. Таким чином, мінімізується перемикання між завданнями і пов’язані з цим втрати при виробництві.
- Оптимізуйте процес – основа оптимізації виробництва в рамках канбана. Необхідно відстежувати середній час завдання і зменшувати його.
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 можна подивитись в презентації Бориса Вольфсона.
Також рекомендую прочитати “Гибкие методологии разработки” Вольфсон Борис