Be Agile. Як піти від Waterfall

image

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

Якщо ви все ж зважилися спробувати нове. У цій статті я поетапно розповім як плавно перейти від Waterfall до Agile без втрат, ризиків і порушення основних налаженых процесів роботи.

Вибір проекту для переходу
При виборі проекту потрібно врахувати кілька важливих факторів. А саме:

  • Розмір
  • Ризики
  • Залучення Зацікавлених осіб
Розмір — Проект повинен бути не менше 4х тижнів. Це оптимальний час для формування повноцінного зворотного зв'язку і розуміння самої методології. Оптимальний максимальний розмір проекту — 12 тижнів.

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

Залучення стейкхолдерів. Важливо що б проект було залучено якомога більше учасників. ПМ, Дизайнери, Розробники, Тестувальники, Аналітики… Так само проект повинен проходити через всі стадії розробки. Концепція, Дизайн, Аналіз, Розробка… Дуже важливо зрозуміти всі аспекти впровадження методології і повністю зануритися в неї. Тут важливо отримати зворотній зв'язок від кожного учасника і на кожному етапі.

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

Один з ключових аспектів Agile полягає в тому, що люди і взаємодії між ними вище ніж процеси.

Формування ролей
Наступним етапом буде формування ролей в команді. Ключові ролі в будь Agile команді:

  • Product Owner
  • Scrum Master
  • Development Team
  • Business Analyst або Клієнт (Не зовсім частина команди але важлива частина процесу)
Ці ролі поділяються на 2 групи. Клієнтська сторона і Технічна.
Клієнтська сторона, а саме Product Owner і BA, відповідають за створення вимог до проекту і формують їх у формі користувальницьких історій або user stores. Завдання власника продукту надати«Just enough» інформації для команди розробки, що останні могли почати роботу над продуктом.

«Керування вимогами — окрема дуже велика тема, яка потребує більш глибокого і детального розгляду»

Планування та оцінка
На ранньому етапі відбувається планування «Road Map». Необхідно спланувати завдання з зразковим зазначенням коли кожна користувацька історія буде закінчена. Так як це перший проект в agile — точність не тоб на що варто робити акцент. Головне — акуратність.

Отже, що ж повинно включати в себе планування. Планування складається з частин функціоналу які розбиті на власні історії, і кожна з користувальницьких історій включає в себе певний набір критерій для прийняття функціоналу. Кожна з цих частин є певним «Defenition of Done». Розглянемо кадую з них ближче.

Користувацька історія — инструумент опису функціоналу, відповідає на головні питання: Хто-то що повинен зробити що б чогось домогтися.
Користувацька історія має вигляд:

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

Scenario: Логін

Given: Я на сторінці логіну
And: логін поле має валідні дані
And: пароль поле має валідні дані
When: Я натискаю на кнопку «Login»
Then: Я логинюсь як користувач
And: Стартова сторінка відкривається
Тепер підійдемо до оцінки. Частини функціоналу оцінюються в розмірах. XS, S, M, L, XL. Але оцінка Користувача історії ж оцінюються в порівнянні з іншими справжніми історіями. Вибирається одна користувацька історія до якої визначається час на розробку. Ця ПІ приймається за один поінт і кожна наступна користувацька історія оцінюється в пунктах. Тобто співвідношення більш великої задачі до дрібної.

Спринт планування і спринт
Спринт 0. У цій ситуації спринт 0 — це необхідний захід, який послужить для вирішення багатьох проблем і питань, які можуть виникнути. Сформувати бачення проекту, замовити необхідну для продукту підготувати команду до роботи Agile, визначити розмір спринту.

Розмір спринту — важливе питання для пілотного Agile проекту. Важливо сформувати розмір спринту так, що б у разі спрацювання ризиків у команди було достатньо часу для відновлення.

Планування спринту. Так як всі User Stories написані, оцінені і реліз план складений, настав час для планування спринту. На плануванні обговорюються будь-які нові User Stories, які були додані але не були оцінені. Далі всі історії быдут розбиті на завдання, відповідні Acceptance criterea і все AC будуть оцінені. Оцінені в годинах.

Velocity. Це середня кількість сторі поінтів яка команда здатна заделиверит протягом спринту. На першому спринті у команди velocity відсутня. З цього команда обговорює і вирішує що вона зможе закінчити на 100% протягом спринту і підтверджується командою.

Спринт беклог фіксується і не змінюється.

Оцінка та успіх спринту. Ключові елементи впливають на успіх спринту — це Стенд АП, Взаємодія та Вимірювання.

Щоденне планування — 15 хвилинне захід проводиться командою кожен день в одному і тому ж місці і відповідає на основні питання.

  • Що я робив вчора
  • Що я буду робити сьогодні
  • чи Є у мене якісь проблеми
Взаємодія — Один з найбільш важливих факторів це командна робота та взаємодія кожного чоена команди з кожним. Як свідчить одна частина Agile маніфесту: “Люди і взаємодія важливіше процесів та інструментів..."

Огляд Спринту і Демо
В кінці кожного спринту мають місце бути 2 заходи.

Огляд спринту і Демо — захід на якому обговорюється робота на спринті і прдукт закінчений протягом спринту показується замовнику або клієнту. Збирається зворотній зв'язок від кожного з учасників і за необхідності створюються нові завдання.

По закінченні цих 2х заходів проходить Ретроспектива. Це заходи проводиться для команди і покриває такі моменти як:

  • Що за час спринту ми зробили добре?
  • Що ми могли б покращити?
  • Що ми покращимо в наступному спринті?
І що ж далі? Коли спринти завершені і закінчений продукт. Ретроспектива всього проекту думку команди з приводу нових процесів — одні з найважливіших елементів прийняття рішення.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.