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

Приложение Х1. Авторы и рецензенты

X1.1. ОСНОВНОЙ КОМИТЕТ «AGILE: ПРАКТИЧЕСКОЕ РУКОВОДСТВО»

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

X1.1.1. ПРЕДСТАВИТЕЛИ ИНСТИТУТА УПРАВЛЕНИЯ ПРОЕКТАМИ (PROJECT MANAGEMENT INSTITUTE, PMI):

Mike Grifths, PMP, PMI-ACP, (председатель Комитета)

Jesse Fewell, CST, PMI-ACP

Horia Slușanschi, PhD, CSM

Stephen Matola, BA, PMP

X1.1.2. ПРЕДСТАВИТЕЛИ AGILE ALLIANCE:

Johanna Rothman, MS (заместитель председателя Комитета)

Becky Hartman, PMI-ACP, CSP

Betsy Kaufman, ICP-ACC, PMI-ACP

X1.2. РЕЦЕНЗЕНТЫ – ЭКСПЕРТЫ ПО ПРЕДМЕТНЫМ ОБЛАСТЯМ «AGILE: ПРАКТИЧЕСКОЕ РУКОВОДСТВО»

Следующие специалисты работали в качестве приглашенных экспертов по предметным областям, которые отвечали за рецензирование черновика и давали рекомендации в процессе SME-рецензирования.

Joe Astolf, PMP, PSM

Maria Cristina Barbero, PMI-ACP, PMP

Michel Biedermann, PhD, PMI-ACP

Zach Bonaker

Robert Bulger, PfMP, CSM

Sue Burk

Shika Carter, PMP, PMI-ACP

Lauren Clark, PMP, CSM

Linda M Cook, CSM, CSPO

Pamela Corbin-Jones, PMI-ACP, CSM

Jef Covert

Alberto Dominguez, MSc, PMP

Scott P. Duncan, CSM, ICP-ACC

Sally Elatta, PMI-ACP, EBAC

Frank R. Hendriks, PMP, PMI-ACP

Derek Huether

Ron Jefries

Fred Koos

Philippe B. Kruchten, PhD, PEng

Steve Mayner, SPCT4, PMP

Michael S. McCalla, PMI-ACP, CSP

Don B. McClure, PMP, PMI-ACP

Anthony C. Mersino, PMI-ACP, CSP

Kenneth E. Nidifer, PhD, PMP

Michael C. Nollet, PMP, PMI-ACP

Laura Paton, MBA, PMP

Yvan Petit, PhD, PMP

Dwayne Phillips, PhD, PMP

Piyush Prakash, PMP, Prince2

Dave Prior, PMP, CST

Daniel Rawsthorne, PhD, PMP

Annette D. Reilly, PMP, PhD

Stephan Reindl, PMI-ACP, PMP

Reed D. Shell, PMP, CSP

Cindy Shelton, PMP, PMI-ACP

Teresa Short

Lisa K. Sieverts, PMP, PMI-ACP

Christopher M. Simonek, PMP, CSM

Robert "Sellers" Smith, PMP, PMI-ACP

Ram Srinivasan, PMP, CST

Chris Stevens, PhD

Karen Strichartz, PMP, PMI-ACP

Rahul Sudame, PMI-ACP

Joanna L. Vahlsing, PMP

Erik L. van Daalen

Annette Vendelbo, PMP, PMI-ACP

Dave Violette, MPM, PMP

Anton Vishnyak, PMI-ACP, CSM

Chuck Walrad, MA, MS

X1.3. ФОКУС-ГРУППА ПО ФОРМАТИРОВАНИЮ

Следующие специалисты участвовали в разработке нового стиля представления содержания и элементов форматирования для «Agile: практическое руководство».

Goran Banjanin, PgMP, PMP

Andrew Craig

Cătălin-Teodor Dogaru, PhD, PMP

Jorge Espinoza, PMP

Jennifer M. Forrest, CSM, PMP

Helen Fotos, PMP, PMI-ACP

Dave Hatter, PMP, PMI-ACP

Christopher Healy, PMP

Mike Hofmann, MBA, PMP

Chadi Kahwaji, PMP

Rajaraman Kannan, PMP, MACS CP

Amit Khanna PMP, PMI – ACP

Ariel Kirshbom, PMI-ACP, CSP

Bernardo Marques, PMP

