Как стало понятно из предыдущих глав, Scrum – это один из ключевых процессных фреймворков в большинстве топовых IT-компаний. Де-факто Scrum – это промышленный стандарт продуктовой разработки. Даже если вы услышите, что в крупной компании применяется собственный Agile-фреймворк, то. скорее всего, это адаптированная версия Scrum.
Scrum в переводе с английского – схватка вокруг мяча. Термин, применяемый в регби, означает прием, когда команда объединяется и наваливается на противников. Смысл такой аналогии в том, что команда разработчиков «наваливается» на проблему для достижения цели спринта, в отличие от водопадного подхода, где каждый в рамках своей выделенной роли выполняет определенный этап обработки артефакта.
Наиболее полное представление о Scrum можно получить из книги Джефа Сазерленда «Scrum: The Art of Doing Twice the Work in Half the Time» (дословно: «Scrum: искусство сделать вдвое больше за половину времени). Официальное название книги в России – «Scrum: Революционный метод управления проектами», однако, несмотря на возможную коммерческую эффективность, этот перевод содержит ряд неточностей: Scrum HE революционный HE метод HE управления HE проектами.
➠ Scrum HE революционный. По ходу книги автор рассказывает, как элементы Scrum были собраны из различных подходов к программированию и организации процессов из разных областей, включая материалы для подготовки военных. Многие элементы на момент создания существовали немало лет, их нельзя назвать революционными. Возможно, революционность в том, как эти элементы были собраны вместе и дополнили друг друга.
➠ Scrum – НЕ метод. Scrum – это фреймворк. В отличие от метода, фреймворк не содержит конкретных алгоритмов для решения задач, а предлагает набор рамок – правил и ограничений, – в которых команда самостоятельно разрабатывает и внедряет методы.
➠ Scrum НЕ для управления проектами. Как уже говорилось ранее, Scrum ориентирован на продуктовый подход; он следует итеративной, адаптивной инкрементальной поставке ценности.
Scrum является эмпирическим процессом управления, что означает, что знания и понимание развиваются на основе опыта и наблюдений. Этот подход основывается на трех основных столпах: прозрачности (transparency), инспектировании (inspection) и адаптации (adaptation).
➠ Прозрачность требует, чтобы все аспекты работы были видимы для тех, кто несет ответственность за результат.
➠ Инспектирование подразумевает регулярное наблюдение за продуктом и процессом работы для определения того, соответствуют ли они ожиданиям и целям.
➠ Адаптация означает изменение подхода или процесса на основе этих наблюдений для оптимизации результатов.
Эмпирический характер Scrum позволяет командам быстро реагировать на изменения, повышает гибкость и адаптивность, а также способствует непрерывному улучшению.
Scrum регулярно обновляется, его актуальное описание можно найти на сайте scrumguides.org. Могу сказать, что я не часто обращался к руководству, так сам по себе фреймворк сложно представить без множества лучших практик, которые стали неотъемлемой частью Scrum-процесса. Поэтому мы рассмотрим роли, события и артефакты Scrum не только по руководству, но и в отношении лучших практик, ставших промышленным стандартом, и множество личных историй и примеров.
3.2.1. Роли в Scrum
В Scrum три роли:
➠ Scrum-мастер (Scrum master, SM)
➠ Владелец продукта (Product owner, РО)
➠ Команда разработки (Development team, DT), вся команда – одна роль.
Вместе они составляют Scrum-команду (Scrum team, ST).
Мы привыкли к тому, что в любом процессе всегда есть две роли: заказчик – исполнитель, начальник – подчиненный. Почему же в Scrum именно три роли, а не две? Давайте вспомним классический треугольник компромиссов: деньги – скорость – качество. Если мы хотим после старта разработки «натянуть» одну вершину, то страдают две остальные (рис. 3.8).
Если в процессе участвуют две роли, значит, кто-то должен одновременно отвечать за две вершины, например, исполнитель – за скорость и качество, что порождает внутренний конфликт. Три роли позволяют создать натяжение, где каждому участнику не нужно бежать в обе стороны (рис. 3.9).
Рис. 3.8. Классический треугольник компромиссов
Рис. 3.9. Треугольник компромиссов, адаптированный для Scrum
Команда разработки (DT) фокусируется на качестве. Владелец продукта (РО) – на возвратности инвестиций (Return of Investments, ROI). Так как продуктовый процесс не ограничен во времени, нет фиксированного бюджета и РО нужно следить, чтобы каждый спринт был максимально эффективным вложением.
Scrum-мастер фокусируется на удовлетворенности всех участников от работы, поскольку бежать с максимальной скоростью можно ограниченное время. Для длительной наивысшей продуктивности человек должен испытывать удовлетворенность от работы или, как это называют, находиться в состоянии потока.
3.2.1.1. Scrum-команда
Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.
Важно, что три роли имеют одинаковый уровень в иерархии, но разные зоны ответственности. Поэтому каждый тянет вершину треугольника компромиссов в свою сторону, находясь в позитивном конфликте.
Scrum-команда кросс-функциональна. Это означает, что участники имеют все необходимые экспертизы, чтобы создавать дополнительную ценность каждый спринт.
Scrum-команда достаточно маленькая, чтобы сохранять проворство, и достаточно большая, чтобы завершать значимую часть работы каждый спринт. Многочисленные исследования показывают, что чем меньше команда, тем она продуктивнее. Следовательно, как только Scrum-команда становится слишком большой (более 15 человек), рекомендуется разделить ее на несколько.
Scrum-команда полностью самостоятельна и наделена полной властью для достижения целей спринта, а следовательно, самостоятельно несет ответственность за взаимодействие со стейкхолдерами, сопровождение, операционную деятельность, исследования, R&D и все остальное, что может понадобиться в процессе.
ST наделена всеми полномочиями на управление собственной структурой и процессами.
Вся Scrum-команда целиком отвечает за поставку ценного для бизнеса и полезного для пользователей инкремента каждый спринт, но внутри есть разделение зон ответственности между командой разработки, Scrum-мастером и владельцем продукта.
3.2.1.2. Лучшие практики организации Scrum-команд
Самостоятельность
Любые внешние зависимости снижают ответственность за поставку. Наверное, самой популярной причиной срывов сроков поставки или нежелания их называть можно считать внешние обстоятельства:
➠ Ждем, пока юристы согласуют формулировку.
➠ Ждем, пока другая команда развернет обновление API.
➠ Ждем, пока Scrum-мастер перенесет истории из продуктового бэклога в бэклог спринта и т. д.
Несколько практик по работе с внешними зависимостями:
➠ Максимальная автономность. Если в команде регулярно возникает потребность в доработке артефакта внешними участниками, необходимо развить внутренние компетенции и получить соответствующие полномочия. Например, для доступа к определенной системе разработчик получает определенные допуски или юрист на время становится частью команды и отвечает вместе со всеми за соблюдения сроков.
➠ Максимальные полномочия. Команда должна иметь возможность связаться с кем угодно в компании и за ее пределами для поиска решения или оценки задач. Например, разработчики могут совершенно самостоятельно назначать встречи с представителями других подразделений компании.
➠ Выход за пределы ролей. Нарушение границ своей роли, описанной в должностных обязанностях или оговоренной на собеседовании, должно стать культурной нормой. Например, дизайнер может попробовать новую для себя роль аниматора.
➠ Выявление и регулярное устранение внешних зависимостей. На определенном масштабе, когда команд становится много, требуется настроить процесс работы с зависимостями. Создается доска зависимостей (dependency board), команды назначают друг другу задачи по устранению зависимостей, и зависимости устраняются, часто с повышенным приоритетом.
Вертикальная интеграция
Уже много было написано ранее о том, что продуктовый подход строится вокруг вертикально интегрированных организационных структур.
➠ Бизнес-блок. Компания подразделяется на несколько бизнес-блоков. Каждый из них автономен с точки зрения внутренней экономики, имеет обособленный P&L, за который отвечает руководитель блока.
➠ Трайб (tribe, иногда племя) – совокупность отрядов, сфокусированных вокруг одного продукта или портфеля родственных продуктов. Руководитель трайба отвечает за финансовый эффект продуктов портфеля трайба.
➠ Отряд – минимальная автономная команда (например, Scrum-команда), разрабатывающая продукт или компонент. Владелец продукта отвечает за возврат инвестиций в разработку продукта.
Приведенная структура может отличаться от компании к компании, но главная идея в том, что разделение бизнеса на несколько автономных зарабатывающих сущностей диверсифицирует риски, делая систему антихрупкой. Каждая минимальная команда (отряд), по сути, представляет собой маленький бизнес в бизнесе.
Несмотря на очевидную логичность, на практике приходилось встречать множество отклонений в понимании, что такое Scrum-команда. Популярный анти-паттерн – создание команды ассенизаторов, также известной как техническая команда. Это команда, которая занимается техническим совершенствованием, пока продуктовые команды расширяют и развивают функциональность продукта. На практике это приводит к тому, что такая техническая команда сильно демотивирована тем, что не видит ценности от своей работы и, по сути, зачищает работу за другими. При этом ответственность за стабильность кода с продуктовой команды не снимается, и в долгосрочной перспективе структура с командой зачистки начинает искрить.
Хороший подход, когда продуктовая команда самостоятельно отвечает за качество на уровне определения завершенности (Definition of Done, DoD).
Второй частый анти-паттерн – формирование команды вокруг экспертиз и инструментов. Например, дашбордисты – команда продуктовых аналитиков, собранная вокруг экспертиз анализа данных и инструментов. Подобная команда в определенный момент превращается в бутылочное горлышко с отдельным бэк-логом задач от нескольких заказчиков – владельцев продукта. Владельцы продукта не могут точно прогнозировать дату получения необходимых данных и принимают решения экспертно. Еще одно негативное последствие – владельцы продукта не заинтересованы в оптимальности получаемых решений и могут заказывать избыточную функциональность. Как следствие, производимые артефакты не утилизируют в полной мере. Хорошей практикой было бы коллективное владение системой, о котором поговорим дальше.
Помимо таких достаточно простых примеров, есть менее очевидные, например команда, образованная вокруг систем, заново используемых другими продуктами, таких как единая точка входа (single sign-on, SSO), рекомендательная система или система мониторинга.
Бывает действительно трудно обойтись без команды, обслуживающей такую горизонтальную систему. Чтобы организовать это с минимальными потерями, применяется практика коллективного владения, о которой поговорим далее.
Коллективное владение системой
Практика коллективного владения системой подразумевает создание виртуальной команды делегатов от продуктовых команд, наделенных полномочиями для развития горизонтальной системы.
Практика коллективного владения системой основана на практике коллективного владения кодом из экстремального программирования (extreme programming, ХР).
Роль делегата может возникать как дополнительная роль у уже существующего участника команды; при увеличении нагрузки может быть выделен отдельный человек или даже несколько.
Рис. 3.10. Виртуальная команда
Доработки системы инициируются владельцами продукта, делегаты осуществляют доработку системы, а развертывание начинается с проверки кода несколькими делегатами.
С примерами реализации практики коллективного владения системой можно ознакомиться в табл. 3.3.
Табл. 3.3. Сравнение коллективного и централизованного владения системами
* Дашборд (англ, dashboard) – это интерактивная панель, на которой отображаются все метрики из гипотез жизнеспособности продукта в режиме реального времени.
Коллективное владение системой представляет собой хорошую практику для создания максимально вертикальных команд, но не единственную для организации разработки горизонтальных систем.
Может быть много различных вариантов с разной степенью централизации. Например, система общего пользования может представлять собой внутренний продукт с внутренним тарифом для команд. Система, разрабатываемая внутри компании, может продаваться наружу.
Главное, что нужно вынести из описанных практик образования команд разработки, – максимальная независимость и прозрачность возврата инвестиций.
3.2.1.2. Команда разработки
Команда разработки (development team, DT), или разработчики – это часть Scrum-команды, которая берет на себя обязательство поставлять полезный инкремент каждый спринт. Команда обладает всеми необходимыми навыками в операционном домене[41] и отвечает за:
➠ формирование бэклога спринта и плана достижения целей спринта;
➠ развитие качества путем соблюдения и дополнения определения завершенности (DoD);
➠ ежедневную адаптацию плана для достижения цели спринта;
➠ профессионализм друг перед другом.
3.2.2. Лучшие практики
3.2.2.1. Т-образные специалисты
Т-образные (англ. T-shaped, в форме буквы «Т») специалисты названы так по способу формирования компетенций и представляют собой комбинацию специалистов широкого профиля (dash-shape, или тиреобразные) и узких специалистов глубокого профиля (I-shape, или 1-образные). Т-образные специалисты глубоко разбираются в одной экспертизе, но при этом на базовом уровне разбираются в смежных (рис. 3.11).
Рис. 3.11. Способы формирования компетенций. Т-, I- и «-»-образные специалисты
Наличие таких специалистов в команде позволяет убрать бутылочные горлышки и снизить так называемый фактор автобуса[42].
Если один из разработчиков заболевает или уходит в отпуск, остальные участники команды Т-образных специалистов способны подхватить его работу и довести до конца, но, возможно, с более медленной скоростью.
Некоторые компании, в которых мне доводилось работать, поощряли развитие разработчиков в сторону Т-образности. Известная практика – создание звездной карты.
Рис. 3.12. Звездная карта
Звездная карта (рис. 3.12) – это простой инструмент, представляющий собой матрицу, в которой в пересечении «сотрудник – экспертиза» устанавливается звездочка, если сотрудник «звезда» в этой экспертизе, и точка, если может подменить «звездного» сотрудника, который по какой-то причине выпал. Звездная карта позволяет видеть провалы в экспертизах и риски возникновения бутылочного горлышка в случае незаменимости «звезды». Для минимизации риска «автобуса» можно поощрять сотрудников к развитию горизонтальных компетенций, например, оплачивая обучение. Если сотрудник хочет изучить что-то не по профилю, в ячейке ставится значок «книга».
Долгое время рынок труда в IT не поощрял многопрофильность. Это накладывало ограничение на желание разработчиков развиваться в смежных сферах. Например, фронтенд-разработчик не хотел развиваться в бэкенде, так как это не увеличивало его стоимость на рынке.
Сейчас, с развитием Agile, растет потребность в фулстек-разработчиках (от англ, full stack, полный стек[43]), и вакансий с каждым годом становится все больше.
3.2.2.2. Минимальная команда
Расширение команды увеличивает время на синхронизацию и ответственность каждого участника.
Согласно закону Меткалфа[44], количество связей в сети растет пропорционально квадрату количества узлов. Начиная с определенного количества участников, перестанет хватать рабочей недели, чтобы все они поговорили друг с другом хотя бы несколько минут. Следовательно, команда естественным образом начнет распадаться на несколько подкоманд. Коллективные встречи начнут терять свою эффективность, так как обсуждаемые задачи не затрагивают большую часть сотрудников.
Чем больше команда, тем меньше ощущение личного вклада в результат, а следовательно, и ответственность становится все менее очевидной.
Я лично наблюдал случаи, когда недобросовестные сотрудники прятались в больших командах и паразитировали там месяцами.
Чтобы обеспечить максимальную связность и ответственность, подходит практика разбивать разработчиков на минимальные кросс-функциональные команды. Для этого можно использовать описанный выше инструмент звездной карты, разделив участников так, чтобы при минимальном количестве участников команда сохраняла кросс-функциональность (наличие полного набора экспертиз) и устойчивость к фактору автобуса.
3.2.2.3. Долгое время вместе
Изменение состава команды нарушает внутренние равновесие и перезапускает процесс ее формирования.
Рис. 3.13. Стадии формирования групп по Брюсу Такману
Брюс Такман в 1961 году предложил модель групповой динамики, согласно которой команда проходит четыре стадии формирования (рис. 3.13):
➠ формирование (forming),
➠ шторм (storming),
➠ нормирование (norming),
➠ производительность (performing).
Согласно этой модели, на первых порах участники команды присматриваются друг к другу. На всякий случай они показательно продуктивны и априори положительно настроены к другим участникам. Затем наступает фаза шторма, когда начинают возникать споры вокруг пустот между зонами ответственности. В третьей фазе участники команды слаживаются, притираются друг к другу и начинают наращивать продуктивность.
В сложившихся командах участники знают, что друг от друга ожидать. Это позволяет точнее оценивать истории, которые берутся в работу, и увереннее брать на себя общекомандные обязательства.
3.2.2.4. Владелец продукта
Название выбрано не случайно. Аналогия с владельцем компании подчеркивает автономность и нацеленность на рост и развитие бизнеса.
Владелец продукта отвечает за максимизацию ценности результата разработки Scrum-команды. Также он отвечает за управление бэклогом команды, а именно:
➠ разработку и детальное донесение цели продукта;
➠ разработку и ясное донесение элементов продуктового бэк-лога;
➠ приоритизацию элементов продуктового бэклога;
➠ обеспечение доступности, прозрачности и понятности продуктового бэклога.
Владелец продукта может делегировать обязанности, но при этом несет ответственность. Это не комитет: он может представлять несколько стейкхолдеров, но при этом автономно принимать решения. Владелец продукта имеет видение продукта (компонента или инициативы) и готов прозрачно его доносить. Как говорилось ранее, он отвечает за ценность продукта. Под ценностью в широком смысле понимается не только ценность для пользователя, но и ценность для бизнеса. Владелец продукта наделен властью управлять датами релизов и инспектировать инкремент на обзоре спринта. Владелец продукта должен быть жизненно заинтересован в успехе продукта и вдохновлять своим видением других.
Плохо, когда владелец продукта:
➠ Не наделен властью: тогда ему придется совещаться с центром, что парализует работу.
➠ Перегружен работой: будет терять контекст.
➠ Совмещает: не будет нести ответственность в трудной ситуации.
➠ Работает удаленно: будет недоступен в срочной ситуации и часто неправильно понят.
➠ Прокси: будет задерживать и искажать сигнал от реального РО.
➠ Скрытный: команде будет трудно понять, как сделать, если непонятно, зачем.
➠ Комитет: решения будут затягиваться.
➠ Не заинтересован: команда будет демотивирована бесполезным трудом.
➠ Боится: страх парализует и заставляет имитировать работу.
3.2.2.5. Scrum-мастер
Больше всего вопросов у людей, не знакомых со Scrum, вызывает роль Scrum-мастера, хотя это важнейшая роль для построения эффективной масштабируемой разработки. Scrum-мастер в первую очередь отвечает за внедрение фреймворка, не ограничиваясь уровнем подотчетной команды и стараясь распространить свое влияние на другие команды и компанию в целом. Scrum-мастер регулярно актуализирует теоретические и практические знания команды. Согласно руководству, Scrum-мастер – это лидер-слуга для Scrum-команды, который:
➠ развивает команду в сторону самоорганизации и кросс-функциональности;
➠ помогает увеличивать производительность – поставлять как можно больше максимально ценных элементов продуктового инкремента каждый спринт;
➠ убирает препятствия в прогрессе команды;
➠ фасилитирует события Scrum для регулярного увеличения их эффективности.
Scrum-мастер помогает владельцу продукта ⁄ Scrum-команде:
➠ внедрить эффективные процессы определения цели продукта и управления бэклогом продукта;
➠ эффективно действовать в комплексном мире (см. п. З.1.З.);
➠ поддерживать ясное понимание элементов продуктового бэклога;
➠ организовать взаимодействие со стейкхолдерами, фасилитировать встречи.
На уровне организации Scrum-мастер:
➠ возглавляет и активно участвует во внедрении Scrum;
➠ участвует в планировании мероприятий по внедрению;
➠ помогает стейкхолдерам осознать и внедрить эмпирический процесс для комплексного мира;
➠ убирает препятствия между стейкхолдерами и Scrum-командой.
Важно добавить, что Scrum-мастер создает эффективную здоровую среду взаимного профессионального уважения и самостоятельности. Он выступает в роли третейского судьи для команды разработки и владельца продукта. Это позволяет добиться состояния справедливости, когда владелец продукта не «продавливает» команду, а команда не «продавливает» ПО.
Scrum-мастер – агент продуктовой трансформации, он бежит впереди организации, осознавая текущий уровень зрелости и направление движения.
Плохо, если Scrum-мастер:
➠ Проджект-менеджер: это противоречие на уровне операционных окружений по модели «Киневин», рассмотренной в п. 3.1.3.
➠ Прокси: чью бы волю ни выполнял – РО, СТО, SH[45], – в команде образуется несправедливый перекос;
➠ Частичный: SM, который работает на две и более команды, по-настоящему не болеет ни за одну из них;
➠ Нянька: потакая капризам команды, убивает в них самостоятельность;
➠ Трусливый: боится настоять на правильном процессе, из-за чего Scrum превратиться в Scream.
3.2.3. События Scrum
В производственном процессе происходит много событий, как правило, это встречи. Без четкого понимания объема будущих встреч достаточно сложно планировать свое время и давать обязательства на спринт.
Табл. 3.4. Краткое описание событий и процессов Scrum
Создатели Scrum выявили все обязательные типы событий, необходимых для разработки, и определили рекомендованную нормативную длительность (табл. 3.4).
Помимо официальных названий, есть устоявшиеся неофициальные: обзор спринта – демо. Далее для краткости будем использовать как официальные, так и неофициальные обозначения.
3.2.3.1. Краткое описание событий Scrum
Для начала давайте рассмотрим «скелет» событий Scrum (рис. 3.14).
➠ На планировании спринта собирается Scrum-команда. Участники идут сверху вниз по бэклогу, прошедшему приоритизацию, и разработчики набирают в него элементы.
➠ Каждый день разработчики и Scrum-мастер собираются на ежедневном Scrum, актуализируют статус готовности элементов спринт бэклога и планируют день.
➠ Несколько раз за спринт Scrum-команда встречается для прояснения бэклога, чтобы добавить новые элементы, провести декомпозицию, приоритизацию и оценку.
➠ В конце спринта Scrum-команда собирается для обзора. Владелец продукта инспектирует инкремент продукта и определяет готовность, согласно определению завершенности.
➠ На ретроспективе команда анализирует события прошлого спринта и проводит ревизию процесса, чтобы решить, что нужно начать делать, что прекратить, а что продолжить.
Затем все повторяется.
Рис. 3.14. Scrum: схема процесса
3.2.3.2. Лучшие практики организации расписания событий Scrum
В Scrum не регламентируется, в какие дни недели и в какой последовательности проводить события. Но мы можем говорить о некоторых сложившихся лучших практиках.
➠ Начинать спринт с планирования. Это помогает избежать дней простоя после окончания спринта, когда команде нечем заняться.
➠ Заканчивать спринт обзором и ретроспективой. Проведение ретро после демо позволяет внести изменения в процессы, которые повлияют уже на следующее планирование: процедура планирования, длительность спринта, дополнительные встречи и пр.
➠ Проводить демо, ретро и планирование в один день. Это позволяет команде избежать не занятых работой часов. Участники не переключаются на разработку и сфокусированы на ритуалах. Однако процесс получается утомительным и важно делать перерывы.
➠ Проводить обзор, ретроспективу и планирование в середине недели. Крайние дни – понедельник и пятница – часто добавляются к выходным из-за праздников и отпусков. Люди уезжают в эти дни для удаленной работы при гибридном графике, а также статистически чаще берут в эти дни отгулы и болеют. Следовательно, середина недели может оказаться наиболее стабильным временем, когда большинство участников команды в сборе.
3.2.3.3. Планирование спринта
Идеально, если команда входит в планирование спринта с полностью проясненной верхушкой продуктового бэклога – набором приоритетных элементов, которые команда оценила ранее на прояснении бэклога. В этом случае планирование проходит очень быстро. Но бывают случаи, когда новые элементы влетают в последний день спринта. В этом случае на планирование закладывают больше времени (до двух часов на неделю спринта, согласно руководству по Scrum), чтобы прояснить бэклог.
На планировании нужно закрыть несколько тем.
Тема 1. Почему этот спринт важен?
Владелец продукта рассказывает про важность спринта, его месте в дорожной карте продукта, стратегии организации и почему он важен для стейкхолдеров. Scrum-команда определяется с целью спринта.
Тема 2. Что будет сделано во время спринта?
Команда идет по списку элементов продуктового бэклога, начиная с самых приоритетных, а разработчики, действуя как одна роль, определяют, что может быть взято в спринт. Если в бэклоге появились новые неприязненные элементы, то команда занимается прояснением. Разработчики ориентируются на емкость предыдущих спринтов и учитывают изменения определения завершенности, внесенные на ретроспективе. (Подробнее об измерении емкости спринта см. в п. 3.2.3.10.)
Тема 3. Как это будет сделано?
В этой части разработчики обсуждают последовательность действий по достижению цели спринта. Выясняются индивидуальные задачи каждого и порядок, в котором они будут реализованы. Формируется бэклог спринта.
3.2.3.4. Лучшие практики планирования
➠ Не менять длину спринта. У команды вырабатывается определенный ритм и определенные внутренние ритуалы. Фиксированная длина спринта позволяет эффективно оценивать его объем и собирать статистику.
➠ Определить количество рабочих дней. Многие дни спринта выпадают на праздники, и это нужно учитывать.
➠ Учитывать отпуска и болезни. Это влияет на то, какие истории и в каком объеме могут быть взяты в спринт.
➠ Учитывать изменение определения завершенности. В результате ретро команда может прийти к повышению требований к инкременту продукта, например адаптивность под разные разрешения экранов, поддержка большего числа устройств или большая стабильность. Все это влияет на объем выработки команды разработчиков.
➠ Делегирование по умолчанию. Если обязательный член команды разработчиков не может принять участие в планировании, он автоматически делегирует принятие обязательств остальной команде.
➠ Чрезвычайный буфер (emergency buffer). Если почти каждый спринт из-за чрезвычайных ситуаций запланированный объем выполняется не в полной мере, нужно зарезервировать несколько единиц объема под такие работы и делать поправку при планировании.
3.2.3.5. Ежедневный Scrum
Разработчики трудятся вместе, и им необходимо синхронизироваться между собой. Важно выделить для этого специальное время, иначе они будут прерывать друг друга запросами статуса, обращаться в неудобное время или тратить его на повторение одного и того же разным участникам.
Цель ежедневного Scrum – обменяться статусами, планами и определить препятствия к достижению цели спринта.
Хорошая практика, когда каждый член команды разработчиков по очереди рассказывает:
➠ что было сделано вчера;
➠ что запланировано на сегодня;
➠ какие препятствия могут помешать выполнить запланированный объем в срок.
Часто для визуализации используется Scrum-доска (см. п. 3.1.3.6.). В этом случае каждый участник передвигает свои задачи по Kanban-доске для изменения статуса (рис. 3.7).
Scrum-мастер модерирует встречу, чтобы не обсуждались темы, не связанные с ежедневным прогрессом. Если команда начинает разбор полетов, то Scrum-мастер предлагает перенести обсуждение на ретро; если начинается обсуждение реализации, то на прояснение бэклога. По другим вопросам предлагается сделать отдельную встречу или перенести обсуждение в чат.
Ежедневный Scrum по нормативу занимает не более 15 минут. Если время увеличивается, это признак того, что либо команда стала очень большая и ее нужно делить, либо проблема в модерации и поднимаются неподходящие цели встречи вопросы.
3.2.3.6. Обзор спринта
Цель обзора спринта – проинспектировать результат спринта. Разработчики демонстрируют продуктовый инкремент элемент за элементом. Если демонстрируемый элемент соответствует описанию в бэклоге продукта и определению завершенности, то элемент считается готовым.
3.2.3.7. Лучшие практики обзора спринта
➠ Открытое демо (public demo). На обзор спринта приглашаются все желающие – стейкхолдеры, члены других команд, сотрудники организации и пользователи-спонсоры[46].
➠ Демо на реальных пользователях. Для тестирования функциональности приглашаются пользователи, приближенные к реальным, что позволяет получить непредвзятую обратную связь и увидеть проблемы для последующей адаптации продукта. Может потребоваться больше времени, чем при демонстрации подготовленными разработчиками.
➠ Выставочное демо (trade show demo). По аналогии с выставкой для каждого реализованного элемента создается «выставочный павильон». Реальные пользователи, стейкхолдеры и другие участники проходят через все павильоны и тестируют функциональность, а представители команды в каждом павильоне фиксируют озарения для улучшений в продукте. Такой подход позволяет протестировать инкремент сразу на нескольких пользователях за ограниченное время.
➠ Блок обратной связи от стейкхолдеров позволяет синхронизировать ожидания, но при этом требует дополнительного времени.
➠ Не показывать почти готовое. Бывает, что элемент почти готов, но не соответствует определению завершенности, например, не развернут на пользователей, но его можно увидеть в тестовом окружении. Статус «почти готово» может сбить с толку, вселить ложные надежды и, самое главное, придется повторно инспектировать артефакт, когда он будет готов.
3.2.3.8. Ретроспектива спринта
Ретроспектива позволяет поддерживать процессы в актуальном состоянии. Scrum-команда инспектирует последний спринт и анализирует его в разрезе ролей, процессов, инструментов и определения завершенности.
Scrum-команда обсуждает, что было хорошо во время спринта, с какими проблемами они столкнулись и как эти проблемы были или не были решены. На основании инспекции выявляются наиболее полезные изменения, которые должны быть внедрены для повышения эффективности. Определяются наиболее важные изменения, необходимые в следующем спринте.
Важно, чтобы каждый член команды мог высказаться.
3.2.3.9. Лучшие практики ретроспективы
➠ Обезличенная критика. Критикуются процессы, а не персоналии, что позволяет не переходить на личности и не вступать в упрямые статусные споры.
➠ Обсуждение положительных моментов в формате благодарения (thanksgiving retro). Участники говорят спасибо за положительные моменты, которые помогали. Это сплачивает и настраивает на позитивную коммуникацию.
➠ Последовательность «коуч – наставник – учитель». Паттерн для Scrum-мастера, который позволяет генерировать проблемы максимально эффективно:
➠ для начала человеку, заявившему о проблеме, предлагается придумать решение самостоятельно (коуч);
➠ если это не приносит результатов, всем предлагается вспомнить лучшие практики из опыта (наставник);
➠ если ничей опыт не включает подобных решений, предлагается использовать теоретические способы решения из литературы или интернета (учитель).
Такой подход позволяет минимизировать трение в процессе принятия решений: решения, исходящие изнутри, вызывают меньше сопротивления, чем решения извне.
➠ Обсуждение проблем, повлекших незавершенность элементов бэклога. Для каждого незавершенного элемента бэклога в спринте выявляются проблемы, которые помешали завершению, и определяются решения этих проблем. Это позволяет острее сфокусироваться на предсказуемости прогнозов и минимизировать разговоры о малозначимых абстрактных проблемах.
➠ Голосование за проблемы позволяет вскрыть то, что волнует большинство. Организовать это можно инструментально, например, при помощи чат-бота, который собирает во время спринта в чате команды темы с хештегом #наретро и позволяет голосовать. Такой подход позволяет сэкономить время ретро и сфокусироваться на наиболее важных проблемах.
➠ Регулярная смена шаблонов ретроспектив. Существуют десятки, если не сотни разных шаблонов проведения ретроспектив. Их регулярная смена вносит разнообразие и позволяет привнести новые лучшие практики в сам процесс ретроспективы.
3.2.3.10. Прояснение бэклога
Цель прояснения бэклога – поддержание верхней части списка в актуальном состоянии, чтобы планирование проходило максимально быстро.
Когда я только начал участвовать во внедрении Scrum, мы не устраивали сессии прояснения бэклога. Это приводило к тому, что планирование затягивалось. Часто получалось так, что для оценки наиболее важных задач требовалось погружение в документацию и эксперименты с кодом, в связи с чем разработчики не могли взять на себя обязательства закончить элемент в ближайший спринт.
Сессии прояснения бэклога позволяют минимизировать неопределенность перед планированием и планировать максимально эффективно.
Руководство по Scrum не регламентирует, какими должны быть элементы продуктового бэклога (product backlog items, или PBI), но без сомнений можно сказать, что самый популярный тип – это пользовательская история. Вторым по популярности можно считать Spike, появившийся впервые в экстремальном программировании. Впоследствии популярный фреймворк масштабирования Agile, SAFe (Scaled Agile Framework), внес Spike в состав более широкого класса сущностей – энейблеров. Они бывают нескольких размерностей – от энейблер-эпик (enabler epic) до энейблер-истории (enabler story). Так как далее в нашем контексте мы будем обсуждать размеренность уровня истории, то для краткости будем использовать термин «энейблер» в отношении «энейблер-история».
Типы элементов продуктового бэклога представлены в табл. 3.5.
Табл. 3.5. Элементы продуктового бэклога
Энейблеры – значительно более редкий элемент продуктового бэклога, поэтому часто можно услышать термин «история». Применяется для всех элементов продуктового бэклога. (Подробнее об энейблерах см. в п. 3.2.4.1.)
За спринт должно быть проведено столько сессий прояснения, чтобы во время планирования хватило на один спринт.
Рекомендуется делать небольшой запас и прояснять бэклог на 2–3 спринта вперед, но не больше, так как часть проясненных историй могут утратить актуальность.
Табл. 3.6. Пример продуктового бэклога и горизонты планирования и декомпозиции
На планировании спринта нужно быстро оценить, сколько элементов бэклога может войти в спринт. Для этого каждая история оценивается в условных единицах – сторипоинтах (англ, story points – баллы истории). Зная объем сторипоинтов, закрытых в прошлых спринтах, можно предположить, сколько сторипоинтов будет завершено в планируемом спринте.
В табл. 3.6 приведен пример бэклога. Команда быстро может набрать истории в спринт, ориентируясь на прошлые показатели. Остается запас оцененных историй на 1–2 спринта, благодаря чему команда может планировать спринты самостоятельно, в исключительной ситуации, когда владелец продукта не смог участвовать. Также запас позволяет варьировать скоуп[47] спринта, и лучше его заполнять. В табл. 3.6 владелец продукта понизил приоритет одной из историй во время планирования для более эффективного заполнения объема спринта.
Для эффективной подготовки элементов к планированию, по аналогии с определением завершенности (DoD), вводят понятие определение готовности (Definition of Ready, DoR).
DoR представляет собой некий чек-лист, которому должна соответствовать история, перед тем как отправиться на планирование.
По аналогии с DoD, DoR формируется командой самостоятельно в процессе работы.
Табл. 3.7. Акроним INVEST как основа для определения завершенности
Для старта подойдет популярная группа критериев, названная INVEST по первым буквам (табл. 3.7).
Помимо INVEST, в DoR могу входить и другие критерии в зависимости от домена, например, «описание соответствует шаблону юзерстори», «готов дизайн-макет» или «написан тест-кейс».
3.2.3.11. Декомпозиция элементов продуктового бэклога
История, которая не умещается в один спринт и обычно занимает до одного квартала разработки, называется эпик (epic story). Для декомпозиции эпиков используются инструменты декомпозиции, такие как картирование пользовательской истории (user story mapping). Далее, если история недостаточно маленькая, ее разбивают снова, используя шаблоны декомпозиции.
3.2.3.12. Картирование пользовательских историй
Картирование пользовательских историй, которое обычно называются сторимэппингом, – это метод, разработанный Джеффом Паттоном и очень интересно и с юмором описанный в одноименной книге.
Если кратко, суть метода в том, что продукт представляется в виде двухмерной матрицы, где по горизонтали – обязательные шаги пользователя (или нескольких) для выполнения работы, а по вертикали – отсортированные по значимости особенности и идеи того, как может быть реализован тот или иной шаг.
Такой подход позволяет собрать все идеи реализации, отсортировать их и распределить по релизам.
В сторимэпе выделяется четыре слоя:
➠ Роль – смена ролей в процессе взаимодействия; иногда их может быть несколько.
➠ Активность – неделимый набор шагов. Если в точку повествования можно попасть из разных мест или меняется роль, то в этой точке началась новая активность.
➠ Шаг – атомарный элемент пользовательского путешествия.
➠ Особенности – идеи того, как может быть реализован шаг.
Рис. 3.15. Пример карты пользовательской истории
Процесс картирования пользовательской истории
1. Определяются активности, которые нужно декомпозировать в первую очередь.
2. Для выбранных активностей выстраиваются шаги от последнего к первому, чтобы избежать ветвления.
3. В процессе размещаются новые активности и роли.
4. После этого для каждого шага описывается особенности – то, как он может быть реализован.
5. Для каждого шага особенности сортируются сверху вниз по критериям, которые определяют участники, например важность для пользователя, для бизнеса и реализуемость.
6. Особенности распределяются по релизам.
7. В первый релиз выделяют то, без чего действительно невозможно обойтись (минимально жизнеспособный релиз).
В приведенном на рис. 3.15 примере команда решила сфокусироваться на функциональности регистрации, авторизации и создания коллективных пространств (спейсов). Для того чтобы запуститься как можно быстрее, команда решила убрать из релиза функцию проверки сложности пароля, так как без нее можно обойтись на старте. Менее значимые и более дорогие идеи были перемещены в последующие релизы.
3.2.3.13. Связь карты пользовательской истории и бэклога продукта
Для каждых из шагов и особенностей, входящих в релиз, формулируется и вносится в бэклог пользовательская история. Название активностей удобно использовать для обозначения эпиков. Приоритизация основана на порядке релизов; внутри каждого релиза в более высоком приоритете истории, основанные на шагах, потом на особенностях. Далее приоритизация идет в соответствии с расположением элементов слева направо и сверху вниз.
Табл. 3.8. Пример бэклога для одного релиза, сформированного на основе карты пользовательской истории (рис. 3.6)
3.2.3.14. Шаблоны декомпозиции
Существует большое количество шаблонов декомпозиции. Приведем некоторые из них.
Разбиение по «и/или»
Если в описании истории используется «И/ИЛИ», значит, можно разделить прямо по этим союзам. Это относится и к спискам, разделенным запятыми.
Пример:
Я как пользователь могу создавать, редактировать, удалять текстовое сообщение и подписывать его цифровой подписью, чтобы отправить заявление.
Можно разделить на:
Я как пользователь могу создавать текстовое сообщение, чтобы отправить заявление.
Я как пользователь могу создавать и редактировать сообщение, чтобы отправить заявление.
Я как пользователь могу создавать и удалять сообщение, чтобы отправить заявление.
Я как пользователь могу подписывать сообщение, чтобы отправить заявление.
Разбиение на операции
Известный представитель такого типа шаблонов – CRUD. Название шаблона – это аббревиатура из первых букв действий, которые можно совершать со списком: Create, Read, Update, Delete (Создать, Прочитать, Обновить, Удалить).
Историю «Я как пользователь могу редактировать список разделов» люжно разделить на:
Я как пользователь могу создать раздел.
Я как пользователь могу видеть список разделов.
Я как пользователь могу редактировать раздел.
Я как пользователь могу удалить раздел.
Разделение по этапам процесса
Если процесс содержит несколько шагов, то можно разделить по ним. Например, если для публикации контента нужно пройти этапы рецензирования редактором и юристом, то история «Я как контент-менеджер могу публиковать материал на сайте» может быть разделена на:
Я как контент-менеджер могу публиковать материал напрямую на сайте.
Я как контент-менеджер могу публиковать материал на тестовом сайте.
Я как корректор могу проверить материал перед отправкой.
Я как редактор могу проверить материал перед отправкой.
Если внимательно приглядеться, история «Я как пользователь могу ввести e-mail, чтобы зарегистрироваться» может быть разбита на три атомарных этапа:
Я как пользователь могу просто ввести e-mail.
Я как пользователь могу увидеть, что e-mail не соответствует шаблону name @domain.zone.
Я как пользователь могу увидеть, что введенный e-mail уже существует.
Разделение по производительности
Историю «Я как пользователь могу получать изображение в реальном времени» можно разбить на варианты «заставить работать» и «работать быстро»:
Я как пользователь могу получать изображение.
Я как пользователь могу получать изображение менее чем за 5 секунд.
Я как пользователь могу получать изображение менее чем за 1 секунду.
Этот шаблон может быть применим для:
➠ времени выполнения;
➠ времени доступности;
➠ качества контента и пр.
Разделение по сегментам пользователей
Историю «Я как пользователь могу распознать текст на фото» можно разделить на:
Я как пользователь iOS версии выше 17 могу распознать текст на фото.
Я как пользователь Android версии выше 13 могу распознать текст на фото.
Этот шаблон может быть применим для:
➠ типов устройств – настольные, мобильные;
➠ операционных систем и их версий – iOS, Android;
➠ лояльности – сотрудник компании, друзья и родственники, бета-тестер, постоянные клиенты, члены команды;
➠ сегментов обслуживания – премиальные, массовые.
Добившись малой размерности истории, можно переходить к оценке.
3.2.3.15. Оценка элементов продуктового бэклога
Как уже говорилось ранее, самый популярный способ оценки в Scrum – общекомандная оценка в сторипоинтах. Это обеспечивает достаточно высокую скорость оценки при высоком качестве прогноза.
Если конкретнее, актуальный способ оценки называется «Коллективная покерная медианная оценка в относительных единицах с шагом Фибоначчи».
Давайте проследим эволюцию способов оценки.
Индивидуальная оценка личного вклада в человеко-часах
Первый интуитивный способ оценки – каждый разработчик прогнозирует, сколько он затратит времени в человеко-часах.
Точно узнать, сколько уйдет времени на задачу, можно только после ее завершения. Люди не очень любят ошибаться, и поэтому чем больше оценка называется, тем выше вероятность в нее попасть. Если в оценке себя люди средне оптимистичны, но более пессимистичны в оценке других, в оценку закладывается риск, что другие участники подготовят максимально неподходящий артефакт: например, дизайнер предоставит плохо сверстанный макет.
Минусы:
➠ требует много времени;
➠ пока не сделаешь точно, не узнаешь, сколько потребуется времени;
➠ перестраховка при новых задачах;
➠ пессимизм в оценке других;
➠ подгонка срока под оценку.
Оценка тимлидами в человеко-часах
Когда количество запросов на оценку начинает расти, приходят к тому, что оценивать начинают авторитетные представители разработчиков – тимлиды.
Есть что-то несправедливое в том, что твою работу оценивают за тебя другие. Это может вызывать внутреннее сопротивление и саботаж. Легче сорвать срок, за который ты не отвечаешь.
Минусы:
➠ сложность учета параллельности и взаимопомощи;
➠ исполнители не отвечают за срок.
Рубашечная оценка тимлидами (XS, S, M, L, X, XL)
При увеличении объема оцениваемых задач тимлиды начинают не справляться и приходят к относительным единицам: разделяют маленький, средний, и большой проект, для которых определяют стандартные сроки, среднюю загрузку членов команды и стоимость.
Этот подход получил название «рубашечная оценка» по аналогии с размерами рубашек – XS, S, M, L, XL (рис. 3.16). Нагрузка на тимлидов при оценке значительно снизилась при сопоставимой точности.
Минусы:
➠ исполнители не отвечают за срок;
➠ сложно почувствовать разницу между размерами рубашек.
Рис. 3.16. Название размеров неочевидно связано с физическими размерами футболок, что затрудняет оценку
Рубашечная оценка командой
Так как трудозатраты на оценку при рубашечном подходе радикально снизились, можно предложить сделать рубашечную оценку всей команде. Но если делать это в открытую, можно прийти к конформизму, который проявляется в эффекте фрейминга: первый, кто называет оценку, влияет на оценки остальных.
Плюс в том, что разработчики оказываются в одной лодке и склонны сотрудничать, в процессе работы помогая друг другу, дорабатывая собственные артефакты и выходя за пределы своей роли.
Минусы:
➠ сложно почувствовать разницу между размерами рубашек;
➠ конформизм.
Покерная рубашечная оценка командой
Покерная оценка названа по аналогии с карточной игрой. Участники проводят индивидуальную оценку командной работы и потом «вскрывают карты».
В случае, если не все согласны с самой популярной оценкой, выслушиваются мнения несогласных и производится переоценка. Эффективнее всего спрашивать мнения участников, имеющих краевые значения, – самое маленькое и самое большое. В процессе обсуждения может выясниться, что команда не учла какие-то особенности реализации, которые нужно включить или исключить из скоупа работ.
Минусы:
➠ сложно почувствовать разницу между размерами.
Покерная усредненная оценка в относительных единицах
Оценка в условных единицах (рис. 3.17) более понятна, чем оценка в рубашках. За единицу принимается атомарная доработка, в которой принимала участие вся команда. Трудно оценить в часах вклад каждого, но легко оценить, что одна работа в два раза больше другой, включая объем работ, сложность и риски. После вскрытия карт полученный ответ усредняется.
Рис. 3.17. Командная оценка в относительных единицах дает хороший баланс интуитивности, скорости и качества
Минусы:
➠ не заметны крайние значения;
➠ экстремальные значения влияют на оценку большинства.
Покерная усредненная оценка в относительных единицах Фибоначчи
Следующий шаг эволюции, когда оценки возрастают не линейно, а по ряду Фибоначчи: 1, 2, 3, 5, 8, 13, 21… Это делает краевые значения очень заметными, но усугубляет проблему влияния экстремальных оценок на среднее.
Минусы:
➠ экстремальные значения влияют на оценку большинства.
Покерная медианная оценка в относительных единицах Фибоначчи
Медиана практически не чувствительна к выбросам, что позволяет большинству участников быстрее согласиться с оценкой.
Например, для оценок 1, 2, 3, 2, 1, 15 медиана будет равна 2, а среднее – 4 (рис. 3.18).
Рис. 3.18. Медианная оценка позволяет избежать влияния выбросов
Процесс оценки тесно связан с декомпозицией. В процессе обсуждения разницы в оценках появляется развилка во мнениях, что должно входить или не входить в скоуп.
Рассмотрим пример того, как происходит оценка.
Scrum-мастер (SM): Следующая история из бэклога для оценки: «Я как пользователь могу согласиться с правилами сервиса».
SM: Все готовы оценить?
Команда разработки (Ш):Да!)
SM: Прошу проставить оценки.
SM: Все поставили оценки?
DT.-Да!)
SM: Вскрываемся. Получились следующие оценки: 1, 2, 3, 2, 1, 15, медиана равна 2. Все согласны на оценку 2?
Backend (BE): Я не согласен.
SM: Почему ты считаешь, что это больше, чем история на 2?
BE: Нужно сохранять статус согласия на бэке.
Владелец продукта (РО): Предлагаю разделить на две истории, когда значение сохраняется только на фронте, а вторая – на бэке.
SM: Разобьем историю на несколько: «Я как пользователь могу согласиться с правилами без повторного запроса на все время браузерной сессии» и «Я как пользователь могу согласиться с правилами без повторного запроса на разных устройствах».
3.2.3.16. Отмена спринта
Бывают такие ситуации, когда нет смысла продолжать спринт. В этом случае Scrum-команда договаривается остановить спринт (рис. 3.19).
Рис. 3.19. Схема разделения одного спринта на два при выполнении остановки спринта
В день остановки проводятся завершающие события спринта – демо и ретро.
После этого запускается новый спринт. Хороша практика, когда окончание нового спринта совпадает с окончанием отмененного: это не дает команде сбиться с ритма.
3.2.4. Артефакты Scrum
Артефакты Scrum созданы для фиксации обязательств и прозрачности:
➠ Бэклог продукта – обязательства по цели продукта.
➠ Бэклог спринта – обязательства по цели спринта.
➠ Инкремент – обязательства в соответствии с определением завершенности.
3.2.4.1. Бэклог продукта
Бэклог продукта – это упорядоченный список того, что нужно улучшить в продукте. Это единый источник доработок для Scrum-команды.
Элементы продуктового бэклога могут быть завершены за один спринт и подготовлены для выбора на планировании спринта. Обычно они подготавливаются в процессе прояснения бэклога. Элементы бэклога отвечают на вопрос «что», а не «как».
Обязательство: цель продукта
Все элементы бэклога направлены на достижение цели продукта. Цель продукта – детальное описание будущего состояния продукта, в направлении которого работает команда. Важно, чтобы у продукта были четкие границы, известны стейкхолдеры и хорошо определены пользователи или клиенты.
Под продуктом в Scrum может подразумеваться как цифровой сервис, так и физический продукт или что-то более абстрактное.
Scrum-команда работает в направлении достижения цели продукта. (Подробнее о том, как эффективно описывать цель продукта, см. в п. 4.3.6.)
Типы элементов бэклога
Как уже говорилось, каждый элемент бэклога, превращаясь в инкремент, должен улучшать жизнь пользователя, напрямую увеличивая его возможности, как пользовательская история, или опосредованно, повышая жизнеспособность продукта, как история-энейблер.
Пользовательская история
Пользовательская история – это описание особенности продукта, какую новую возможность он получает, голосом пользователя. Пользовательская история – идеальный граничный объект (см. п. 2.4.), который позволяет передать суть функциональности («что?»), но дает при этом свободу команде разработчиков в способе реализации («как?»).
Наибольшую популярность получил шаблон, описанный Майком Коном (рис. 3.20).
Истории записывались на карточках (по слухам, на использованных перфокартах). С появлением цифровых инструментов поле «Приоритет» стало использоваться гораздо реже, так как приоритетом может служить порядковый номер строки в электронной таблице.
Энейблер
Энейблеры (enabler), как правило, начинают появляться на зрелых фазах существования продукта, когда сформирован поток ценности (см. 4.2.2. Определение потока ценности).
Рис. 3.20. Шаблон пользовательской истории, описанный Майком Коном
В руководстве по фреймворкам масштабирования Agile SAFe выделяют четыре вида энейблеров:
➠ Исследовательский (exploration). Обозначает работы по проведению исследований, прототипирование и прочие активности, необходимые для прояснения пользовательских историй. Популярный вид таких энейблеров – Spike, который используется разработчиками, если они не могут оценить историю в процессе прояснения бэклога.
➠ Архитектурный (architectural). Работы по повышению эффективности разработки и поддержки, например настройка CI/CD.
➠ Инфрастуктурный (infrastructural). Работы, направленные на оптимизацию инфраструктуры. Например, снижение стоимости владения или митигация рисков стабильности.
➠ Комплаенс (compliance). Работы по аудиту и приведению системы в соответствие стандартам, спецификациям, внешним и внутренним требованиям, например, приведение хранилища платежных данных в соответствие стандарту PCI DSS.
Критерии приемки
Обязательная часть пользовательской истории – критерии приемки (Acceptance Criteria, АС). Это описание того, в каких условиях будет тестироваться функциональность и какой ожидается результат.
Критерии приемки позволяет делать формулировки историй более короткими и не перегружать их техническими деталями.
Примеры связки US и АС можно увидеть в табл. 3.9.
Используется одна и та же формулировка US, но разные АС.
Табл. 3.9. Пример бэклога с разными критериями приемки
3.2.4.2. Бэклог спринта
Бэклог спринта (sprint backlog) – это план спринта для разработчиков. Прозрачная картина того, что было сделано для достижения цели спринта, актуализируемая каждый день на ежедневном Scrum.
Обязательство: цель спринта
Цель спринта – это задание на спринт. Команда берет на себя обязательство по ее выполнению, при этом самостоятельно принимает решение, как и в какой последовательности будет ее достигать. Цель спринта формируется в процессе планирования спринта и фиксируется в бэклоге спринта.
Лучшие практики управление бэклогом спринта
Использовать Scrum-доску. Ее описание было предложено в п. 3.1.3.6. Это удобный инструмент визуализации прогресса спринта, который позволяет в первую очередь фокусироваться на реализации пользовательских историй, а не составляющих их задач.
Рис. 3.21. Диаграмма сгорания показывает, насколько команда выдерживает темп по количеству историй, сторипоинтов и задач
Использовать диаграмму сгорания. Диаграмма сгорания позволяет в реальном времени видеть отставание в процессе спринта. Например, на рис. 3.21 видно, что разработчики закрывают задачи вовремя, практически по идеальному графику. Но если посмотреть на график сгорания сторипоинтов, то заметно отставание. Ну и самое главное – график сгорания пользовательских историй отражает самую суть: сколько единиц ценности будет поставлено. Ориентация на график сгорания пользовательских историй позволяет минимизировать риски недопоставки. Для ритмичной поставки истории на протяжении спринта можно использовать практику роения.
Роение (swarming) – подход к разработке, когда вся команда последовательно реализует историю за историей на протяжении спринта. Это позволяет не терять время на переключение между задачами и не держать в голове дополнительный контекст по принципу «сделал – забыл». При достаточно мелкой декомпозиции пользовательских историй команда может сразу двигать их по Kanban-доске, на разбивая на задачи. Этот подход подразумевает, что вся команда «набрасывается» на историю и работает над ней одновременно.
Как можно одновременно работать над одной пользовательской историей, не всегда очевидно, особенно для тех, кто до этого занимался заказной разработкой. Обычно в таких случаях возникают вопросы типа: «Как я сверстаю интерфейс без дизайн-макета?» или «Как мне делать разработку фронта без бэкенд API?».
Прежде всего история должна быть достаточно маленькая, желательно атомарная, типа «Я как пользователь могу удалить раздел». Это делает работу каждого понятной и обозримой. Далее команда активно взаимодействует и дорабатывает артефакты друг для друга.
Например: в начале разработки дизайнер и фронт-разработчик совместно рисуют схему расположения элементов, фокусируясь при этом на уже существующих компонентах. Фронт-разработчик и бэк-разработчик прописывают контракты[48] взаимодействия. QA (quality assurance, инженер, отвечающий за тестирование) создает моки[49] (mock) – тестовые данные, которые позволят фронту и бэку отлаживать базовые сценарии взаимодействия. В середине пути дизайнер создает макет более стильного и удобного интерфейса. Фронтенд элемент за элементом улучшает интерфейс согласно макету.
Бэкенд постепенно заменяет моковые методы на настоящие, a QA в реальном времени тестирует эти методы, адаптируя тест-кейсы. Бывает, что не все идеи дизайнера получается воплотить; в этом случае команда находит компромиссное решение (рис. 3.22).
Рис. 3.22 Управление качеством артефакта в процессе спринта
В конце пути QA тестирует функциональность на тестовой среде в составе релиз-кандидата, остальные участники исправляют выявленные недочеты.
3.2.4.3. Инкремент продукта
Инкремент – это шаг в достижении цели продукта. Это дополнение ко всем предыдущим инкрементам, которое детально проверяется, гарантируя совместную работу всех инкрементов. Чтобы обеспечить его ценность, должна быть возможность использовать его.
Инкремент может представлять собой сумму инкрементов. За спринт инкремент может быть поставлен несколько раз. Стейкхолдеры могут получить инкремент до обзора спринта, по договоренности со Scrum-командой.
Работа не может считаться инкрементом, пока она не соответствует определению завершенности.
Обязательство: определение завершенности
Определение завершенности – это формальное описание состояния инкремента, когда он соответствует показателям качества, необходимым для продукта.
DoD обеспечивает прозрачность, предоставляя всем общее понимание того, какая работа была завершена в рамках инкремента. Если элемент бэклога продукта не соответствует DoD, то согласно руководству по Scrum он не может быть выпущен или даже представлен на обзоре спринта. Вместо этого он возвращается в бэклог продукта для дальнейшего рассмотрения.
Определение завершенности может формироваться на уровне Scrum-команды в процессе ретроспективы спринта, а также на уровне трайба или всей организации – в этом случае Scrum-команда также обязана ему следовать.
Пример определения завершенности
Часто бывает, что на старте члены Scrum-команды по-разному понимают значение Done (Выполнено). Владелец продукта ожидает, что функциональностью можно пользоваться реальным пользователям. Для разработчиков Done может значить, что код написан и ждет тестирования. DoD позволяет выравнивать ожидания.
В табл. 3.10 вы можете ознакомиться с примером определения завершенности с показательными элементами, собранными в разное время от разных команд.
Как уже стало заметно, DoD – мощнейший инструмент для управления требованиями к:
➠ производительности;
➠ архитектуре;
➠ безопасности;
➠ развертыванию;
➠ качеству кода;
➠ сбору аналитических данных;
➠ сравнительным экспериментам;
➠ дизайну;
➠ документации;
➠ инфраструктуре;
➠ ролям;
➠ процессам;
➠ требованиям;
➠ обслуживанию;
➠ автоматизации тестирования;
➠ процессам тестирования.
Табл. 3.10. Пример определения завершенности (DoD)
Важно как можно раньше начинать развивать DoD для подготовки к фазе масштабирования.
Определение завершенности – важный инструмент управления качеством программного обеспечения. О том, как выглядит процесс управления качеством ПО в гибких подходах, поговорим в следующей главе.