Agile: оценка и планирование проектов

С учетом представленного выше перечня проблем, связанных с традиционными подходами к планированию, вряд ли можно удивляться неудовлетворительным результатам многих проектов. Процессно-ориентированное планирование отвлекает внимание от функций, которые на деле определяют потребительскую стоимость продукта для клиента. Помимо этого, целый ряд проблем возникает в связи с вероятностью задержки поставок относительно календарного графика, полученного на основе процессно-ориентированного планирования. С самыми благими намерениями участники проектов уповают на многозадачность как возможное решение проблем, однако в конечном итоге еще больше отстают от календарного графика из-за скрытых издержек многозадачности. Когда не удается выдержать график выполнения проекта, исполнители начинают урезáть функциональность. Поскольку работа над функциями ведется в том порядке, который наиболее удобен разработчикам, далеко не всегда в жертву приносятся функции, имеющие наименьшую потребительскую стоимость для пользователей.

Игнорирование неопределенности конечных требований пользователей может приводить к завершению проекта в срок, однако без включения в него значимых возможностей, которые были идентифицированы после принятия плана. Кроме того, игнорирование неопределенности подходов к разработке продукта связано с риском упустить те или иные задачи и не включить их в план проекта. Это, в свою очередь, повышает вероятность задержки проекта, урезания функциональности или неприемлемого снижения качества продукта.

Многие организации путают оценки с обязательствами. Как только команда предоставляет оценку, ее тут же превращают в обязательство.

Вопросы для обсуждения

1. Какие проблемы возникают, если планы составляются на основе видов деятельности, а не на основе поставляемых функций?

2. Существует ли у вас практика отождествления оценки и обязательства? Какие проблемы это влечет? Что можно сделать для изменения ситуации?

3. Как многозадачность влияет на ваш текущий проект? Каким образом можно уменьшить ее влияние?

Глава 3 Agile-подход

Хороший план, составленный сегодня, лучше идеального плана, который появится на следующей неделе.

Генерал Джордж Паттон

Хотя этот процесс начался намного раньше, официально agile-движение существует с момента принятия Agile-манифеста в феврале 2001 г. (Beck et al.). Манифест был разработан и подписан 17 «идеологами облегченных методологий», как они называли себя в то время. Их документ дал и название проповедуемому ими подходу к разработке программного обеспечения, и заявления о ценностях. Авторы Agile-манифеста писали о том, что для них более значительную ценность имеют:

• люди и взаимодействия, а не процессы и инструменты;

• работающая программа, а не полный пакет документации;

• сотрудничество с клиентом, а не переговоры по условиям контракта;

• реагирование на изменение, а не следование плану.

Agile-команды считают людей и взаимодействия более ценными, чем процессы и инструменты, в силу уверенности в том, что слаженно работающая команда высокопрофессиональных исполнителей с посредственными инструментами при любых обстоятельствах превосходит неработоспособную команду посредственных исполнителей с превосходными инструментами и процессами. Выдающиеся программы создаются выдающимися людьми, и как отрасль мы слишком долго и безуспешно занимались созданием процесса разработки, в котором людям отводится роль взаимозаменяемых винтиков в механизме. Agile-процессы строятся на признании уникальных способностей (и недостатков) отдельных людей и их использовании для извлечения выгоды вместо попыток сделать всех одинаковыми.

Agile-команды считают работающую программу более ценной, чем полный пакет документации, потому что она ведет к получению стабильной, последовательно улучшаемой версии продукта в конце каждой итерации. Такой подход позволяет быстро и часто получать обратную связь от потребителей относительно продукта и процесса. По мере улучшения разработанной программы с каждой итерацией ее можно демонстрировать потенциальным или реальным пользователям. Их отзывы и замечания учитываются в процессе разработки, что позволяет команде всегда работать над наиболее ценными функциями и гарантирует удовлетворение ожиданий пользователей.