Noura Saad, PMI-ACP, CSPO

Kurt Schuler, PMP

Demetrius L. Williams, MBA, PMP

Liza Wood

Melody Yale, CSP, SPC4

X1.4. ГРУППА ЧЛЕНОВ-КОНСУЛЬТАНТОВ (MEMBER ADVISORY GROUP, MAG) ПО СТАНДАРТАМ PMI

Следующие специалисты работали в составе Группы членов-консультантов по стандартам PMI, которые давали рекомендации по стандартам PMI и окончательное одобрение от имени PMI в ходе подготовки «Agile: практическое руководство».

Maria Cristina Barbero, PMI-ACP, PMP

Brian Grafsgaard, PMP, PgMP

Hagit Landman, PMP, PMI-SP

Yvan Petit PhD, PMP

Chris Stevens, PhD

Dave Violette, MPM, PMP

John Zlockie, MBA, PMP, руководитель по стандартам PMI

X1.5. СОВЕТ ДИРЕКТОРОВ AGILE ALLIANCE®

Следующие специалисты являются членами Совета директоров Agile Alliance, которые давали рекомендации и окончательное одобрение от имени Agile Alliance в ходе подготовки «Agile: практическое руководство».

Juan Banda

Phil Brock (исполнительный директор)

Linda Cook

Stephanie Davis

Ellen Grove

Paul Hammond (председатель)

Victor Hugo Germano

Rebecca Parsons (секретарь)

Craig Smith

Declan Whelan

X1.6. ТЕХНИЧЕСКИЙ ПЕРСОНАЛ PMI И НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЕ ОБЕСПЕЧЕНИЕ

Следующие специалисты обеспечивали поддержку Основного комитета в ходе разработки и одобрения проекта Руководства, при оказании поддержки группы, ответственной за форматирование, и работы PMI по маркетингу.

Melissa M. Abel, специалист по маркетинговым коммуникациям

Karl F. Best, PMP, CStd, специалист по стандартам

Alicia C. Burke, MBA, CSM, руководитель продукта, подтверждение квалификации

Edivandro C. Conforto, PhD, консультант PMI по исследованиям в области Agile

Dave Garrett, CSPO, вице-президент по трансформации

Erica Grenfell, административный помощник вице-президента, организационные отношения

M. Elaine Lazar, MA, MA, AStd, специалист по проектам

Andrew Levin, PMP, руководитель проекта

Tim E. Ogline, дизайнер пользовательского взаимодействия

Stephen A. Townsend, директор сетевых программ

Michael Zarro, PhD, исследователь пользовательского взаимодействия

X1.7. ПРОИЗВОДСТВЕННЫЙ ПЕРСОНАЛ PMI

Donn Greenberg, менеджер, Отдел публикаций

Kim Shinners, сотрудник отдела подготовки публикаций

Roberta Storer, редактор конечного продукта

Barbara Walsh, ответственный издатель

X1.8. ЧЛЕНЫ КОМИТЕТА ПО ПРОВЕРКЕ ПЕРЕВОДА НА РУССКИЙ ЯЗЫК

Valerii Funtov, DrSc, PMP

Mikhail Lazarev, PMP

Kirill Melnikov, PhD, PMP

Konstantin Trunin, PMP

X1.9. КОМИТЕТ ПО ПРОВЕРКЕ ПРАВИЛЬНОСТИ ПЕРЕВОДА

Barbara Walsh, ответственный издатель

Margaret Lyons, разработчик экзаменационных материалов

Stephen Townsend, директор, Network Programs

Vivian Isaak, президент бюро переводов Magnum Group, Inc.

Brian Middleton, менеджер по стратегическим решениям бюро переводов Magnum Group, Inc.

Приложение Х2. Свойства, влияющие на адаптацию

X2.1. ВВЕДЕНИЕ

Настоящее приложение содержит высокоуровневые указания о том, когда и как требуется осуществлять адаптацию подходов agile. Его можно использовать для определения обстоятельств, которые могут послужить основанием для внесения изменений или применения новых методов. Кроме того, здесь содержатся некоторые рекомендации для принятия во внимание.

