Гнучка методологія розробки (від англ. – Agile software development)- маніфест, що визначає спосіб мислення і містить основні цінності та принципи, на яких базується кілька підходів (фреймворків, від англ. framework- каркас, структура) до розробки програмного забезпечення (хоча останнім часом йде тенденція та спроби застосування гнучкої методології розробки до інших напрямів діяльності, не тільки в частині інформаційних технологій), що мають на увазі інтерактивну розробку, періодичного (динамічного) надання (оновлення) вимог від Замовника та їх реалізацію за допомогою робочих груп, що самоорганізуються, сформованих з експертів різного профілю (розробники, тестувальники, впровадженці тощо). Такий переклад Agile, як " гнучка методологія розробки " некоректний т.к. Зазвичай Agile не називають методологією, тоді як підходи з урахуванням даного маніфесту є методології, але з погляду Agile їх називають - фреймворки. На даний момент існує безліч фреймворків (методологій), підходи яких базуються на гнучкій методології розробки, наприклад: Scrum, Extreme programming, FDD, DSDM і т.д.
Визначення з погляду BPM CBoK [від англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile- одна з методологій ітеративної та покрокової розробки ПЗ, на противагу традиційній лінійній методології «водоспад». Методологія гнучкої розробки визначає систему методів проектування, розробки та тестування протягом усього життєвого циклу програмного забезпечення. Методи гнучкої розробки (наприклад, SCRUM) засновані на оперативному реагуванні на зміни за рахунок застосування адаптивного планування, спільного вироблення вимог, раціоналізації крос-функціональних груп розробників, що самоорганізуються, а також покрокової розробки ПЗ з чіткими часовими рамками. Цей підхід використовують у багатьох сучасних проектах розробки комерційного ПЗ.
В основі гнучкої методології розробки лежить ліберально-демократичний підхід до управління та організації праці команд, члени якої сконцентровані розробки конкретного програмного забезпечення.
За рахунок того, що розробка програмного забезпечення із застосуванням гнучкої методології визначає серії коротких циклів (ітерацій), з тривалістю 2-3 тижні, досягається мінімізація ризиків, т.к. після завершення кожної ітерації Замовник приймає результати та видає нові чи коригувальні вимоги, тобто. контролює розробку та може на неї відразу впливати. Кожна ітерація включає етапи планування, аналізу вимог, проектування, розробку, тестування і документування. Зазвичай однієї ітерації недостатньо для випуску повноцінного програмного продукту, але при цьому після закінчення кожного етапу розробки повинен з'являтися "відчутний" продукт або частина функціоналу, яку можна переглянути, потестувати і видати додаткові або коригувальні заходи. На основі виконаної роботи, після кожного етапу, команда підбиває підсумки та збирає нові вимоги, на підставі чого вносить коригування у план розробки програмного забезпечення.
Однією з основних ідей Agile є взаємодія всередині команди і з замовником віч-на-віч, що дозволяє швидко приймати рішення і мінімізує ризики розробки програмного забезпечення, тому команду розміщують в одному місці, з географічної точки зору. Причому в команду входить представник замовника (англ. product owner - повноважний представник замовника або сам замовник, який представляє вимоги до продукту; таку роль виконує менеджер проекту від замовника чи бізнес-аналітик).
Історія випуску Agile маніфесту
«Маніфест гнучкої методології розробки програмного забезпечення» було випущено та прийнято у лютому 2001 року (штат ЮТА США, лижний курорт The Lodge at Snowbird) групою експертів. Даний маніфест визначає 4 основні цінності та 12 принципів для методологій, що базуються на ньому, а також дає альтернативне бачення підходу до розробки програмного забезпечення на відміну від великих та відомих методів та методологій, але не є сам по собі методологією. Зазвичай Agile порівнюють насамперед із " методом водоспаду " ( " waterfall " ), т.к. на момент виходу маніфесту саме "метод водоспаду" був основним при плануванні розробки програмного забезпечення. У розробці та випуску Agile маніфесту брали участь представники таких методологій:
- Adaptive software development (ASD)
- Crystal Clear
- Dynamic Systems Development Method (DSDM)
- Extreme Programming (XP)
- Feature driven development (FDD)
- Pragmatic Programming
- Scrum
Власне, дані методології гнучкої розробки існували і до випуску маніфесту. Сам випуск маніфесту дав новий поштовх до розвитку гнучких методологій, заклав основи, можна сказати конституцію гнучкого підходу до розробки програмного забезпечення.
Agile-маніфест розробки програмного забезпечення:
Основною метрикою agile-методів є робочий продукт. Віддаючи перевагу безпосередньому спілкуванню, agile-методи зменшують обсяг письмової документації проти іншими методами.
Це призвело до критики цих методів як недисциплінованих.
Ми постійно відкриваємо для себе більш досконалі методи розробки програмного забезпечення, займаючись розробкою безпосередньо та допомагаючи іншим. Завдяки виконаній роботі ми змогли усвідомити, що:
- Люди та взаємодія важливіші за процеси та інструменти
- Працюючий продукт важливіший за вичерпну документацію
- Співпраця із замовником важливіша за погодження умов контракту
- Готовність до змін важливіша за проходження початкового плану
Тобто, не заперечуючи важливості того, що праворуч, ми таки більше цінуємо те, що ліворуч.
Автори маніфесту:
Кент-Бек, Мік-Підл, Арі ван Беннекум, Алістайр Кокбурн, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland , Dave Thomas
Основні принципи Agile-маніфесту:
Ми дотримуємося таких принципів:
- Найвищим пріоритетом для нас є задоволення потреб замовника завдяки регулярній та ранній поставці цінного програмного забезпечення.
- Зміна вимог вітається навіть на пізніх стадіях розробки. Agile процеси дозволяють використовувати зміни для забезпечення замовнику конкурентної переваги.
- Працюючий продукт слід випускати якнайчастіше, з періодичністю від кількох тижнів до кількох місяців.
- Протягом усього проекту розробники та представники бізнесу мають щоденно працювати разом.
- Над проектом мають працювати вмотивовані професіонали. Щоб роботу було зроблено, створіть умови, забезпечте підтримку та повністю довіртеся їм.
- Безпосереднє спілкування є найбільш практичним та ефективним способом обміну інформацією як із самою командою, так і всередині команди.
- Діючий продукт - основний показник прогресу.
- Інвестори, розробники та користувачі повинні мати можливість підтримувати постійний ритм безкінечно. Agile допомагає налагодити такий сталий процес розробки.
- Постійна увага до технічної досконалості та якості проектування підвищує гнучкість проекту.
- Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.
- Найкращі вимоги, архітектурні та технічні рішення народжуються у команд, що самоорганізуються.
- Команда повинна систематично аналізувати можливі способи покращення ефективності та відповідно коригувати стиль своєї роботи.
Критика Agile
Agile погано визначає процеси управління вимогами, можна сказати, що таке поняття просто відсутнє т.к. Гнучка методологія розробки не має на увазі під собою довгострокового планування (планування здійснюється на короткострокову перспективу), як наслідок пропущений етап формування плану розвитку товару або іншими словами дорожньої карти товару. Т.к. планування короткострокове (на найближчу ітерацію розробки), а Замовник по закінченні кожної ітерації приймає продукт і виставляє нові вимоги, сам продукт може змінитися в корені, а нові вимоги, що виставляються, часто суперечать структурі та архітектурі продукту вже поставляється клієнтам. За великим рахунком, якщо Замовник не до кінця розуміє, що хоче побачити в результаті (кінцевий продукт), а розуміння приходить під час розробки (це трапляється в 90% випадків), процес розробки перетворюється на формалізовану і легалізовану бюрократію тобто . продукт допрацьовується нескінченно, доки не закінчуються гроші, або замовник не перемикається на інший продукт. Заради справедливості, необхідно помітити, що Замовник знає на що йде і сам вирішує, платити за розробку продукту чи ні, за великим рахунком команда розробників просто виконує вимоги замовника. Однак, реально, у роботі це призводить до хаосу, зриву термінів та авралів, що породжує нові вимоги, які змінюють не на краще продукт. Понад те, знижується якість продукту, т.к. Agile визначає підхід до розробки, в рамках якого необхідно швидко гасити пожежі, найпростішим та найшвидшим способом. Код пишеться не дотримуючись вимог платформи, на якій розробляється продукт, з'являється безліч обхідних рішень та дефектів, а така конструкція не дуже стійка і не безпечна, зростає обурення клієнтів від частих збоїв у роботі програмного забезпечення. Бізнес на виході отримує втрати, знижується якість планування.
Деякі експерти Agile асоціюють більше з підходом щодо вдосконалення готового продукту, ніж розробки нового. Прибічників багато гнучкою методології розробки, так само, як і противників. Останні свого часу навіть випустили Anti Agile Manifesto. Далі в ознайомлювальних цілях, ми наводимо зміст двох найбільш популярних маніфестів, що суперечать основному маніфесу Agile:
Anti-Agile маніфест (необхідно відзначити, що даний anti-agile маніфест насправді суперечить не самому Agile, а скоріше одному з фреймворків, заснованому на принципах Agile - Scrum, тому що в маніфесті використовуються терміни саме з цього фреймворку):
Через нас пройшло безліч консультантів і ми провели величезну кількість годин на зустрічах та нарадах з гнучкої методології. Спираючись на цей досвід, ми зрозуміли, що Agile, це просто запудрювання мозку, тому що:
- епіки (epics) – це просто проекти
- користувальницькі історії (user stories) - це просто сценарії використання (use case)
- спринти (sprints) – це просто робота
- стенд апи (stand-ups) – це просто наради
- ітерації (iterations) – це просто версії
- беклоги (backlogs) – це просто список справ
- швидкість команди (velocity) – це просто результати
- і ці завдання (tasks) – це реально, просто завдання
Таким чином, у той час, коли терміни лівої сторони пропонується розглядати як новаторські, що змінюють підхід до розробки, вони просто є розпливчастими поняттями термінів праворуч.
Різновид методологій гнучкої розробки
На основі цінностей та принципів, визначених в Agile Manifesto, були сформовані такі гнучкі методології розробки:
- Agile Modeling (AM)- даний підхід в основі визначає процедури моделювання (в т.ч. перевірка моделі кодом) і документування в рамках розробки програмного забезпечення. У меншій мірі описані процедури проектування та побудови діаграм на UML. також не порушені галузі розробки, тестування, управління проектом, розгортання та супроводу.
- Agile Unified Process (AUP)- уніфікована версія методології RUP (IBM Rational Unified Process), сформована Скоттом Амблером. AUP визначає модель створення програмного забезпечення у рамках бізнес-додатків.
- Agile Data Method (ADM)- Набір ітеративних методик гнучкої розробки програмного забезпечення, в рамках яких наголошується на формування вимог і рішень за допомогою співробітництва різних крос-функціональних команд.
- Dynamic Systems Development Method (DSDM)- ітеративний та інкрементний підхід, що базується на концепції швидкої розробки додатків - Rapid Application Development (RAD), упор у якому робиться на максимальне залучення кінцевого користувача до розробки програмного продукту.
- Essential Unified Process (EssUP)- підхід, розроблений Іваром Якобсоном (Ivar Jacobson), містить у собі методи ітеративної розробки програмного забезпечення, з упором на архітектуру продукту та напрацьовані практики команди (по суті запозичені з RUP, CMMI та Agile Development). Ідея полягає в тому, що ви використовуєте тільки ті практики та методи, які застосовуються в конкретній ситуації. На основі обраних методів та практик визначається цільовий процес. На відміну від RUP, де всі практики та методи взаємопов'язані, в даному випадку з'являється гнучкість та можливість вичленувати з усього доступного обсягу саме необхідні елементи (методи та практики).
- Extreme programming (XP)- ідея екстремального програмування полягає в тому, щоб використовувати вже існуючі кращі практики в галузі розробки програмного забезпечення, піднявши їх на новий (екстремальний) рівень. Наприклад, на відміну від звичайної практики, коли один програміст послідовно перевіряє написаний код за своїм колегою, в екстремальному програмуванні дана перевірка здійснюється паралельно, що збільшує швидкість випуску продукту, але й ризики теж.
- Feature driven development (FDD)- основне обмеження, яке накладається в рамках даного підходу, це "кожна функція має бути реалізована не більше ніж за два тижні". Тобто. якщо реально розробити функцію за один присід, то це добре, інакше дана функція повинна розбитися на кілька і реалізовуватися поступово.
- Getting Real (GR)- у рамках цього підходу виключені процедури функціональних специфікацій, які використовуються для веб-додатків. Розробка починається від зворотного, спочатку розробляється інтерфейс та дизайн, а потім сама функціональність.
- OpenUP (OUP)- Цей підхід визначає ітеративно-інкрементальний метод розробки програмного забезпечення. Розроблено на основі RUP. У рамках цього методу визначено життєвий цикл розробки (фаза запуску, фаза уточнення, фаза розробки та передачі замовнику). Завдяки певній етапності та контрольних точок, підвищується ефективність контролю та моніторингу ходу реалізації проекту, як наслідок своєчасне прийняття рішень щодо проекту.
- lean software development- Цей підхід заснований на концепції бережливого управління виробничим підприємством (lean production, lean manufacturing).
- Scrum- один із найпоширеніших підходів гнучкої розробки програмного забезпечення, що визначає правила управління процесом розробки із застосуванням існуючих практик розробки. Упор здійснюється на залучення Замовника до процесу (можливість після кожного етапу змінювати або уточнювати вимоги до продукту), що дозволяє вчасно визначити відхилення та внести необхідні зміни.
Методологія Agile - термін, який зараз у всіх на слуху, але що за ним стоїть? Чи є він панацеєю проектного управління, чи це заміна застарілим методам? Чи застосовний він десь, крім IT? Відповіді на ці питання у цій статті.
Що таке Agile
Agile(англ. «Швидкий, кмітливий») - філософія, сукупність гнучких підходів до розробки програмного забезпечення, які стали використовувати для управління проектами. Гнучкі підходи мають на увазі, що продукт створюють в результаті ітерацій, замовник формує вимоги поступово, причому зміни вимог вітаються навіть на пізніх стадіях розробки.Виконання вимог замовника забезпечують робочі групи, які складаються із спеціалістів різного профілю. Ключові ідеї та принципи Agile закріплені у Agile-маніфесті.
«Agile» – це зведення загальних принципів, які є спільними для низки нових методів розробки та управління проектами, таких як SCRUM, екстремальне програмування, Канбан та інших, як протиставлення традиційному бюрократизованому підходу, який часто не відповідає сучасним вимогам. Але, крім того, це маркетинговий термін, парасольковий бренд, для синергії просування гнучких методологій.
Підкреслю, що Agile – це методика, а загальні принципи. Незважаючи на те, що в маніфесті прописано, що Agile – це методологія розробки програмного забезпечення, гнучкі методи можна застосовувати до ширшого кола завдань та її принципи використовуються скрізь, де є висока невизначеність кінцевого результату, критичні терміни та вартість розробки.
Вважається, що методи Еджайлу ефективні для організації праці невеликих груп (які роблять однорідну творчу роботу).
Завантажте та візьміть у роботу:
11. Найкращі вимоги, архітектурні та технічні рішення народжуються у команд, що самоорганізуються. Так вважають автори та підписанти маніфесту, тому в рамках усіх гнучких методик відбувається делегування розробки вимог та рішень на рівень команди. Досягти ефективної самоорганізації дозволяє наявність спільного інтересу та згоду щодо цілей та синергії у досягненні цих цілей спільно.
12. Аналіз та адаптація до умов, що змінюються, постійний пошук способів підвищення ефективності роботи. Це та гнучкість, про яку заявлено в назві підходу і до якої повинні прагнути всі розробники в рамках концепції методології Agile.
Agile SCRUM
SCRUM (читається як «скрам») – термін із регбі, застосований для назви найбільш структурованої на даний момент методики гнучкої розробки Agile. У спорті – це командна та високоінтенсивна дія по досягненню результату – отримання м'яча для наступної атаки, що триває короткий час. Для такої фази гри через її високу травматичність використовуються найкращі та найпідготовленіші гравці команди, а якщо таких гравців з якоїсь причини не вистачає (через видалення, наприклад, чи травми) scrum не проводиться.
У Росії її методологія набуває дедалі більшого поширення. В основі scrum лежать так звані спринти – жорстко фіксовані та невеликі за часом ітерації робіт, протягом яких необхідно розробити та надати кінцевому користувачеві працюючий продукт з новими щодо попереднього спринту можливостями. Тривалість спринту жорстко фіксується, і визначає гнучкість і передбачуваність процесу розробки, чим коротший спринт – тим вища гнучкість і передбачуваність, але підвищується відносна вартість кожної ітерації, також зростають витрати часу на планування та проведення зустрічей із замовником і всередині команди.
Дуже важливим елементом цієї гнучкої методології є беклог продукту (backlog) – список структурованих за ступенем важливості технічних та бізнесових вимог до фінальної версії продукту, з якого беруться завдання для кожного наступного спринту, цей список може поповнюватися в міру реалізації проекту та уточнення параметрів.
Новий функціонал продукту, що розробляється, для чергового спринту визначається на етапі планування, після чого складає беклог спринту (Sprint Backlog), який не змінюється на всьому його протязі.
Методологія передбачає також структуру ролей у проекті:
- Scrum-master – посередник між замовником та командою;
- Product Owner – представник замовника, завдання якого - формувати та пріоритизувати Product Backlog, та приймати проміжні результати спринтів;
- Team – команда проекту, в якій немає окремих ролей, вона є системою, що самоорганізується, з кросфункціональних мотивованих професіоналів.
Навіщо Agile фінансистам
Ключові переваги методології управління проектами Agilw для фінансистів:
- можливість економії коштів на тривалому опрацюванні проектної документації;
- високий рівень контролю за бюджетом (
У сучасному менеджменті "гнучку" модель управління розглядають у трьох різних контекстах, які (кожен по-своєму) і визначають, що таке Agile.
Три обсяги значення Agile
У першому, вужчому значенні, цей термін став з початку 2000-х використовуватися у сфері розробки програмного забезпечення, коли в американському штаті Юта, на гірському курорті, зібралися галузеві фахівці, щоб обговорити методики та практики створення програмних продуктів, затребуваних кінцевим споживачем. Результатом тієї зустрічі став Маніфест (Agile Manifesto) розробки програмних продуктів, з 12-ма принципами, які насамперед стосувалися вузької сфери діяльності авторів, але потенційно могли бути поширені і на деякі інші бізнес-проекти.
У другому, ширшому, значенні терміна принципи Agile застосовуються до ведення майже будь-якого бізнесу і як складові використовуються, наприклад, в концепції «ощадливого стартапу» (Lean Startup). У цьому значенні під Agile-моделлю (Agile Model) розуміють проходження гнучкої методології розвитку проекту, що проходить за характерною схемою за кілька кроків.
- Робота над проектом проводиться ітераціями – короткими циклами (спринтами). (У разі розробки програмного забезпечення тривалість цих циклів становить від 1 тижня до 1 місяця).
- По завершенні кожного циклу виходить продукт, який можна застосовувати у бізнесі. Для програмного забезпечення таким продуктом може стати додаток або лише його частина, проте навіть «сирий» софт вже можна і потрібно пробувати у справі.
- Продукт перевіряється замовником або користувачами, які підтримують з розробниками постійний зворотний зв'язок. Клієнтоорієнтований підхід застосовується протягом усього проекту (всіх ітерацій).
- Будь-які зауваження швидко включаються в доопрацювання, а зміни, що дозволили відразу підправити розробку продукту, – вітаються, оскільки це дозволяє не накопичувати глобальні помилки системи.
У третьому, ще ширшому значенні Agile – це частина моделі управління, що застосовується на заводах «Toyota» і тепер – одна з базових складових менеджменту майже будь-якого успішного виробництва. Основи Agile у цьому контексті схожі на основи розуміння технології в інших контекстах.
Швидкий зворотний зв'язок у налаштуванні кінцевого формату виробництва на заводах «Toyota» забезпечував будь-який робітник, який міг стати ініціатором зупинки конвеєра та автором коригувань з доналаштування виробничого циклу. У масштабах всього виробництва Agile-трансформація може спричинити переналагодження виробничої діяльності в цілому, якщо продукт стає результатом живого відгуку на поточні потреби клієнта. Так, якщо фабрика випускала пластикові тази, а зворотний зв'язок з клієнтом демонструє потребу у відр, то швидка адаптація з паралельним коригуванням нюансів (форми ручки, величини, кольору) буде якраз у стилі Agile management (якщо дотримані й інші принципи).
Принципи Agile-управління
Agile в управлінні проектами як модель управління бізнес-процесом застосовується тисячами команд у всьому світі, і скрізь є такі відмінні риси цього підходу:
- Вирішальне значення для налаштування продукту має споживач і рівень його залучення до створення результату.
- Для ухвалення рішення команди мають бути високоефективними та згуртованими.
- Поетапна та циклічна робота стає основою процесу. Проект поділяється на дрібні частини, які завершуються до певного терміну до завершення проекту загалом.
- Фокус оцінки результативності спрямовано часті уявлення проміжних станів проекту.
- Діяльність колектив спирається на закон Парето, яким 20% зусиль дають 80% ефективності, що дозволяє не доводити кожен окремий цикл до досконалості перед поданням результату споживачеві. Продукт удосконалюється природно з кожною новою ітерацією.
- Передбачається обов'язкове завершення одного етапу перед переходом до наступного.
«Гнучкий» підхід став базовим для цілого ряду методологічних практик, які відрізняються між собою, але включають ідеї Agile: Scrum, Kanban, Lean, Crystal та ін. Методологія Scrum, наприклад, практично завжди розглядаються у зв'язці з Agile як єдина система управління проектами розробка програмного забезпечення.
Метод Scrum демонструє, як «гнучкий підхід» можна застосувати практично у конкретних операціях. Так, наприклад, робота з вимогами щодо проекту реалізується за допомогою чотирьох «артефактів»:
- Product backlog передбачає формування списку вимог, створеного за єдиним шаблоном (User Story) та відсортованого за пріоритетами. Якщо вимоги немає, проект завершується.
- Sprint backlog – це вимоги найближчого спринту (етапу), поділені на завдання без можливості додавати нові вимоги до спринту. Зобов'язання на найближчий етап, взяті командою із типом управління Agile, записуються на дошці (т. зв. Kanban).
- Sprint Goal – загальна мета спринту – орієнтир під час прийняття альтернативних рішень.
- Sprint Burndown Chart - "діаграма згоряння". Вона показує, наскільки просунулась команда протягом етапу.
Формат Agile-управління проектами підходить не всім і не завжди. Державні структури, діяльність яких базується на незмінному законодавстві та консервативна за своїми цілями та реалізацією, не потребують такої оптимізації.
Характерні помилки впровадження Agile та недоліки підходу
Той самий фактор, який вважається в одних випадках сильною стороною підходу, в інших може призводити до виникнення проблем. Так "гнучкість" нерідко стає причиною розмивання фокусу. За відсутності методологічної основи виникає втрата орієнтирів і підміна первинного вторинним. Для запобігання подібним «перекосам» використовують готові методології або власні розробки, що суворо регламентують зміст та послідовність операцій у процесі втілення проекту. Тим не менш, і в цьому випадку в Agile-management можливі помилки.
До поширених помилок застосування належать такі:
При всіх складностях впровадження гнучкого підходу в цілому він ефективніший за традиційні «неповоротливі» виробництва, якщо йдеться про швидке створення нового клієнтоорієнтованого продукту. Поки традиційне виробництво грузне в бюрократичних тяганинах, Agile-підхід забезпечує природний рух відразу після запуску проекту.
Agile - гнучкий підхід до розробки, що включає різні методології (Scrum, Канбан, ХР, Lean та інші). Про це знає багато хто. Але є десятки дрібниць та всяких цікавих штук, які не лежать на поверхні.
Підготували серію статей і для новачків, які з гнучкими методологіями поки що на «ви», і для тих, хто з ними давно товаришує. Розкажемо і про основні поняття (стисло), і про несподіване застосування Agile та Scrum у повсякденному житті. Сьогоднішня стаття - як вступна лекція: про те, що таке Agile і з чим його їдять.
Великий вибух проектів
Якщо провести паралель із зародженням Всесвіту – цю роль відведемо Agile, – тоді Великим вибухом стане проблема номер один, яка довела до нервового зриву не одну сотню менеджерів проектів – зміну вимог до продукту. Саме це – причина стогнань, надривних вигуків «За що мені ця кара?» і порідшали шевелюр.
Зазвичай процеси працюють в рамках каскадної моделі (або waterfall model) – все відбувається поетапно та послідовно. Простіше кажучи, «бачу мету – йду до мети». І якщо певний момент вимоги до продукту, кінцевої мети змінюються, іноді доводиться переробляти заново. Як тільки чудово відточений план стикається з реальністю, він відразу розсипається на порох. Але замість того, щоб викинути у смітник і сам план, і свій підхід до нього, керівники вдають, ніби план працює, і навіть наймають для цього фахівців. По суті вони платять людям за те, що ті їм брешуть.
На думку Джефа Сазерленда, творця Scrum, це нагадує модель поведінки Політбюро ЦК КПРС наприкінці 1980-х років, який нібито вірив звітам, які воно отримувало напередодні катастрофи Радянського Союзу.
Agile-методи покликані боротися з цим за рахунок своєї гнучкості. Можна сміливо сказати, що Agile - збірна солянка кількох підходів, покликана мінімізувати всілякі ризики з допомогою набору принципів. Ці принципи та 4 основні ідеї зібрані в Agile-маніфесті, датованому 2001 роком.
Маніфест Agile
Якщо спростити формулювання, щоб «викристалізувати» міркування, якими керуються всі, хто працює по еджайлу, вийде щось на кшталт цього:
- Найголовніше люди, а не речі
- Документація (яку ще й ніхто не читає) не має нікому заважати працювати
- Співпрацюйте, а не перечитуйте контракт
- Живіть, дихайте, міняйтеся – так швидко, наскільки це можливо
Як влаштовані процеси
Подивимося, як можна працювати за еджайлом. Для прикладу візьмемо Scrum – сьогодні це найпопулярніша гнучка методика. Джефф Сазерленд, автор книги «Scrum», винайшов цю методику, щоб упоратися з вадами класичного управління проектами.
1. Виберіть власника продукту- це людина, яка бачить, до якої мети ви йдете та що хочете отримати у результаті.
2. Визначтеся з командою- від 3 до 10 осіб, які володіють навичками, які дозволять отримати результат (тобто працездатний продукт).
3. Виберіть скрам-майстра- ця людина стежить за перебігом проекту та допомагає команді боротися з труднощами.
4. Складіть беклог продукту- Зберіть в одному місці (бажано на Agile-дошці) всі вимоги до продукту і розставте пріоритети. Власник продукту повинен продумати та зібрати всі побажання. Потім команда повинна оцінити беклог, щоб зрозуміти, чи можливо все це зробити і скільки часу потрібно.
Так виглядає agile-дошка в Яндексі, - .
5. Заплануйте спринти- відрізки часу (тиждень чи два), які команда виконує певний набір завдань. Спринти будуть регулярними: наприклад, 15 разів на два тижні, поки вийде готовий продукт.
6. Проводьте щоденні зустрічі на 15 хвилин (і не хвилиною більше)- на порядку денному три питання, на які коротко відповідає кожен: що робив учора, що робитиму сьогодні і які перешкоди заважають «взяти висоту».
7. Робіть огляди- за підсумками спринту команда розповідає, що вдалося зробити, та демонструє працездатні частини продукту. На огляди може прийти будь-хто: власник продукту, головний замовник або навіть потенційні клієнти.
8. Проводьте ретроспективу- після кожного спринту Agile-команда обговорює проблеми та шукає рішення. Має вийти план змін, який команда одразу ж і впровадить – на наступному спринті.
Докладніше про те, як запровадити скрам і підвищити ефективність команди, читайте у цій статті.
Scrum – це більше, ніж метод командної роботи. Scrum прискорює темпи всіх починань людини. Неважливо, у чому суть проекту чи проблеми, - методика Scrum може бути використана у будь-якому починанні, щоб підвищити продуктивність і досягти кращих результатів.
Знати Agile в обличчя
Agile-методики легко впізнати за ключовими характеристиками, такими собі «сигнальними прапорцями».
- Мінімізація ризиків – це головна мета у межах будь-якого гнучкого підходу.
- Ітеративна технологія - робота в коротких циклах.
- Люди та комунікація – найважливіше.
Якщо розглядати Agile з двох берегів річки – замовника та команди, – такий підхід має сенс для всіх.
- Замовнику потрібно вчасно отримувати хоча б мінімально працездатний продукт (не важливо, йдеться про ПЗ або про інші процеси та явища), змінювати умови, при цьому не залишаючись з діркою від бублика в кишені, - це вже до питання страхування ризиків.
- Команді на руку спілкування із замовником та колегами (щоб без цього: "Ви мене неправильно зрозуміли - переробіть все швиденько. І так, це треба вчора!"), прозорість процесів, що зменшує шанси на несподіванки, швидке вирішення проблем. Ну і багато хто розуміє, куди подіється час і де робота стопориться. Дрібниця (насправді ні), а приємно.
Плюс якісно покращується комунікація усередині команди. Усі фокусуються на спільній ідеї, секретів один від одного немає, кожен бере на себе обіцянку (соціальні зобов'язання – куди без них). Вишенька на торті - можливість працювати в комфортному темпі, нехай і швидкому (як мінімум швидше, ніж зазвичай).
Agile приводить від хаосу до порядку. Проводились дослідження: з'ясувалося, що проекти, де робота велася в рамках гнучкого підходу, втричі успішніша, ніж ті, де процеси вибудовані у стандартній парадигмі. І це виглядає цілком логічним: замовник отримує те, що хоче, і з мінімальними витратами часу та ресурсів.
Кому це може не сподобатися?
З моменту свого виникнення концепція Scrum стала основою проектування нових програмних продуктів для технологічних галузей. Однак, здобувши визнання та успіх у Кремнієвій долині серед керівників проектів зі створення програмного забезпечення та нового обладнання, у спільній діловій практиці Scrum залишається ще маловідомою методологією.
На сьогодні це все. Наступного разу розповімо про скрам скрамів і про те, як гнучкі методології працюють у російській дійсності. Не перемикайтеся.
P.S.Хочете щотижня отримувати корисні поради з найцікавіших книг з бізнесу та маркетингу, дізнаватися про новинки та отримувати знижки? Підписуйтесь на нашу розсилку. У першому листі – подарунок.
- Переклад
«Будь-яка справа завжди триває довше, ніж очікується, навіть якщо врахувати закон Хофштадтера.»
- Закон Хофштадтера
Найбільший ролик на YouTube на тему agile. 744 625 переглядів на час публікації цієї статті. Легкий стиль викладу, картинки та всього 15 хвилин – найкраще що я бачив. TED відпочиває.
Ролі
Це Пет, власник продукту. Вона не знає технічних деталей, зате має бачення загальної картинки, знає, навіщоми робимо продукт, які проблеми він вирішуватиме і для кого.
Це зацікавлені особи. Вони будуть використовувати продукт, підтримувати його або якось ще залучені в розробку.
Це користувальницькі історії. Вони виражені побажання зацікавлених осіб. Наприклад, "у системи бронювання авіаквитків у користувача повинен бути пошук по рейсах".
У зацікавлених осіб багато ідей, і Пет допомагає зробити з ідей користувальницькі історії.
Це команда розробників. Ті, хто буде будуватиробочу систему.
Пропускна здатність
Оскільки команда використовує гнучку методологію розробки, вони не збирають всі ці історії до великого релізу, навпаки, вони випускають їх відразу і якомога частіше. Зазвичай вони випускають 4-6 історій користувача на тиждень. Це їх пропускна здатність. Її дуже просто виміряти - кількість історій користувача за 7 днів.
Для того, щоб підтримувати цей ритм і щоб не зав'язнути у ручному регресивному тестуванні, команда посилено працює над автоматичним тестуваннямта постійною інтеграцією. Тому на кожну фічу доводиться писати автотести, і більшість коду має вбудовані автотести.
Проблема полягає в тому, що зацікавлених осіб дуже багато, і їх запити неможливо задовольнити 4-6 історіями на тиждень.
Щоразу коли ми реалізуємо користувальницьку історію, у них з'являється ще кілька ідей, з яких випливає ще більше запитів.
Що станеться, якщо ми робитимемо все, про що вони нас просять? У нас буде перевантаження.
Припустимо, команда візьметься зробити 10 нових історій за цей тиждень. Якщо на вході 10, а на виході 4-6, то команда буде перевантажена. Поспішатиме, перемикатиметься між завданнями, втрачатиме мотивацію, в результаті знижується продуктивність і якість. Це свідомо програшна стратегія.
Scrum і XP у разі використовують метод “вчорашня погода”. Команда каже: “За останній час ми робили 4-6 фіч на тиждень, які 4-6 фіч ми робитимемо наступного тижня?”
Завдання власника продукту в тому, щоб грамотно вибирати, які саме власні історії будуть реалізовані цього тижня.
Kanban рекомендує обмежитися кількома завданнями – WIP limit. Допустимо команда вирішує, що 5 - це прийнятна кількість історій користувача, над якими вони зможуть працювати одночасно без перевантаження, не перескакуючи з однієї на іншу.
Обидва ці підходи добре працюють і обидва вони створюють чергу завдань, які у Scrum називається Backlog, або пріоритезований список завдань.
Цією чергою теж необхідно управляти. Якщо зацікавлені особи запитують 10 історій на тиждень, а команда реалізує 4-6 історій, то ця черга ставатиме дедалі більше. І незабаром ваш Backlog буде розписаний на півроку наперед. Тобто одна історія чекатиме на вихід 6 місяців.
Є лише один спосіб тримати список завдань під контролем – це слово “ні”
Це найважливіше слово для власника продукту. Він повинен тренувати його щодня перед дзеркалом.
Сказати "так" - легко. Але важливіше завдання - вирішувати, що не треба робитита нести за це відповідальність. Власник товару так само визначає послідовність, що робимо зараз, а що пізніше. Це складна робота і виконувати її слід разом із командою розробки та мінімум однією зацікавленою особою.
Щоб правильно розставити пріоритети, власник продукту повинен розуміти цінність кожної історії та її обсяг.
Прийняття рішень
Деякі історії конче необхідні, а деякі просто бонусні фічі. На розробку одних історій потрібно кілька годин, на розробку інших - місяці.Як співвідноситься розмір історії та її цінність? Ніяк.Більше не означає краще. Цінність та складність завдання – ось що допомагає Пет розставляти пріоритети.
Як власник продукту визначає цінність та обсяг історії? Ніяк.Це гра в угадайку. І краще у ній брати участь усім. Пет постійно спілкується із зацікавленими особами, щоб знати цінність кожної історії, спілкується з командою розробників, щоб знати обсяг робіт, але все це приблизні здогади, жодних точних цифр. Спочатку завжди будуть промахи, і це нормально. Набагато більшу цінність становить спілкування, ніж надточні цифри.
Щоразу коли розробники випускають щось нове, ми дізнаємося більше інформації і можемо краще орієнтуватися.
Однією пріоритезацією недостатньо. Щоб випускати історії швидко та часто, потрібно розбивати на шматочки, які можна зробити за кілька днів. Ми хочемо, щоб на початку воронки були маленькі та чіткі історії, а наприкінці – великі та невизначені. Вчасно робити таку розбивку ми можемо скористатися нашими останніми відкриттями щодо продукту та потреб користувача. Це все називається очищення Backlog.
Пет проводить зустріч з очищення Backlogа щосереди з 11 до 12. Зазвичай на ній збирається вся команда і іноді кілька зацікавлених осіб. Зміст зустрічей буває різним. Фокусування на оцінці, на розбивці історій, на умовах приймання.
Власник ІТ-продукту повинен постійно спілкуватися з усіма.
Матері власники продукту виділяють 2 компоненти успіху: пристрасть до роботи та спілкування. Які завдання власник продукту вирішує на місці з командою.Баланс між складністю розробки та цінністю користувальницької історії
На ранній стадії балансу загрожує невизначеність і кілька ризиків.
Ризики
Бізнес ризик: «Чи правильну річ ми робимо?»Соціальний ризик: "Чи зможемо ми зробити те, що потрібно?"
Технічний ризик: «Чи проект працюватиме на даній платформі?»
Ризики з вартістю та термінами реалізації: «Чи встигнемо і чи вистачить грошей?»
Знання можна як протилежність ризику. Коли невизначеність велика, ми фокусуємося на придбанні знань - прототипах інтерфейсу, технічних експериментах,
Компроміс між цінностями знання та цінностями для клієнта
З погляду замовника крива виглядає так:
З погляду цінності для замовника ця крива має такий вигляд. У міру того, як невизначеності знижуються, ми можемо концентруватися на цінностях для замовника. Ми знаємо, що і як робити. Залишається лише зробити. Після того, як реалізували основні історії, будемо робити бонусні фічі або запускати новий проект.
Компроміс між короткостроковим та довгостроковим мисленням
Що реалізувати насамперед? Терміново усувати помилки або почати розробляти карколомну фічу, яка вразить користувачів. Або робити складний апгрейд платформи, який пришвидшить роботу у майбутньому. Необхідно постійно дотримуватися балансу між реактивною та проактивною роботою.
Робити правильні речі, робити речі правильно чи робити швидко?
В ідеалі – всі три одночасно, але насправді доводиться обирати.
Припустимо, ми тут. Намагаємось створити ідеальний продукт за допомогою ідеальної архітектури. Якщо ми витратимо багато часу, ми можемо не потрапити до «маркетингового вікна» і у нас з'являться проблеми з грошима.
Ми швидко робимо прототип продукту. Для короткострокової перспективи це непогано. У довгостроковій – ми отримуємо технічний ризик. І швидкість розробки зменшиться до нуля.
Ми ось тут, створюємо чудовий храм у рекордні терміни. Але користувачеві не потрібний був храм, йому потрібний був житловий фургон.
Між ролями у Scrum існує здорове протистояння
Власник продукту фокусується на побудові правильних речей. Команда фокусується на будувати речі правильно. Scrum-майстер або agile-тренер фокусується на скороченні циклу зворотного зв'язку.
Окремо варто підкреслити важливість швидкості, так як короткий цикл зворотного зв'язку прискорює навчання. Це дозволяє нам швидше дізнаватися якісь речі правильні і як їх правильно побудувати.
Компроміс між розробкою нового продукту та покращенням старого
Продукт ніколи не може бути повністю завершено, тому що йому постійно потрібні зміни. Коли команда розпочинає роботу над новим продуктом, що відбувається зі старим? Передача продукту від однієї команди до іншої – дуже затратно та ризиковано. Зазвичай, команда підтримує старий продукт, розробляючи новий. Тому скоріше поняття "Backlog" відноситься не до продукту, а до команди. Backlog – це список речей, які хоче власник продукту від команди. І набір історій для різних продуктів. Власник товару необхідно постійно вибирати актуальні для реалізації.
Графік знищення історій
Іноді, зацікавлені особи запитуватимуть у Пет: “Коли випустять мою фічу?” або "Скільки фіч випустять до Різдва?". Власник продукту повинен керувати очікуваннями користувача. І керувати очікуваннями реалістично.
Два тренди - оптимістичний та песимістичний (можна на око). Відстань між трендами показує, наскільки нестабільна швидкість роботи команди. Згодом ці тренди стабілізуються і конус невизначеності зменшуватиметься.
Припустимо, зацікавлена особа запитує, коли ця фіча буде зроблена?
Це питання з фіксованим змістом та невизначеним терміном. Для відповіді Пет використовує дві лінії тренду. Відповідь - у квітні чи травні.
Зацікавлена особа запитує Пет: «Скільки буде зроблено на Різдво?» Це питання з фіксованим терміном та невизначеним змістом. Лінії тренду відсікають на вертикальній шкалі можливий відрізок того, що встигнуть продати.
Зацікавлена особа запитує: "Чи встигнемо ми зробити ось ці фічі до Різдва?" Це питання з фіксованими часовими рамками та фіксованим змістом. Орієнтуючись на тренди, Пет відповідає: Ні. Додаючи: «На Різдво ми встигнемо зробити стільки, а ось стільки часу нам знадобиться щоб завершити всю цю роботу повністю».
Зазвичай краще зменшувати вміст проекту, аніж збільшувати час. Якщо ми зменшуємо зміст, ми матимемо можливість відсунути терміни. Ми можемо випустити дещо тут, а решту – пізніше.
Власник продукту робить розрахунки щотижня та використовує виключно емпіричні дані, а не видає бажане за дійсне. Він чесно говорить про невизначеність. Команда підтримує темпи роботи, а Пет не тисне на них, змушуючи прискоритися.
Завантаження...
