Agile підхід – що являє собою, як з’явився, плюси і мінуси

У цій статті ми розповімо про основні принципи Agile методології, плюси та мінуси цієї філософії, основні варіанти реалізації.

Термін Agile часто пов’язують із методологією розробки програмного забезпечення. З’явився цей підхід дійсно в IT-середовищі і активно в ньому використовується. Однак модель Agile виявилася досить універсальною та застосовною до робочих процесів у сферах, які не пов’язані з виробництвом IT-продукту.

Що таке Agile – базові ідеї

Аджайл це і методологія, і набір практик, і зведення правил. Кожен із подібних описів буде справедливим. Але на вищому абстрактному рівні Agile — це філософія чи підхід, який має підвищити ефективність певних робочих процесів.

У перекладі з англійської “agile” – гнучкий. Занурюючись у принципи цієї методології, стає очевидним, що найбільш підходящу назву для неї складно підібрати.

В основі гнучкої методології розробки лежить 4 основні пріоритети:

1. Люди та їх комунікація;
2. Діючий продукт;
3. Постійна взаємодія із замовником;
4. Готовність до змін.

Ці чотири ідеї вважаються важливішими, ніж інструменти, написання докладної документації, узгодження умов контракту, чітке дотримання плану. Звичайно, всі ці моменти також мають право на існування. Йдеться про градацію пріоритетів.

У чому суть підходу

Agile методологія, крім ключових ідей, також базується на 12 принципах. Вони, як і чотири головні цінності, описані у спеціальному документі – Аджайл Маніфесті.

Які основні думки закладені в Agile принципах:

• Працюючий стан продукту необхідно забезпечувати, починаючи з ранніх стадій;
• Вимоги можуть активно змінюватись на будь-якому етапі;
• Проєкт має будуватися навколо зацікавлених людей;
• Продукт має бути максимально актуальним та ефективно вирішувати поставлені завдання;
• Необхідно дотримуватися балансу між простими рішеннями та технічною досконалістю;
• Взаємодія із замовником або його представником має відбуватися на регулярній основі.

Виконання рекомендацій, описаних у Agile Manifesto, має забезпечити проєкту можливість постійного тестування та трансформації. Вимоги до продукту можуть змінюватися на тлі дослідження досвіду користувача, тенденцій на ринку тощо. Аджайл враховує цей фактор і у своїй філософії закладає можливість постійних оновлень функціоналу та інших складових.

Дотримуючись гнучкої методології неможливо розробляти компоненти в автономному режимі, а потім їх зв’язувати між собою. На чільне місце ставиться постійне спілкування команд і тісна взаємодія між усіма учасниками процесу. Як правило, робота розбивається на короткі ітерації тривалістю 1-4 тижні. Результатом кожного такого циклу має бути робочий продукт із наміченим приростом функціоналу.

Причини появи методології Agile

Гнучкий підхід до розробки став логічною реакцією перетворення ринку IT. Висока конкуренція та необхідність швидко видавати працюючий продукт поставили під сумнів підвалини, які були актуальними довгі роки. За своєю сутністю підхід Аджайл є антиподом моделі Waterfall, що базується на таких принципах:

• наявність чіткої та докладної документації;
• беззаперечне слідування плану роботи;
• неможливість повернення на попередні етапи з метою змін;
• виявлення та виправлення помилок тільки на етапі тестування.

Довгий час ці постулати були непорушними у сфері IT. Але коли бізнесу стали важливими такі аспекти, як швидкість одержання продукту та можливість його швидкої адаптації під поточні потреби ринку, “закостеніла” та неповоротка методика Waterfall почала різко втрачати позиції.

Документ Agile Manifesto був створений та опублікований у 2001 році. Саме цю подію прийнято вважати стартовим етапом становлення гнучкої методики розробки як базову модель. Тим не менш, до цього моменту вже існували підходи до розробки (наприклад, XP — екстремальне програмування), які не вкладалися у стійку парадигму Waterfall.

• замовник не планує брати активну участь у процесі;
• є необхідність чіткого визначення інструментарію та функціоналу;
• не передбачаються зміни вимог до товару;
• якість результату набагато важливіша, ніж швидкість його отримання.

Плюси та мінуси гнучкого підходу

При використанні Agile вже на початкових етапах є продукт, що працює. Це дає такі переваги:

• тестування на ранніх стадіях;
• можливість оцінки доданого функціоналу “в дії”;
• дослідження досвіду користувача на всіх етапах;
• можливість швидкої презентації на ринку “сирої”, але працюючої версії.

Методологія Agile враховує реалії робочих процесів, не ідеалізуючи їх. Замовники регулярно змінюють свої вимоги, підлаштовуючись під кон’юнктуру ринку та потреби кінцевого користувача. Адаптивний підхід Аджайл передбачає зміни на будь-якій стадії розробки, що дозволяє отримати більш конкурентоспроможний продукт. Гнучка система також є гарним рішенням в умовах невідомості (скільки буде виділено фінансування, які фахівці працюватимуть, скільки знадобиться часу тощо)

За всіх своїх позитивних якостей гнучка модель будівництва робочих процесів не гарантує хороших результатів. Ефективний інструмент важливо правильно використовувати. Якщо ж “перегнути” з гнучкістю, то результат може бути плачевним.

Головні ризики при використанні моделі Agile:

• відсутність чіткого плану розвитку проєкту;
• постійна загроза переробки великої частини роботи;
• зниження якості продукту для швидкості і спрощення.

Працюючи за гнучкою системою розробникам важко визначити мотивацію підтримки високого рівня якості продукту кожному етапі. Якщо є ймовірність, що багато чого може змінитися на наступних ітераціях, немає сенсу доводити до ідеалу поточну версію проєкту. Це цілком логічні міркування, однак “не потрібно доводити до ідеалу” часто легко трансформується в “працює і добре”.

Основні реалізації Agile

Найпоширенішими реалізаціями гнучкої методології Аджайл є Scrum та Kanban. Обидві ці методики дотримуються основних принципів Agile-філософії, але мають відмінні риси.

Scrum передбачає наявність профільних спеціалістів, які працюють над своїми завданнями у рамках спринту (певний проміжок часу від 1 до 4 тижнів). Активну участь бере Product Owner, який забезпечує постійний зв’язок замовника з командою розробників. Координує всі процеси Скрам-майстер. Для філософії Agile Scrum є однією із найпопулярніших реалізацій.

Kanban-підхід також активно використовується аджайл-командами. Основні принципи методики – це прозорість робочого процесу та відстеження виконання завдань у реальному часі. Кожне завдання розташовується на віртуальній чи фізичній Kanban-дошці. У міру зміни статусу завдання вона просувається далі у відповідний стовпець.

Наприклад, життєвий цикл завдання може складатися з таких етапів: у розгляді, у роботі, зроблено, на перевірці, прийнято. За кожним статусом закріплено свій стовпець. Можна наочно оцінити поточний стан конкретної задачі та всього робочого процесу загалом.

Agile – гнучкий інструмент в умілих руках

Підхід до роботи, заснований на філософії Аджайл, сьогодні є базовим для IT-галузі і не тільки. Однак не варто сприймати цю методологію як “чарівну паличку”, яка самостійно налагоджує робочі процеси в компанії. Необхідно грамотно використовувати Agile підхід і намагатися дотримуватися балансу швидкості роботи, рівня якості та залученості замовника. Занадто великий наголос на швидку видачу продукту або прийняття змін, що суперечать архітектурі проєкту, можуть негативно позначитися на результаті.

Розуміння гнучкої методології розробки продукту є гарною підмогою для ефективної діяльності в IT-сфері та суміжних галузях. Існує велика кількість книг з Agile, різноманітних відеоматеріалів та курсів, які допоможуть освоїти цей підхід. Кваліфіковані аджайл-фахівці (наприклад, Scrum-майстри) відіграють важливу роль у створенні продукту та є бажаними співробітниками в IT-компаніях.

Прагнете вивести бізнес на новий рівень, досягати цілей швидше та ефективніше? Apix-Drive — це надійний помічник для цих завдань. Онлайн-конектор сервісів та програм допоможе вам автоматизувати ключові бізнес-процеси та позбутися рутини. Ви та ваші співробітники звільните час для виконання важливих профільних завдань. Спробуйте можливості Apix-Drive безкоштовно, щоб переконатися в ефективності онлайн-конектора особисто.

Спринт в скрамі: міфи, помилки та вигадки

Якщо розробники та менеджери не до кінця розуміють, що таке спринт і нащо він потрібен у скрамі, вони можуть нашкодити проєкту. Тож розбираємось із правильним визначенням спринту, поширеними помилками та способами їх виправлення.