Модель приобретения навыков «сюхари» (Shu-Ha-Ri) описывает порядок последовательного перехода от соблюдения правил («Сю» 守 означает повиновение и защиту) через осознанное отступление от правил («Ха» 破 означает изменение или отступление) и, наконец, определение в процессе последовательной практики и совершенствования собственного пути («Ри» 離 означает отделение или отход). Сначала нужно приступить к деятельности и пройти практику на уровне «Сю», чтобы подготовится к переходу на уровень «Ха» для адаптации процесса или на уровень «Ри» для создания нового кастомизированного процесса.

X2.2. СНАЧАЛА НЕСКОЛЬКО ПРЕДУПРЕЖДЕНИЙ

Адаптация – это продвинутая тема обсуждения для опытных специалистов-практиков, которые, прежде чем рассматривать возможность адаптации подходов agile, ранее успешно использовали такие подходы в соответствии с оригинальным описанием их применения в разнообразных средах. Другими словами, сначала нужно приобрести опыт и добиться успеха в применении того или иного подхода, прежде чем пытаться его адаптировать.

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

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

X2.3. КАК ИСПОЛЬЗОВАТЬ ЭТО ПРИЛОЖЕНИЕ

Чтобы можно было извлечь выгоду от содержащихся в настоящем приложении указаний, рекомендуем сначала добиться успешного использования подходов agile в исходном виде. Затем следует изучить указания по адаптации, приведенные в таблице Х2-1, которые применимы к данной ситуации, и ознакомиться с соответствующими рекомендациями. Далее обсудите изменения и согласуйте порядок действий с людьми, на которых они окажут воздействие.

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

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

Наконец, успешно принятые адаптированные подходы можно принять официально, введя их в число стандартных процессов, используемых в проектах, которые имеют общие характеристики. Рекомендуется также соблюдать приведенные в разделе 5 указания, которые описывают порядок принятия (или адаптации) новых подходов.

X2.4. РЕКОМЕНДАЦИИ ПО АДАПТАЦИИ

Ниже перечислены некоторые хорошие практики, которые следует рассмотреть, прежде чем приступать к адаптации подхода.

X2.4.1. НУЖНА ОСТОРОЖНОСТЬ ПРИ ОТКАЗЕ ОТ ЧЕГО-ЛИБО

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

X2.4.2. ИСПОЛЬЗОВАНИЕ ТАБЛИЦЫ С УКАЗАНИЯМИ ПО АДАПТАЦИИ

С помощью таблицы Х2-1 найдите обстоятельства, которые соответствуют определенной ситуации и рассмотрите рекомендации по адаптации. Обсудите любые изменения с теми, на кого они окажут влияние, и для начала запланируйте краткосрочное испытание наряду с последующим добросовестным анализом по результатам испытаний, прежде чем окончательно принять предлагаемые изменения.

Таблица X2-1. Указания по адаптации

Таблица X2-1. Указания по адаптации (прод.)

Таблица X2-1. Указания по адаптации (прод.)

Приложение X3. Инструменты фильтров применимости agile

X3.1. ВВЕДЕНИЕ

В литературе по agile предлагается много инструментов фильтров, используемых для оценки того, при каких обстоятельствах может быть целесообразно применять подход agile. В 1994 г. в рамках динамического метода разработки систем (DSDM) были созданы «Анкета оценки применимости agile к проекту» (Agile Project Suitability Questionnaire) и «Анкета оценки применимости к организации» (Organizational Suitability Questionnaire), предназначенные для измерения вероятности соответствия требованиям, а также для определения потенциальных проблемных областей.

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

За период после разработки этих подходов появилось еще много моделей, предназначенных для определения условий и времени применения подхода agile. Бем (Boehm) и Тернер (Turner) взяли на вооружение некоторые элементы из DSDM и Crystal для разработки популярной модели оценки, помогающей определить при осуществлении проектов целесообразность использования agile или более традиционных подходов.

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

X3.2. КРАТКИЙ ОБЗОР МОДЕЛИ

Оценка свойств организации и проекта производится по трем основным категориям:

♦ Культура. Имеется ли благоприятная среда с поддержкой данного подхода и доверием внутри команды?

♦ Команда. Имеет ли команда подходящий размер для успеха в использовании agile, обладают ли ее члены необходимым опытом и доступом к представителям бизнеса для достижения успеха?

♦ Проект. Имеют ли место высокие темпы изменений? Возможна ли инкрементная поставка? Насколько критическое значение имеет проект?

