Начать надо с того, что загадочный agile изначально представлял собой лишь гибкий подход к разработке программного обеспечения. Однако этот метод оказался настолько эффективным, что в качестве явления и самобытного понятия стал известен и пригоден далеко за пределами одной лишь узкопрофильной среды.
В России популяризации этого подхода сильно помог Герман Греф. Он не без помощи того самого agile постарался превратить старую колымагу, у которой на ходу отваливались колёса, в нечто, хотя бы примерно напоминающее средство передвижения, пригодное для использования. И мало того, что он тянет из болота этого бегемота, так попутно к этому процессу было подключено столько айтишников, что сегодня банк напоминает собой скорее IT-компанию, нежели привычный в нашем понимании сервис по хранению денег.
Agile стал ответом на крайне неэффективный подход к управлению разработкой ПО, который привыкли называть «водопадным» (это классический метод, когда всё заранее планируется и документируется, пишутся талмуды требований, которые в итоге могут никому и не пригодиться на все 100%). Команда пытается двигаться по этим документам, а тем временем что-то меняется в требованиях или в целях, таким образом, добиться оперативной реакции по факту уже оказывается просто невозможно. В итоге стоимость проекта растет, удовлетворённость заказчиков падает, программисты сидят до ночи в расстроенных чувствах.
Проблема неэффективности управления была настолько актуальной, что даже НАТО в 1968 году на своей конференции для разработчиков сформулировала термин «кризис программного обеспечения». Однако от осознания кризиса до создания новой методологии с того момента пройдёт ещё несколько десятилетий.
Суть agile закреплена в его манифесте «Agile Manifesto»:
1) Люди и взаимодействие важнее процессов и инструментов;
2) Работающий продукт важнее исчерпывающей документации;
3) Сотрудничество с заказчиком важнее согласования условий контракта;
4) Готовность к изменениям важнее следования первоначальному плану.
Вроде бы всё здраво. И кто-то даже скажет — ну и что тут такого, на самом деле? Но те, кто занимается управлением, знают, что тысячи часов и огромные деньги тратятся впустую просто потому, что спущенные сверху планы утрачивают свою актуальность быстрее, чем придумываются новые, а следование плану зачастую превращается не в движение к заявленным целям, а в самый настоящий саботаж. Сколько ресурсов тратится впустую, если заказчик не готов или не способен говорить с командой на одном языке, не дает обратную связь, не конкретизирует свои требования.
В agile важную роль играет «собственник» или «заказчик», то есть тот, кто всегда держит в уме конечную цель. Популярный способ постановки этих целей — «пользовательская история» — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Например, минимальные функции банковской системы могут быть описаны так: проверить баланс счета, перевести средства по реквизитам, пополнить баланс мобильного телефона. Подобная формулировка задач — чёткая и конкретная — экономит силы и деньги. Особую роль в agile, таким образом, приобретают коммуникации внутри команды - например, знаменитые ежедневные брифинги, когда все могут рассказать о трудностях или о своих замечаниях по ходу проекта, чтобы его руководитель мог оперативно подкорректировать план, сэкономив время и деньги.
Всё гениальное вновь оказалось максимально простым и понятным. До такой степени, что применять этот подход можно как на сложных производствах, на которых задействованы десятки и сотни людей, так и в быту. Но для этого потребуется готовность вовремя признавать свои ошибки, умение оперативно реагировать на изменения и смелость брать ответственность на себя.
Автор: Кристина Потупчик