Методологія Agile. Матір драконів або всіх гнучких методологій

Історія Agile починається з публікації 2001 року «Маніфесту гнучкого розроблення ПЗ», що складається з 12 принципів. Звісно, окремі положення Agile-підходу з’явилися з’являлися і до цього, але тільки цей документ систематизував і виклав їх достатньою для використання мірою. Щороку під маніфестом підписуються нові компанії, IT-фахівці та проєктні менеджери. З’являються нові методи і модифікації гнучкої системи розробки.

Що таке Agile Methodology (гнучка методологія)?

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

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

12 принципів, які складають Agile Methodology, можна поділити на 4 головні ідеї:

  • Пріоритет людей і спілкування над інструментами та процесами;
  • Пріоритет працюючого продукту над повною документацією;
  • Пріоритет співпраці із замовниками над затвердженням контракту;
  • Пріоритет готовності змінюватися над дотриманням спочатку створеного плану. 

Методи присутні в Agile:

Scrum

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

Метод успішно застосовують такі компанії як Microsoft, Yahoo, Siemens Healthcare, а проєктний менеджер в Amazon навіть описав кейс впровадження Scrum на основі отриманого досвіду. 

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

Джефф Сазерленд, автор книги «Scrum. Навчись робити вдвічі більше за менший час» виокремив 8 кроків з використання методики:

  1. Виберіть власника продукту — він знає про мету проєкту та очікуваний результат. 
  2. Зберіть команду — до 10 осіб із необхідними для створення працездатного продукту навичками.
  3. Знайдіть скрам-майстра — він стежить за перебігом проєкту, допомагає проєктній команді боротися з труднощами.
  4. Складіть беклог продукту — на Agile-дошці розставте пріоритети за кожною вимогою до продукту. У цьому велику роль відіграє власник продукту, який збирає побажання до продукту для оцінки командою беклогу. 
  5. Заплануйте спринти (ітерації) — відрізки часу на виконання певної низки завдань. 
  6. Організовуйте щоденні п’ятнадцятихвилинні «міт-апи» — ставте по 3 запитання кожному з команди: що робив учора, що буде сьогодні, що заважає виконати завдання.
  7. Робіть огляди робочих частин продукту — із залученням до перегляду та обговорення стейкхолдерів.
  8. Проводьте ретроспективу — обговорення проблеми і пошук рішення після кожного спринту. Отриманий план зміни впроваджуєте на наступному спринті.

У скрам є 4 ключові елементи:

  • Product Backlog — список вимог за проєктом
  • Sprint Backlog — список вимог, які потрібно виконати в найближчий спринт
  • Sprint Goal — мета спринту
  • Sprint Burndown Chart — діаграма, яка оновлюється в міру завершення завдань. За нею легко зрозуміти динаміку і рівень просування команди в проєкті

eXtreme Programming (XP)

Розробник методики, Кент Бек, створив метод екстремального програмування, мета якого — впоратися з постійно мінливими вимогами до програмного продукту і підвищити якість розробки. 

Він може бути застосований виключно у сфері розробки ПЗ, і будується навколо 4 процесів:

  1. кодування — згідно з єдиними в команді стандартами оформлення;
  2. тестування — тести пишуться самими програмістами до написання коду, який будуть тестувати;
  3. планування — як фінального білда, так і окремих ітерацій. Останнє відбувається в середньому раз на два тижні. 
  4. слухання — як розробників, так і клієнта, під час якого зникають незрозумілості, визначаються вимоги та цінності.

Crystal Methodologies

Маловідоме на вітчизняних теренах проєктного менеджменту сімейство методологій, розроблене Алістером Кокберном, одним з авторів «Маніфесту гнучкого розроблення ПЗ». Класифікацію Кокберн пропонує проводити за кольорами за критерієм кількості осіб у команді: від 2 (Crystal Clear) до 100 (Crystal Red). Під більш масштабні проєкти виділено кольори Maroon, Blue і Violet.

Crystal-проєкти мають відповідати 3 основним показникам:

  1. швидка доставка робочого коду — розвиток ідеї ітеративної моделі розробки Agile.
  2. досконалість через рефлексію — нова версія ПЗ поліпшується на основі даних про попередню.
  3. «осмотична» взаємодія — нововведення Алістера, метафора комунікації та обміну інформацією між розробниками ПЗ в одній кімнаті. 