На вопросы в каждой из указанных категорий даются ответы, а результаты изображаются на лепестковой диаграмме. Группы значений вокруг центра диаграммы показывают высокую степень приемлемости использования подходов agile. Результаты вдоль внешнего края показывают, что более целесообразным может быть предиктивный подход. Значения в средней части (в промежуточной области между подходом agile и предиктивным подходом) указывают, что хороший результат мог бы дать гибридный подход. Пример диаграммы показан на рис. Х3-1.

Рис. X3-1. Модель применимости подхода agile

X3.3. УКАЗАНИЯ ПО ПРИМЕНЕНИЮ

X3.3.1. ЗАПОЛНИТЕ АНКЕТУ ВСЕЙ ГРУППОЙ

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

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

X3.3.2. ДАЙТЕ ОЦЕНКУ ПО ВОПРОСАМ В БАЛЛАХ ОТ 1 ДО 10

В составе группы обсудите и согласуйте (или найдите компромиссное решение) балл, который наиболее точно отражает субъективную оценку для данного вопроса. Хотя конкретные варианты ответа предлагаются только для начальной, средней и конечной позиций, соответствующих баллам 1, 5 и 10 полного диапазона ответов на вопрос, вполне допустимо (и даже желательно) использовать такие баллы, как 2, в случае ответа «почти, но не совсем 1», или 7 при ответе «где-то между 5 и 10». Стоит повторить, что оценка – это инструмент дискуссии: мнения будут иметь субъективный характер, и следует ожидать наличия в них неопределенности.

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

X3.3.3. ИНТЕРПРЕТИРУЙТЕ РЕЗУЛЬТАТЫ

Пометьте ответы на вопросы на бланке диаграммы оценки применимости и соедините точки. Группирование результатов вокруг центра в зоне agile показывает приемлемость использования подхода agile в чистом виде.

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

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

X3.4. ВОПРОСЫ ПО ФИЛЬТРУ ПРИМЕНИМОСТИ

X3.4.1. КАТЕГОРИЯ: КУЛЬТУРА

X3.4.1.1. ПОДДЕРЖКА ПОДХОДА

Понимает ли главный спонсор суть использования подхода agile для данного проекта и согласен ли он поддержать данный проект? См. рис. X3-2.

Рис. Х3-2. Оценка поддержки подхода

X3.4.1.2. ДОВЕРИЕ В КОМАНДЕ

Стоит изучить мнение спонсоров и представителей бизнеса, которые будут работать с командой. Имеют ли эти заинтересованные стороны уверенность, что команда в состоянии претворить их видение и потребности в успешный продукт или услугу при постоянной двусторонней поддержке и обратной связи между сторонами? См. рис. X3-3.

Рис. X3-3. Оценка доверия в команде

X3.4.1.3. ПОЛНОМОЧИЯ КОМАНДЫ НА ПРИНЯТИЕ РЕШЕНИЙ

Будет ли команда иметь самостоятельность в принятии своих собственных решений по вопросам выполнения работы? См. рис. X3-4.

Рис. X3-4. Оценка полномочий команды на принятие решений

X3.4.2. КАТЕГОРИЯ: КОМАНДА

X3.4.2.1. РАЗМЕР КОМАНДЫ

Какой размер имеет основная команда? Используйте следующую шкалу: 1–9 = 1, 10–20 = 2, 21–30 = 3, 31–45 = 4, 46–60 = 5, 61–80 = 6, 81-110 = 7, 111–150 = 8, 151–200 = 9, 201+ = 10. См. рис. X3-5.

Рис. X3-5. Оценка размера команды

X3.4.2.2. УРОВНИ ОПЫТА

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

Рис. X3-6. Оценка уровня опыта

X3.4.2.3. ДОСТУП К ЗАКАЗЧИКУ/БИЗНЕСУ

Будет ли у команды ежедневный доступ, по крайней мере, к одному представителю заказчика/бизнеса для уточнения возникающих вопросов и обратной связи? См. рис. X3-7.

Рис. X3-7. Оценка доступа к заказчику/бизнесу

X3.4.3. КАТЕГОРИЯ: ПРОЕКТ

X3.4.3.1. ВЕРОЯТНОСТЬ ИЗМЕНЕНИЙ

Каков процент требований, которые могут с определенной степенью вероятности измениться или проявиться на протяжении месяца? См. рис. X3-8.

Рис. X3-8. Оценка вероятности изменений

