Текст книги "Agile. Процессы, проекты, компании"

2.6. Гибридный цикл

Вы можете уговорить человека подписаться на нереалистичные сроки, но вы не сможете заставить его выполнить проект в такие сроки.

Джон Эдвардс, Джим Батлер, Барри Хилл, Сандра Расселл

Правильное сочетание предиктивных и адаптивных циклов может комбинировать преимущества и тех и других и называется гибридным или смешанным циклом. Вариантов совмещения «Водопада» с элементами Agile много.

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

♦ В другом варианте сначала происходят проработка и согласование бизнес-требований, планирование, финансирование, оценка затрат всего проекта в предиктивном варианте. Потом включаются параллельные виды работ: проектирование и разработка продукта, создание документации по адаптивным правилам. Здесь даже могут быть организованы несколько одновременно работающих команд. Испытания, сдача проходят также в «водопадном» варианте. Такое сочетание называют сэндвичем, или Water Scrum Fall, или как-то иначе. Возможны и другие термины – Iterative Agile, ScrummerFall, WaterScrum, AgileFall, Water-Agile-Fall.

Water Scrum Fall

Независимая исследовательская компания Forrester Research опубликовала отчет Дейва Уэста (тогда главного аналитика компании, а через два месяца ее вице-президента и директора по исследованиям) и его команды аналитиков, который называется «Water-Scrum-Fall – реальность Agile для большинства организаций сегодня».

♦ Интересны и перспективны гибридные варианты, например, в крупных проектах, где чисто «водопадное» мышление с высокой вероятностью ведет к неуспеху. Даже если на стадии детальной проработки и согласования ТЗ удастся избежать недопонимания и неправильной трактовки требований, к завершению полученный результат может уже устареть.

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

♦ Возможен вариант заключить рамочный договор, отказавшись от фиксирования содержания и фиксированного бюджета. После завершения каждого этапа, например после проектирования, смета уточняется, включая новые объемы с согласия заказчика, что оформляется дополнительным соглашением к первоначальному договору. Бюджет становится изменяемым, но заказчик получит то, что ему на самом деле нужно и влияет на объем и содержание работ.

♦ Некоторая гибкость в предиктивном проекте с жесткими сроками может быть создана путем переоценки остающегося к концу проекта объема вместе с заказчиком. Оставшиеся фактические объемы, которые невозможно закончить целиком, делятся на три части: то, что обязательно должно быть выполнено (исполнитель берет это как жесткое обязательство); то, что заказчик может назвать важным, но несрочным (это переносится в будущее и выполняется ресурсами исполнителя или в рамках нового проекта по договоренности с заказчиком), и то, что заказчик уже может счесть неактуальным и от чего может отказаться (этот объем не делается совсем). Переносимый на будущее объем работ называется в ИТ-отрасли техническим долгом.

♦ Может быть организован цикл, когда заказчик практически сам ставит задачи либо наблюдает за работой команды и контролирует сроки. Оплачивается только отработанное время (Time & Materials). Некоторые риски опасений в нетрудолюбии исполнителя могут быть сняты, если заказчик рядом, постоянно наблюдает за развитием и результатами, в том числе через систему листа учета рабочего времени. Этот подход довольно распространен за рубежом.

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

♦ Возможна гибкость и в EPC-договорах (фиксированных договорах, включающих проектирование, поставки и строительство), хотя такой договор – это классический «Водопад» с большим количеством промежуточных этапов, или итераций, где для каждой итерации установлены жесткие ограничения по срокам, затратам и ресурсам и предусмотрены заранее оговоренные действия при возможных нарушениях. Внутрь всего «водопадного» цикла можно вложить внутренний Agile-цикл с перечнем требований и перечнем задач. Формируется роль владельца продукта как внутреннего (от исполнителя) менеджера, контролирующего общую концепцию проекта. Вводится роль администратора по поддержке работы команды (скрам-мастер). Работа команды ведется по коротким итерациям. Для заказчика «снаружи» в этом случае сохраняется приемлемая для него схема фиксированной цены. Для исполнителей обеспечивается использование Agile, но с жестким контролем концепции и заранее продуманными ограничениями на каждую итерацию.

Возможный пример организации проекта

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

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

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

2.7. Как выбрать «правильный» цикл?

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

Рори Бурк, Enterprise Enablement

Когда в проекте применить адаптивный (Agile-) цикл, а когда – каскадный вид, зависит от целого ряда моментов, таких как тип проекта, ограничения заказчика, культура компании, сложившиеся практики и др.

Предпочтительному использованию Agile способствуют такие факторы, как:

♦ начальная высокая неопределенность в содержании проекта; непонятная скорость появления новых требований;

♦ сложное наполнение проекта;

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

♦ желание реализовывать изменения за меньшую цену из-за частых инкрементов или итераций;