Детально сімейство методологій описано в книзі Алістера «Crystal Clear: A Human-Powered Methodology for Small Teams».

Dynamic Software Development Method (DSDM)

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

Особлива роль відводиться участі кінцевого споживача (користувача) в процесі розробки. Крім цього принципу, до базових належать:

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

DSDM ділиться на версії, які оновлюються в міру розвитку технологій, появи нових вимог до розробки ПЗ. Остання на сьогодні — DSDM Atern, випущена 2007 року, хоча попередня (2003 року) ще в строю.

На початку команда вивчає реальність розробки застосунку та сферу застосування. Далі робота ділиться на три взаємопов’язані цикли:

  1. цикл функціональної моделі — створення аналітичної документації та прототипів.
  2. цикл проєктування і конструювання — приведення системи в робочий стан.
  3. цикл реалізації — розгортання системи. 

Feature Driven Development (FDD)

Методологія, яка з’явилася навіть раніше, ніж «Маніфест гнучкого розроблення ПЗ».

Хоч у FDD теж застосовується ітераційна модель розробки, від Agile вона відрізняється в такому:

  • більше уваги попередньому моделюванню
  • підвищена (порівняно з Agile) важливість побудови звітності та графіків
  • націлене на корпоративну розробку.

Feature Driven Development складається з таких циклічних етапів:

  1. Створення загальної моделі — бачення проєкту на основі попередніх даних.
  2. Розробка списку властивостей — аналог product backlog у методиці скрам. 
  3. Планування за властивостями — оцінка складності властивостей кожним членом команди.
  4. За кожною властивістю — технічний дизайн і реалізація — фінальна стадія, по закінченню якої властивість йде в продукт і цикл повторюється.

Lean Software Development

Lean Software Development — скоріше не методологія, а набір принципів ощадливого виробництва, який спрямований на підвищення ефективності процесу розробки, мінімізацію витрат. 

До набору входять такі 7 принципів:

  1. позбавлення від втрат — усе, що не додає цінності продукту для кінцевого споживача.
  2. постійне навчання — безперервний розвиток команди збільшує можливості ефективного виконання завдань.
  3. прийняття рішення так пізно, як тільки можна — пріоритет не спонтанним рішенням, а продуманим, розробленим на основі отриманих знань.
  4. швидка доставка — по суті основа ітеративної моделі.
  5. посилення команди — один із принципів «Маніфесту…» свідчить, що люди і взаємодія важливіші за процеси та інструменти. Проєктна команда — основа успішного завершення завдань.
  6. цілісність і якість — потрібно від самого початку робити якісний продукт, щоб не витрачати час і ресурси на подальше тестування і позбавлення від багів.
  7. бачення цілісної картини — розбиття проєкту на окремі частини неможливе без розуміння поточного статусу розроблення, цілей, концепції та стратегії ПЗ, що розробляється.

Різновид методологій гнучкої розробки

Agile Modeling (AM)

Agile Modeling — набір цінностей, принципів і практик для моделювання програмного забезпечення. 

AM використовують як складову повноцінної методики розробки ПЗ — наприклад, екстремального програмування або Rapid Application Development.

Принципи Agile Modeling наступні:

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

Agile Unified Process (AUP)

AUP — спрощена версія іншої методології розробки ПЗ — Rational Unified Process (RUP). З 2012 року її замінили на Disciplined Agile Delivery (DAD), але подекуди AUP ще зустрічається. 

Автор методики, Скотт Амблер, виділив такі ключові позиції Agile Unified Process:

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

Agile Data Method (ADM)

ADM — набір ітеративних методик гнучкого розроблення програмного забезпечення, які наголошують на формуванні вимоги та рішень за проєктом через співпрацю окремих команд. Як і AUP, це не самоцінна методика. 

Суть Agile Data Method визначається шістьма положеннями:

  1. Дані — основа створення будь-якого застосунку.
  2. Проблеми з проєктом — їх можна виявити тільки при чіткому розумінні мети та концепції проєкту.
  3. Робочі групи — крім безпосередньої команди розробників є enterprise groups, які підтримують інші робочі групи.
  4. Унікальність — немає ідеальної методики, під кожен проєкт потрібно комбінувати інструменти з різних методологій.
  5. Робота в команді — спільна робота набагато ефективніша, ніж поодинці.
  6. «Солодка пляма» — пошук оптимального вирішення проблеми («солодкої плями»), уникаючи крайнощів.

