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

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

Так как же все-таки суметь удовлетворить потребности стейкхолдеров и запустить проект создания работающего программного обеспечения?

Реализация проекта

Agile-команды признают, что наиболее важная задача для них – предоставление работающего программного обеспечения для своих клиентов. Вы уже знаете из , как они делают это: работая вместе как команда, сотрудничая со своими клиентами и реагируя на изменения. Но как это воплотить в повседневной работе команды?

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

Первый принцип включает в себя три важные идеи: ранний выпуск программного продукта, непрерывная реализация ценности и удовлетворение клиента. Чтобы понять суть этого принципа, нужно знать, как эти три идеи работают вместе.

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

Так что если вы хотите получать от клиента реальную, обоснованную обратную связь после просмотра рабочего программного продукта, то лучше всего делать это через раннюю поставку: «отгрузить» заказчику первую рабочую версию программного обеспечения как можно раньше. Даже если вы реализовали только одну рабочую функцию, которую клиент может использовать, – это уже победа для команды. Потому что теперь потребитель способен предоставить вам обратную связь, и она поможет двигать проект в нужном направлении. Это также победа для заказчиков, потому что, имея эту рабочую программу, они могут реализовать то, о чем раньше только мечтали. Можно сказать, что команда создала реальную ценность, поскольку ПО работает и клиенты могут его использовать. Пусть это лишь небольшая часть того, в чем нуждается потребитель, но все-таки это «лучше-чем-ничего», особенно если альтернатива этому – расстроенный пользователь, который должен долго ждать, прежде чем получит программный продукт.

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