Тактики достижения цели
С 1995 года, когда скрам был формализован впервые, его определение постепенно изменялось. Основные элементы, принципы и правила остались такими же. Но обязательные предписания скрама стали мягче, что явно демонстрирует эволюция «Руководства по скраму». В нем описывается цель правил, исходя из понимания того, для чего они вообще существуют, а не даются инструкции о том, как именно применять эти правила.
Предыдущая глава описывает правила игры. Эти правила оставляют место для различных тактик, которые применимы в любое время и могут быть приспособлены к контексту и обстоятельствам. Так же как в обычных играх и в спорте, все играют по одним и тем же правилам, однако некоторые становятся успешнее других. Успех зависит от многих факторов, и не все из них контролируют сами игроки, но, несомненно, большое значение имеют тактики, избранные для игры.
Из большого количества хороших практик выбирается какая-то одна, и ее делают идеальной с помощью подстройки к контексту. Скрам — это процесс, но процесс служения, а не приказаний. Скрам не диктует, какие практики использовать. Скрам помогает понять, работает ли та или иная практика, и оставляет игрокам право продолжать использовать ее или заменить.
В скраме можно использовать много тактик. Хорошие тактики служат цели скрама. Хорошие тактики усиливают ценности скрама, а не уменьшают их.
Давайте посмотрим на некоторые примеры, чтобы прояснить разницу между тактиками и обязательными правилами скрама.
3.1. Визуализация продвижения в работе
Хорошей иллюстрацией того, как скрам движется в сторону большей легкости, стала отмена обязательности диаграмм сгорания.
Глядя на правила скрама, особенно на необходимость прозрачности, критически важной для инспекции, адаптации и самоорганизации, становится ясно, почему важно визуализировать продвижение в работе. Очень трудно достичь самокоррекции без отслеживания и визуализации продвижения в работе.
Однако требование использовать для этого диаграммы сгорания было изъято из определения скрама. Теперь нет обязательного формата визуализации. Это требование заменено простым ожиданием визуализации продвижения в работе над обязательными артефактами скрама: бэклогом продукта и бэклогом спринта.
Посмотрите на пример диаграммы сгорания спринта (рис. 2.7) в разделе 2.5.3 «Отслеживание продвижения в работе».
Диаграммы сгорания и сейчас хороший инструмент самоуправления в спринте для команды разработки и способ отслеживания и визуализации прогресса для бэклога продукта. Визуализация поддерживает коммуникацию владельца продукта с заинтересованными лицами, пользователями и средой. Диаграмма сгорания и включенный в нее визуальный прогноз позволяют обсуждать баланс времени и объема работ на основе фактически достигнутых результатов.
Диаграммы сгорания — хороший способ игры, они применимы во многих ситуациях. И все же они стали необязательной практикой.
Да, скрам — это бэклог продукта, бэклог спринта и доступная и ясная их визуализация. Но существует множество хороших способов такой визуализации. Это может быть диаграмма сгорания с оставшимся объемом трудозатрат. Это может быть накопительная диаграмма потока. Это может быть простая скрам-доска. Это может быть накопительная диаграмма предполагаемой бизнес-ценности.
3.2. Вопросы ежедневного скрама
На ежедневной встрече каждый игрок должен отвечать на три вопроса, относящихся к продвижению команды к цели спринта: сделал? запланировал? проблемы?
Но, даже если игроки ответят на эти вопросы, они могут ограничиться информированием о своем персональном статусе. Они могут использовать стены или скрам-доску для отчетов. Они могут поверхностно ответить на три вопроса из-за неспособности взглянуть за рамки предложения. Это происходит, если правила выполняются формально, без понимания, зачем это нужно.
Смотрит ли команда на скрам просто как на методологию? Или использует скрам как фреймворк для открытий и сотрудничества? Если отвечать на три вопроса формально или вообще не отвечать на них, если члены команды не будут разговаривать и слушать друг друга, никакого толка не будет. Если сотрудники не будут раскрывать информацию, необходимую для оптимизации общего плана работ по достижению цели спринта на ближайшие 24 часа, это тоже не будет работать. Возможно, все дело в том, что люди находятся под прессингом обязательства записывать все свои микрозадачи и пытаются прикрыть себя от возможных обвинений.
Но, делая так, они упускают возможность увидеть и понять реальную ситуацию, чтобы адаптироваться к ней мягко и быстро.
Инспекция без адаптации не имеет смысла в сложной и изменчивой среде. Цель ежедневного скрама — делиться информацией и заново планировать коллективную работу команды разработки таким образом, чтобы наилучшим путем двигаться к цели спринта. Команда создает собственный формат, на который требуется 15 минут или меньше. Именно это должно стать основой ежедневного скрама (с тремя вопросами или без них), а не бездумное прохождение по трем вопросам.
Вы знали, что ежедневный скрам — необязательно ежедневное короткое собрание команды?
Ежедневное короткое собрание команды — это практика, описанная в экстремальном программировании, которая служит той же цели, что и ежедневный скрам. Но экстремальное программирование советует последователям проводить это мероприятие стоя.
В скраме не обязательно стоять. Однако это хорошая тактика, особенно если вы хотите уложиться в 15 минут.
3.3. Уточнение бэклога продукта
Уточнение бэклога продукта должно постоянно происходить в течение спринта. Команда разработчиков и владелец продукта должны проверять бэклог продукта на следующий спринт и удостоверяться, что его элементы будут действительно реализованы.
Когда настанет время реализации этих элементов, команды могут захотеть точнее понять, какие результаты работы ожидаются, выработать общий подход к разработке или помочь владельцу продукта лучше осознать изменения, которые вносит разработка на функциональном уровне. Совместное уточнение бэклога продукта и дополнительное знание, которое возникает во время проясняющих обсуждений, увеличивают шансы того, что задачу действительно возьмут в спринт.
Уточнение бэклога продукта — неофициальное, ограниченное по времени событие. Скрам должен оставаться простым. Скрам нацелен на то, чтобы помочь командам открыть для себя конкретные практики, которые могут быть или не быть уместными в их конкретном контексте. Многие команды используют уточнение бэклога продукта, чтобы уменьшить турбулентность в первые дни спринта. Какие-то команды во время уточнения бэклога продукта устанавливают или пересматривают предварительные оценки усилий или затрат. Другим командам не требуется столь тщательное планирование спринта или в их взаимоотношениях с владельцем продукта не нужна такая точность оценок. Тогда они обходятся без уточнения бэклога, не выделяя на него конкретное время. Если бы уточнение бэклога было обязательным элементом скрама с фиксированной продолжительностью и расписанием, его бы воспринимали как необязательную или даже излишнюю активность.
Уточнение бэклога продукта — отличное событие в спринте, хорошая тактика для совместного управления бэклогом продукта. Однако некоторые команды могут обходиться без нее.
3.4. Пользовательские истории
В экстремальном программировании требования фиксируются в виде пользовательских историй. Эти истории пишутся на карточках и описывают функциональные ожидания с точки зрения пользователя. Билл Уэйк, ранний энтузиаст экстремального программирования, предложил акроним INVEST как простой способ запоминания, а также оценки того, хорошо или плохо сформулирована пользовательская история: независимая, обсуждаемая, ценная, оцениваемая, небольшая, тестируемая.
Пользовательские истории обычно описывают функцию как историю с точки зрения пользователя. Преимуществом описания требования к системе или приложению с точки зрения пользователя является возможность сфокусироваться на ценности данной функции для этого пользователя.
Карточки легко перемещать по панели планирования или убирать с нее, используя панель как информационное зеркало. Другим преимуществом использования карточек для историй является ограниченное место для текстовых описаний и спецификаций. Это гарантирует, что описание неполно по определению и приведет к детальному обсуждению каждой истории. Как только подходит время реализации функционала пользовательской истории и растут шансы того, что он может быть воплощен, неизбежно требуется обсуждение, чтобы раскрыть подробности. На карточку может быть добавлено больше информации, и какая-то ее часть может быть сформулирована как критерии приемки пользовательской истории. Такие критерии приемки обычно пишутся на оборотной стороне карточки.
Бэклог продукта в скраме служит для обеспечения прозрачности всей работы, которую команда должна выполнить. Это больше чем просто функциональные требования. Формат пользовательских историй может быть использован для других типов требований, однако здесь уже нет естественного соответствия, поэтому появляется опасность фокусироваться на форме, а не на содержании.
В скраме необязательно создавать пользовательские истории для всех элементов бэклога продукта. Иначе появляется риск забыть о другой важной работе, которая должна быть сделана, или принуждение команды тратить больше времени и энергии на правильный формат, таким образом создавая потери. Однако для функциональных элементов бэклога продукта пользовательские истории могут быть отличной тактикой.
3.5. Покер планирования
Покер планирования — это техника оценки, изобретенная Джеймсом Греннингом на проекте в стиле экстремального программирования, где он понял, что слишком много времени уходит на оценку трудозатрат.
На покере планирования команда устраивает обсуждение требования, после которого каждый член команды делает оценку требования, выбирая карту с определенным значением из колоды. Карты для покера обычно используют экспоненциальную шкалу наподобие последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34, …). Члены команды не раскрывают выбранного значения до тех пор, пока все не сделают выбор. Далее все раскрывают свои оценки одновременно, после чего обсуждают возможные различия. Этот цикл повторяется до тех пор, пока не будет достигнуто согласие и общее понимание оценки требования. Оценки относительны и выражаются в абстрактных единицах, например в стори пойнтах или даже мишках Гамми, как в ранних проектах экстремального программирования.
Ответственна за оценку элементов бэклога продукта в скраме команда разработки. Частью прозрачности и сотрудничества является требование давать честные и непредвзятые оценки от всей команды разработки, коллективной точки зрения, включающей все умения и экспертность, присутствующие в команде.
Несмотря на то, что он не является обязательным элементом, покер планирования — хорошая тактика для обеспечения прозрачности оценок и ответственности команды за них. Но не забывайте, что конечной целью является честная дискуссия по поводу оценок, так как это приводит к лучшему пониманию работы, связанной с реализацией обсуждаемого элемента.
3.6. Длина спринта
Скрам определяет лишь максимальную длину спринта — не более четырех недель. Это гарантирует, что все имеют право изменять планы на продукт по крайней мере каждые четыре недели. Также и команда не должна быть слишком долго закрыта от внешнего мира, так как это создает риск потерять связь с внешними изменениями.
Длина спринта создает баланс между удержанием фокуса и адаптивностью к возможностям. Фокус нужен, чтобы выполнить существенную часть работы, а адаптивность регулируется другими факторами, например технологической неопределенностью и возможностями обучения.
В эмпирическом процессе, таком как скрам, системе предъявляются контрольные цели и результаты регулярно инспектируются на соответствие этим целям с помощью обратной связи, а затем вносятся изменения в исходные данные, задачи и процессы. Опытные инспекторы (чьи роли предусмотрены скрамом) осуществляют проверки с необходимой частотой, чтобы фокус и время, необходимые для создания значимого результата, были сбалансированы относительно риска допустить слишком большую вариативность созданного результата.
Наряду с прозрачностью частота является важной чертой эмпиризма. Мероприятия скрама определяют частоту инспекций и адаптаций, где спринт является мероприятием-контейнером, в которое входят цикл обратной связи ежедневного скрама и циклы обратной связи практик разработки, применяемых в спринте.
Появилась явная тенденция к укорачиванию спринтов. Хотя это и не является формальным требованием, недельные спринты представляются приемлемым минимумом.
Давайте посмотрим на команду с однодневными спринтами.
Все мероприятия скрама как возможности инспекции и адаптации проводятся в один день и поэтому организованы с большой частотой. Пытаясь провести все мероприятия, команда потратит неоправданно много времени на инспекцию и адаптацию мельчайшего пакета работ. Частота входит в противоречие с созданием ценности.
Есть даже бо́льшая опасность: команда просто сосредоточится на ежедневной работе и продвижении в ней и потеряет перспективу. У них не будет времени инспектировать и адаптировать весь процесс целиком, или исследовать пути улучшения качества, или привязаться к общим стратегическим целям и задачам. Каждый день они просто будут пытаться выпустить больше функционала.
Длина спринта также определяет частоту, с которой владелец продукта и команда разработки консультируются с заинтересованными лицами по поводу работающей версии продукта. Задача состоит в том, чтобы раскрыть всю информацию, необходимую владельцу продукта для принятия решения о будущем продукта. В случае однодневных спринтов трудно будет достичь вовлеченности заинтересованных лиц, не говоря уже о том, чтобы осмыслить и адаптироваться к стратегическим изменениям, изменениям компании и рынка.
При этом длина спринта должна быть соотнесена с риском потерять бизнес-гибкость из-за того, что спринты слишком длинные. Если ваш бизнес настолько изменчив, что вы рискуете потерять гибкость, проводя более одного дня в контейнере спринта, пожалуйста — делайте однодневные спринты. Но будьте осторожны, такой частотой вы можете разрушить механизмы инспекции.
Предотвратите превращение скрама в новое название для старых добрых крысиных бегов, где нет места для гуманизации работы. Организуйте работу так, чтобы она как можно дольше сохраняла устойчивость.
Рассматривайте длину спринта как тактику игры в скрам. Посмотрите, как она работает, и соответственно адаптируйтесь, не забывая о стабильности, пульсе и устойчивом темпе работы. И, если вы хотите выпустить версию продукта раньше конца спринта, ничто в скраме не говорит, что вы не можете этого сделать. Тем не менее назначение ограниченных по времени спринтов и обзор спринта должны оставаться нетронутыми.
3.7. Как масштабировать скрам
Были описаны обязательные элементы скрама, правила игры и правила, которые тесно связывают эти элементы вместе. Они остаются неизменными и не зависят от масштаба.
Скрам за простоту. Скрам за ответственность и взаимное сотрудничество, позволяющие справляться с непредсказуемостью и формулировать ответы на комплексные вопросы.
Когда предприятия масштабировались на базе индустриальной парадигмы, они редко полагались на простоту, ответственность и сотрудничество. Основной вызов в масштабировании скрама состоит не в том, чтобы приспособить скрам к существующим структурам, а в том, чтобы пересмотреть существующие структуры. Приспособьте организацию к скраму, а не наоборот.
Есть несколько тактик, которые позволяют играть в скрам в большем масштабе в зависимости от контекста.
3.7.1. Скрам одной команды
Простейшая ситуация продуктовой разработки с использованием скрама заключается в том, что бэклог продукта содержит все пожелания по поводу продукта и одна команда разработки выпускает инкременты продукта в ограниченных по времени спринтах.
У команды разработки есть все необходимые компетенции, чтобы превратить за один спринт несколько элементов бэклога продукта в потенциально готовый к выпуску инкремент продукта, руководствуясь определением готовности. Команда разработки автономно управляет своей работой через бэклог спринта и проверяет направление движения и соответствие контексту организации с помощью ежедневного скрама. Владелец продукта вовремя предоставляет разъяснения по части функциональности и бизнеса. Скрам-мастер тренирует команду и организацию, служит и помогает им.
Одна команда — это скрам-команда, в которой есть владелец продукта, одна команда разработки и один скрам-мастер. Чтобы делать поставки функций продукта, которые от начала до конца предоставляют ценность конечному пользователю, команда разработки должна быть тем, что обычно называют фиче-команда.
Наибольшая трудность состоит в том, чтобы все специалисты разработки сотрудничали как одна команда. Если эта проблема преодолена и обзор спринта полностью прозрачен, заработает эмпирический подход. Команда будет использовать ретроспективы спринта для самосовершенствования.
3.7.2. Многокомандный скрам
Для больших продуктов или получения более быстрых результатов может возникнуть необходимость создавать и выпускать продукт при помощи нескольких скрам-команд.
Несколько скрам-команд создают один продукт. Они работают над одним бэклогом продукта. Общая система имеет одного владельца продукта, несколько команд разработки и одного или нескольких скрам-мастеров. Каждая команда разработки составляет бэклог спринта для своей работы, исходя из прогноза. Каждая команда разработки самоадаптируется с помощью ежедневного скрама и гарантирует интеграцию своей работы с результатами других команд разработки.
Остается необходимой полная прозрачность на обзоре спринта, полная прозрачность относительно выпущенных или потенциально готовых к выпуску версий продукта. Инкременты продукта не могут включать в себя несделанную или скрытую оставшуюся работу. Однако несколько команд вместе создают один продукт. Только полностью интегрированный инкремент формирует уверенность в полной прозрачности у владельца продукта и заинтересованных лиц.
Несколько скрам-команд самоорганизуются в рамках правил и принципов скрама. При работе в конструкции нескольких скрам-команд, т.е. когда несколько команд создают и поддерживают один и тот же продукт, команды самоорганизуются в интересах создания интегрированного инкремента не позднее конца спринта.
На протяжении спринта необходима регулярная коммуникация, связывающая несколько скрам-команд, которая поможет выстроить рабочие планы в спринте относительно создания интегрированного инкремента. Скрам-команды масштабируют принцип ежедневного скрама на межкомандный уровень и проводят скрам скрамов.
Помогающий оптимизировать целое скрам скрамов происходит до индивидуальных командных ежедневных скрамов. Наиболее подходящие представители команд разработки собираются вместе, чтобы обменяться информацией о ходе разработки, главным образом фокусируясь на состоянии интеграции продукта. Далее каждая команда разработки может оптимально перепланировать и подстроить свой бэклог спринта внутри мультикомандной экосистемы. В результате несколько команд оптимизируют совместное продвижение к интегрированному инкременту продукта, чтобы получить его не позднее конца каждого спринта. Технически зрелый инкремент может быть выпущен после оценки владельцем продукта, имеет ли этот инкремент необходимую степень полезности и не сдерживается ли его выпуск неизвестным объемом предстоящей разработки.
Несколько скрам-команд используют одни и те же критерии качества продукта, выраженные в определении готовности. Они, возможно, решат, что проще работать с одинаковой продолжительностью спринта, чтобы упростить планирование, интеграцию, выпуск и оценку работы. Будет предусмотрен дополнительный объем работ в индивидуальных бэклогах спринтов, чтобы работа была всегда интегрированной.
Если работать с разной длиной спринтов, критически важно, чтобы политики и соглашения гарантировали, что вся работа непрерывно будет интегрированной. Если что-то ломает целое, это всегда нужно чинить в первую очередь. В результате каждая команда или каждое сочетание команд может потенциально независимо собрать потенциально готовый к выпуску инкремент из общей кодовой базы. И все же общие обзоры спринтов имеют много смысла.
Соблюдаются все правила, определенные скрамом. Ядро системы — узнаваемый скрам. Чтобы выпускать инкременты продукта, которые обеспечивают от начала до конца ценность для конечного пользователя, все целиком есть «система функциональной возможности». Независимо от их комбинации, команды совместно выпускают интегрированные инкременты продукта не позднее конца каждого спринта.
3.7.3. Мультипродуктовый скрам
В зависимости от функциональной или технической взаимозависимости нескольких продуктов может возникнуть необходимость планирования и имплементации продуктов, которые должны быть выровнены и синхронизированы.
У каждого продукта есть свой владелец. Для каждого продукта существует бэклог продукта и несколько команд, которые его выпускают и поддерживают. Каждая продуктовая экосистема — это однокомандный или мультикомандный скрам.
Из схем мультипродуктового скрама (рис. 3.4) становится ясно, что синхронизация и выравнивание в основном происходят на уровне бэклогов продуктов через соответствующих владельцев продуктов. Отдельные бэклоги продукта упорядочиваются с помощью оптимизации продуктовой линейки, пакета продуктов, соображений относительно программ или портфолио. Таким образом, владельцы продуктов при поддержке и помощи своей организации инкрементально управляют своими бэклогами продуктов на основе обмена информацией и общего продвижения в работе.
Технические зависимости и зависимости в разработке разрешаются внутри спринта командами разработки различных продуктовых центров в духе неиерархического взаимодействия.
Существует намного больше проблем масштабирования и поэтому намного больше сценариев. Не существует одного решения. Скрам за мышление снизу вверх с поддержкой сверху вниз, что позволяет открыть и развить то, что наилучшим образом подходит вам, вашей организации и в вашей ситуации.