X3.4.3.2. КРИТИЧНОСТЬ ПРОДУКТА ИЛИ УСЛУГИ

Чтобы помочь определить вероятные уровни дополнительных верификаций и строгости документов, которые могут потребоваться, оцените критичность производимого продукта или услуги. Используя оценку, которая учитывает ущерб, возникающий в результате возможных последствий дефектов, определите, каким может быть результат неуспеха. См. рис. Х3-9.

Рис. X3-9. Оценка критичности продукта или услуги

X3.4.3.3. ИНКРЕМЕНТНАЯ ПОСТАВКА

Можно ли создавать и оценивать продукт или услугу по частям? Кроме того, будут ли доступны представители заказчика или бизнеса для своевременной обратной связи по вопросам поставленных инкрементов? См. рис. X3-10.

Рис. X3-10. Оценка инкрементной поставки

X3.5. ДИАГРАММА ОЦЕНКИ ПРИМЕНИМОСТИ

На рис. Х3-11 представлена лепестковая диаграмма, используемая для оценки применимости.

Рис. X3-11. Лепестковая диаграмма оценки применимости

X3.5.1. ПРАКТИЧЕСКИЕ ПРИМЕРЫ

Для иллюстрации того, как работает лепестковая диаграмма, рассмотрим два примера использования данной модели для оценки в баллах проектов различного типа. Первый является примером проекта интернет-аптеки (см. рис. Х3-12), а второй (рис. Х3-13) – военной системы обмена сообщениями. Эти два практических примера иллюстрируют некоторые различия, которые можно наблюдать при сравнении разных проектов. Концентрация значений в центре означает хорошую приемлемость использования подходов agile, разброс баллов по периферии говорит о том, что предиктивные подходы могут оказаться более целесообразными. Баллы некоторых проектов концентрируются в средней части, но имеют пики по одной или двум осям. Для таких проектов лучше всего подходит гибридный подход.

Рис. X3-12. Проект аптечного интернет-магазина

X3.5.1.1. ПРИМЕР АПТЕЧНОГО ИНТЕРНЕТ-МАГАЗИНА

Проект был предпринят с целью создать интернет-аптеку для продажи более дешевых канадских рецептурных лекарств покупателям (преимущественно) в США. Продажа этих лекарств является предметом споров и в Канаде, и в США, и в результате для этой отрасли характерны быстрые изменения в государственно-правовом регулировании и острая конкуренция. Проект осуществлялся в условиях постоянно меняющихся требований, когда серьезные изменения происходили каждую неделю. Использовались очень короткие (двухдневные) итерации и еженедельные релизы, чтобы решить проблему высоких темпов изменений.

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

X3.5.1.2. ПРИМЕР ВОЕННОЙ СИСТЕМЫ ОБМЕНА СООБЩЕНИЯМИ

Сравните первый пример с крупным проектом по разработке военной системы обмена сообщениями, которая на момент проведения оценки, работала уже в течение 5 лет. См. рис. X3-13.

Рис. X3-13. Пример военной системы обмена сообщениями

Поддержка подхода agile отсутствовала, поскольку подход agile не рассматривался. Доверие поставщикам было смешанным, но в целом присутствовало. Решения принимались не на местном уровне, а комитетами по архитектуре и требованиям. Хотя имелась возможность тестировать элементы проекта инкрементно (по частям) в лабораторных условиях, их невозможно было собрать вместе для полномасштабной демонстрации функциональности. Потенциально существовал риск для жизни многих людей, поэтому уровень критичности был очень высоким. Требования были фиксированы, поскольку их изменения влияли на работу очень большого числа организаций-субподрядчиков.

Проект был крупным, с участием более 300 человек только от одного поставщика, но в исполнении каждой роли участвовало много опытных специалистов-практиков. И наконец, доступ к бизнесу/заказчику был невозможен, но можно было связаться со специалистами по договорам, которым можно было задать вопросы по спецификации, и они обычно давали ответы или задавали уточняющие вопросы в течение 10 дней. Часть проекта можно было выделить и осуществлять как проекты agile, но в центре работы был один единственный крупный проект.

X3.6. ВЫВОДЫ

Фильтры применимости подхода agile являются полезным инструментом для определения потенциальных соответствий и несоответствий для использования подхода agile. Их следует использовать не в качестве конкретных триггеров включения или исключения, а как темы для объективного обсуждения со всеми заинтересованными сторонами.