Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

При принятии мер по отдельной проблемной области или реализации нового гибридного подхода или подхода agile рекомендуется производить работы инкрементно. Обычная практика – относиться к процессу изменений как к проекту agile с его собственным бэклогом изменений, который может быть принят и приоритизирован командой на основе предполагаемой ценности или других соображений. К каждому из изменений можно относиться как к эксперименту, который проходит недолгое тестирование для установления приемлемости в состоянии «как есть» или необходимости дополнительной доработки/рассмотрения.

Для отслеживания прогресса используйте доски «канбан», показывающие новые и уже используемые подходы как «выполненные», проходящие испытания как «незавершенные» и ожидающие введения как «намеченные для исполнения». На рис. 6–3 представлен исходный вид доски с ранжированным бэклогом. На рис. 6–4 приведен пример того, как может выглядеть доска по мере выполнения работ.

Рис. 6–3. Исходный вид ранжированного бэклога для изменений

Рис. 6–4. Использование бэклогов и досок «канбан» для организации и отслеживания работ по изменениям

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

7. Призыв к действию

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

Сегодня стремление «быть agile» получило более широкое распространение, чем когда-либо. Споры о наилучшем пути к гибкости продолжают поддерживать поступательное развитие дискуссии и инноваций. Неизменной остается одна истина: инспекции, адаптация и прозрачность имеют решающее значение для успешной поставки ценности.

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

И наконец, мы призываем вас принять участие в работе с более широкими сообществами специалистов по управлению проектами и agile, чтобы углубить разговоры по этой тематике. Ищите представителей из PMI и Agile Alliance® на конференциях и собраниях и привлекайте их к дискуссии. Используйте социальные сети и излагайте в блогах свои соображения.

Вы можете обеспечить обратную связь и вступить в разговор о содержании этого Практического руководства в блоге под названием «Agile на практике» («Agile in Practice») по ссылке https://www.projectmanagement.com/blogs/347350/Agile-in-Practice.

Приложение A1. Картирование руководства PMBOK®

В таблице А1-1 показано соотношение групп процессов управления проектом с областями знаний, которые определены в Руководстве PMBOK® – Шестое издание.

В настоящем приложении описано, как при гибридном подходе и подходе agile рассматриваются свойства, описанные в областях знаний Руководства PMBOK® (см. таблицу А1-2). В нем, наряду с некоторыми указаниями, позволяющими повысить вероятность успеха, разъясняется, что остается неизменным, а что может выполняться иначе.

Таблица A1-1. Картирование групп процессов управления проектом и областей знаний

Таблица A1-2. Применение подходов agile в областях знаний Руководства PMBOK®

Таблица A1-2. Применение подходов agile в областях знаний Руководства PMBOK®(прод.)

Таблица A1-2. Применение подходов agile в областях знаний Руководства PMBOK® (прод.)

Таблица A1-2. Применение подходов agile в областях знаний Руководства PMBOK® (прод.)

Таблица A1-2. Применение подходов agile в областях знаний Руководства PMBOK®(прод.)

Приложение A2. Картирование Agile-манифеста

В этом приложении описывается, как элементы Agile-манифеста представлены в «Agile: практическое руководство».

Таблица A2-1. Ценности Agile-манифеста, представленные в «Agile: практическое руководство»

Таблица A2-2. Картирование «Agile: практическое руководство» по принципам, вытекающим из Agile-манифеста

Приложение A3. Обзор фреймворка agile и бережливого фреймворка

В настоящем приложении дано описание некоторых часто используемых подходов agile. Эти подходы можно использовать в оригинальном виде или в определенных сочетаниях с целью их адаптации так, чтобы обеспечить их максимальное соответствие определенной среде или ситуации. Если необходимость использовать какие-либо из них отсутствует, подход agile можно разработать с самого начала при условии, что он будет соответствовать образу мышления, ценностям и принципам Agile-манифеста. В случаях, когда принципы agile соблюдаются для поставки ценности устойчивыми темпами, а разработанный подход способствует сотрудничеству с заказчиком, применять особый подход не требуется. Ссылку на источники с дополнительной информацией о каждом подходе можно найти в разделе «Список использованной литературы» настоящего Руководства.

