Чи не гнучкий план, а гнучке планування
Методологія agile (гнучка методологія розробки) з’явилася близько 20 років тому. Вона була створена відповідно до міжнародних стандартів проектного менеджменту спеціально для проектів із розробки програмного забезпечення.
Традиційний підхід до планування проекту полягає у поетапній побудові плану, із зазначенням стадій здійснення проекту та дедлайнів. Метод agile відрізняється від цього підходу тим, що орієнтований не так на фінальний узгоджений план, але в сам процес планування.
Всі, хто має досвід роботи в проектному бізнесі, знає, як важко протягом усього життя проекту дотримуватися плану, створеного на початку. Іноді це просто неможливо. Методологія agile враховує цю особливість проектної роботи та налаштовує менеджерів на те, що зміни в плані з урахуванням мінливої обстановки — це не брак плану, а особливість, властива будь-якому проекту. Завдання менеджера — навчитися створювати плани, які можна безболісно змінити, та вміти перетворювати кожну зміну у плані на корисний досвід. Книга Майка Кона побудована на прикладах зі сфери програмного забезпечення, але принципи agile відмінно підходять для будь-яких проектів.
Що таке agile-планування
Оскільки кожен проект — це визначення комплексу дій, які виконуються протягом тривалого часу командою людей, очевидно, що роботу в проекті потрібно планувати. Чим складніший проект, чим більше завдань і людей до нього залучено, тим складніший процес планування.
Тому часто люди або вирішують не витрачати час на планування і діють взагалі без плану, що неминуче призводить до хаосу, зриву термінів та невиконання зобов’язань, або, навпаки, намагаються передбачити кожну деталь, витрачають величезну кількість часу та ресурсів на деталізацію плану, а потім випробовують. стрес і жалкують про витрачений час, коли в ході проекту щось починає йти інакше.
Мета планування – не розписати до дрібних деталей весь список завдань і призначити чіткий час початку та закінчення кожної. Це, в принципі, нереалізовано.
Планування потрібно, щоб:
• оцінити загальний обсяг завдань у проекті , передбачати основні ризики та спробувати їх мінімізувати;
• більш чітко сформулювати кінцеву мету всього проекту;
• налагодити комунікації між усіма учасниками проекту , у тому числі замовниками. План повинен пояснювати всій проектній команді основні завдання проекту, приблизний термін, служити інструментом встановлення взаємної довіри між замовниками та виконавцями. У цьому плані — одночасно технічне завдання і список зобов’язань. Тому особливо важливо, щоб він містив зрозумілу всім інформацію, але водночас давав простір для маневру.
По-справжньому гнучкий план є планом, який легко змінити. При цьому кожна зміна у такому плані — це не катастрофа, а новий інсайт, який залишається в проектній команді, незважаючи на всі зміни.
Саме тому планування важливіше, ніж план. Гнучке планування, а чи не гнучкий план — це основа методології agile.
Основні риси гнучкого планування:
• фокусується на процесі планування, а не на плані як документ;
• дозволяє вносити зміни до плану та заохочує їх;
• призводить до створення планів, які легко змінити;
• поширюється весь проект, а чи не його окремі частини.
Недоліки традиційного планування
Типові плани орієнтовані на список дій, а не на список результатів, що надаються. Широко поширена діаграма Ґантта, яку використовують для побудови більшості планів проектів, розписує конкретні дії членів проектної команди із прив’язкою до календаря. Але насправді замовник очікує від нас не виконання певних дій, а надання певних результатів.
Діаграма Гантта та інші традиційні інструменти мають чітку прив’язку саме до дат. При цьому дії, які має виконати команда, взаємозалежні. Тобто такий план виявляється негнучким: якщо десь відбувається затримка, частина людей простоює, бо їм не передали вчасно роботу, а зсув на одній ділянці призводить до зсуву ланцюжком у всьому плані.
Традиційне мережеве планування не дозволяє пріоритизувати результати. У результаті, якщо терміни зсуваються і проект затягується, команда відмовляється від тих цілей, які вона не встигає виконати, хоча саме вони, можливо, мають більший пріоритет для замовника, ніж ті, що вже виконані.
Мережеве планування не дає простору змін. Це дуже важливо. Замовник не має можливості змінити список цілей проекту, не зруйнувавши весь план. У команди також немає можливості змінити порядок роботи. У результаті такий план, створений ще до початку проекту, перетворюється на зобов’язання, а його зміни стають порушеннями.
Чим планування agile відрізняється від традиційного методу
Agile насамперед базується на іншому наборі цінностей: на людях, а не на процесах, на співпраці, а не на торгівлі, на результатах, а не на плані.
Команда, що працює за принципами agile, підходить до проекту як до спільної роботи , а не як до списку окремих, не пов’язаних один з одним завдань. Така команда прагне досягнення загального результату, а не виконання лише своєї ділянки.
p align=”justify”> Гнучке планування відмовляється від плану як єдиного списку однорівневих завдань або кроків. Мета agile-планування — загальніша, вона полягає в тому, щоб до закінчення проекту досягти тих умов, які ставить замовник. Ці умови полягають у поєднанні властивостей кінцевого продукту, термінів, вартості та якості.
Щоб ці принципи можна було здійснити, методологія agile вводить кілька нових понять.
• Рівні планування . Гнучке планування, на відміну традиційного, відбувається на трьох рівнях: рівень всього проекту, рівень ітерації і рівень робочого дня. На першому рівні формулюється загальна мета проекту. На другому — докладніші завдання для даного відрізку проекту. На третьому – завдання на конкретний день.
• Ітерація – це відрізок проекту, на якому команда має повністю виконати певний шматок роботи. Причому ключовий момент тут у повному виконанні — результат ітерації можна показати замовнику. Якщо йдеться про програмне забезпечення, то результат ітерації — це функціонуючий і вже протестований фрагмент коду.
• Історія користувача — це коротка (в один рядок) пропозиція, що описує одну з вимог замовника. Зазвичай історія виглядає так: «Як , я хочу , щоб ». Одна ітерація в залежності від величини може включати одну або кілька історій.
• Епопея — це поєднання кількох історій користувача, об’єднаних логічно.
• Бали – це одиниця виміру, якою можна виразити розмір історії.
• Ідеальні дні – ще один спосіб виміру історій. Це кількість чистого часу, який команда витрачає на проект.
Оцінка розміру та завдань проекту
У першому розділі ми розглянули чим гнучке планування відрізняється від традиційного. Тепер побачимо, як гнучке планування працює.
Перший крок планування — оцінка обсягу роботи, який має бути виконати за проектом . Зазвичай люди оцінюють роботу за тимчасовою шкалою: проект (ітерація) триватиме 3 місяці (2 тижні).
Наріжний камінь гнучкої методології полягає в тому, що розмір та тривалість проекту – це принципово різні речі. При agile-плануванні ми завжди оцінюємо розмір проекту та обчислюємо його тривалість.
Процес виглядає так. Ми розбиваємо весь проект на історії. Кожній історії надається певний розмір у балах.
Перед вами 10 собак різної породи. Щоб описати їх розмір, ми можемо, наприклад, виділити найменшу з них (припустимо, йоркширського тер’єра), взяти її розмір за одиницю, і описувати інших собак щодо неї: пудель буде втричі більшим, так що його розмір буде 3 бала, вівчарка — у 7 разів більший, тож її розмір — 7 балів тощо. Можна піти іншим шляхом: взяти середню за розміром собаку (сеттера) і присвоїти їй розмір 5, а решту порівнювати з нею. Так само можна оцінювати і користувальницькі історії.
Другий крок – оцінка, з якою швидкістю команда працюватиме. Очевидно, що якщо історію розміром 5 балів команда зможе виконати за 10 днів, то на історію 3 бали їй знадобиться 6 днів. Після цього ми можемо вирахувати тривалість всього проекту.
Швидкість завжди дозволить нам скоригувати будь-які помилки, допущені під час оцінки. Тобто якщо, наприклад, швидкість команди насправді виявилася не 1 балом у два дні, як ми планували, а 1 балом у 3 дні, то ми можемо швидко перерахувати тривалість всього проекту, не зруйнувавши план.
Крім того, якщо це обчислення покаже таку тривалість, яка не влаштує замовника, то завдяки тому, що проект розбитий на історії, ми зможемо запропонувати йому вибрати історії, від яких йому потрібно буде відмовитися, щоб його побажання щодо тривалості проекту були власними. . Цей підхід дає прозорість у взаєминах із закачиком, дозволяє більш точно передбачити для нього кінцевий результат проекту, а також дозволяє вилучити з проекту або додати до нього певну кількість ітерацій, не перебудовуючи весь план цілком.
Окрім балів, історії можна оцінювати в ідеальних днях. На перший погляд це здається простіше, тому командам-початківцям рекомендують дотримуватися цього методу. Суть його в тому, що з 8 робочих годин кожен сотник проводить на проекті, припустимо, 4 години чистого часу. Решту часу в нього зайнято дзвінками, написанням електронних листів, участю в нарадах і т.д. Відповідно, два календарні дні — це один ідеальний день. Ця методологія потребує оцінки швидкості роботи кожного учасника команди окремо.
При цьому не можна забувати, що різниця між ідеальними та календарними днями може бути дуже значною, якщо члени команди задіяні, наприклад, на кількох проектах.
Команди, які працюють за методологією гнучкого планування, планують разом. Дуже важливо, щоб користувальницькі історії оцінювала не людина з боку, а саме виконавець. При цьому всі члени команди розуміють, що гнучке планування за своєю суттю підлягає змінам. Тому вони приділяють час і увагу процесу планування, але не дозволяють цьому забирати занадто багато зусиль. Як правило, найбільш детально плануються найближчі 2 ітерації. Решта, більш віддалена в часі, планується менш детально.
Основні методи оцінки історій користувача:
• Експертна думка (питаємо тих, хто вже працював у схожих проектах, має досвід).
• Аналогія (користуємося власним досвідом у подібних проектах).
• Поділ історії на складові та оцінка частинами.
При оцінці історій можна грати в так званий “оцінний покер” – просити кожного члена команди оцінити історію, а потім озвучити та порівняти всі оцінки.
Якщо в процесі роботи виявилося, що оцінка розміру при плануванні була зроблена неправильно, потрібно провести переоцінку цієї історії, а також інших, розмір яких виводили на її підставі. Тільки так можна отримувати та накопичувати досвід у команді.
При виборі методу оцінки (бали або ідеальні дні) слід враховувати такі фактори:
• Оцінка в балах краще сприяє згуртуванню команди , оскільки вся команда бере участь у оцінці. Коли йдеться про ідеальні дні, кожен оцінює лише свою ділянку роботи.
• Оцінка в балах об’єктивніша , оскільки не повинна враховувати швидкість роботи та завантаженості кожного окремого співробітника.
• Оцінка в балах більш абстрактна та не прив’язується до дат . Психологічно людина схильна дорівнювати оцінку в ідеальних днях до календарних днів.
• Оцінку в ідеальні дні простіше пояснити людям поза командою.
Третій крок – крім оцінки обсягу майбутньої роботи, при плануванні команді необхідно оцінити її суть . Насамперед необхідно пріоритизувати завдання проекту та виділити з них ті, які найбільш важливі для замовника.
Основні фактори пріорітизації завдань:
• Фінансова цінність завдання – тобто скільки прибутку принесе замовнику її впровадження.
• Вартість розробки – необхідно розуміти, що розробка цього завдання не стане надто дорогою для замовника, щоб він зміг окупити витрати на розробку.
• Цінність нової інформації , яку отримає замовник у результаті впровадження завдання.
• Розмір ризиків, яких вдасться уникнути внаслідок завдання.
Як правило, основна мета замовника – отримання прибутку. Він замовляє нам новий продукт, щоб залучити нових клієнтів, або надати нові платні послуги вже існуючим клієнтам, або заощадити гроші за рахунок оптимізації процесів. Тут для пріорітизації, швидше за все, доведеться вдатися до фінансового моделювання. Побудувавши фінансову модель з урахуванням впровадження результатів проекту, можна буде точно порахувати, який прибуток принесе замовнику розробка тієї чи іншої користувальницької історії — і яка, відповідно, більш важлива.
У процесі переговорів із замовником, особливо якщо йдеться про великий проект із значною кількістю історій, завжди важливо виділити більш менш важливі історії.
Градація історій за ступенем важливості:
• Обов’язкові історії – ті, без яких замовник не прийме проект і не вважатиме його виконаним.
• Лінійні історії – такі, які замовник теж хотів би бачити у результаті. Чим більше їх буде, тим краще. Вони доповнюють обов’язкові.
• Бонуси — несподівані для замовника приємні історії, які спочатку не обговорювалися, але які команда може виконати та уявити замовнику, якщо залишиться час і буде технічна можливість.
Історії можуть у процесі проекту кочувати з однієї категорії до іншої, особливо це стосується історій з першої та другої груп, тому дуже важливо тримати постійний зв’язок із замовником та регулярно інформувати його про хід проекту.
Побудова графіка проекту
Як уже говорилося вище, методологія agile передбачає планування роботи на кількох рівнях.
На рівні проекту слід визначити його кінцеву мету. Для замовника ця мета показуватиме, як швидко він зможе почати заробляти на зовнішньому продукті. Залежно від цього він зможе вести своє стратегічне планування.
Для проектної команди кінцева мета — маяк, до якого вона рухається. Важливо, щоб команда знала цю мету і не втрачала її з поля зору.
Щоб сформулювати мету на рівні проекту, потрібно:
• визначити умови задоволеності замовника – терміни, обсяг виконаної роботи, використані ресурси;
• вибрати оптимальну для цього проекту довжину ітерації;
• оцінити швидкість роботи команди;
• пріоритизувати власні історії;
• надати замовнику список історій, які команда зобов’язується виконати, та приблизну дату завершення проекту.
Потрібно регулярно перевіряти та звіряти із замовником актуальність кінцевої мети проекту.
Планування лише на рівні ітерації стає більш детальним, і його необхідно проводити перед початком кожної ітерації. При цьому під час планування важливо уникнути ситуації, коли кожному учаснику проекту просто лунають його завдання. Це повністю руйнує командний дух. Потрібно планувати всю ітерацію повністю, а чи не для кожного учасника індивідуально. Ітерації зазвичай тривають від двох до чотирьох тижнів, тому вони завжди плануються в ідеальному годиннику. Наприкінці кожної ітерації слід також проводити зустріч для оцінки виконаної роботи та отримання уроків на майбутнє.
Планування ітерації може ґрунтуватися або на швидкості (ви до початку ітерації вибираєте таку кількість історій, яка відповідає швидкості роботи команди та обраної довжини ітерації), або на виконанні зобов’язань (ви під час роботи вибираєте історії по одній, залежно від того, скільки у вас залишилося часу до кінця ітерації).
Щоб визначити довжину ітерації, потрібно враховувати:
• Загальну тривалість проекту . Чим він довший, тим довшим може бути довжина ітерації (але не більше 4 тижнів).
• Рівень невпевненості замовника, нечіткості кінцевої мети . Чим вона вища, тим коротшими повинні бути ітерації, щоб замовник якнайчастіше отримував інформацію про те, що вже виконано (але не коротше одного тижня).
• Частота отримання фідбека на зроблену роботу . Що частіше, то краще. Але якщо, наприклад, замовник може зустрічатися з командою лише раз на три тижні — відповідно потрібно планувати ітерації так, щоб до моменту зустрічі надавати черговий результат.
• Комфорт команди . Команда в процесі роботи не повинна бути занадто розслабленою, ні занадто завантаженою.
Коли довжина ітерації вибрана – тримайтеся її і намагайтеся дотримуватись до закінчення проекту. Єдиний виняток – постарайтеся, щоб кінець чергової ітерації не випадав на кінець кварталу – зазвичай це дуже нервовий час у будь-якій організації, і у команди буде додаткове навантаження, а також складно буде отримати фідбек, тому що всі будуть мати інші справи.
Оскільки гнучке планування не ставить собі завдання планувати хід проекту з точністю до дня, необхідно закладати в план буфери. Буфери особливо корисні для тих проектів, де складно сформулювати кінцеву мету або дуже високий ризик серйозних негативних наслідків у разі помилок при плануванні.
Буфери бувають двох видів:
• За завданнями . Щоб створити буфер із завдань, потрібно пріоритизувати історії, як пояснювалося вище, і вирішити, які потрібно виконати обов’язково, а які необов’язково. Необов’язкові історії це і є ваш буфер.
• . _ Щоб обчислити оптимальний тимчасовий буфер, потрібно оцінити розмір історій із ймовірністю 50% та 90% (наприклад, з ймовірністю 50% розмір цієї історії 5 балів, але з ймовірністю 90% вона більша – 7 балів). Потім різницю між цими оцінками для різних історій потрібно підсумовувати та витягти із суми квадратний корінь — так ви отримаєте кількість балів, яку потім потрібно розділити на швидкість — так ви отримаєте тривалість тимчасового буфера.
Важливо вміти пояснити замовнику, як ви прийшли до тієї чи іншої оцінки буфера. Буфери не можна вибирати випадково, тому що ви можете втратити довіру замовника, похитнути його впевненість у надійності вашого планування.
Agile-команда не може бути більшою за 10–12 осіб, інакше буде складно побудувати роботу. Тому, якщо проект вимагає залучення більшої кількості людей, найкраще не поєднувати їх в одну команду, а розбити на кілька команд. Щоб робота в проекті була ефективною, потрібно встановити правила, які будуть дотримуватись усіма командами.
• Ввести єдину систему оцінки: усі команди в одному проекті повинні оцінювати історії або в ідеальних днях або в балах. • Як можна точніше формулювати завдання перед кожною ітерацією та комунікувати їх одне одному, щоб вони не перетиналися. • Потрібно додати до планування буфери, які виникнуть, коли команди виконуватимуть взаємозалежні завдання.
Відстеження та комунікація
Agile дає змогу відстежувати прогрес команди протягом усієї роботи. Такий проект передбачає відкритість комунікації та побудову довіри між командою та замовником, щоб замовник у будь-який момент міг отримати достовірну інформацію про те, на якій стадії проект, та дати фідбек команді.
На рівні проекту відстеження виглядає як загальна інформація про те, де знаходиться команда стосовно дати здачі проекту. Ця інформація виглядає зазвичай або як графік, на якому показано, скільки ще ітерацій чи історій залишилося до завершення проекту, або як шкала, на якій виконана частина роботи і та, яка ще належить, виражені у відсотках.
На рівні ітерації відстеження прогресу потрібне передусім самій команді. Для коротких ітерацій (1-2 тижні) прогрес зручно відстежувати на дошці із завданнями. Це або магнітна, або коркова дошка, розділена на дві частини: виконані та невиконані завдання. Кожне завдання, яке заплановано в ітерації, записується на окремому аркуші паперу. У міру виконання завдання переносяться з одного боку дошки на іншу.
Якщо ітерація довша, ніж 2 тижні, можна використовувати складніші способи: наприклад, такі ж графіки, як відстеження прогресу лише на рівні проекту. Але планування та відстеження мають, перш за все, бути простими і не забирати багато часу.
Що стосується комунікації, важливо пам’ятати три правила: комунікація із замовником має бути частою, чесною та двосторонньою. Потрібно регулярно інформувати замовника про хід роботи та про всі зміни у плані. При цьому замовник повинен розуміти (і потрібно постійно нагадувати йому про це), що планування – це не точна наука, що в плані відбуваються зміни і це норма. Також замовники зазвичай цінують, коли наприкінці кожної ітерації команда з власної ініціативи і без нагадувань пропонує їм короткий звіт про виконану роботу.
10 найкращих думок на одній сторінці
1. Планування методології agile поділяє поняття величини проекту та його тривалості. Величину проекту оцінюють, а тривалість обчислюють.
2. Планування має ґрунтуватися на властивостях кінцевого продукту, які хоче отримати замовник , а не на завдання, які має виконати команда.
3. Планування має відбуватися на трьох рівнях: всього проекту, ітерації та одного робочого дня.
4. Планування – не точна наука, в ході проекту план змінюється кілька разів , і це необхідно пояснювати замовнику.
5. Потрібно постійно відстежувати прогрес і повідомляти замовника, на якому етапі команда.
6. Початковий план потрібно постійно переоцінювати та тримати замовника в курсі змін.
7. При плануванні слід розставляти пріоритети.
8. У плані корисно залишати буфери , не варто планувати зайнятість кожного члена команди на 100%.
9. У процес планування треба включати всю проектну команду.
10. Планування – це інструмент навчання . Будь-яка зміна у плані має перетворюватися на досвід, який можна використати надалі.