Чи доводилося вам коли-небудь займатися проектами або хоча б брати участь у проектній роботі? Якщо так, то напевно ви помітили, що налагодити роботу команди може бути досить складно. І навіть якщо вона налагоджена, є ризик, що всі зусилля виявляться марними, адже вимоги до необхідного результату часто змінюються.
Однак істотно спростити роботу над проектом і навчитися ним керувати, тим самим підвищивши ефективність команди, можна за допомогою системи гнучкого управління проектами під назвою Agile («Аджайл» або «Еджайл»). Взагалі, ми вже коротко розповідали про неї в нашому курсі з управління проектами (четвертий урок), але зараз поговоримо на цю тему більш детально.
Метод Agile: визначення і коротка історія
Як би незвично це не звучало, але серйозно розробляти програмне забезпечення і керувати проектами почали вже в 70-х роках минулого століття. Саме в 1970 році американський вчений-комп'ютерник Вінстон Ройс склав документ, що називався «Управління розвитком великих програмних систем». У ньому він наводив критику послідовної розробки, вказуючи на те, що розробка програмного забезпечення не повинна бути схожою на роботу складальної лінії (як, наприклад, робиться в автомобільному виробництві), де нові деталі по черзі додаються в послідовні фази.
Замість того щоб чекати, поки будуть по черзі завершені всі етапи (фази), Ройс запропонував застосовувати фазовий підхід. Суть його в тому, що спочатку збираються всі вимоги, необхідні для проекту, після чого завершується вся архітектура, створюється дизайн, записується код тощо.
На основі цього в 90-х вдалося створити комплекс гнучких методів розробки ПЗ, здатних замінити складні і трудомісткі методи. Відбувалося це так:
- У 1991 році з'явився метод швидкої розробки додатків RAD
- У 1994 році з'явився метод розробки динамічних систем DSDM
- У 1995 році з'явилася платформа (фреймворк) гнучкої розробки Scrum
- У 1996 році з'явилася гнучка методологія розробки Crystal Clear, а також екстремальне програмування XP
- У 1997 році з'явилася ітеративна методологія розробки ПО FDD
Всі разом ці методи об'єдналися під загальною назвою гнучких методів розробки ПЗ.
Через чотири роки - 2001 року в штаті Юта (США) на курорті Snowbird зібралися сімнадцять розробників програмного забезпечення. У результаті обговорення методів розробки був опублікований «Маніфест про гнучку розробку програмного забезпечення Agile» (у перекладі з англійської поняття «agile» означає «рухливий», «провірний» або «швидкий», але в більшості випадків його перекладають саме як «гнучкий»). Він і задав темп всій подальшій роботі над створенням ПЗ.
Маніфест Agile
Маніфест, створений програмістами, включає в себе 4 базових ідеї та 12 принципів ефективного управління проектами. Будь-яка з систем управління проектами на основі Еджайл (про системи ми поговоримо пізніше) спирається саме на ці ідеї і принципи, хоча і використовує їх у різних варіаціях.
Ідеї Agile:
- Люди та їх взаємодія важливіші, ніж процеси та інструменти
- Робоче ПЗ важливіше, ніж документація
- Клієнти і співпраця з ними важливіша, ніж контракт і обговорення умов
- Готовність до внесення змін важливіша, ніж початковий план
Принципи Agile:
- Задовольняти клієнтів, завчасно і постійно поставляючи ПЗ (клієнти задоволені, коли робоче ПЗ надходить до них регулярно і через однакові проміжки часу)
- Змінювати вимоги до кінцевого продукту протягом усього циклу його розробки
- Постачати робоче ПЗ якомога частіше (раз на тиждень, на два тижні, на місяць тощо)
- Підтримувати співпрацю між розробниками та замовником протягом усього циклу розробки
- Підтримувати і мотивувати всіх, хто залучений в проект (якщо команда мотивована, вона набагато краще справляється зі своїми завданнями, ніж команда, члени якої умовами праці незадоволені)
- Забезпечувати безпосередню взаємодію між розробниками (можливість прямого контакту сприяє більш успішній комунікації)
- Вимірювати прогрес тільки за допомогою робочого ПЗ (клієнти повинні отримувати тільки функціональне і робоче програмне забезпечення)
- Підтримувати безперервний темп роботи (команда повинна виробити оптимальну і підтримувану швидкість роботи)
- Приділяти увагу дизайну і технічним деталям (завдяки ефективним навичкам і хорошому дизайну команда проекту отримує можливість постійного вдосконалення продукту і роботи над його поліпшенням)
- Намагатися зробити робочий процес максимально простим, а ПО - простим і зрозумілим
- Дозволяти членам команди самостійно приймати рішення (якщо розробники можуть самі приймати рішення, самоорганізовуватися і спілкуватися з іншими членами колективу, обмінюючись з ними ідеями, ймовірність створення якісного продукту істотно зростає)
- Постійно адаптуватися до мінливого середовища (завдяки цьому кінцевий продукт буде більш конкурентоспроможний)
Осягаючи Agile, на додаток до огляду ідей і правил обов'язково ознайомтеся з цим невеликим відео, де фахівець з проектного управління, консультант і бізнес-тренер Олексій Таченков розповідає про основи системи.
Щоб реально здійснити на практиці вищевикладені ідеї та принципи, необхідно дотримуватися кількох правил. Тільки тоді Agile-менеджмент проекту може бути ефективний.
Ключові моменти у застосуванні Agile
Agile-методологія ґрунтується, в першу чергу, на візуальному контролі. Найчастіше учасники проекту, працюючи над досягненням результату, користуються спеціальними кольоровими картками. Один колір сигналізує про завершення планування якогось елемента кінцевого продукту, інший - про завершення його розробки, третій - про готовність і т. п. Візуальний контроль дозволяє команді мати наочне уявлення про поточний стан процесу і гарантує однакове бачення проекту всіма її членами.
Члени команди і клієнт в більшості випадків працюють разом і поруч. Завдяки цьому істотно прискорюються багато робочих процесів, які пов'язані з інформуванням учасників проекту. Крім того, спільна робота сприяє створенню здорової атмосфери для плідної та ефективної співпраці та якнайшвидшого досягнення результатів.
Коли керівник проекту, команда і клієнт діють спільно, виключається небезпека непорозуміння цілей і втрати інформації. Всі робочі процеси стають максимально прозорими, а це означає, що будь-які виникаючі проблеми можна вирішувати практично моментально і знаходити кращі варіанти їх вирішення.
Особливу увагу потрібно приділити керівнику проекту. Його не можна назвати людиною, що роздає вказівки наліво і направо. Керівник тут виступає швидше в ролі лідера, який задає напрямок і визначає правила співпраці і роботи. Іншими словами, Agile-управління є адаптованим.
Ще одним важливим моментом Agile-методології є поділ всього обсягу проекту на кілька дрібніших складових частин. Такий підхід багаторазово спрощує процес розробки, а окремі групи команди можуть фокусуватися кожна на своєму конкретному завданні.
Працюючи над одним циклом, учасники проекту оволодівають новими навичками і отримують нові знання, а також аналізують допущені в процесі помилки. Все це зводить ймовірність здійснення подібних помилок в майбутньому (в наступних циклах та інших проектах) практично до нуля.
І, нарешті, останній значущий елемент підходу - це спринти і щоденні зустрічі. Спринтами називаються обмежені конкретними термінами (дедлайнами) відрізки часу, протягом яких команда встигає виконати певні завдання. Саме завдяки спринтам команда може бачити результати своїх дій.
Якщо ж ми розділимо весь час, відведений на проект, на кілька спринтів, отримаємо конкретну їх кількість; нехай їх буде 15. Кожен спринт триває, наприклад, два тижні. Ось якраз протягом цих двох тижнів (часу, відведеного на спринт) учасники щодня зустрічаються для обговорення процесу і прогресу.
Щоденні зустрічі не повинні перевищувати 15 хвилин. Організовуються вони для того, щоб кожен член команди дав собі ж відповідь на три питання:
- Що я робив вчора?
- Чим я буду зайнятий сьогодні?
- Що заважає мені працювати?
Відповіді на ці питання дозволяють тримати під контролем процес, розуміти, на якій стадії знаходиться кожен з учасників команди, і усувати потенційні проблеми на шляху до мети. Якщо ж узагальнити, то впровадження Agile-методології можливе, якщо дотримується кілька умов:
- Чітко позначається значення проекту
- У процесі реалізації бере активну участь клієнт
- Загальний обсяг робіт виконується покроково
- Орієнтуватися слід на конкретний результат
- Чисельність однієї робочої групи: від 7 до 9 осіб
В даний час проект-менеджмент з підтримкою Аджайл здебільшого поширений в IT-сфері, однак і ділова сфера його починає освоювати. Ця система застосовується в навчанні, маркетингу, бізнесі. Гнучке управління проектами береться на озброєння безліччю компаній і державних структур.
Приклади: уряд Нової Зеландії, уряд Нігерії, Норвезький пенсійний фонд, компанія Return Path (програмне забезпечення), компанія Oreo (виробництво печива), компанія Aviasales (найбільший пошуковик авіаквитків), компанія Hewlett-Packard (найбільша американська IT-компанія), «Сбербанк» (напевно, знаєте, що це).
Ці та багато інших організацій використовують у роботі різні методи управління проектами, засновані на Agile. І поговорити про ці методи не менш важливо, ніж про саму методологію.
Популярні методи керування проектами
Існує чимало методів проект-менеджменту, які застосовуються різними сучасними компаніями. Але найвідомішими і затребуваними серед них по праву вважаються Scrum (Скрам) і Kanban (Канбан).
Метод Scrum
Серед усіх методів системи Agile Scrum відрізняється тим, що робить основний упор на якісний контроль робочого процесу. Японські фахівці зі стратегічного менеджменту Хіротака Такуеті і професор у галузі науково-технічних знань Ікуджиро Нонака, які вперше описали його, називають метод «підходом у регбі», де Scrum є «боротьбою за м'яч».
Метод полягає в тому, що розробка проекту поділяється на спринти, після закінчення яких клієнт отримує поліпшене ПЗ. Спринти суворо фіксуються за часом, і можуть тривати від 2 до 4 тижнів. Робочий процес в одному спринті включає в себе кілька стадій:
- Визначаються обсяги роботи
- Кожен день проводяться 15-хвилинні зустрічі, щоб члени команди могли скоригувати свою роботу і підвести проміжні підсумки
- Демонструються отримані результати
- Спринти обговорюються для пошуку вдалих і невдалих рішень і дій
У більшості випадків Скрам застосовується в роботі зі складним ПЗ і для розробки продукту з використанням інкрементних та ітеративних методів. Завдяки йому серйозно підвищується продуктивність команди і скорочуються тимчасові витрати на досягнення мети.
Scrum покращує результати, допомагає адаптувати проект до змін, забезпечує більш точну оцінку при менших трудовитратах на аналіз і дозволяє ефективніше контролювати етапи роботи і сценарій проекту. Все це якнайкраще відповідає бізнес-цілям.
Метод Kanban
Канбан - ще один метод, що робить командну роботу більш результативною і продуктивною. Сенс його зводиться до надання процесу розробки максимальної прозорості та рівномірного розподілу навантаження серед учасників проекту. Важлива особливість Kanban ще й у тому, що він мотивує людей на постійну співпрацю, вдосконалення та навчання.
Робота за методом Kanban вибудовується на декількох принципах. По-перше, вся інформація про проект повинна бути візуалізована, що дозволяє бачити накладки, помилки і недоліки і активно їх усувати. По-друге, робота над одним завданням повинна вестися одночасно всією командою - це допомагає збалансувати зусилля і отримувані результати, виключає нерівномірний розподіл навантаження. І, по-третє, час на виконання всіх завдань суворо контролюється, завдяки чому оптимізується процес і економиться час.
На відміну від Скрам, Канбан здобув популярність набагато пізніше, але це жодною мірою не применшує його достоїнств і не робить менш ефективним. Метод корисний як в IT-області, так і в бізнес-сфері.
Це лише приклади основних методів управління проектами, заснованих на Agile. Але не варто нехтувати й іншими методами, такими як PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall та інші. До того ж у Аджайл, поряд з перевагами, є і деякі недоліки.
Плюси і мінуси Agile
Спіткаючи Agile, важливо знати як про позитивні, так і про негативні сторони цієї методології. Почнемо з плюсів.
В першу чергу варто відзначити, що Agile-управління дуже гнучке. Якщо, наприклад, традиційна методологія вказує на конкретні етапи роботи, то Еджайл легко підлаштовується під споживача кінцевого продукту і вимоги замовника.
Власне, і в кінцевому продукті число дефектів мінімізується, адже він є результатом ретельної перевірки якості, яка проводиться по завершенні кожного етапу-спринту.
Крім того, Agile швидко запускається, легко реагує на зміни, дозволяє команді розробників і клієнтів підтримувати постійний зв'язок в реальному часі. Переваги очевидні, але давайте поговоримо і про мінуси.
Недоліки методології полягають у тому, що, по-перше, постійний зворотний зв'язок може призводити до того, що весь час буде переноситися і дедлайн проекту, тим самим створюючи загрозу нескінченно триваючої роботи. Якщо замовник бачить, наприклад, тільки результати, але не має уявлення про зусилля, які знадобилися для їх досягнення, він буде весь час вимагати поліпшень.
Другий недолік полягає в необхідності адаптувати під змінювані умови проекту проектну документацію. За відсутності належного інформування команди про зміни або додаткові функції документи з функціональними вимогами або архітектурою можуть виявитися неактуальними на поточний момент часу.
Третім істотним мінусом Аджайл можна назвати необхідність у частих зустрічах. Вони, звичайно, сприяють підвищенню ефективності роботи, але все ж постійне відволікання членів команди може позначитися на процесі негативно, адже увага людей систематично йде в бік від вирішуваних завдань.
Сюди ж можна віднести такі речі як необхідність у постійній присутності клієнта, неможливість вибудовувати довгострокові плани і потребу в мотивованих і висококваліфікованих фахівцях. До речі, останнє величезною мірою стосується і впровадження Agile-управління в діяльність організації. І, осягаючи Agile, з темою її впровадження теж потрібно познайомитися.
Впровадження Agile
Прикладів впровадження Еджайл в роботу компаній є досить багато. І практично всі вони кажуть, що воно потребує цілого комплексу важливих заходів.
Для початку вибирається конкретний метод, що залежить від умов проекту. Потім визначаються завдання і цілі, основний дедлайн і терміни спринтів, чисельність команди та інші складові роботи над проектом. Важливо підібрати метод, що відповідає максимальній кількості вимог.
Як ми і сказали, для впровадження Agile необхідна команда професіоналів. Всі її члени повинні знати базові ідеї та принципи методології і вміти їх застосовувати. Якщо в компанії немає таких людей, співробітників потрібно навчити. Керівництво компанії, яка вирішила перейти до використання Аджайл, також має чітко розуміти, чи готова організація до змін, чи можна застосовувати систему до своїх проектів тощо. Найчастіше, щоб відповісти на ці питання, доводиться звертатися до фахівців з Agile.
На наступному етапі запрошується людина, яка має досвід роботи з системою. Він демонструє її, роз'яснює суть спринтів і дій, функції членів майбутньої команди, особливості взаємодії між ними та інші питання. І тільки після цього формується нова команда, розподіляються ролі, завдання та обов'язки, підбираються інструменти для ведення аналітики, звітності тощо.
Остаточним етапом буде перший досвід з Аджайл, тобто перший проект з його використанням. Потрібно розуміти, що неминучі помилки, недоліки, нестиковки, відставання. Доведеться відмовитися від одних інструментів і замінювати їх іншими, можливо - змінювати ролі між людьми в команді. Перший досвід - це процес адаптації, причому адаптації двосторонньої: компанія звикає до методології, а методологія підлаштовується під компанію.
Ув'язнення
Підсумовуючи цей огляд, нагадаємо, що теорія і практика - це дві різні речі. Нові методики і технології та їх впровадження - це своєрідний виклик команді, і як прийти до більшої ефективності - справа завжди індивідуальна. Agile - це не панацея і не гарантія успіху, але він дозволяє встановити правильний курс і знайти орієнтири на шляху.
Для реалізації будь-якого проекту обов'язково доведеться щось змінювати, шукати нові рішення, генерувати незвичайні ідеї. Лише підлаштовуючись під постійно мінливі умови роботи і вимоги замовників, можна знайти вірні способи дій. І гнучка методологія управління проектами Agile може стати в цій справі вірним помічником.