♦ непростые требования заказчика или невозможность их согласовать;

♦ новые, непроверенные технологии.

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

Если в проектах:

♦ полная предсказуемость с начала и до конца;

♦ четкие вводные и малоизменяемые цели, поддающиеся полному планированию;

♦ типовые технологии в знакомых комбинациях;

♦ ценность видна и нужна только при завершении проекта;

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

В приложении 1 приведен чек-лист для более точного выбора подхода.

Спринт 3
Фокус на Agile

Введение

Проект считается завершенным, когда он начинает работать на вас, а не вы на него.

Скотт Аллен, Microsoft

В рамках спринта под номером 3 вы получите всю основную информацию о том, что такое Agile. Это позволит понять, если ли Agile у вас в компании, правильно ли он определен и применяется, а также что надо объяснить руководству, если возникнет вопрос об Agile.

3.1. Преимущества

Высокая скорость движения не имеет смысла, если неизвестен пункт назначения. Не путайте процесс с результатом.

Мэйбел Ньюкомбер

Заметим, что гибкость (здесь и далее я часто буду использовать Agile и «гибкость» как синонимы) применима не всегда. Даниэль Пинк в своей книге «Драйв, или Что нас на самом деле мотивирует» (см. список литературы) разделил человеческую деятельность на два типа задач:

♦ эвристические задачи, где нет заранее известной инструкции, алгоритма решения, нет точно обозначенной цели.

Есть примерные очертания: нарисовать такую рекламу, чтобы все ахнули, определить непонятную причину поломки оборудования, разработать уникальный способ обучения, удивить подарком близких и т. д. От исполнителя требуется самостоятельно найти решение;

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

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

Кроме эвристичности, в основе Agile-мышления лежат:

♦ фокус на создании ценности для заказчика, куда направляются все время и усилия, которые расходуются в проекте. Но также минимизируется то, что ценности не несет;

♦ разделение рисков между исполнителем и заказчиком;

♦ регулярная обратная связь;

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

♦ самоорганизация команды, включающей представителя заказчика, выражающего интересы бизнеса;

♦ команда разработчиков, которая сама распределяет задачи, имеет внутреннюю ответственность и, соответственно, будет гарантировать производительность труда и качество продукта;

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

К применению Agile ведут и внешние факторы:

♦ высочайшая конкуренция, и не столько в продуктах и сервисах, сколько в моделях доставки их до клиента или в моделях управления желаниями клиентов, когда клиенты хотят все сразу, качественно, быстро и дешевле, чем у других; 30 % опрошенных мечтают об ускорении выпуска продуктов на рынок, то есть об улучшении Time-To-Market;

♦ уход от долгосрочного прогнозирования (когда надо забыть «пятилетки», «трехлетки» или жесткие стратегические программы) в VUCA-мире, когда темпы изменения экономической среды настолько высоки, что неизвестно, что будет актуально на рынке уже сегодня вечером;

♦ 29 % опрошенных хотят управлять постоянно меняющимися приоритетами;

♦ исторически или ментально сформированная и абсурдная бюрократия, затянутость и сложность принятия решений, неповоротливость компаний с решениями, которые не принимаются, а растворяются… и многое другое; 23 % опрошенных хотят улучшить взаимодействие бизнеса, сервиса, ИТ-решений, больших данных.

Если руководство вас спрашивает, в чем разница между хаосом или бардаком (а именно такие понятия несведущие часто отождествляют с Agile) и гибкими подходами, то можно дополнительно использовать и другие аргументы:

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

♦ улучшение качества продукции за счет быстрой реакции клиента (в конечном продукте число дефектов минимизируется, поскольку проверка качества проводится по завершении каждой итерации);

♦ Agile-проект быстро запускается, не надо ждать всех согласований;

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

♦ уменьшение рисков переделок опять же за счет постоянной реакции клиента;

♦ упрощение процессов (не делаем лишнего, все делают то, что должны, сложное разбито на простое);

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

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

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

Финансисты также жалуют Agile, который дает возможность:

♦ экономить средства, не прорабатывая проектные документы в течение длительного времени;

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

♦ вносить коррективы без существенных финансовых потерь для предприятия;

♦ осуществлять ранний запуск продукции и получать первые доходы.

3.2. Ограничения

Нельзя держать все в голове. Для управления крупным проектом просто необходимы инструменты контроля.

Льюис Фрид

Выше прозвучали похвалы в адрес Agile. Нельзя не остановиться и на ограничениях, хотя все относительно.

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

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

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

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

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

3.3. Agile или «Водопад»?

«Водопад» – это проект по правилам, Agile – это проект без правил.

Российские менеджеры крупной международной компании

При использовании предиктивных циклов формируются следующие особенности.

Команда:

♦ создается под проект и расформировывается после;