Essential Unified Process (EssUP)

Розробка шведського вченого Івара Якобсона, створена для поліпшення Rational Unified Process. 

EssUP оперує поняттям практики, до яких входять:

  • сценарій використання — опис поведінки системи.
  • ітераційна розробка — створення робочих шматків коду короткими циклами в кілька тижнів.
  • командні практики — спрямовані на згуртування команди та підвищення її ефективності.
  • процесуальні практики — наприклад, «Думай глобально, починай з малого» або «Залучайте стейкхолдерів до бізнес-процесів». 

Усі практики в тому чи іншому вигляді зустрічаються в методологіях RUP, CMMI і гнучкій методиці розроблення. 

Getting Real (GR)

Ефективна для стартапів і команд-початківців методологія, яка пропонує максимально використовувати особливості невеликих проєктів і компаній: мобільність, гнучкість, пошук нових рішень, відсутність жорсткої заплутаної ієрархії тощо. Джейсон Фрід і Давид Ханссон, засновники компанії 37signals (тепер — Basecamp), визначили Getting Real як систему для розв’язання реальних завдань: максимально просту, зрозумілу і функціональну. 

GR — збірна солянка з десятка інструментів гнучкої розробки, які використовуються для мінімізації:

  • можливостей
  • опцій і налаштувань
  • структури компанії
  • зустрічей
  • обіцянок.

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

OpenUP (OUP)

Незалежна від інструментів методологія розробки ПЗ без жорсткої структури, яка містить такі практики:

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

Практики реалізуються на основі чотирьох принципів:

  1. узгодження інтересів і досягнення спільного бачення під час спільної роботи
  2. безперервне вдосконалення через постійний зворотний зв’язок
  3. фокусування на архітектурі застосунку на ранніх стадіях для мінімізації ризиків
  4. максимізація цінності для кінцевого споживача. 
Непрерывное совершенствование через постоянную обратную связь

Agile показники

З огляду на розмаїття інструментів, практик, методів і методологій в Agile, потрібно обрати інструмент, який допоможе визначити ефективність кожного з них. Таким інструментом виступають метрики. 

Для більшості проєктів вистачить 4 напрямків метрик:

  1. Продуктивність — сюди відносяться Velocity і WIP. Перша підійде не для всіх проєктів, оскільки йде вимірюється кількість виконаних завдань за ітерацію, а вони нерівнозначні. Метрика Work-in-Progress визначає ліміт завдань на різних стадіях: і чим він вищий, тим гірше;
  2. Прогнозування — метрика capacity: визначення кількості ідеальних годин, доступних у наступному спринті. Відповідно, можна зрозуміти, скільки часу є на роботу, наскільки ефективне виконання завдань і як спланувати кількість завдань для спринту;
  3. Якість — наприклад, індекс стабільності вимог, який розраховується за формулою = (Загальна кількість оригінальних бізнес-вимог + Кількість вимог, які змінилися до цього часу + Кількість доданих вимог + Кількість прибраних вимог) / (загальна кількість оригінальних вимог). За допомогою метрики визначається кількість часу, витраченого на перероблення завдань;
  4. Цінності — у кожному випадку прораховується індивідуально, залежно від формату проєкту. Наприклад, стартап AirBnb як метрику, що визначає кінцеву цінність продукту для користувачів, обрала кількість завантажених фотографій високої якості. З їхнім збільшенням пропорційно зростала і кількість споживачів.

До метрик застосовні ті самі правила, що й до інших Agile-інструментів. 

Немає єдино правильної або потрібної вашому проєкту метрики. 

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

 Метрика ради метрики — плохое решение.

Руйнівники міфів: Agile

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

Міф №1: Agile підійде для всіх проєктів.

Найбільш поширена помилка. Жоден метод Agile не додасть сам по собі цінності продукту і не змотивує команду.

Міф №2: Agile проти документації.

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

Міф №3: Agile і планування несумісні.

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

Міф №4: Agile вимагає багато перероблення (re-work).