Основне. Що таке спринт у скрамі

Як пишеться в Посібнику зі скраму, спринт — це часовий відрізок тривалістю місяць або менше, протягом якого створюється «готовий», тобто придатний до використання й релізу інкремент продукту. Для ефективної розробки спринти мають мати однакову тривалість. Новий спринт завжди починається відразу ж по завершенню попереднього.

• не допускаються зміни, що можуть поставити під загрозу ціль спринту;
• якість продукту не має знижуватися;
• по мірі появи нових знань, об’єм робіт може уточнюватися і заново узгоджуватися між власником продукту і розробниками.

Спринт як концепція базується на теорії емпіричного управління. Її застосовують, щоб зробити розробку більш передбачуваною і знизити ризики. Три кити теорії емпіризму — прозорість, інспекція й адаптація. Саме інспеція результатів роботи і адаптація їх під потреби користувачів є основою успіху спринту. На жаль, саме ці принципи найчастіше викликають непорозуміння. Замість них команди покладаються на міфи.

Міф перший. Зворотний зв’язок можна часом ігнорувати

Десятиліттями успіх проєктів з розробки вимірювався за допомогою “золотого трикутника менеджера”, тобто за співвідношенням тривалості, вартості й об’єму робіт. Як результат, загинув не один проєкт і народився не один безтолковий продукт: цей трикутник стосується успіху продукту лише опосередковано.

Та як тоді зробити проєкт успішним? Перш за все, пам’ятати про те, що скрам створено для розробки креативних ПРОДУКТІВ (не проєктів).

Головна ціль у застосуванні скраму — створити продукт, що користуватиметься попитом у користувачів і даватиме достатню окупність інвестицій (ROI). Найсерйозніший ризик у розробці — випустити нікому не потрібний продукт. Скрам зменшує цей ризик за допомогою частих циклів зворотного зв’язку. Щоб розробити потрібний продукт, скрам-команда регулярно проводить демонстрації (інспектує інкремент) на оглядах спринту. На цих зустрічах ключові стейкхолдери і кінцеві користувачі працюють з інкрементом продукту. Так ми отримуємо зворотний зв’язок, а власник продукту корегує плани — адаптує беклог продукту, а часом і план релізу.

Спринт без відгуків порушує принципи прозорості, інспекції й адаптації. Тому завжди запрошуйте стейкхолдерів і кінцевих користувачів на огляд спринту.

Міф другий. Спринт провалився, якщо в ньому не вдалося досягти цілей

Оскільки процес у скрамі емпіричний, кожен спринт — це експеримент, у якому трапляються різні випадковості. Це тягне за собою деякі ризики — якраз ці ризики мають знизитися завдяки обмеженням часу.

Кен Швабер у книзі «Софт за 30 днів» (Software in 30 days) так описує випадковості в розробці: «Від початку в нас є бачення чи можливість, якою ми маємо скористатися. Розробники створюють додаток, щоб втілити найважливіші сторони нашого бачення. Ми дивимося на інкремент і починаємо думати, як будемо його використовувати. Ми обговорюємо, що додати, щоб зробити інкремент кориснішим. У деяких дисциплінах це також називається проміжним контролем. Ми проводимо його в кожній ітерації».

Якщо спринт розглядати як експеримент, а скрам — як емпіричний процес, стає зрозуміло:

Проваленим можна назвати спринт, наприкінці якого ми нічому не навчилися. При такому сценарії ми не можемо інспектувати й адаптувати результати роботи, не можемо кастомізувати продукт і процеси.

Багатьом складно прийняти таку концепцію. Ми звикли думати, що успішна команда — це та, котра за один спринт встигає розробити більше фіч. У реальності ж ця більшість виявиться марною, якщо фічі не підлягатимуть інспекції й адаптації.

Команда не виконала цілі спринту, від початку переоцінивши свої можливості і напланувавши забагато. На огляді спринту вона чесно показує замовникам тільки готове, навіть якщо це тільки декілька речей. Вона отримує зворотний зв’язок, яким би він не був. Після цього власник продукту приймає рішення, чи фінансувати наступний спринт. Його рішення може бути як позитивним, так і негативним. Якщо він приймає рішення на користь наступного спринту, то команда йде на ретроспективу, де інспектує себе, свої інструменти і процеси, щоб адаптувати їх у наступному спринті.

Приклад невдалого спринту:

Команда змогла закінчити багато функцій і виконати до огляду спринту все заплановане (завдяки овертаймам і зниженню якості). Та ніхто, крім власника продукту, не прийшов на огляд спринту. Розробники досі не бачать реакції користувачів, а стейкхолдери надто зайняті, щоб ходити на огляди. Немає жодного зворотного зв’язку про інкремент. Якщо так, то можна пропустити і ретро — всі надто зайняті. А тоді — почати новий «успішний» спринт.

Миф третій. Спринт не обов’язково закінчується випуском готового інкременту

Недосвідчені фахівці вважають, що не всі спринти мають закінчуватися створенням готового інкременту. В результаті з’являються різні види «недоспринтів», яких слід уникати. Ось деякі з них.

Спринт нуль

Так називають невеликий відтинок робіт з формування бачення і ескізу беклогу продукту. Це робиться, щоб оцінити час і об’єм роботи до релізу. Відокремлено, такі дії непогані, та лише коли всі причетні розуміють, що отриманий результат змінюватиметься після інспекції в кожному спринті. Так чи інакше, називати прогнозування спринтом не можна, адже це суперечить визначенню спринту в скрамі.

Дизайн-спринт

Такий «спринт» починають, щоб створити технічну архітектуру — посібник для всього наступного релізу. Цей випадок «важчий» за попередній: окрім того, що він не відповідає визначенню спринту, він ще й заважає інспекції й адаптації в наступних спринтах. Знову ж таки, ескізи архітектури й функціоналу можуть бути корисними як частина бачення продукту: так команда уникне ризику і налагодить діалог зі стейкхолдерами. Однак не слід розробляти детальний і фіналізований дизайн процесу.

Жорсткий спринт (Hardening Sprint)

З усіх вільних інтерпретацій спринту ця є потенційно найнебезпечнішою. Концепція прийшла з одного популярного фреймворку, і в його останніх редакціях щодо жорстких спринтів вже є поправки. Ціль такого спринту — отримати готовий до випуску й інтеграції інкремент, який неможливо було отримати раніше. Така постановка питання передбачає, що в результаті інших спринтів можуть виходити неготові інкременти. Так виникає двобічне розуміння прозорості, інспеції й адаптації, а без них команди вже не можуть провести жодного справжнього спринту.

Висновки

• Тим, хто працює за скрамом, потрібно створювати діючі творчі продукти, а не проєкти.
• Кожен спринт — це експеримент. Його результати обов’язково підлягають інспеції й адаптації.
• Якщо результати спринту не можна інспектувати й адаптувати, спринт вважається невдалим.
• У результаті спринту має з’являтися готовий інкремент продукту, а не жорстко визначений план наступних робіт. На цьому базується емпіризм скраму.

Стаття підготовлена за матеріалами й мотивами:

Перекладено й адаптовано командою BrainRain.

Agile, scrum, kanban: у чому різниця і навіщо використовувати?

Agile (agile software development, від англ. agile – моторний) – це сімейство «гнучких» підходів до розробки програмного забезпечення. Такі підходи також іноді називають фреймворками чи agile-методологіями.

Agile виник у IT-середовищі, але потім поширився і на інші сфери – від промислової інженерії до штучного інтелекту.

Сенс Agile сформульований в Agile-маніфесті розробки ПЗ: «Люди та взаємодія важливіші за процеси та інструменти. Працюючий продукт важливіший за вичерпну документацію. Співпраця із замовником важливіша за узгодження умов контракту. Готовність до змін важливіша за дотримання початкового плану».

Agile припускає, що при реалізації проекту не потрібно спиратися лише на заздалегідь створені докладні плани. Важливо орієнтуватися на умови зовнішнього і внутрішнього середовища, що постійно змінюються, і враховувати зворотний зв’язок від замовників і користувачів. Це заохочує розробників та інженерів експериментувати та шукати нові рішення, не обмежуючи себе жорсткими рамками та стандартами.

До окремих agile-підходів відносяться scrum та kanban.

Scrum – це “підхід структури”. Над кожним проектом працює універсальна команда фахівців, до якої приєднується ще двоє людей: власник продукту та scrum-майстер. Перший з’єднує команду із замовником та стежить за розвитком проекту; це не формальний керівник команди, а скоріше куратор. Другий допомагає першому організувати бізнес-процес: проводить загальні збори, вирішує побутові проблеми, мотивує команду та стежить за дотриманням scrum-підходу.

