Agile : іменник чи прикметник ?
“Нє, чуваки у нас аджайл, тому документацію ми не пишемо”
“Давайте докинемо задачі у спринт. Ну і що, що вже середина спринта, ми ж аджайл і мусимо бути готові до змін”
“Не-не, ми тести не пишемо, у нас аджайл”
Знайомо ?
Мені доводилось неодноразово бачити або чути подібні ідеї. Будь який бардак оправдовувати магічним словом Agile. Але чи впевнені Ви, що Agile каже так робити ? Давайте будемо розбиратись
Трохи історії
У 90-тих індустрія розробки ПЗ розвивалась досить стрімко. ПК стали дешеві та доступні, почав з’являтись інтернет. Ну і звісно всім потрібен був софт. Окрім того, що розвивались технології та мови програмування, почали активно розвиватись підходи до розробок. Саме у 90-тих почали з’являтись такі підходи, як Scrum. Були розроблені інженерні практики такі як Extreme Programing, Continues Integration та Test-Driven-Development.
Власне, що означає розроблені — різні команди та люди, під впливом своїх проблем, шукали як би вирішити ці проблеми, і на основі успішних підходів писали свої книги, які зараз стали бестселерами для всіх програмістів по цілому світу.
Якщо глянути на бізнес того часу, то він був доволі бюрократизований та повільний. Для мене яскравим прикладом є методологія RUP. Щоб розібратись у Scrum-і вам потрібно переглянути 5-хвилинний ролик на youtube. Щоб розібратись у RUP — прочитати книгу на 300 сторінок. Багато формальностей, залежностей від менеджменту робило розробку повільною.
Зимою 2001, група відомих програмістів, які багато писали про інженерні практики зібрались на лижах, щоб поїсти, випити пива та поговорити про розробку ПЗ. Результатом цієї зустрічі став Manifesto for Agile Software Development і сам термін Agile Software Development.
Agile Software Development Manifesto
Маніфест маленький — лише 4 рядки.
Люди та співпраця важливіші за процеси та інструменти
Працюючий продукт важливіший за вичерпну документацію
Співпраця із замовником важливіша за обговорення умов контракту
Готовність до змін важливіша за дотримання плану
Цей маніфест описує абстрактні ідеї та немає якихось конкретних вказівок чи обмежень. Для мене це філософія якої варто дотримуватись під час розробки.
Тут немає “Agile — значить не пишемо документацію”, а є — основна цінність працюючий продукт. Якою крутою не була би документація, ваші клієнти очікують робочий продукт. Звісно, документація важлива, але продукт важливіший.
Готовність до змін не означає, що у будь який момент потрібно змінювати плани та задачі. А означає рухатись ітераціями і бути готовим, що через зміну бізнес пріоритетів, змінюються пріоритети розробки. І це ОК, бо бізнес динамічний.
Також існують принципи Agile Software Development. Вони доповнюють маніфест.
До речі, якщо хтось вам скаже, що все це розробки злих менеджерів — основні підписанти цього маніфесту відомі програмісти, такі як Мартін Фаулер, Роберт Мартін та Кент Бек.
Іменник чи прикметник ?
Дейв Томас, один з підписантів Agile маніфесту, має доповідь Agile is Dead. Ідея цієї доповіді, що Agile подається як якась річ чи сутність. Відповідно, Agile як предмет чи сутність є іменником. І її можна продати.
Ми можемо продавати вам трохи Agile.
І ось тут найцікавіше — творці Agile творили не іменник, а прикметник. Не якусь сутність, а зміну існуючого підходу. Software Development став Agile Software Development.
Тобто, ми не можемо взяти Agile як чарівну пілюлю і виправити всі наші проблеми. Натомість ми мусимо робити наш процес гнучкішим та готовим до змін. І це не вийде зробити, сліпо наслідуючи якусь методологію чи іншу пілюлю, яка продається як панацея.
Summary
Для мене Agile Software Development — філософія, яку слід дотримуватись на всіх стадіях проекту. Виправдовувати бардак та відсутність чітких та зрозумілих процесів відмазками у стилі — “у нас еджайл” чи “та то ж скрам” — це ховатись від проблем та не розуміти їх. Ідеї закладені у Agile Software Development є хорошими та актуальними і сьогодні. І так як бізнес дуже швидко розвивається, то будуть актуальні ще довго.
А от з реалізацією цих ідей є проблеми. І переважно вони через відсутність розуміння цих ідей.
P.S.
Дякую, що ви прочитали цю статтю. Я хочу бути максимально корисний Вам і тому, витратьте ще 1 хв на заповнення форми фідбеку. За це вам плюсик у карму !
