При гибком подходе время делится на интервалы – итерации, периоды с фиксированными датами начала и завершения. У техники
В аджайле вся разработка организована таким образом, чтобы оптимизировать способность отвечать на
Ценность – это ответ на требования пользователей, рынка и бизнеса, общая мера продвижения вперед и успеха. Ценность является внутренней гипотезой, предположением до тех пор, пока продукт не будет выпущен на рынок. Выпуск версий продукта на рынок – единственный способ проверить предположение относительно ценности продукта. Регулярный выпуск на рынок – единственный способ получить обратную связь и оценку со стороны рынка и изменить продукт в соответствии с ними. Это делается путем последующего развития продукта: ценность постоянно оптимизируется от итерации к итерации. Риск снижается с помощью регулярного выпуска работающих инкрементов продукта, выполненных на основе четко определенных стандартов разработки.
Мы привыкли к тому, что риск в ИТ-контексте определяется как нечто техническое (
Риск также относится к бизнесу. Любой современный процесс разработки должен учитывать риск того, что вы не сможете извлечь выгоду из неизвестных или непредвиденных возможностей рынка, риск невыпуска продукта достаточно быстро, риск разочарования клиентов, например при выпуске непротестированного софта, риск того, что пользователи не оценят функциональность продукта, риск проиграть конкурентам.
Гибкая разработка устроена так, чтобы максимально смягчить этот бизнес-риск. Требования, имеющие высокую ценность, удовлетворяются в первую очередь. Версии продукта и обновления выпускаются быстро и часто. Они удовлетворяют существующие потребности, а также предлагают неожиданные, инновационные функции. Благодаря этому пользователи платят за продукт, а инвестиции возвращаются. Версии продукта качественные, что позволяет минимизировать сопровождение и поддержку, оптимизировать общую стоимость владения (Total Cost of Ownership, TCO).
Аджайл признает значение «обычных» ИТ-активностей (на рис 1.4 они представлены как анализ, дизайн, кодирование и тестирование/интеграция), но ломает их последовательную организацию. Чтобы производить ПО с необходимой скоростью и получать выгоды быстрее, структура работы меняется. Цель в том, чтобы обеспечить гибкость и скорость, а не мешать им. В аджайле все эти действия осуществляются нелинейно, параллельно, инкрементальным образом, разнопрофильными командами, которые постоянно сотрудничают и обмениваются идеями.
Цель такого интегрированного кросс-функционального подхода – изначально делать продукт качественно и предотвращать дефекты, а не пытаться создать качество за счет вылавливания ошибок в фазе постразработки. Обязательно не просто хотеть выпускать версии продукта часто, а действительно это делать. Качество не может быть добавлено к законченному продукту. Задержки и бюджет имеют тенденцию выходить из-под контроля, когда недостаток качества обнаруживается после того, как закончен процесс разработки.
Чтобы получить реальную и долговременную выгоду от гибких методов разработки, надо выходить за границы ИТ и других технических отделов. Придется меняться всей организации. Но это не только необходимость, это