Что такое предиктивный жизненный цикл
Что такое предиктивный жизненный цикл
Agile: практическое руководство
Подана заявка на библиографическую запись в Библиотеке Конгресса США.
Project Management Institute, Inc.
14 Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 США
Телефон: +1 610-356-4600
Эл. почта: [email protected]
Материалы Project Management Institute, Inc. охраняются авторским правом в соответствии с законом США об интеллектуальной собственности, который признан в большинстве стран. Для переиздания или воспроизведения материалов PMI вам необходимо получить наше разрешение. Для получения более подробной информации посетите www.pmi.org/permissions.
Для размещения торгового заказа или получения информации о расценках обратитесь в Independent Publishers Group:
Independent Publishers Group
814 North Franklin Street
Chicago, IL 60610 США
Телефон: +1 800-888-4741
Факс: +1 312- 337-5985
Эл. почта: [email protected] (только для заказов)
По всем остальным вопросам обращайтесь в PMI Book Service Center.
PMI Book Service Center
P.O. Box 932683, Atlanta, GA 31193-2683 США
Телефон: 1-866-276-4764 (в США или Канаде) или +1-770-280-4129 (по всему миру)
Эл. почта: [email protected]
Напечатано в Соединенных Штатах Америки. Запрещается воспроизведение или передача в любой форме или любыми средствами, электронными, ручными, путем фотокопирования, записи или с помощью любой системы хранения и извлечения информации любой части данного издания без предварительного разрешения издателя.
PMI, логотип PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION и девиз MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. являются товарными знаками Project Management Institute, Inc. Для получения полного списка товарных знаков PMI обратитесь в юридический отдел PMI. Все остальные товарные марки, знаки обслуживания, торговые наименования, торговое оформление, названия продуктов и логотипы, появляющиеся в данном документе, являются собственностью их соответствующих владельцев. Любые права, не переданные в явной форме в настоящем документе, принадлежат владельцу авторского права.
SAFe является зарегистрированной маркой компании Scaled Agile, Inc.
Agile Alliance и логотип Agile Alliance являются торговыми знаками Agile Alliance.
Финансирование издания настоящего Практического руководства и его подготовка осуществлялись совместно с Agile Alliance®.
Agile Alliance® не занимается вопросами утверждения методологий и сертификатов agile.
Все права защищены. Воспроизведение всей книги или ее части в любом виде воспрещается без письменного разрешения издателя.
© 2017 Project Management Institute, Inc. Все права защищены.
© Перевод на русский язык, издание, оформление издательство «Олимп – Бизнес», 2018
Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.
PMI не несет ответственность за какие-либо травмы, повреждения, нанесенные собственности, или какие-либо другие убытки, будь то реальные, косвенные или компенсаторные, произошедшие непосредственно или косвенно вследствие издания, применения или использования данного документа. PMI не несет ответственность и не предоставляет гарантию, прямую или предполагаемую, относительно точности или полноты любого материала, содержащегося в данном документе, а также не несет ответственность и не предоставляет гарантию того, что содержащаяся в данном документе информация отвечает каким-либо вашим целям или нуждам. PMI не предоставляет гарантию относительно качества каких-либо продуктов или услуг отдельного производителя или продавца, проистекающего из использования данного стандарта или руководства.
Издавая и распространяя данный документ, PMI не оказывает профессиональные или иные услуги какому-либо лицу или организации или от имени какого-либо лица или организации; также PMI не выполняет обязательства какого-либо лица или организации по отношению к какой-либо третьей стороне. При использовании данного документа использующее его лицо должно самостоятельно определять действия, необходимые в конкретных обстоятельствах, полагаясь при этом исключительно на свое суждение или, при необходимости, на совет компетентного профессионала. Информация относительно темы, освещаемой данным документом, или относящиеся этой теме стандарты могут быть получены из других источников, к которым пользователь может при необходимости обратиться, чтобы получить дополнительную информацию, не содержащуюся в данном документе.
PMI не имеет полномочий и не берет на себя обязательства по контролю за соответствием существующих практик содержанию данного документа или приведению этих практик в соответствие с данным документом. PMI не занимается сертификацией, проведением контрольных испытаний или инспекций в отношении продуктов, проектов или конструкций на предмет безопасности их эксплуатации или безопасности для здоровья потребителей. Любой сертификат или иное утверждение соответствия какой-либо информации относительно безопасности эксплуатации или безопасности для здоровья, содержащейся в данном документе, не могут быть приписаны PMI; в таком случае ответственность лежит всецело на лице, выдавшем сертификат или высказавшем такое утверждение.
Институт управления проектами (Project Management Institute, PMI) и Agile Alliance® создали настоящее Практическое руководство с целью достичь более глубокого понимания подходов agile в своих сообществах. Назначение настоящего практического руководства состоит в том, чтобы наделить команды проектов инструментами, ситуационными принципами и пониманием существующих методов и подходов agile, которые позволят добиться лучших результатов.
Команды проектов применяют подходы agile не только в области разработки программных продуктов, но и в самых разных отраслях. Обе организации осознают, что в результате более широкого охвата возникла необходимость в создании общего языка, отказе от предвзятого мышления и готовности гибко подходить к тому, как продукты и поставляемые результаты выводятся на рынок. Кроме этого, обе организации исходят из того, что существует множество способов обеспечить успешную поставку. Имеется широкий набор инструментов, методов и фреймворков, и у команд есть выбор подходов и практик, отвечающих особенностям их проектов и организационных культур, которые они могут использовать для достижения желаемого конечного результата.
Члены основного комитета разработчиков Практического руководства agile имеют разный практический опыт и применяют различные подходы. Некоторые из членов комитета работают консультантами, а другие – непосредственно в организациях. Но все они уже многие годы ведут работу в направлении agile.
Agile. Процессы, проекты, компании
Новая книга известного тренера-преподавателя и директора многочисленных учебных программ по проектному управлению В. Н. Фунтова посвящена применению гибких методов в современных компаниях, а особенно применению Agile в управлении за пределами ИТ-отрасли. Компании, использующие Agile, очень гибко реагируют на изменение запросов потребителей и продуктивно сотрудничают с ними, быстро и эффективно создают правильные результаты и продукты, не делают лишней работы. В книге кратко рассмотрена история Agile, гибкие ценности, принципы и подходы, приведены многочисленные примеры применения Agile в процессах, проектах, практиках компаний, описаны гибкие стандарты и системы сертификации. Важное место занимает материал по созданию и развитию гибкости в организации. Книга адресована собственникам бизнеса, проектным командам, руководителям направлений, коучам, консультантам, студентам и всем, кто интересуется подходами Agile в менеджменте и развитии.
Оглавление
Приведённый ознакомительный фрагмент книги Agile. Процессы, проекты, компании предоставлен нашим книжным партнёром — компанией ЛитРес.
Жизненный цикл проекта
Слишком малое количество людей в проекте может решить его проблемы, слишком большое количество людей создает больше проблем, чем могут решить.
Второй спринт информирует читателя о видах жизненных циклов проектов. По итогам спринта вы сможете различать «Водопад» и Agile, консультировать свою команду или генерального директора, сделать правильный выбор жизненного цикла при запуске нового проекта.
Условное деление проектов на предиктивный и адаптивный варианты предполагает, что успех проекта в первом случае определяется полной проработанностью будущего результата и пути его достижения, следованием управленческим регламентам и зафиксированным договоренностям. Другие же проекты — уникальные и инновационные, где гарантий заранее нет, успех определяют люди, их взаимодействие и мнение заказчика.
Выбор варианта реализации проекта во многом связан с понятием жизненного цикла как набора временных итераций, через которые проходит проект со старта до достижения результата. Подобный цикл может включать в себя отдельные фазы, непосредственно связанные с разработкой какого-либо продукта, например сервиса или ИТ-решения. Такой вложенный цикл называют жизненным циклом разработки.
2.1. Предиктивный цикл
Проект без критического пути — как корабль без руля.
Н. Деан Мейер, автор работ по экономике и управлению
Представим проект, где содержание, сроки и стоимость определены и зафиксированы на начальной фазе договором или техническим заданием. Заказчик обещал не вмешиваться в реализацию и прийти только в конце. Любые изменения объявлены не слишком желательными и будут требовать управления по документарным запросам. Примером может быть следующий цикл.
1. Разработка концепции: назначение руководителя проекта и формирование ключевой команды; сбор исходных данных; выявление и фиксация требований; определение целей, задач, результатов, ограничений, рисков, сроков, ресурсов, средств, утверждение ТЗ.
2. Подготовка к реализации: разработка полного содержания проекта и календарного плана работ; составление сметы на весь проект; определение и снижение рисков; заключение договоров с подрядчиками.
3. Организация основных работ: оперативное планирование; контроль за ходом работ; организация обеспечения; руководство, прогноз состояния; контроль основных KPI проекта (объем, качество, сроки, стоимость).
4. Завершение: сдача заказчику, подготовка документации и отчета, сбор уроков реализации проекта.
Интересны сравнения таких циклов с баллистической траекторией и конусом.
Баллистическая траектория: точно прицелились в начале проекта, спустили «курок», подписывая договор, и внимательно следим за траекторией снаряда, ограничивая влияние ветра или других препятствий. Изменения вносить нельзя, от точности попадания в мишень зависит приемка результата проекта заказчиком.
Конус. Реализация проекта — это множество маршрутов от вершины к основанию, среди которых выделена область допустимых траекторий его развития. Управление рассматривается как деятельность, препятствующая выходу траектории из области их допустимости.
Такие и подобные циклы, которые подразумевают последовательный переход с фазы на фазу без пропусков и возвращений, еще называют последовательными, «водопадными» (Waterfall), прогнозируемыми, предсказуемыми, классическими, типовыми или каскадными.
Первое их официальное упоминание приписывается статье Винстона Ройса, вышедшей в 1970 г., хотя сам автор и не использовал термин «Водопад», который, как считается, появился только в 1976 г.
Такие предпочтения имеют свои основания, поскольку предиктивный цикл характеризуется рядом положительных моментов:
♦ иногда очень важно, чтобы переход от одной фазы к другой происходил только после полного и успешного завершения предыдущей фазы (подход Stage-Gate), например при передаче технической информации или сдаче технического элемента;
♦ в проекте объявлена жесткая необходимость обязательного расчета затрат и сроков при фиксированном содержании;
♦ лучше всего подходит для проектов, где создаются физические объекты, — от строительных до проектов по установке оборудования;
♦ требования заказчика непротиворечивы, известны, понятны и зафиксированы;
♦ все стороны хорошо понимают, какой продукт они создают, и этот продукт важен именно полностью и в конце проекта;
♦ проект не очень масштабный;
♦ графики и алгоритмы проектов можно использовать в будущем для идентичных или аналогичных проектов;
♦ проект типовой, существует понятное ТЗ, заказчик не хочет управлять проектом и похожие ситуации.
Руководство компании Toyota, знаменитое созданием Lean и Канбан, часто критикуют за недостаток гибкости: до конца 2000-х для нужд производства компания пользовалась каскадной моделью разработки ПО.
Анализ разработки сайта в компании Ericsson AB показал, что предиктивный вариант привел к путанице и 26 % изначальных требований оказались просто бесполезными.
Оплот классического подхода сейчас — строительные и инженерные проекты, в которых содержание остается практически неизменным на протяжении всего времени, а также проекты с материальными выходами.
2.2. ИНКРЕМЕНТНЫЙ ЦИКЛ
Прежде чем создать что-то повторяемое и многоразовое, сначала нужно создать что-то одноразовое.
Встречается много ситуаций, когда содержание проекта очевидно будет подвержено изменениям (ресурсы и сроки не являются ключевыми ограничениями) или когда заказчик хочет активно экспериментировать вместе с командой, планируя уточнять содержание проекта пошагово. Такие циклы называются адаптивными.
Одним из вариантов адаптивного цикла является пошаговая реализация проекта; выпуск на первом шаге (или итерации) продукта в базовой функциональности и затем, на следующих итерациях — создание отдельных составных частей или функциональностей продукта, так называемых инкрементов, с приращением ценности. Процесс продолжается до тех пор, пока не будет создана полная система, при этом требования могут вырабатываться постепенно, по итерациям, так же вносятся и изменения. В конце каждой итерации заказчик и/или потребители принимают активное регулярное участие в оценке. Контроль рисков и стоимости осуществляется на основе постепенно разрабатываемых планов по мере поступления новых вводных. Промежуточные результаты содержат необходимые характеристики для выработки новых требований и для анализа их ценности. Такой цикл называется инкрементным и используется там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы или требуется ранний вывод продукта на рынок. Команда обычно постоянна.
Так можно создавать портал компании — сначала немедленно вводить в работу основные функции или «кнопки», потом дополнять следующими, получая пользу от уже введенных.
Фавелы в Латинской Америке строятся по комнатам. У жителей времени много, зимы нет, как и денег. Они строят свою первую комнату из кирпичей, пока не кончатся или сколько есть. Потом достраивают, ставят окна, накрывают крышу и иногда даже штукатурят и красят. Когда семья растет, пристраивают следующую комнату.
2.3. Итеративный цикл
Нам не нужны повторяющиеся процессы, нам нужны повторяющиеся результаты.
Канадский программист Скотт Амблер
Итеративность определяет разработку продукта также путем выполнения ряда повторяющихся итераций, когда основная цель и требования к конечному результату определены, разработано высокоуровневое видение, но детали реализации могут меняться с течением итераций, как и оценки сроков и стоимости, в рабочем порядке, по мере расширения понимания командой продукта. Планирование следующей итерации происходит по мере выполнения работ в рамках предыдущей. Команда проекта может меняться между итерациями или во время них. Так можно написать объемный аналитический отчет. Сначала согласовать содержание, потом, на следующей итерации, разработать разделы, затем добавить материал внутрь разделов, после этого итерационно создать несколько последовательных редакций.
В проекте создания фильма сначала пишут сценарий. Его можно откорректировать, положить на полку, продать. На следующей итерации отснимут видеоматериалы. В них также можно вносить изменения. Потом провести технический просмотр. Далее смонтировать и озвучить. На каждом шаге принимается решение о движении дальше. Выхода итерации достаточно, чтобы запланировать следующую. Работают разные участники.
У итеративных циклов есть свои зоны предпочтений. Они применяются, если содержание проекта подвержено изменениям, а требования к конечной системе заранее четко определены, ресурсы понятны и сроки не являются ключевыми ограничениями. Можно управлять изменением целей и содержания, уменьшить сложность проекта. Крупные и сложные проекты часто выполняются в итеративном цикле с целью сокращения риска, позволяя команде использовать отзывы и извлеченные уроки, полученные между итерациями.
MVP имеет только те функции, которые считаются достаточными для того, чтобы быть ценными для клиентов, и позволяют отправлять или продавать его самым ранним клиентам. Обратная связь с клиентом даст информацию о будущем развитии продукта.
Скотт М. Граффиус. Agile Scrum: краткое руководство с пошаговыми инструкциями
По результатам итераций разрабатывается продукт с минимально необходимым набором возможностей или функций. Заказчик его оценивает, давая свои новые требования и по возможности начиная использовать этот продукт уже в своей деятельности. Такая версия продукта называется MVP — Minimum Viable Product (минимально ценный продукт) (исполнительный директор SyncDev Фрэнк Робинсон, 2001 г., позже Эрик Райс, основатель IMVU) или PSPI — Potentially Shippable Product Increment (готовое к поставке приращение продукта). Например, это базовая функциональность продукта, первый тестовый продукт для рынка.
Текст книги «Agile. Практическое руководство»
Автор книги: Коллектив авторов
Жанр: Зарубежная деловая литература, Бизнес-Книги
Текущая страница: 2 (всего у книги 3 страниц)
2.3 Бережливый подход и метод «канбан»
Взаимосвязь между бережливым мышлением, подходом agile и методом «канбан» можно представить себе, например, если рассматривать agile и метод «канбан» как производные бережливого мышления. Другими словами, бережливое мышление включает более широкий набор характеристик, имеющий общие свойства с подходом agile и методом «канбан».
Эти общие свойства весьма схожи и сосредоточены на поставке ценности, уважении к людям, сокращении потерь, обеспечении прозрачности, адаптации к изменениям и непрерывном совершенствовании. В некоторых случаях команда проекта может счесть полезным объединить вместе различные методы: все то, что может принести пользу организации или команде, следует сделать, независимо от его природы. Цель состоит в том, чтобы получить наилучший конечный результат, независимо от применяемого подхода.
Метод «канбан» разработан на основе оригинальной системы бережливого производства и используется в частности в сфере умственного труда. Он появился в середине 2000-х гг. в качестве альтернативы методам agile, которые в то время преобладали.
Метод «канбан» является менее директивным в сравнении с некоторыми подходами agile, и менее «дезорганизующим», поскольку является оригинальным подходом, основанным на принципе «начинай прямо там, где находишься». Командам проектов сравнительно просто начать применять метод «канбан» и затем перейти к более прогрессивным подходам agile, если они сочтут это необходимым или целесообразным. Более подробно метод «канбан» описан в приложении А3, содержащем обзор фреймворков подхода agile и бережливого подхода.
Ведутся сейчас и, вероятно, еще долго будут идти споры о методе «канбан» и о том, куда его отнести – к бережливому подходу или движению agile. Он был задуман в рамках и в связи с бережливым производством, но широко применяется в средах agile.
2.4 Неопределенность, риск и выбор жизненного цикла
Некоторые проекты отличаются значительной неопределенностью при определении требований проекта и того, как исполнить эти требования, используя имеющиеся знания и технологии. Эти неопределенности могут стать причиной увеличения темпов изменений и усложнения проекта. Эти свойства наглядно представлены на рис. 2–5.
По мере усиления неопределенности проекта происходит также увеличение риска возникновения необходимости доработок и применения другого подхода. Для снижения уровня этих рисков команды выбирают жизненные циклы, которые позволяют им заниматься проектами с высокой степенью неопределенности путем исполнения небольших инкрементов работы.
При использовании небольших инкрементов команды получают возможность проверять результаты своей работы и вносить изменения в то, что предстоит сделать. Когда команды производят поставки небольшими инкрементами, улучшается их способность понимать подлинные требования заказчиков, и делать это в более короткие сроки и точнее, чем в случае работы по неизменным письменным спецификациям.
Рис. 2–5. модель неопределенности и сложности на основе модели сложности Стейси (Ralph D. Stacey)
Команда может без особых затруднений планировать проект и управлять им, имея четкие и стабильные требования, а также ясные и легко решаемые технические задачи. Однако, по мере нарастания неопределенности в проекте, вероятность необходимости внесения изменений, бесполезной работы и доработок также возрастает, что влечет убытки и потерю времени.
Некоторые команды используют развитые жизненные циклы проектов, где используются как итеративные, так и инкрементные подходы. Многие команды обнаружили, что когда они изучают требования итеративно и осуществляют поставки чаще и по частям (инкрементно), им становится легче адаптироваться к изменениям. Такие итеративные и инкрементные подходы позволяют сократить объемы потерь и доработок, поскольку команда получает обратную связь. В этих подходах используются:
♦ очень короткие циклы обратной связи,
♦ частая адаптация процесса,
♦ регулярное обновление планов,
Что означают определения проектов «простой», «усложненный» и «сложный»? Возьмем большие проекты, например, проект строительства Большого бостонского тоннеля. На первый взгляд, этот проект выглядит довольно очевидным: просто переместить автомагистраль с эстакады под землю. Был заключен генеральный договор о требованиях (см. ось Y на рис. 2–5). Степень неопределенности в отношении порядка исполнения проекта была невысокой, пока не приступили к его осуществлению. И, как это часто бывает с большими проектами, на всем протяжении осуществления этого проекта постоянно возникали неприятные сюрпризы.
Когда команда ведет работу над проектом, причем возможности поставки промежуточных результатов или создания прототипов практически отсутствуют, она, скорее всего, будет использовать для управления проектом предиктивный жизненный цикл. Команда может вносить изменения с учетом новых обстоятельств, но не сможет использовать подходы agile для управления итеративно возникающими новыми требованиями или осуществлять инкрементные поставки с целью обратной связи.
Проект строительства Большого тоннеля, безусловно, не был простым. Однако при осуществлении многих проектов, начало которых лежит в нижней левой части Модели сложности Стейси, реальная возможность перейти к другим моделям практически отсутствует. Необходимо оценить проект с точки зрения как требований, так и средств поставки, чтобы определить наилучший подход при выборе жизненного цикла для данного проекта.
Эти итеративные, инкрементные agile-подходы хорошо работают в проектах, которые связаны с использованием новых или инновационных инструментов, методов, материалов или областей применения. (См. раздел 3, посвященный вопросам выбора жизненного цикла). Они также хорошо работают в проектах, которые:
♦ требуют проведения НИОКР,
♦ имеют высокие темпы изменений,
♦ имеют неясные или неизвестные требования, неопределенность или риск,
♦ имеют конечную цель, которую сложно описать.
Создав небольшой инкремент и проведя затем его испытания и исследование, команда может изучить неопределенность с незначительными затратами и в короткий срок, снизить уровень риска и добиться поставки максимальной бизнес-ценности. Центральными вопросами в отношении неопределенности могут быть: пригодность продукта и требования (создается ли именно тот продукт, который нужен?); техническая возможность и исполнение (возможно ли создать этот продукт таким образом?) или процесс и кадры (эффективный ли это способ работы команды?). Все три указанные характеристики (спецификация продукта, производственные возможности и пригодность процесса) обычно включают элементы высокой неопределенности.
Однако применение итеративных и инкрементных подходов имеет известные ограничения. В случаях, когда высока степень неопределенности, как технической, так и связанной с требованиями (верхняя правая сторона на рис. 2–5), проект выходит за пределы «сложного» и становится «хаотическим». Чтобы иметь уверенность в возможности осуществления проекта, необходимо установить одну из переменных неопределенности.
3. Выбор жизненного цикла
Проекты могут иметь много форм, и существуют разнообразные способы их осуществления. Командам проектов нужно знать характеристики и имеющиеся варианты, из которых можно выбрать тот подход, который с наибольшей вероятностью обеспечит успех в данной ситуации.
В настоящем Руководстве речь идет о четырех типах жизненных циклов, которые можно определить следующим образом:
♦ Предиктивный жизненный цикл. Относительно традиционный подход, который предусматривает осуществление основной части планирования до начала работы по проекту с его последующим исполнением за одинарный проход и последовательным процессом.
♦ Итеративный жизненный цикл. Подход, позволяющий использовать обратную связь с целью доработки и уточнения незавершенной работы.
♦ Инкрементный жизненный цикл. Подход, дающий конечные поставляемые результаты, которые заказчик может немедленно использовать.
♦ Жизненный цикл agile. Подходы, которые являются итеративными и, в то же время, инкрементными и предназначены для уточнения элементов работы и частой поставки.
ЧТО МОЖНО НАЗВАТЬ ПОДХОДАМИ, НЕ ЯВЛЯЮЩИМИСЯ AGILE?
Единого универсального термина, который описывает не являющиеся agile подходы, не существует. Изначально в Практическом руководстве, чтобы подчеркнуть акцент на предварительное планирование с последующим исполнением, использовалось понятие подход на основе плана. Некоторые специалисты для описания этого жизненного цикла предпочитают использовать понятия водопад или последовательный. В конце концов мы остановили выбор на понятии предиктивный, поскольку оно используется в Руководстве к своду знаний по управлению проектом (Руководство PMBOK®) [3] и в Дополнении к Руководству PMBOK® по разработке программного обеспечения – пятое издание [4].
В практике многих организаций нет таких крайних позиций, и они просто занимают какое-то среднее положение. Это естественно, но нам все же необходимо определить, как называть крайние позиции этого диапазона понятий. Если подход agile находится на одном конце диапазона, то предиктивный подход – на другом.
3.1 Характеристики жизненных циклов проектов
В таблице 3–1 обобщены характеристики четырех категорий жизненных циклов, о которых идет речь в настоящем Руководстве.
Таблица 3–1. Характеристики четырех категорий жизненных циклов
Важно отметить, что все проекты имеют эти характеристики – ни в одном проекте нельзя полностью избавиться от соображений о требованиях, поставке, изменениях и целях. Какой жизненный цикл лучше всего подходит для использования в данном проекте, определяют внутренне присущие ему характеристики.
Еще один путь к пониманию различий жизненных циклов проектов состоит в использовании континуума в диапазоне от предиктивных циклов на одном конце до циклов agile на другом, где те или иные итеративные или инкрементные циклы занимают среднее положение между ними.
На рис. Х3-1 в приложении Х3 к Руководству PMBOK® – Шестое издание данный континуум представлен линией. Данное представление подчеркивает смещение характеристик из одного конца в другой. Еще одним способом визуализации данного континуума является двумерный квадрат, который показан на рис. 3–1.
Рис. 3–1. Континуум жизненных циклов проектов
Ни один жизненный цикл не может идеально подходить для всех проектов. Напротив, каждому проекту соответствует определенная точка континуума, которая обеспечивает оптимальный баланс характеристик для его контекста. А именно:
♦ Предиктивные жизненные циклы. Используются преимущества того, что известно и прошло проверку практикой. Такое снижение уровня неопределенности и сложности позволяет командам разбить работу по следующим в определенном порядке предсказуемым группам работ.
♦ Итеративные жизненные циклы. Позволяют использовать обратную связь в отношении частично завершенной или незавершенной работы с целью ее доработки и уточнения.
♦ Инкрементные жизненные циклы. Дают конечные поставляемые результаты, которые заказчик может немедленно использовать.
♦ Жизненные циклы agile. Используют преимущества как итеративных, так и инкрементных характеристик. При использовании командой подходов agile продукт производится итерациями в виде создания готовых поставляемых результатов. Команда получает обратную связь уже на раннем этапе и обеспечивает заказчику наглядность, уверенность и контроль в отношении продукта. Поскольку команда может выпустить продукт раньше, проект может обеспечить окупаемость инвестиций в более короткие сроки, так как команда в первую очередь производит имеющую наибольшую ценность работу.
ПЛАНИРОВАНИЕ ОСУЩЕСТВЛЯЕТСЯ ПРИ ЛЮБЫХ ОБСТОЯТЕЛЬСТВАХ
Когда речь идет о жизненных циклах, следует всегда помнить, что в каждом из них присутствует элемент планирования. Разница между жизненными циклами состоит не в том, осуществляется ли планирование в принципе, а в том, в каком объеме и на каком этапе проекта это происходит.
На предиктивном конце континуума работы производятся по плану. Планирование в максимально возможном объеме производится заблаговременно. Требования выясняются настолько подробно, насколько это возможно. Команда оценивает, когда она будет в состоянии поставить каждый из поставляемых результатов и выполняет закупочную деятельность в полном объеме.
В случае с применением итеративных подходов планирование выпуска прототипов и проведения испытаний также производится, однако полученные результаты предназначены для уточнения первоначальных планов. Анализ незавершенной работы на ранних этапах помогает получить информацию для использования при производстве последующих работ по проекту.
С другой стороны, в инкрементных инициативах планируется последовательная поставка промежуточных результатов проекта в целом. Команды заранее могут планировать несколько последовательных поставок или только по одной поставке за один раз. Такие поставки обеспечивают информацию для использования при производстве последующих работ по проекту.
Планирование в проектах agile также осуществляется. Основным отличием является то, что команда планирует и пересматривает планы по мере поступления новой информации, получаемой по результатам периодических поставок. Любой проект требует планирования, независимо от типа его жизненного цикла.
Предиктивные жизненные циклы предполагают использование преимуществ от высокой определенности твердо установленных требований, стабильного состава команды и низкого уровня риска. Как следствие, операции проекта во многих случаях исполняются в определенной последовательности, как показано на рис. 3–2.
Чтобы иметь возможность использовать этот подход, команде необходимо иметь подробные планы, которые определяют, какие производятся поставки и как. Такие проекты завершаются успешно, когда для других потенциальных изменений (например, изменений в требованиях; члены команды проекта вносят изменения в поставки) установлены ограничения. В предиктивном проекте руководитель стремится свести объем изменений к минимуму.
Когда команда определяет подробные требования и разрабатывает планы в самом начале проекта, ограничения можно сформулировать. В последующем команда может использовать эти ограничения для управления рисками и затратами. В процессе постепенной реализации подробного плана команда осуществляет мониторинг и контроль изменений, которые могут оказать влияние на содержание, расписание или бюджет проекта.
В предиктивном проекте поставка бизнес-ценности производится лишь в конце проекта из-за сосредоточенности на эффективности подразделений и на установленной последовательности производства работы. Если в ходе предиктивного проекта возникают изменения или расхождения с требованиями, или техническое решение перестает быть очевидным, осуществление проекта будет связано с непредвиденными затратами.
Рис. 3–2. Предиктивный жизненный цикл
3.1.2 Характеристики итеративных жизненных циклов
Итеративные жизненные циклы позволяют улучшать продукт или результат посредством последовательного создания прототипов или подтверждения концепции. Результатом каждого нового прототипа становятся новая информация от обратной связи с заинтересованными сторонами и углубление понимания командой предметной области. Затем команда внедряет полученные новые знания, повторяя одну или несколько операций в проекте в ходе следующего цикла. Команды могут ограничить временные рамки для данной итерации несколькими неделями, собрать важную информацию и после этого произвести доработку операции на основе этих новых знаний. Таким образом, итерации помогают выявить и снизить уровень неопределенности в проекте.
Преимущества от использования итеративного жизненного цикла проект получает в тех случаях, когда он имеет высокую сложность, в нем часто происходят изменения или его содержание зависит от различий в точках зрения заинтересованных сторон на желаемый конечный продукт. Итеративные жизненные циклы могут занимать больше времени, поскольку их назначение состоит в получении знаний, а не в сокращении сроков поставки.
На рис. 3–3 показаны некоторые элементы итеративного жизненного цикла проекта для единичной поставки продукта.
Рис. 3–3. Итеративный жизненный цикл
Приходилось ли вам участвовать когда-либо в проекте, когда, по вашим ощущениям, требования изменялись ежедневно, и вам казалось: «Мы узнаем требования, когда поставим прототип, который получит одобрение предприятия»? Если «да», то это был проект, в котором могло бы помочь использование подходов agile. Прототип служит стимулом обратной связи и помогает лучше понять требования, которые могут быть исполнены в каждом поставляемом результате.
Оптимизация некоторых проектов осуществляется с целью сокращения сроков поставки. Многие предприятия и инициативы не имеют возможности дожидаться, когда работы будут завершены полностью, и в таких случаях заказчики желают предварительно получить составную часть общего решения. Частую поставку поставляемых результатов меньшего объема называют «инкрементный жизненный цикл» (см. рис. 3–4).
Рис. 3–4. Жизненный цикл с поставкой инкрементов разного объема
У вас нет уверенности в том, как новая бизнес-услуга может работать на практике? Разработайте обоснование концепции, предусматривающее критерии оценки, для анализа желаемых конечных результатов. Используйте итеративные подходы, когда есть основания ожидать, что требования будут изменяться по результатам обратной связи с заказчиком.
Инкрементные жизненные циклы оптимизируют работу для поставки ценности спонсору или заказчики часто, а не однократно, в виде конечного продукта. Команды планируют поставляемые результаты до начала работы и приступают к работе по созданию первого поставляемого результата как можно раньше. Поставка ценности в некоторых проектах agile происходит в течение нескольких дней с момента его инициации. В других проектах для этого требуется больше времени – от 1 до нескольких недель.
По ходу исполнения проекта команда может отклоняться от изначальных представлений. Команда может управлять отклонениями, так как она осуществляет поставку в более короткие сроки. Не так важна степень изменений и вариаций, как поставка клиентам ценности до окончания проекта.
Поставка заказчику отдельного свойства или законченной части работ является примером инкрементного подхода.
Например, у строителей может возникнуть потребность показать заказчику завершенное помещение или этаж в здании до продолжения работ в остальной его части. В этом случае они могут полностью выполнить работы на этаже с установкой недвижимого оборудования, завершением отделочных и прочих работ, которые должны быть произведены на данном этаже для приемки, прежде чем переходить к работам на следующем этаже. Заказчик может осмотреть и принять стиль, цвет и другие элементы, что дает возможность внести какие-то изменения до того, как будут произведены дальнейшие затраты рабочего времени и денежных средств. Это сокращает объемы возможной доработки и/или степень неудовлетворенности заказчика.
Завершенность и поставка являются субъективными понятиями. Команде может требоваться обратная связь в отношении прототипа, после чего она может принять решение о поставке минимально приемлемого продукта (minimum viable product, MVP) части заказчиков. Обратная связь с заказчиками помогает команде узнать, что из свойств конечного готового продукта ей необходимо обеспечить в последующих поставках.
Ключевое отличие agile-команды заключается в том, что она поставляет бизнес-ценность часто. При условии постепенного расширения набора свойств продукта и круга его потребителей, можно сказать, что его поставка осуществляется инкрементно.
В среде agile команда ожидает, что в требованиях будут происходить изменения. Итеративные и инкрементные подходы обеспечивают обратную связь, которая позволяет лучше планировать следующую часть проекта. Однако в проектах agile инкрементная поставка выявляет скрытые или неправильно понятые требования. На рис. 3–5 наглядно представлены два возможных способа осуществления инкрементной поставки так, чтобы проект был согласован с потребностями заказчика и при необходимости мог быть адаптирован.
Рис. 3–5. Итерационный и потоковый жизненные циклы agile
В случае итерационного жизненного цикла agile команда работает в рамках итераций (временные рамки имеют одинаковую длительность) с целью поставки завершенных свойств. Команда работает над наиболее важным свойством для его завершения силами всей команды. Затем команда приступает к работе над следующим по важности свойством и полностью завершает его. Команда может принять решение вести работу по нескольким свойствам сразу, но она не занимается всей работой для данной итерации одновременно (т. е. не занимается всеми требованиями по результатам всех анализов и т. д.).
В потоковом agile команда берет для работы свойства из бэклога в зависимости от своей ресурсной возможности начать работу, а не по основанному на итерациях расписанию. Команда определяет для себя поток работ с помощью столбцов доски задач и управляет незавершенными работами в каждом столбце. Для завершения работы по каждому свойству может требоваться разное время. Команды сохраняют небольшой объем незавершенных работ, чтобы было легче определить проблемы на раннем этапе и сократить объем доработок при возникновении необходимости внести изменения. Поскольку для определения точек планирования и контроля уже не используются итерации, команда и заинтересованные стороны со стороны бизнеса определяют наиболее целесообразное расписание для планирования, анализа продукта и ретроспективного анализа.
К жизненным циклам agile относятся те, в которых соблюдаются принципы Agile-манифеста. В частности, досрочная и непрерывная поставка имеющих ценность продуктов обеспечивает рост удовлетворенности заказчика. Кроме того, поставляемый инкрементно результат, который является функциональным и обладает ценностью, является главным показателем прогресса. В жизненных циклах agile в целях адаптации к условиям высоких темпов изменений и более частой поставки ценности проекта сочетаются итеративные и инкрементные подходы.