кажется невероятным! Но ради нашего воображаемого эксперимента попробуйте поверить, что так и произошло.) Каждое требование в спецификации реализовано, протестировано и исполнено. Команда очень гордится собой, и все заинтересованные стороны согласны, что получили именно то, что просили.
Итак, продукт выходит на рынок… и его ждет провал. Никто не покупает книгу, стейкхолдеры недовольны. Что же произошло?
Оказывается, ПО, актуальное всего полтора года назад, сегодня никому не нужно. За это время в отрасли произошли изменения, появились новые стандарты и отраслевой формат для электронных книг, которые не вошли в созданную ранее спецификацию. И теперь никто из интернет-продавцов не хочет размещать на своих ресурсах нестандартный формат. Команда создала отличный шаблон для интернет-магазина, но его интерфейс сильно проигрывает шаблонам, которые используют розничные продавцы в настоящее время. Поэтому он никого не привлекает.
Труд и усилия вашей команды по созданию специальной функции предварительного просмотра для авторов потрачены впустую, потому что эта функция уступает опции, разработанной конкурентами и позволяющей поддерживать документы MS Word и отправлять их по почте.
Какая неприятность! Спецификация, разработанная вашей командой в самом начале, имела большое значение для клиентов и была важна для всех как внутри компании, так и за ее пределами. Но теперь ПО, задуманное полтора года назад, потеряло свою ценность. Необходимость внесения некоторых изменений можно было обнаружить на ранних этапах проекта, но многое требовалось поменять с самого начала. Необходимая при водопадном подходе «подробная спецификация перед началом работы» лишает команду гибкости и не позволяет реагировать на изменения.
Так как же все-таки суметь удовлетворить потребности стейкхолдеров и запустить проект создания работающего программного обеспечения?
Реализация проекта
Agile-команды признают, что наиболее важная задача для них – предоставление работающего программного обеспечения для своих клиентов. Вы уже знаете из главы 2, как они делают это: работая вместе как команда, сотрудничая со своими клиентами и реагируя на изменения. Но как это воплотить в повседневной работе команды?
Чтобы что-то изменить, прежде всего необходима частая поставка ценностей, восприятие каждого изменения в качестве положительного стимула для проекта, частая поставка ПО, совместная работа команды и клиента. Программное обеспечение, которое разрабатывает команда, может быть не таким, каким планировалось изначально, но это хорошо – потому что в итоге она создаст такое ПО, в котором клиенты больше нуждаются.
Первый принцип включает в себя три важные идеи: ранний выпуск программного продукта, непрерывная реализация ценности и удовлетворение клиента. Чтобы понять суть этого принципа, нужно знать, как эти три идеи работают вместе.
Проектные группы существуют в реальном мире, в котором не бывает ничего совершенного. Даже блестяще работающей команде при сборе и записи требований к проекту будет чего-нибудь не хватать, потому что невозможно полностью и точно отразить требования для каждой системы. Это не означает, что команды не должны стараться, а agile-методологии основываются на беспрецедентных методах коммуникации и фиксации требований. Но дело в том, что, пока клиенты не получат в руки работающее ПО, им трудно представить, как именно оно будет функционировать.
Так что если вы хотите получать от клиента реальную, обоснованную обратную связь после просмотра рабочего программного продукта, то лучше всего делать это через раннюю поставку: «отгрузить» заказчику первую рабочую версию программного обеспечения как можно раньше. Даже если вы реализовали только одну рабочую функцию, которую клиент может использовать, – это уже победа для команды. Потому что теперь потребитель способен предоставить вам обратную связь, и она поможет двигать проект в нужном направлении. Это также победа для заказчиков, потому что, имея эту рабочую программу, они могут реализовать то, о чем раньше только мечтали. Можно сказать, что команда создала реальную ценность, поскольку ПО работает и клиенты могут его использовать. Пусть это лишь небольшая часть того, в чем нуждается потребитель, но все-таки это «лучше-чем-ничего», особенно если альтернатива этому – расстроенный пользователь, который должен долго ждать, прежде чем получит программный продукт.
Недостаток ранней поставки в том, что программное обеспечение далеко от совершенства. Это представляет сложность для некоторых клиентов и заинтересованных сторон: если одни пользователи привыкли к мысли, что увидят программное обеспечение рано, то другим свыкнуться с этой мыслью труднее. Многие люди очень переживают, когда их софт не идеален. В компаниях (особенно крупных, где затрачиваются годы на работу с командами, разрабатывающими программное обеспечение) эти команды должны очень тщательно оговаривать условия поставки ПО заинтересованным сторонам. При отсутствии партнерских отношений между заказчиком ПО и командой-разработчиком поставляемый неполный программный продукт может быть оценен строго и даже привести пользователя в ужас, если действительно не соответствует ожиданиям.
Основные agile-ценности отвечают на этот вопрос: сотрудничество с заказчиком важнее согласования условий контракта. Команда, жестко привязанная к спецификации, не может вносить изменения в программное обеспечение в процессе его создания. Работая в таких условиях, требуется запустить новый процесс тотального управления изменениями, который потребует новых переговоров по контракту с заказчиком. Зато команда, действительно сотрудничающая с клиентами, имеет возможность внести все необходимые изменения в ходе работ. Вот что означает непрерывная поставка.
Именно поэтому гибкие методологии, как правило, итеративны. Agile-команды планируют итерации проекта путем выбора показателей и требований, которые обеспечивают максимальную отдачу. Единственный способ, при помощи которого команда может выяснить, какие показатели реализуют эту ценность, – сотрудничество с клиентом и встраивание обратной связи от предыдущей итерации. Это позволяет команде удовлетворить запросы потребителя в краткосрочной перспективе, демонстрируя ценность продукта на раннем этапе сотрудничества, а в долгосрочной перспективе предоставить ему готовый продукт, обладающий всеми возможными ценными качествами.
Многие успешные agile-практики, впервые сталкиваясь с этим принципом, погружаются в проблемы. Легко рассуждать о готовности к изменениям. Но в разгар проекта, когда команда работает над изменениями, требующими больших трудозатрат, эмоции бывают на пике, особенно у разработчика, который знает, что руководство не изменит сроков независимо от того, каких усилий требуют эти изменения. Очень сложно согласиться с этим, особенно если в ходу критика за нарушение сроков. Но это бывает и полезно, потому что, приветствуя изменения в требованиях, можно овладеть одним из самых мощных agile-инструментов.
Почему изменения в проекте несут эмоциональную окраску? Понимание этого вопроса – ключ к данному принципу. Вспомните, когда в последний раз вы, работая над проектом, узнали, что нужно внести изменения в уже созданное. Что вы чувствовали? До этого момента казалось, что дела идут хорошо. Вы, наверное, многое успели обдумать – например, как структурировать работу, что создавать и что обещать клиентам. И вдруг кто-то, не участвующий в проекте, заявляет, что вы ошибались – и планирование, и работа были сделаны неправильно.
Такое трудно принять, особенно если вы делали работу именно для этого человека. Почти всеми инженерами-программистами движет чувство гордыни великого мастера: они хотят поставлять продукты, которые могут поддерживать и которые удовлетворяют потребности пользователей. Изменения в проекте угрожают этому, потому что ставят под сомнение тот путь, который они выбрали, и те допущения, которые они сделали.
Очень часто вам сообщают, что нужно изменить курс, после того как вы его выбрали.
Если этот человек уже объяснил, что именно нужно делать, и вы наполовину выполнили его требования, то вас очень огорчит его неожиданное заявление: «Я подумал вот о чем – а не можем ли мы создать что-то совсем другое?» Он не уважает ваш труд. Теперь вам придется внести изменения в уже сделанное. Трудно при этом не испытать возмущения! И хуже всего приходится тому, кто несет ответственность за результат и не соблюдает сроки.
Почти каждый профессиональный разработчик хотя бы раз попадал в подобную ситуацию. Поэтому понятно, что мы не можем заставить себя приветствовать изменяющиеся требования.
Первый шаг навстречу меняющимся требованиям – попытаться посмотреть на ситуацию с точки зрения клиента. Это не всегда легко, но поучительно. Как вы думаете, заказчик, направивший вас по ложному пути, хотел этого? Представляете, что творилось у него в душе, когда он понял, что несколько месяцев назад распорядился создать неправильное ПО и из-за этого вы потратили массу времени на выполнение ненужной работы? Он приходит к вам с просьбой изменить это. Кроме того, он признает свою ошибку, которая, к сожалению, будет стоить вам дополнительной работы. Это нелегко сделать. Неудивительно, что часто клиенты подолгу не решаются прийти к команде и попросить об изменениях! Им стыдно и к тому же не хочется приносить плохие новости. Все сроки будут сорваны, ну и пусть! Если у заказчика есть потребности, а компания готова тратить деньги на разработку ПО, удовлетворяющего их, то в случае их неудовлетворения проект не будет иметь ценности. И это вина заказчика, потому что именно он ошибся в начале проекта.