Непереборна сила зустрічає нерухомий об'єкт: Ітераційні "спринти" Agile порівняно з необхідністю для бізнесу вкладатися в терміни. На перший погляд здається, що ітераційний підхід Agile не підходить для проєктів із жорсткими термінами. Проте на практиці ці два підходи можуть чудово доповнювати один одного, працюючи в гармонії та створюючи потужний мультиплікатор сили.
У цьому блозі ми розглянемо взаємовідносини між Agile-підходами й термінами, опишемо способи їхньої спільної роботи, підтримуючи фокус команд на термінах проєкту, і проілюструємо, як саме ці підходи можуть проявити себе в реальному діловому світі.
Що таке Agile?
Agile – це набір принципів розробки програмного забезпечення, який обертається навколо безперервного доставлення. Це філософія спільної роботи, узгодженої з потоком цінності, яка дає змогу часто постачати невеликі, але функціональні частини програмного забезпечення – зазвичай за кілька тижнів, іноді менше: короткі "спринти" або короткі "ітерації". Це дуже гнучкий і адаптивний підхід протягом усього життєвого циклу розробки.
Традиційна та Agile-розробка програмного забезпечення
Традиційні моделі розробки програмного забезпечення передбачають набагато більше формальних обмежень. Вони зосереджені на детальному плануванні та прогнозуванні, вимоги чітко визначені, комунікації часто формальні та структуровані, а фази планування та доставлення зазвичай більші та триваліші, з чітким поділом та ієрархічною організацією команди.
На відміну від цього, багато з цих обмежень знімаються при використанні Agile-методологій. Замість негнучкої конкретики метою стає швидкість реакції та плинність. Основна увага приділяється тому, щоб якнайшвидше доставити робоче програмне забезпечення задоволеним клієнтам. Agile заохочує привілеї близькості, контакти віч-на-віч і безперервну співпрацю. "Спринти" дають змогу вносити відносно постійні корективи в Agile-проєкт із меншими перебоями. В Agile команди можуть самоорганізовуватися відповідно до проєкту та завдань.
Ось таблиця, в якій порівнюються ці два підходи:
|
Аспект |
Традиційна розробка |
Agile розробка |
|
Структура |
Формальна, жорстка |
Гнучка, адаптивна |
|
Комунікація |
Письмові, формальні зустрічі |
Віч-на-віч, неформальна |
|
Планування |
Довгі, нечасті цикли |
Короткі, часті "спринти" |
|
Організація команди |
Ієрархічна, розділена |
Спільна, самоорганізована |
|
Сфокусованість |
Суворі вимоги, передбачуваність |
Задоволеність клієнтів, адаптивність |
Це порівняння підкреслює чіткі відмінності у підходах та філософії між традиційною та Agile методологіями розробки програмного забезпечення.
Як команда думає про впровадження Agile без довгострокових фіксованих термінів?
Замість того щоб намагатися вкластися в довільні терміни, Agile-команди приділяють більше часу формулюванню цілей і розв'язанню конкретних проблем. Спринти дають змогу командам здобувати поступові перемоги й регулярно випускати частини продукту, які потенційно відвантажуються. Відстежувати прогрес у такій системі стає значно простіше, що дає змогу команді постійно рухатися до завершення проєкту найефективнішим способом.
Agile не відмовляється від термінів повністю, а більш гнучко їх визначає. Короткі спринти дають змогу стримувати раптові зміни або неочікувані проблеми, щоб одне питання не зірвало весь проєкт. Найімовірніше, проблема буде включена в обмежений сегмент роботи, що зробить її розв'язання швидшим і часто простішим. Agile-підхід передбачає зміни та побудований таким чином, щоб приймати та інтегрувати ці нові зміни в міру їх надходження. Завдяки цьому agile-команди легше адаптуються і справляються з новими завданнями.
Реальний сценарій
У реальному світі все ще існують дедлайни, а отже, планування в тій чи іншій формі неминуче. Критична відмінність між традиційним управлінням проєктами та agile-розробкою полягає в тому, як кожен із них справляється із невідворотніми змінами.
Традиційне управління проєктами ґрунтується на тому, щоб якомога більше планувати заздалегідь, оцінювати все, формувати план, а потім виконувати його. У цьому світі зміни – це небажані відхилення. Їх не можна передбачити і кожна з них потребує ретельного документування та управління, оскільки зазвичай може вплинути на графік.
З іншого боку, Agile-розробка ґрунтується на розумінні того, що зміни – це норма, на них слід очікувати та вітати. Терміни, які визначають і надають форму Agile-команді, як правило, великі, коли продукт має бути готовий до симбіотичної маркетингової кампанії або до "чорної п'ятниці" або до вирішальної зустрічі з інвесторами. Команда орієнтується на виконання найважливіших частин. Проте вона зберігає достатню гнучкість, щоб під час проєкту з'являлися нові ідеї, які поліпшать те, що створює команда, і їх можна було інтегрувати. Метою є створити максимальну цінність для клієнта або користувача. У результаті продукт, який команда уявляє собі на початку проєкту, і продукт, який виходить наприкінці, можуть бути мало схожі один на одного, якщо команда реагуватиме на мінливі обставини та потреби.
Утримання команд на плаву та забезпечення ефективності
Agile гарантує, що всі члени команди працюють над однією метою і що розробка йде відповідно до очікувань. Ось більш детальний огляд деяких з його найважливіших практик.
Робочі збори
Щоденні стендап-наради є обов'язковими в багатьох Agile-фреймворках, включно зі Scrum. Кожен день починається з короткого ритуалу, під час якого кожен обговорює, чого він домігся за попередній день і що планує зробити сьогодні. Це допомагає інформує всіх про те, що роблять інші, які ролі необхідно виконати, і підтверджує, що наступний день все ще є частиною спринту. Таким чином, команда може негайно відреагувати на все, що вибивається із графіка спринту.
Стійкий темп роботи
Фундаментальний постулат Agile полягає в тому, що ви маєте працювати стабільно. Agile вимагає стабільної віддачі, а не просто нічого не робити протягом тривалого часу і працювати як божевільний в останні два тижні проєкту. Це ефективно, оскільки ви знаєте, що досягнете результату. Проте, це також сприяє підтримці стабільної якості роботи, а не створенню чогось неякісного, тому що люди, які його створювали, були в стресі та втомилися.
Прозорість
Найважливіші речі видно людям, які виконують роботу. Це означає, що робочий процес та інша інформація, необхідна тим, хто виконує роботу, легко доступна команді. Загальним стандартом ефективної Agile-розробки є те, що робота, яку виконує кожен член команди, має бути видима іншим членам команди.
Передбачуваність
Це допомагає Agile-командам щоразу досягати однакового рівня результативності спринту, що сприяє вирівнюванню довгострокового планування. Така передбачуваність дає змогу менеджеру проєкту точніше оцінити обсяг робіт для кожного спринту і дозволити кожному новому спринту завершитися одночасно. Це полегшує управління Agile-проєктами та підвищує їхню ефективність.
Практики оцінювання
Agile також охоплює інноваційні підходи до оцінювання часу, необхідного для виконання завдань або спринтів, як-от "планування покеру" – кумедна групова вправа, у якій члени команди надають початкові оцінки необхідного часу, діляться своїми думками, що лежать в основі цих оцінок, а потім переглядають їх на основі нової інформації, отриманої під час обговорення. Це робить сам процес оцінювання більш інтерактивним, а також створює основу для того, щоб команди дійшли більш обґрунтованого консенсусу.
Ці практики Agile сприяють створенню атмосфери співпраці та високої продуктивності, необхідної для успіху проєкту в умовах швидкого розвитку та динамічного ландшафту.
Шлях до майстерності Agile
Agile може стати проблемою для команд розробників, які звикли працювати з більш традиційними методологіями. Однак він приносить користь стартапам, які повинні прагнути впровадити його у свою діяльність якомога раніше. Чи то перехід наявної команди на Agile, чи то створення нової з нуля, допомога тих, хто вже пройшов цей шлях, може суттєво змінити ситуацію.