A3.1. КРИТЕРИИ ВЫБОРА ДЛЯ РАССМОТРЕНИЯ В «AGILE: ПРАКТИЧЕСКОЕ РУКОВОДСТВО»

Различных подходов и методов agile слишком много, чтобы их все можно было подробно описать в настоящем Практическом руководстве. На рис. А3-1 представлены примеры подходов agile на основе глубины указаний и ширины жизненных циклов этих подходов. Конкретные выбранные для обсуждения подходы являются широко распространенными примерами, которые:

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

♦ Формализованы для общего пользования. Некоторые фреймворки agile по своей природе являются частными и предназначены для использования в особых случаях в одной единственной организации или в рамках одного единственного контекста. Фреймворки, описанные в разделах с А3.2 по А3.14, предназначены для обычного использования в разнообразных контекстах.

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

Рис. A3-1. Подходы agile, представленные по ширине охвата и детализации

A3.2. СКРАМ

Скрам – это фреймворк процесса с участием одной команды, используемый для управления разработкой продукта. Этот фреймворк состоит из ролей, событий, артефактов и правил скрам и используется как итеративный подход для поставки работающего продукта. Скрам осуществляется в пределах временных рамок с фиксированной длительностью до 1 месяца, называемых «спринтами», в течение которых производятся инкременты продукта с потенциальной возможностью релиза. В таблице А3-1 перечислены события и артефакты скрам, используемые для исполнения проекта.

Скрам-команда состоит из владельца продукта, команды разработчиков и скрам-мастера.

♦ Владелец продукта отвечает за максимизацию ценности продукта.

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

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

Таблица А3-1. События и артефакты скрам

A3.3. ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ

Экстремальное программирование (eXtreme Programming, ХР) – это методология разработки программного обеспечения, основанная на частом повторении циклов разработки. Название вытекает из концепции выделения имеющейся передовой практики в ее наиболее чистой, простой форме и ее постоянного применения на всем протяжении проекта.

Метод XP получил известность, главным образом, благодаря популяризации ряда комплексных практик, предназначенных для улучшения результатов проектов по разработке программного обеспечения. Эта методология была впервые формализована в виде двенадцати основных практик, но в процессе последующего поступательного развития в нее были включены несколько других связанных с ними практик. Они приводятся в таблице А3-2.

Таблица А3-2. Практики экстремального программирования

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

A3.4. МЕТОД «КАНБАН»

Метод «канбан» в бережливом производстве – это система для контроля расписания и пополнения ресурсов. Этот процесс пополнения ресурсов «точно в срок» первоначально возник в гастрономах, где пополнение продуктов на полках производилось по мере появления на полках свободных мест, а не в зависимости от запасов у поставщика. На примере этих систем управления запасами по принципу «точно в срок» Тайити Оно (Taiichi Ohno) разработал метод «канбан», который был применен на главном производственном объекте компании Toyota в 1953 году.

Слово канбан буквально означает в переводе «рекламный щит» или «карточка». Реальные доски «канбан» с карточками создают необходимые условия и способствуют визуализации и потоку работы через систему так, чтобы он был представлен наглядно для всех. Информационная доска (большой дисплей) состоит из колонок, представляющих состояния, через которые поток работы должен пройти, чтобы работа была выполнена. Самые простые доски могут иметь три колонки (а именно: «нужно сделать», «делается» и «сделано»), но их можно адаптировать с указанием состояний, которые, по мнению использующих их команд, необходимы.

Метод «канбан» применяется и предназначен для использования во многих средах. Он позволяет осуществить непрерывный поток работы и ценности для заказчика. Метод «канбан» является менее директивным в сравнении с некоторыми подходами agile и, соответственно, менее деструктивным на начальном этапе его применения, поскольку является оригинальным принципом «начинай прямо там, где находишься». Организации могут сравнительно просто начать применять метод «канбан» с последующим переходом к его полному внедрению, если сочтут это необходимым или целесообразным.

В отличии от большинства подходов agile, метод «канбан» не предусматривает ограниченных временными рамками итераций. Итерации могут использоваться в рамках метода «канбан», однако принцип непрерывного проведения отдельных элементов через процесс и ограничения объемов незавершенных работ для оптимизации потока должен неукоснительно соблюдаться. Метод «канбан» лучше всего можно использовать в случаях, когда команде или организации необходимы следующие условия:

♦ Гибкость. Команды, как правило, не связаны временными рамками и занимаются имеющими наивысший приоритет работами, включенными в бэклог.

♦ Фокус на непрерывной поставке. Команды считают главной задачей организацию потока работы через систему до ее завершения и не начинают новую работу до завершения текущих работ.

♦ Повышенные производительность и качество. Производительность растет и качество улучшается благодаря ограничению объемов текущих работ.

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

♦ Сфокусированность членов команды. Ограничение объема текущей работы позволяет команде сосредоточить усилия на непосредственно выполняемой работе.

♦ Вариативность рабочей нагрузки. Когда существует непредсказуемость в порядке поступления работы и у команд больше нет возможности принимать прогнозируемые обязательства – даже на короткие периоды времени.

♦ Сокращение потерь. Прозрачность делает потери наглядными, так что их можно устранить.

Метод «канбан» вытекает из принципов бережливого мышления. Определяющие принципы и основные свойства метода «канбан» перечислены в таблице А3-3.

Метод «канбан» – это комплексный фреймворк, предназначенный для инкрементного, последовательно развивающегося процесса и системных изменений для организаций. В данном методе для продвижения работы в рамках процесса используется принцип «вытягивающая система» (pull system). По завершении командой отдельного элемента она может вытянуть другой элемент в данный шаг.

Таблица А3-3. Определение принципов и свойств метода «канбан»

Доски «канбан», подобные представленной на рис. А3-2, являются неавтоматизированной технологией низкого уровня, которая на первый взгляд может создать впечатление чересчур простой, однако те, кто их практически использует, очень скоро понимают их большие возможности. Доски «канбан» при использовании правил входа в колонки и выхода из них, а также ограничений, подобных ограничениям объемов текущих работ, обеспечивают ясное наглядное представление о потоке работ, узких местах, блокерах и общем статусе. Кроме этого, доска служит в качестве информационной доски для всех желающих, предлагая актуальную информацию о состоянии хода работ в команде.

Рис. A3-2. Доска «канбан», демонстрирующая ограничения объемов текущих работ и вытягивающую систему для оптимизации потока работ

В методе «канбан» самое важное – завершить работу, а не начать новую. Незавершенная работа не производит никакой ценности, поэтому команда работает коллективно, чтобы применять и поддерживать лимиты объемов текущей работы (work in progress, WIP) и провести все части работы через систему до состояния «сделано».

A3.5. МЕТОДИКИ CRYSTAL

Методики Crystal – это семейство методологий. Методологии Crystal предназначены для масштабирования и предусматривают выбор средств обеспечения строгости методологии в зависимости от размера (количество участвующих в проекте людей) и критичности проекта.

Рис. A3-3. Семейство методологий Crystal

Методология Crystal предусматривает, что каждый проект может потребовать применения ряда незначительно адаптированных политик, практик и процессов, чтобы обеспечить соответствие уникальным характеристикам проекта. В этом семействе методологий для определения методологии, которую следует использовать, применяются различные цвета в зависимости от «веса». Использование слова crystal (кристалл) связано с драгоценным камнем, где разные «грани» представляют главные основополагающие принципы и ценности. Эти грани служат представлением методов, инструментов, стандартов и ролей, перечисленных в таблице А3-4.

Таблица А3-4. Главные ценности и наиболее распространенные свойства методологии Crystal

^А _{Чем больше таких свойств в проекте, тем выше вероятность его успешного завершения.}

A3.6. СКРАМБАН

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

При подходе скрамбан работа организована в небольших спринтах, а доски «канбан» применяются для наглядного представления и мониторинга работы. Истории помещаются на доску «канбан», и команда организует свою работу с учетом ограничений на объемы текущей работы. Для поддержания сотрудничества между членами команды и устранения препятствий проводятся ежедневные совещания. Определяется триггер планирования, чтобы команда знала, когда в следующий раз заниматься планированием. Обычно это происходит тогда, когда уровень текущей работы опускается ниже установленного предварительно ограничения. В методе скрамбан отсутствуют предварительно определенные роли – команда сохраняет свои текущие роли.

