Найчастіше Agile зустрічається у великих компаніях і не поширений серед фрілансерів, але чи варто фрілансеру використовувати «водоспад»? Ні. Фрілансеру також варто використовувати гнучкі методології проектування і розробки, які допомагають використовувати ітераційну розробку.
Ідея прийшла в рамках основної роботи методологію розробки Agile. Подумав, чому б не застосувати її вечірком, коли в зручному кріслі фрілансю?
Що дає Agile?
- Швидка демонстрація результату клієнту;
- Пред'явлення вимог можливе в будь-який час;
- Ітеративний підхід.
Тобто. мій клієнт побачити початковий результат через 1 спринт, може надати мені вимогу в середині і в кінці розробки проекту і знову висунуті вимоги ніяк не ускладнять і не змінять процес розробки. Тобто. клієнт може «мацати» продукт кожні 2 тижні висуваючи свої рекомендації до подальшого продакшену. Тобто. більшість побажань не вплинуть на терміни і трудомісткість розробки ПЗ.
Це те, що просить клієнт від професійного фрілансера. Як це виглядає в житті.
Отримавши передоплату за проект (без передоплати раджу не ніколи не працювати) беремося за роботу, природно виконуючи процес розробки згідно Agile. Розробляємо «морду» будь-якої сторінки, вішаємо її на схему MVC, робимо посилання клікабельні. Нагадуємо клієнту, що раз на тиждень відбувається оновлення dev версії його сайту і що після кожного перегляду можна надсилати додаткові вимоги або коригування. Отримавши список всіх за і проти, ми дописали в очікуванні від другого спринту (раніше складене нами) і пішли на вихідні. Далі продовжуємо в тому ж дусі.
Чи збіглося те, що ми зробили? Ми отримали швидкий результат, отримали нові вимоги/зауваження, пройшли перший цикл ітерації. Так, ми молодці і йдемо Agile.
І ще: не можна кидати замовника одного. Робота із замовником триває протягом усієї розробки проекту.
Коли замовник каже «я прийду дивитися на готовий результат», я відповідаю: «ось, будь ласка, дивіться початкову версію готового результату і вносьте рекомендації». Тому що найвищим пріоритетом є задоволення потреб замовника, отже, потрібен feedback і отже потрібні нові побажання, нові вимоги, нові рекомендації і потрібні вони не по закінченню розробки, а сьогодні і зараз. Хтось скаже ТЗ опише всі завдання і головне зробити все по ТЗ. На практиці все інакше. Частково ТЗ все опише, а частково все чи правильно зрозуміло і чи все правильно зроблено і чи все, що хотів замовити клієнт, він описав в ТЗ. Або, може, «ту штучку» яку, клієнт тільки що побачив, буде не діставати новенькому ПЗ. Задоволений клієнт - постійний клієнт.
Постійний клієнт - постійний дохід. Тому треба намагатися, щоб кожен клієнт був задоволений і всі його побажання були задоволені.
Уважне ставлення до клієнта і постійна робота завжди розповість про те, що нового побачив клієнт, переживаючи за свій продукт. Що йому не подобається в черговій версії і що йому сподобалося у вашій роботі. Постійний feedback є перше правило з регулярним постачанням нової версії розроблюваного ПЗ.
Пред'являти вимоги до ПЗ можна в будь-який час. Ми постійно отримуємо нові і нові очікування клієнта від його ПЗ, постійно тримаємо «вухо в гостро», оцінюючи разом з клієнтом якість ПЗ і всі очікування. Природно кожна демонстрована версія повинна бути повністю робочою і ефективною.
Продовжуючи розповідь про Agile, варто звернути увагу на якісний контроль. Такий підхід забезпечує Скрам.
Скрам (Scrum) - це набір принципів, на яких будується процес розробки, що дозволяє в жорстко фіксовані і невеликі за часом ітерації, звані спринтами (sprints), надавати кінцевому користувачеві працююче ПЗ з новими можливостями, для яких визначено найбільший пріоритет. Можливості ПЗ до реалізації в черговому спринті визначаються на початку спринту на етапі планування і не можуть змінюватися на всьому його протязі. При цьому суворо фіксована невелика тривалість спринту надає процесу розробки передбачуваність і гнучкість.
Спринт в Agile - це період часу, за який відбувається оновлення результату, тобто той час який ми старанно працюємо ні про що не думаємо. Це тиждень, але можна і від 2 до 4 тижнів.
За результатами кожного спринту проводяться уточнення у вимогах проекту і складається список нових завдань, які будуть розглянуті в наступному спринті.
Використовуючи такий підхід, вже не вийде так, що за оцінюючи кінцевий результат клієнт висуне вимоги, які зачіпають фундамент всього ПЗ, для впровадження яких необхідно перекроювати движок. Це призведе до повної зміни всієї системи, тому що ітераційний підхід призведе до постійного внесення змін і до самого завершення будь-які впровадження будуть марні.
Спринт також є ітерація в скрамі, в ході якої створюється функціональне зростання програмного забезпечення.
Протягом спринту де вимоги не змінюються, якісний контроль є не менш важливим, ніж контроль якості на початку і по завершенні спринту.
Для такого контролю якості проводяться щоденний огляд вчорашнього дня - що зроблено, що викликало труднощі, що викликало проблему. Оглядаючи такі питання і знаходячи на них рішення, призводять до надання якісного ПЗ на завершення спринту. Якісний результат всіх спринтів дасть якісний результат розробки ПЗ - якісне ПЗ.
Що відбувається в житті: щодня проводиться оцінка циклу виконання завдань і вибудовуються плани на наступний міні цикл (спринт довжиною на добу). Тобто. щоранку дивимося, що вийшло вчора і що належить зробити сьогодні, наскільки ми наблизилися до завершення, наскільки наш продукт відповідає вимогам. Після цього продовжуємо роботу. Таким чином, відбувається щоденний самоконтроль, що є добре, тому що самоконтроль виконаних завдань призводить до самоконтролю всього процесу розробки. Завжди є можливість відзвітувати перед замовником, для замовника завжди ж є можливість внести коригування вимог і внести нові вимоги до кінцевого продукту.
У процесі розробки звертайте увагу на проблемно-орієнтований підхід. Також варто звернути особливу увагу на виконання очікувань від ПЗ «точно в строк», розробки через предметну область та розроблення за засобами тестування що рекомендується застосовувати у своїй повсякденній діяльності.