У гнучкій методології розроблення ПЗ перероблення проявляється у двох формах: перероблення вимог (користувачі розуміють, що їм справді потрібно) і програмного забезпечення (команди розробників знаходять поліпшені способи написати та спроєктувати застосунок). Але з цим доводиться стикатися і в інших методиках! Ба більше, для зменшення негативного впливу rework і потрібна ітераційна модель, яка є особливістю Agile.


Плюси та мінуси використання Agile

Плюси:

  1. залучення стейкхолдерів — у команди з’являється більше можливостей зрозуміти бажання клієнта. А рання і часта доставка ПЗ посилює довіру стейкхолдерів до проєктної команди і ще глибше залучає до проєкту.
  2. рання і передбачувана доставка — модель розробки через ітерації (короткі проміжки від 1 до 6 тижнів) дає гнучкість, прискорює випуск релізу продукту.
  3. фокусування на бізнес-цінності — колаборація з клієнтом забезпечує розуміння командою того, як зробити продукт максимально цінним для споживача.
  4. безперервне поліпшення якості — тестування під час кожної ітерації, розподіл фінального білда на окремі шматки робочого коду дають змогу покращувати і справлятися з помилками ПЗ до виходу фінального продукту.

Минуси:

  • підвищені вимоги до команди і клієнтів — без тісної взаємодії між проєктною командою і користувачами неможливо домогтися виходу якісного продукту з високою цінністю. А велика кількість інструментів і методів в Agile для впровадження вимагає досвідчену команду.
  • не підходить для аутсорсу і проєктів, де учасники взаємодіють один з одним тільки онлайн.
  • ризик ніколи не випустити фінальну версію ПЗ — цей мінус, як не дивно, випливає з ітеративної розробки та безперервного вдосконалення продукту — плюсів Agile.
  • не працює без чіткого бачення бізнес-цілей проєкту — оскільки Agile-команда орієнтується на стейкхолдерів, то без вироблення цілей і концепції продукту розробка неможлива.

Програми​

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

Якщо ваш бізнес належить до маркетингових і рекламних, дизайнерських, seo або digital агентств, то saas-сервіс Worksection можна застосувати для роботи всієї команди цілком. Нас рекомендують COXO Digital, Royal ® Advertising и Prozorro.

Ось кілька лайфхаків, щоб налаштувати Agile у Worksection:

  1. налаштуйте мітки і статуси, які необхідні для роботи саме вашої компанії.
    Статуси можуть бути такими: у роботі, перевірка, виконано, потребує доопрацювання, критично, фіча, оплатити.
    Мітки часто виглядають як: верстка, тестування, продакшен, концепт, код.
  2. створіть проєкт-беклог і проєкт-спринг. 
  3. створюйте завдання і попередні чеклісти, скетчі та інше в беклозі. 
  4. на міт-апах визначайте завдання на спрінг і переносьте їх із беклогу в спринт.
  5. використовуйте гостьовий доступ клієнтів до завдань, щоб завжди мати узгоджені й актуальні коментарі щодо проєкту.
  6. позначайте відповідальних у завданнях, щоб кожен колега знав зону своєї відповідальності та відчував причетність до результату спринту.

Вердикт

З гнучкою методологією розробки програмного забезпечення невеликі проектні команди досягають максимальної ефективності. Agile реалізується через інші гнучкі методи: Scrum, XP, Lean тощо. 

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

esc
Поділитись у
или
Школа PM
Якщо ви зацікавлені в успішному управління проєктами, розуміння RAID стане вам у пригоді. RAID, що є абревіатурою від Risks, Assumptions, Issues, and Dependencies, допомагає керувати ризиками будь-якого...
18 червня 2024   •   22 min read
Школа PM
Гібридна робота – це гнучка модель зайнятості, яка поєднує в собі елементи як віддаленої, так і офісної роботи. За такого підходу працівники мають можливість розподіляти свій робочий час між роботою в...
9 червня 2024   •   23 min read
Школа PM
Підходи «Зверху вниз» і «Знизу вгору» окреслюють, як організації орієнтуються в процесі прийняття рішень та їхнього виконання. Ці підходи розмежовують стилі управління та втілюють різні культури в організаціях...
5 червня 2024   •   11 min read
Почніть роботу прямо зараз
Введіть, будь ласка, свій справжній email 🙂