A3.7. РАЗРАБОТКА НА ОСНОВЕ ФУНКЦИОНАЛЬНОСТИ

Разработка на основе функциональности (Feature-Driven Development, FDD) была создана для удовлетворения особых потребностей крупных проектов по разработке программных продуктов. Функциональные свойства соотносятся с возможностью создания небольшой бизнес-ценности.

В проекте по разработке на основе функциональности имеется шесть основных ролей, когда человек может играть одну или несколько из них:

♦ руководитель проекта,

♦ главный архитектор,

♦ руководитель разработки,

♦ главный программист,

♦ владелец класса, и (или)

♦ эксперт в прикладной области.

Организация проекта по разработке на основе функциональности осуществляется на основе пяти процессов или действий, которые осуществляются итеративно:

♦ разработка общей модели,

♦ создание списка свойств,

♦ планирование по свойствам,

♦ проектирование по свойствам,

♦ создание по свойствам.

Поток жизненного цикла и взаимодействия этих пяти процессов показаны на рис. А3-4.

Обеспечением операций разработки на основе функциональности служит основной набор передовых практик разработки программного обеспечения, а именно:

♦ объектное моделирование предметной области,

♦ разработка по свойствам,

♦ владение индивидуальными классами,

♦ закрепленные за свойствами команды,

♦ инспекции,

♦ управление конфигурацией,

♦ регулярные сборки,

♦ наглядность прогресса и результатов.

Рис. A3-4. Жизненный цикл проекта по разработке на основе функциональности

A3.8. ДИНАМИЧЕСКИЙ МЕТОД РАЗРАБОТКИ СИСТЕМ

Динамический метод разработки систем (Dynamic Systems Development Method, DSDM) – это фреймворк поставки проекта agile, изначально предназначенный для придания большей строгости существующим итеративным методам, получившим широкое распространение в 1990-е годы. Он был разработан как форма некоммерческого сотрудничества среди отраслевых лидеров.

DSDM известен, главным образом, своим упором на поставку на основе ограничений. Этот фреймворк устанавливает стоимость, качество и время с самого начала, и затем использует формальную приоритизацию содержания, чтобы обеспечить соблюдение этих ограничений, как показано на рис. А3-5.

Рис. A3-5. Подход DSDM к гибкости на основе ограничений

Порядок использования фреймворка DSDM определяют восемь принципов:

♦ фокус на потребности бизнеса,

♦ поставка в срок,

♦ сотрудничество,

♦ недопустимость снижения уровня качества,

♦ инкрементное создание продукта на твердой основе,

♦ итеративная разработка,

♦ непрерывные и ясные коммуникации,

♦ демонстрация контроля (использование соответствующих методов).

A3.9. УНИФИЦИРОВАННЫЙ AGILE-ПРОЦЕСС

Унифицированный agile-процесс (Agile Unifed Process, AgileUP) является ответвлением унифицированного процесса (Unifed Process, UP) для проектов по разработке программных продуктов. В сравнении с предшествовавшим ему унифицированным процессом он отличается ускоренными циклами и менее тяжеловесными процессами. Цель состоит в совершении большего числа итеративных циклов во всех семи ключевых дисциплинах, а также инкорпорировании полученной обратной связи до формальной поставки. Эти дисциплины, наряду с руководящими принципами, перечислены в таблице А3-5.

Таблица A3-5. Ключевые элементы унифицированного agile-процесса

A3.10. МАСШТАБИРУЕМЫЕ ФРЕЙМВОРКИ

A3.10.1. СКРАМ СКРАМОВ

Скрам скрамов (Scrum of Scrums, SoS), известный также под названием «мета-скрам» (meta Scrum) – это метод, используемый в случаях, когда у двух и более скрам-команд в составе от трех до девяти членов в каждой возникает необходимость в координации своей работы, чтобы не создавать одну большую скрам-команду. Представитель от каждой команды участвует в совещаниях с представителями других команд, потенциально каждый день, но на практике два-три раза в неделю. Такие ежедневные совещания проводятся аналогично ежедневным летучкам в скраме, когда представитель докладывает о выполненных работах, предстоящей на следующем этапе части работы, а также потенциальных предстоящих препятствиях, которые могут помешать работе других команд. Цель состоит в обеспечении того, чтобы команды координировали работу и устраняли препятствия для оптимизации эффективности всех команд.

