Хороший план, составленный сегодня, лучше идеального плана, который появится на следующей неделе.
Генерал Джордж Паттон Хотя этот процесс начался намного раньше, официально agile-движение существует с момента принятия Agile-манифеста в феврале 2001 г. (Beck et al.). Манифест был разработан и подписан 17 «идеологами облегченных методологий», как они называли себя в то время. Их документ дал и название проповедуемому ими подходу к разработке программного обеспечения, и заявления о ценностях. Авторы Agile-манифеста писали о том, что для них более значительную ценность имеют:
• люди и взаимодействия, а не процессы и инструменты;
• работающая программа, а не полный пакет документации;
• сотрудничество с клиентом, а не переговоры по условиям контракта;
• реагирование на изменение, а не следование плану.
Agile-команды считают людей и взаимодействия более ценными, чем процессы и инструменты, в силу уверенности в том, что слаженно работающая команда высокопрофессиональных исполнителей с посредственными инструментами при любых обстоятельствах превосходит неработоспособную команду посредственных исполнителей с превосходными инструментами и процессами. Выдающиеся программы создаются выдающимися людьми, и как отрасль мы слишком долго и безуспешно занимались созданием процесса разработки, в котором людям отводится роль взаимозаменяемых винтиков в механизме. Agile-процессы строятся на признании уникальных способностей (и недостатков) отдельных людей и их использовании для извлечения выгоды вместо попыток сделать всех одинаковыми.
Agile-команды считают работающую программу более ценной, чем полный пакет документации, потому что она ведет к получению стабильной, последовательно улучшаемой версии продукта в конце каждой итерации. Такой подход позволяет быстро и часто получать обратную связь от потребителей относительно продукта и процесса. По мере улучшения разработанной программы с каждой итерацией ее можно демонстрировать потенциальным или реальным пользователям. Их отзывы и замечания учитываются в процессе разработки, что позволяет команде всегда работать над наиболее ценными функциями и гарантирует удовлетворение ожиданий пользователей.
Сотрудничество с клиентом ценится выше переговоров по условиям контракта, потому что agile-команды предпочитают вовлекать в работу над общими целями все стороны проекта. Переговоры по условиям контракта иногда заставляют команду разработчиков и клиента проекта занимать непримиримые позиции с самого начала. Мне нравятся игры, и, когда моей старшей дочери исполнилось четыре, я подарил ей «кооперативную игру», поскольку она, на мой взгляд, должна была понравиться и поскольку я понятия не имел, насколько увлекательны кооперативные игры. В купленной мною игре на принцессу было наложено заклятие и игрокам нужно было преодолевать препятствия (ров, наполненный водой, запертая дверь и т. п.), чтобы добраться до принцессы. Игроки делали ходы по очереди, как и в большинстве игр, однако цель заключалась в преодолении препятствий сообща и спасении принцессы. Все либо выигрывали, либо проигрывали. Эта игра очень увлекательна, и нам хотелось бы, чтобы, как и в ней, команды разработчиков программного обеспечения и клиенты подходили к проектам с желанием сотрудничать и двигаться к общим целям. Конечно, без контрактов зачастую не обойтись, однако от контрактных условий и деталей очень сильно зависит, как будут взаимодействовать стороны проекта — на основе сотрудничества или на основе соперничества.
Agile-команды считают реагирование на изменение более ценным, чем следование плану, потому что они заинтересованы в поставке максимально возможной потребительской стоимости клиенту проекта и пользователям. Пользователи никогда, кроме самых простых проектов, заранее не знают во всех деталях, какие именно функции им нужны. Поэтому они неизбежно выходят с новыми идеями, и почти так же неизбежно некоторые функции, которые они считают необходимыми сегодня, оказываются низкоприоритетными завтра. Для agile-команды план является лишь одним из целого ряда возможных представлений о будущем. По мере того как команда приобретает знания и опыт, она учитывает их в плане. Команда может продвигаться в разработке быстрее или медленнее, чем первоначально ожидалось. Не исключено, что какой-то конкретный набор функций понравится пользователям больше, чем ожидалось, а какая-то функция, которая первоначально считалась критически важной, полностью разонравится.
Итак, с учетом четырех заявлений о ценностях Agile-манифеста рассмотрим, что понимается под agile-подходом к проекту и что такое agile-подход к оценке и планированию.
Agile-подход к проекту
Теперь, имея представление о четырех основополагающих заявлениях по agile-ценностям, посмотрим, что представляет собой agile-команда на практике. Четыре заявления по ценностям, взятые в целом, приводят к итеративным и последовательным процессам разработки программного обеспечения, которые позволяют получать работоспособную и протестированную программу в конце каждой итерации. Последующие разделы посвящены основным аспектам работы agile-команд, в том числе:
• работа единой командой;
• работа короткими итерациями;
• поставка какого-либо результата после каждой итерации;
• фокус на бизнес-приоритетах;
• проверка и модифицирование.
Agile-команда работает как единое целое
Критически важно для успеха проекта, чтобы все участники считали себя членами одной команды, имеющей общую цель. В agile-проекте нет места менталитету «самоустранение от участия в дальнейшем процессе после выполнения своей непосредственной задачи». Аналитики не уходят в тень после выдачи требований дизайнерам. Дизайнеры и системные архитекторы не отстраняются от работы после выдачи заданий программистам, а программисты не бросают без поддержки тестировщиков. Успешной agile-команде необходимо мышление «мы все работаем над этим вместе». Хотя agile-команда должна работать как единое целое, в ней есть целый ряд конкретных ролей. Полезно понимать, чтó это за роли и каково их место в agile-подходе к оценке и планированию.
