Валерий Николаевич Фунтов
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].
Майк Кон (2005): «Рассматривайте проект как быстро и надежно генерирующий поток полезных новых возможностей и новых знаний. Новые возможности поставляются в продукте; новые знания используются, чтобы сделать продукт лучше, чем он может быть».
♦ Совместная работа и сотрудничество всей команды для получения хороших результатов, объективных мнений и реализации всех полученных знаний на следующей итерации. Одновременно постоянство объективных мнений и улучшений. Тесное сотрудничество с клиентом.
♦ Реализация проекта, основанная на инкрементах разрабатываемого продукта и их приоритетах, что значительно снижает сложность проекта и позволяет команде сфокусироваться на каждом инкременте в отдельности. Об интеграции всех элементов беспокоится руководитель проекта, который обеспечивает, чтобы следующий инкремент в списке имел наивысший приоритет, основываясь на его ценности в бизнесе и уровне риска.
♦ Руководство и сотрудничество в противовес административным указам и жесткому контролю. Agile тесно связан с лидерством. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта и исключить все барьеры в нем.
♦ Фокус на бизнесе. Оценка приоритетов на основе значимости в бизнесе позволяет не допустить чрезмерного углубления команды только в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности.
♦ Усвоение полученных уроков. После каждой итерации команда оценивает все полученные навыки и знания для того, чтобы улучшить процесс на следующей итерации. Обучаясь, участники адаптируются к деятельности других коллег и работают вместе над улучшением производительности команды.