Результатом крупных проектов с участием нескольких команд может стать проведение «скрам-скрама-скрамов» (Scrum of Scrum of Scrums), который имеет такую же схему, как и «скрам скрамов» (SoS), когда представитель каждого «скрама скрамов» докладывает на совещании большей группы представителей, как показано на рис. А3-6.

Рис. A3-6. Представители скрам-команд, участвующие в командах скрама скрамов

A3.11. МАСШТАБИРОВАННЫЙ AGILE-ФРЕЙМВОРК

Основная задача масштабированного agile-фреймворка (Scaled Agile Framework, SAFe®) состоит в формировании базы знаний о схемах масштабирования работы по разработке на всех уровнях предприятия.

В основе SAFe® лежат следующие принципы:

♦ учет экономических факторов;

♦ применение системного мышления;

♦ принятие изменчивости, сохранение вариантов;

♦ создание инкрементов в рамках быстрых, интегрированных циклов обучения;

♦ базовые контрольные события по объективной оценке работающих систем;

♦ наглядное представление и ограничение объема текущих работ, уменьшение размера порций работ и управление длинами очередей;

♦ применение каденции, синхронизация с межобластным планированием;

♦ высвобождение внутренней мотивации работников интеллектуального труда;

♦ децентрализация процесса принятия решений.

В фокусе SAFe® находятся практики детализации, роли и действия на уровнях портфеля, программы и команды с упором на организацию предприятия вокруг потоков ценностей, главная задача которых состоит в поставке непрерывной ценности заказчику.

A3.12. КРУПНОМАСШТАБНЫЙ СКРАМ (LESS)

Крупномасштабный скрам (Large Scale Scrum, LeSS) – это фреймворк, предназначенный для организации работы нескольких команд разработки для достижения общей цели, расширяющий метод скрам, представленный на рис. А3-6. Главный организационный принцип состоит в максимальном сохранении элементов традиционной модели фреймворка скрам для одной команды. Это помогает минимизировать расширения этой модели, которые могут стать причиной возникновения ненужной путаницы и сложности. В таблице А3-6 дано сравнение LeSS со скрамом.

Таблица A3-6. Сравнение LeSS со скрамом

Для расширения скрама без утраты его сущности LeSS поощряет применение определенных принципов здравомыслия, например, системного мышления, фокуса на продукте в целом, прозрачности и других.

A3.13. СКРАМ ПРЕДПРИЯТИЯ

Скрам предприятия – это фреймворк, предназначенный для применения метода скрам на более глобальном организационном уровне, а не на уровне единичной разработки продукта. В частности, этот фреймворк рекомендует руководителям организаций:

♦ распространить использование метода скрам на все аспекты деятельности организации;

♦ обобщить методы скрам, чтобы их можно было без труда применять к этим разнообразным аспектам;

♦ масштабировать метод скрам с использованием, по мере необходимости, дополнительных методов.

Цель состоит в использовании подходов agile за пределами исполнения проекта путем создания условий для применения прорывных инноваций.

A3.14. УПОРЯДОЧЕННЫЙ AGILE

Упорядоченный agile (Disciplined Agile, DA) – это фреймворк процесса принятия решений, где несколько передовых практик подхода agile интегрированы в одной комплексной модели. Фреймворк DA был разработан с целью предложить баланс между теми популярными методами, которые считались либо имеющими слишком узкий фокус (например, скрам), либо слишком директивными по детализации (например, AgileUP). Чтобы обеспечить этот баланс, в данном фреймворке объединяются воедино различные методы agile на основе следующих принципов:

♦ Сначала люди. Определение ролей и элементов организации на различных уровнях.

♦ Ориентация на обучение. Поощрение совместного совершенствования.

♦ Жизненный цикл полной поставки. Использование нескольких подходящих по назначению жизненных циклов.

♦ Ориентация на цель. Адаптация процессов для достижения конкретных результатов.

♦ Осознание интересов организации в целом. Предложение рекомендаций по управлению организацией на основе взаимодействия ее подразделений.

♦ Возможность масштабирования. Охват множества измерений сложностей программы.