Історія Agile починається з публікації 2001 року «Маніфесту гнучкого розроблення ПЗ», що складається з 12 принципів. Звісно, окремі положення Agile-підходу з’явилися з’являлися і до цього, але тільки цей документ систематизував і виклав їх достатньою для використання мірою. Щороку під маніфестом підписуються нові компанії, IT-фахівці та проєктні менеджери. З’являються нові методи і модифікації гнучкої системи розробки.
Що таке Agile Methodology (гнучка методологія)?
Agile — ітеративна модель розроблення, у якій програмне забезпечення створюють інкрементально від самого початку проєкту, на відміну від каскадних моделей, де код доставляють наприкінці робочого циклу.
Основа гнучкої методології — розбиття проєктів на маленькі робочі шматочки, звані користувацькими історіями. Згідно з пріоритетністю завдання вирішують у рамках коротких двотижневих циклів (ітерацій).
12 принципів, які складають Agile Methodology, можна поділити на 4 головні ідеї:
- Пріоритет людей і спілкування над інструментами та процесами;
- Пріоритет працюючого продукту над повною документацією;
- Пріоритет співпраці із замовниками над затвердженням контракту;
- Пріоритет готовності змінюватися над дотриманням спочатку створеного плану.
Методи присутні в Agile:
Scrum
Джефф Сазерленд, автор книги «Scrum. Навчись робити вдвічі більше за менший час» виокремив 8 кроків з використання методики:
- Виберіть власника продукту — він знає про мету проєкту та очікуваний результат.
- Зберіть команду — до 10 осіб із необхідними для створення працездатного продукту навичками.
- Знайдіть скрам-майстра — він стежить за перебігом проєкту, допомагає проєктній команді боротися з труднощами.
- Складіть беклог продукту — на Agile-дошці розставте пріоритети за кожною вимогою до продукту. У цьому велику роль відіграє власник продукту, який збирає побажання до продукту для оцінки командою беклогу.
- Заплануйте спринти (ітерації) — відрізки часу на виконання певної низки завдань.
- Організовуйте щоденні п’ятнадцятихвилинні «міт-апи» — ставте по 3 запитання кожному з команди: що робив учора, що буде сьогодні, що заважає виконати завдання.
- Робіть огляди робочих частин продукту — із залученням до перегляду та обговорення стейкхолдерів.
- Проводьте ретроспективу — обговорення проблеми і пошук рішення після кожного спринту. Отриманий план зміни впроваджуєте на наступному спринті.
У скрам є 4 ключові елементи:
- Product Backlog — список вимог за проєктом
- Sprint Backlog — список вимог, які потрібно виконати в найближчий спринт
- Sprint Goal — мета спринту
- Sprint Burndown Chart — діаграма, яка оновлюється в міру завершення завдань. За нею легко зрозуміти динаміку і рівень просування команди в проєкті
eXtreme Programming (XP)
Розробник методики, Кент Бек, створив метод екстремального програмування, мета якого — впоратися з постійно мінливими вимогами до програмного продукту і підвищити якість розробки.
Він може бути застосований виключно у сфері розробки ПЗ, і будується навколо 4 процесів:
- кодування — згідно з єдиними в команді стандартами оформлення;
- тестування — тести пишуться самими програмістами до написання коду, який будуть тестувати;
- планування — як фінального білда, так і окремих ітерацій. Останнє відбувається в середньому раз на два тижні.
- слухання — як розробників, так і клієнта, під час якого зникають незрозумілості, визначаються вимоги та цінності.
Crystal Methodologies
Маловідоме на вітчизняних теренах проєктного менеджменту сімейство методологій, розроблене Алістером Кокберном, одним з авторів «Маніфесту гнучкого розроблення ПЗ». Класифікацію Кокберн пропонує проводити за кольорами за критерієм кількості осіб у команді: від 2 (Crystal Clear) до 100 (Crystal Red). Під більш масштабні проєкти виділено кольори Maroon, Blue і Violet.
Crystal-проєкти мають відповідати 3 основним показникам:
- швидка доставка робочого коду — розвиток ідеї ітеративної моделі розробки Agile.
- досконалість через рефлексію — нова версія ПЗ поліпшується на основі даних про попередню.
- «осмотична» взаємодія — нововведення Алістера, метафора комунікації та обміну інформацією між розробниками ПЗ в одній кімнаті.
Детально сімейство методологій описано в книзі Алістера «Crystal Clear: A Human-Powered Methodology for Small Teams».
Dynamic Software Development Method (DSDM)
Над розробкою DSDM працювала не одна людина і навіть не команда, а консорціум із 17 англійських компаній. DSDM, як і екстремальне програмування, використовується переважно для створення програмного забезпечення.
Особлива роль відводиться участі кінцевого споживача (користувача) в процесі розробки. Крім цього принципу, до базових належать:
- часті випуски робочих версій продукту
- автономність розробників у плані прийняття рішень
- тестування протягом усього робочого циклу.
DSDM ділиться на версії, які оновлюються в міру розвитку технологій, появи нових вимог до розробки ПЗ. Остання на сьогодні — DSDM Atern, випущена 2007 року, хоча попередня (2003 року) ще в строю.
На початку команда вивчає реальність розробки застосунку та сферу застосування. Далі робота ділиться на три взаємопов’язані цикли:
- цикл функціональної моделі — створення аналітичної документації та прототипів.
- цикл проєктування і конструювання — приведення системи в робочий стан.
- цикл реалізації — розгортання системи.
Feature Driven Development (FDD)
Методологія, яка з’явилася навіть раніше, ніж «Маніфест гнучкого розроблення ПЗ».
Хоч у FDD теж застосовується ітераційна модель розробки, від Agile вона відрізняється в такому:
- більше уваги попередньому моделюванню
- підвищена (порівняно з Agile) важливість побудови звітності та графіків
- націлене на корпоративну розробку.
Feature Driven Development складається з таких циклічних етапів:
- Створення загальної моделі — бачення проєкту на основі попередніх даних.
- Розробка списку властивостей — аналог product backlog у методиці скрам.
- Планування за властивостями — оцінка складності властивостей кожним членом команди.
- За кожною властивістю — технічний дизайн і реалізація — фінальна стадія, по закінченню якої властивість йде в продукт і цикл повторюється.
Lean Software Development
Lean Software Development — скоріше не методологія, а набір принципів ощадливого виробництва, який спрямований на підвищення ефективності процесу розробки, мінімізацію витрат.
До набору входять такі 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 визначається шістьма положеннями:
- Дані — основа створення будь-якого застосунку.
- Проблеми з проєктом — їх можна виявити тільки при чіткому розумінні мети та концепції проєкту.
- Робочі групи — крім безпосередньої команди розробників є enterprise groups, які підтримують інші робочі групи.
- Унікальність — немає ідеальної методики, під кожен проєкт потрібно комбінувати інструменти з різних методологій.
- Робота в команді — спільна робота набагато ефективніша, ніж поодинці.
- «Солодка пляма» — пошук оптимального вирішення проблеми («солодкої плями»), уникаючи крайнощів.
Essential Unified Process (EssUP)
Розробка шведського вченого Івара Якобсона, створена для поліпшення Rational Unified Process.
EssUP оперує поняттям практики, до яких входять:
- сценарій використання — опис поведінки системи.
- ітераційна розробка — створення робочих шматків коду короткими циклами в кілька тижнів.
- командні практики — спрямовані на згуртування команди та підвищення її ефективності.
- процесуальні практики — наприклад, «Думай глобально, починай з малого» або «Залучайте стейкхолдерів до бізнес-процесів».
Усі практики в тому чи іншому вигляді зустрічаються в методологіях RUP, CMMI і гнучкій методиці розроблення.
Getting Real (GR)
Ефективна для стартапів і команд-початківців методологія, яка пропонує максимально використовувати особливості невеликих проєктів і компаній: мобільність, гнучкість, пошук нових рішень, відсутність жорсткої заплутаної ієрархії тощо. Джейсон Фрід і Давид Ханссон, засновники компанії 37signals (тепер — Basecamp), визначили Getting Real як систему для розв’язання реальних завдань: максимально просту, зрозумілу і функціональну.
GR — збірна солянка з десятка інструментів гнучкої розробки, які використовуються для мінімізації:
- можливостей
- опцій і налаштувань
- структури компанії
- зустрічей
- обіцянок.
Незвичайна концепція не набула широкого поширення, хоча окремі елементи використовують інші методики.
OpenUP (OUP)
Незалежна від інструментів методологія розробки ПЗ без жорсткої структури, яка містить такі практики:
- вимірювання швидкості роботи команди;
- проведення щоденних зустрічей і ретроспектив по завершенню ітерацій;
- концепція мікрокроків і раннього тестування з використанням чеклистів;
- методика гнучкого моделювання (AMDD).
Практики реалізуються на основі чотирьох принципів:
- узгодження інтересів і досягнення спільного бачення під час спільної роботи
- безперервне вдосконалення через постійний зворотний зв’язок
- фокусування на архітектурі застосунку на ранніх стадіях для мінімізації ризиків
- максимізація цінності для кінцевого споживача.
Agile показники
З огляду на розмаїття інструментів, практик, методів і методологій в Agile, потрібно обрати інструмент, який допоможе визначити ефективність кожного з них. Таким інструментом виступають метрики.
Для більшості проєктів вистачить 4 напрямків метрик:
- Продуктивність — сюди відносяться Velocity і WIP. Перша підійде не для всіх проєктів, оскільки йде вимірюється кількість виконаних завдань за ітерацію, а вони нерівнозначні. Метрика Work-in-Progress визначає ліміт завдань на різних стадіях: і чим він вищий, тим гірше;
- Прогнозування — метрика capacity: визначення кількості ідеальних годин, доступних у наступному спринті. Відповідно, можна зрозуміти, скільки часу є на роботу, наскільки ефективне виконання завдань і як спланувати кількість завдань для спринту;
- Якість — наприклад, індекс стабільності вимог, який розраховується за формулою = (Загальна кількість оригінальних бізнес-вимог + Кількість вимог, які змінилися до цього часу + Кількість доданих вимог + Кількість прибраних вимог) / (загальна кількість оригінальних вимог). За допомогою метрики визначається кількість часу, витраченого на перероблення завдань;
- Цінності — у кожному випадку прораховується індивідуально, залежно від формату проєкту. Наприклад, стартап AirBnb як метрику, що визначає кінцеву цінність продукту для користувачів, обрала кількість завантажених фотографій високої якості. З їхнім збільшенням пропорційно зростала і кількість споживачів.
До метрик застосовні ті самі правила, що й до інших Agile-інструментів.
Немає єдино правильної або потрібної вашому проєкту метрики.
Їх потрібно постійно переглядати, відкидати застарілі та додавати нові в міру необхідності. Вона має бути зрозумілою і доступною всій всій команді, не перетворюватися на самоціль. Метрика заради метрики — погане рішення.
Руйнівники міфів: Agile
Популярність сімейства гнучкої методології розробки зіграла з ним злий жарт, і навіть на спеціалізованих порталах зустрічаються міфи про той чи інший аспект Agile. Будемо розбиратися!
Міф №1: Agile підійде для всіх проєктів.
Найбільш поширена помилка. Жоден метод Agile не додасть сам по собі цінності продукту і не змотивує команду.
Міф №2: Agile проти документації.
Гнучка методологія розробки не проти документації, вона проти документації як самоцілі. А ось при виборі документації як засобу комунікації Agile справді віддає пріоритет живому спілкуванню.
Міф №3: Agile і планування несумісні.
Спростуванням цього міфу слугують денні планування з 10-хвилинними стендапами, ітераційне планування кожні два тижні, спринт-зустрічі тощо.
Міф №4: Agile вимагає багато перероблення (re-work).
У гнучкій методології розроблення ПЗ перероблення проявляється у двох формах: перероблення вимог (користувачі розуміють, що їм справді потрібно) і програмного забезпечення (команди розробників знаходять поліпшені способи написати та спроєктувати застосунок). Але з цим доводиться стикатися і в інших методиках! Ба більше, для зменшення негативного впливу rework і потрібна ітераційна модель, яка є особливістю Agile.
Плюси та мінуси використання Agile
Плюси:
- залучення стейкхолдерів — у команди з’являється більше можливостей зрозуміти бажання клієнта. А рання і часта доставка ПЗ посилює довіру стейкхолдерів до проєктної команди і ще глибше залучає до проєкту.
- рання і передбачувана доставка — модель розробки через ітерації (короткі проміжки від 1 до 6 тижнів) дає гнучкість, прискорює випуск релізу продукту.
- фокусування на бізнес-цінності — колаборація з клієнтом забезпечує розуміння командою того, як зробити продукт максимально цінним для споживача.
- безперервне поліпшення якості — тестування під час кожної ітерації, розподіл фінального білда на окремі шматки робочого коду дають змогу покращувати і справлятися з помилками ПЗ до виходу фінального продукту.
Минуси:
- підвищені вимоги до команди і клієнтів — без тісної взаємодії між проєктною командою і користувачами неможливо домогтися виходу якісного продукту з високою цінністю. А велика кількість інструментів і методів в Agile для впровадження вимагає досвідчену команду.
- не підходить для аутсорсу і проєктів, де учасники взаємодіють один з одним тільки онлайн.
- ризик ніколи не випустити фінальну версію ПЗ — цей мінус, як не дивно, випливає з ітеративної розробки та безперервного вдосконалення продукту — плюсів Agile.
- не працює без чіткого бачення бізнес-цілей проєкту — оскільки Agile-команда орієнтується на стейкхолдерів, то без вироблення цілей і концепції продукту розробка неможлива.
Програми
Для ведення проєктів з Agile підходять далеко не всі сервіси або програми для проєктного менеджменту, адже в кожного є своя специфіка.
Якщо ваш бізнес належить до маркетингових і рекламних, дизайнерських, seo або digital агентств, то saas-сервіс Worksection можна застосувати для роботи всієї команди цілком. Нас рекомендують COXO Digital, Royal ® Advertising и Prozorro.
Ось кілька лайфхаків, щоб налаштувати Agile у Worksection:
- налаштуйте мітки і статуси, які необхідні для роботи саме вашої компанії.
Статуси можуть бути такими: у роботі, перевірка, виконано, потребує доопрацювання, критично, фіча, оплатити.
Мітки часто виглядають як: верстка, тестування, продакшен, концепт, код. - створіть проєкт-беклог і проєкт-спринг.
- створюйте завдання і попередні чеклісти, скетчі та інше в беклозі.
- на міт-апах визначайте завдання на спрінг і переносьте їх із беклогу в спринт.
- використовуйте гостьовий доступ клієнтів до завдань, щоб завжди мати узгоджені й актуальні коментарі щодо проєкту.
- позначайте відповідальних у завданнях, щоб кожен колега знав зону своєї відповідальності та відчував причетність до результату спринту.
Вердикт
З гнучкою методологією розробки програмного забезпечення невеликі проектні команди досягають максимальної ефективності. Agile реалізується через інші гнучкі методи: Scrum, XP, Lean тощо.
Її неможливо реалізувати з наскоку, недосвідченою командою, за короткий проміжок часу, але впровадження Agile поліпшить взаємодію між IT і бізнесом, прискорить вихід продукту на ринок, підвищить цінність продукту для кінцевого користувача.