Scrum-підхід ділить робочий процес на рівні спринти – зазвичай це періоди від тижня до місяця, залежно від проекту та команди. Перед спринтом формулюються завдання на спринт, наприкінці – обговорюються результати, а команда починає новий спринт. Спринти дуже зручно порівнювати між собою, що дозволяє керувати ефективністю роботи.

Kanban – це “підхід балансу”. Його завдання – збалансувати різних фахівців усередині команди та уникнути ситуації, коли дизайнери працюють цілодобово, а розробники скаржаться на відсутність нових завдань.

Вся команда єдина – у kanban немає ролей власника продукту та scrum-майстра. Бізнес-процес ділиться не на універсальні спринти, а на стадії виконання конкретних завдань: «Планується», «Розробляється», «Тестується», «Завершено» та інших.

Головний показник ефективності в kanban – це середній час проходження завдання на дошці. Завдання пройшло швидко – команда працювала продуктивно та злагоджено. Завдання затяглося – треба думати, на якому етапі і чому виникли затримки і чию роботу треба оптимізувати.

Для візуалізації agile-підходів використовують дошки: фізичні та електронні. Вони дозволяють зробити робочий процес відкритим та зрозумілим для всіх фахівців, що важливо, коли команда не має одного формального керівника.

У чому різниця між Scrum та Kanban?

Основу Scrum становлять короткі ітерації чи спринти, зазвичай, 2-3-х тижневі. Перед початком спринту команда сама формує список фіч на ітерацію, далі запускається спринт.

Після закінчення спринту виконані фічі заливаються на продакшн, а невиконані переносяться в інший спринт. Як правило, фічі, які робляться під час спринту, не змінюються: що було на старті спринту – має бути зроблено до закінчення спринту.

На Kanban ми подивимося там, де він і з’явився. Уявіть конвеєр, на якому роблять деталі для машин Toyota. Є верстат, він робить дзеркала для машин. Він вміє робити ліві дзеркала, праві дзеркала, задні та дзеркала для сонцезахисного козирка. Принцип простий: натисни на кнопку, поміняй режим — отримай нову продукцію.

Ось ви замовляєте нову Toyota Camry на “максималці”, і для вас уже роблять дзеркала в козирку (ви вибрали “максималку” саме через дзеркала в козирку). Важливий момент, тут ми можемо змінювати пріоритети у будь-який момент. Ми дуже швидко можемо перемикати верстат в інший режим.

Основна різниця між Scrum та Канбан — у довжині ітерацій. У Scrum ітерації – 2 тижні, у Kanban завдання програмісту можна «підсовувати» хоч щодня.

Kanban дає більше гнучкості, якщо під гнучкістю розуміти частоту зміни пріоритетів. Вчора ви залили на прод нову фічу, а сьогодні отримали дані з передової і дізналися, що ця штука не працює так, як було задумано — люди не натискають кнопку «купити». Ви “даєте по шапці” UX, він дає вам нові вимоги. Ви піднімаєте нагору черги це завдання, програміст бере це завдання «згори», виконує його і, до вечора fix вже на продажі, конверсія в платежі зросла на 12%. Це перемога.

У Scrum завдання прийнято оцінювати в Story points або годинах. Без оцінки не вдасться сформувати спринт: нам треба знати, чи встигнемо ми зробити завдання за 2 тижні. Через 2 тижні ми отримуємо цінну статистику — скільки годин чи Story points команда змогла зробити за спринт. Velocity – це продуктивність команди за один спринт. Цей параметр дозволяє Scrum менеджеру передбачити, де команда буде через 2 тижні.

У Kanban не прийнято робити оцінку часу. Це опціонально, команда вирішує самостійно. Тут не має поняття “швидкість роботи команди”, рахується лише середній час, витрачений на виконання задачі. Цей час рахується за допомогою спеціального відліку — Cycle Time.

Cycle Time для задачі = час виконання завдання мінус час початку роботи над завданням. Наприклад, у вас є колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для завдання дорівнюватиме deployed-developing, тобто скільки часу пройшло від моменту, коли завдання почали виконувати, до моменту, поки воно потрапило в deployed.

Отже, у Scrum наша мета – закінчити спринт, у Kanban – завдання.

Scrum – це автобус, який зупиняється лише на певних зупинках, де люди виходять гуртами. А Kanban це маршрутка: захотів пасажир вийти, попросив водія і вийшов там, де йому потрібно.