♦ состав может меняться, и даже часто;

♦ допустимы узкопрофильные специалисты.

Руководитель проекта:

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

♦ важность внимания развитию зрелости и эффективности его роли в проекте;

♦ заинтересованность в точном соблюдении сроков и бюджета;

♦ сопротивление изменению утвержденного объема работ.

Процессы:

♦ важность планирования работы с ресурсными пулами, подразделениями, взаимодействия с ними;

♦ работа различных подразделений координируется через руководителя проекта;

♦ ресурсы от подразделений взаимодействуют с проектом через руководителей подразделений;

♦ связи проекта с подразделениями оформляются в виде задач и ставятся в планы подразделений, иногда с очень низким приоритетом;

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

♦ для усиления контроля увеличивается степень бюрократизации процесса;

♦ при риске нарушения сроков или бюджета в жертву приносится качество продукта;

♦ изменение требований по ходу проекта часто приводит к его задержке;

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

♦ регулярная поставка улучшений в документах;

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

♦ бюджет составляется под определенный объем работ;

♦ проект часто финансируется вне зависимости от того, существует ли физическая возможность реализовать его имеющимися ресурсами.

В Agile особенности следующие.

Команда:

♦ формируются стабильные команды вокруг продуктов, а не разовых проектов;

♦ внимание развитию навыков работы в командах, их зрелости и эффективности;

♦ команды заинтересованы в поставке ценности бизнесу и конечному пользователю;

♦ фокус на планировании работы целых команд;

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

♦ независимые кросс-организационные команды с общими планами и ответственным руководителем.

Процессы:

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

♦ при появлении проблемы – исследование ее корневых причин и способов противодействия им;

♦ для избавления от проблем – проведение экспериментов и в случае успеха экспериментов – проведение улучшений;

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

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

♦ валидация результатов в конце итерации после обратной связи от заказчика;

♦ коммуникация лицом к лицу;

♦ регулярная поставка улучшений продукта;

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

♦ фиксация бюджета под итерации и поток ценности.

3.4. Ключевые компоненты Agile

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

Джон Эдвардс, Джим Батлер, Барри Хилл, Сандра Расселл

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

Компонентами Agile является следующее.

♦ Визуализация коммуникаций, планирования и контроля, скрам– или канбан-доски, военные комнаты (Обея), инфопанели с электронными данными и многое другое.

Канбан-доска

В одном проекте команда расположила на стене карточки различных цветов и видов, которые обозначали элементы конечного продукта. Спланированные, разработанные, протестированные и уже выпущенные элементы были одного цвета, а спланированные, разработанные, протестированные, но еще не выпущенные (однако уже готовые к выпуску) – другого. Команда смогла с легкостью изучить положение дел для каждого набора элементов.

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

♦ Применение гибкого планирования. Например, модель М. Кона, «луковица планирования» (The Planning Onion, 2005), которая последовательно описывает слои, или уровни, планирования: стратегия, портфель, продукт, релиз (выпуск), итерация, день. Команда Agile в основном связана с тремя самыми внутренними слоями: релизом, итерацией и дневным горизонтом. При первоначальном планировании релиза основное внимание уделяется объему, срокам и ресурсам, и этот план постепенно обновляется. Компоненты планирования релиза иногда называются историями или темами. Планирование итераций проводится в начале новой итерации. Их можно назвать задачами. Самый низкий уровень – ежедневное планирование с помощью летучек, на которых координируется работа и синхронизируются ежедневные усилия. Более высокие три уровня – стратегия, портфель, продукт – обычно не касаются Agile-команд, хотя при планировании продукта его владелец смотрит дальше, чем только на отдельный релиз. Для планирования всего продукта и/или даже комплекса продуктов также используется термин «дорожная карта».

♦ Применение командных оценок. Поскольку вся команда будет выполнять работу, все члены команды будут давать оценки. Рабочие элементы часто называются пользовательскими историями, а оценки, применяемые для выражения общего размера истории пользователя, часто называются относительными «стори пойнтами» (story points) или пунктами. История пользователя размером два «стори пойнта» должна быть в два раза больше истории размером один «стори пойнт». Нет какой-то формулы для определения размеров истории; оценка – это смесь усилий, сложности и риска и т. д.

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

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

Суть Agile

«Agile базируется на трех вещах: 1) принципы, не методики; 2) внимание к людям и 3) всегда приспосабливайся»[5]5
  http://experience.openquality.ru/agile-ruined-my-life/


[Закрыть].

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

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

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

♦ Руководство и сотрудничество в противовес административным указам и жесткому контролю. Agile тесно связан с лидерством. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта и исключить все барьеры в нем.

♦ Фокус на бизнесе. Оценка приоритетов на основе значимости в бизнесе позволяет не допустить чрезмерного углубления команды только в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности.

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