Страница 6 из 8
Когда команда определяет подробные требования и разрабатывает планы в самом начале проекта, ограничения можно сформулировать. В последующем команда может использовать эти ограничения для управления рисками и затратами. В процессе постепенной реализации подробного плана команда осуществляет мониторинг и контроль изменений, которые могут оказать влияние на содержание, расписание или бюджет проекта.
В предиктивном проекте поставка бизнес-ценности производится лишь в конце проекта из-за сосредоточенности на эффективности подразделений и на установленной последовательности производства работы. Если в ходе предиктивного проекта возникают изменения или расхождения с требованиями, или техническое решение перестает быть очевидным, осуществление проекта будет связано с непредвиденными затратами.
Рис. 3–2. Предиктивный жизненный цикл
3.1.2 Характеристики итеративных жизненных циклов
Итеративные жизненные циклы позволяют улучшать продукт или результат посредством последовательного создания прототипов или подтверждения концепции. Результатом каждого нового прототипа становятся новая информация от обратной связи с заинтересованными сторонами и углубление понимания командой предметной области. Затем команда внедряет полученные новые знания, повторяя одну или несколько операций в проекте в ходе следующего цикла. Команды могут ограничить временные рамки для данной итерации несколькими неделями, собрать важную информацию и после этого произвести доработку операции на основе этих новых знаний. Таким образом, итерации помогают выявить и снизить уровень неопределенности в проекте.
Преимущества от использования итеративного жизненного цикла проект получает в тех случаях, когда он имеет высокую сложность, в нем часто происходят изменения или его содержание зависит от различий в точках зрения заинтересованных сторон на желаемый конечный продукт. Итеративные жизненные циклы могут занимать больше времени, поскольку их назначение состоит в получении знаний, а не в сокращении сроков поставки.
На рис. 3–3 показаны некоторые элементы итеративного жизненного цикла проекта для единичной поставки продукта.
Рис. 3–3. Итеративный жизненный цикл
Приходилось ли вам участвовать когда-либо в проекте, когда, по вашим ощущениям, требования изменялись ежедневно, и вам казалось: «Мы узнаем требования, когда поставим прототип, который получит одобрение предприятия»? Если «да», то это был проект, в котором могло бы помочь использование подходов agile. Прототип служит стимулом обратной связи и помогает лучше понять требования, которые могут быть исполнены в каждом поставляемом результате.
3.1.3 Характеристики инкрементных жизненных циклов
Оптимизация некоторых проектов осуществляется с целью сокращения сроков поставки. Многие предприятия и инициативы не имеют возможности дожидаться, когда работы будут завершены полностью, и в таких случаях заказчики желают предварительно получить составную часть общего решения. Частую поставку поставляемых результатов меньшего объема называют «инкрементный жизненный цикл» (см. рис. 3–4).
Рис. 3–4. Жизненный цикл с поставкой инкрементов разного объема
ПОЛЕЗНЫЙ СОВЕТ
У вас нет уверенности в том, как новая бизнес-услуга может работать на практике? Разработайте обоснование концепции, предусматривающее критерии оценки, для анализа желаемых конечных результатов. Используйте итеративные подходы, когда есть основания ожидать, что требования будут изменяться по результатам обратной связи с заказчиком.
Инкрементные жизненные циклы оптимизируют работу для поставки ценности спонсору или заказчики часто, а не однократно, в виде конечного продукта. Команды планируют поставляемые результаты до начала работы и приступают к работе по созданию первого поставляемого результата как можно раньше. Поставка ценности в некоторых проектах agile происходит в течение нескольких дней с момента его инициации. В других проектах для этого требуется больше времени – от 1 до нескольких недель.
По ходу исполнения проекта команда может отклоняться от изначальных представлений. Команда может управлять отклонениями, так как она осуществляет поставку в более короткие сроки. Не так важна степень изменений и вариаций, как поставка клиентам ценности до окончания проекта.
Поставка заказчику отдельного свойства или законченной части работ является примером инкрементного подхода.
Например, у строителей может возникнуть потребность показать заказчику завершенное помещение или этаж в здании до продолжения работ в остальной его части. В этом случае они могут полностью выполнить работы на этаже с установкой недвижимого оборудования, завершением отделочных и прочих работ, которые должны быть произведены на данном этаже для приемки, прежде чем переходить к работам на следующем этаже. Заказчик может осмотреть и принять стиль, цвет и другие элементы, что дает возможность внести какие-то изменения до того, как будут произведены дальнейшие затраты рабочего времени и денежных средств. Это сокращает объемы возможной доработки и/или степень неудовлетворенности заказчика.
Завершенность и поставка являются субъективными понятиями. Команде может требоваться обратная связь в отношении прототипа, после чего она может принять решение о поставке минимально приемлемого продукта (minimum viable product, MVP) части заказчиков. Обратная связь с заказчиками помогает команде узнать, что из свойств конечного готового продукта ей необходимо обеспечить в последующих поставках.
Ключевое отличие agile-команды заключается в том, что она поставляет бизнес-ценность часто. При условии постепенного расширения набора свойств продукта и круга его потребителей, можно сказать, что его поставка осуществляется инкрементно.
3.1.4 Характеристики жизненных циклов agile
В среде agile команда ожидает, что в требованиях будут происходить изменения. Итеративные и инкрементные подходы обеспечивают обратную связь, которая позволяет лучше планировать следующую часть проекта. Однако в проектах agile инкрементная поставка выявляет скрытые или неправильно понятые требования. На рис. 3–5 наглядно представлены два возможных способа осуществления инкрементной поставки так, чтобы проект был согласован с потребностями заказчика и при необходимости мог быть адаптирован.
Рис. 3–5. Итерационный и потоковый жизненные циклы agile
В случае итерационного жизненного цикла agile команда работает в рамках итераций (временные рамки имеют одинаковую длительность) с целью поставки завершенных свойств. Команда работает над наиболее важным свойством для его завершения силами всей команды. Затем команда приступает к работе над следующим по важности свойством и полностью завершает его. Команда может принять решение вести работу по нескольким свойствам сразу, но она не занимается всей работой для данной итерации одновременно (т. е. не занимается всеми требованиями по результатам всех анализов и т. д.).
В потоковом agile команда берет для работы свойства из бэклога в зависимости от своей ресурсной возможности начать работу, а не по основанному на итерациях расписанию. Команда определяет для себя поток работ с помощью столбцов доски задач и управляет незавершенными работами в каждом столбце. Для завершения работы по каждому свойству может требоваться разное время. Команды сохраняют небольшой объем незавершенных работ, чтобы было легче определить проблемы на раннем этапе и сократить объем доработок при возникновении необходимости внести изменения. Поскольку для определения точек планирования и контроля уже не используются итерации, команда и заинтересованные стороны со стороны бизнеса определяют наиболее целесообразное расписание для планирования, анализа продукта и ретроспективного анализа.