Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло все с ног на голову:

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

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

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

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

В более строгом варианте эти тезисы были сформулированы отцами-основателями гибких методологий в документе, который получил название Agile Manifesto.

 Люди и их взаимодействие важнее процессов и инструментов.

 Готовый продукт важнее документации по нему.

 Сотрудничество с заказчиком важнее жестких контрактных ограничений.

 Реакция на изменения важнее следования плану.

Визуализация ценностей манифеста гибкой разработки

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

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

Принципы гибких методологий

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

1. Наш высший приоритет – это удовлетворение заказчика с помощью частых и непрерывных поставок продукта, ценного для него.

Основная проблема с программными продуктами заключаются в том, что для потребителя они представляются чем-то эфемерным. Чтобы понять, что наш продукт действительно удовлетворяет заказчика, необходимо максимально часто (в идеале – непрерывно) поставлять его и собирать отзывы.

2. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта.

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

3. Гибкие процессы приветствуют изменения, что является конкурентным преимуществом для заказчика.

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

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

Результатом нашей работы должен быть рабочий программный продукт, а не техническое задание, какие-либо макеты и т. п., что мы демонстрируем заказчику. Мы должны уметь быстро делать максимально готовый программный продукт.

5. Представители бизнеса и команда разработки должны работать вместе над проектом.

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

6. Успешные проекты строятся мотивированными людьми. Дайте им подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу.

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

7. Самый эффективный метод взаимодействия и обмена информацией – это личная беседа.

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

8. Рабочее программное обеспечение – главная мера прогресса проекта.

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

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

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

10. Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.

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

11. Простота необходима как искусство максимизации работы, которую не следует делать.

Простота важна во всем, от интерфейса/дизайна до архитектуры. Чем проще продукт, тем легче им пользоваться, проще изменять и дешевле поддерживать.

12. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.

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

13. Команда должна постоянно искать способы стать эффективнее путем настройки и адаптации своих процессов.

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

Оригинальные принципы Agile на английском языке вы можете найти на странице .

Scrum в двух словах

Общая схема Scrum

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

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

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

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

Не Scrum’ом единым

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

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

Популярность гибких методологий

Менее популярные методологии перечислены и кратко описаны в главе 12.

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

Практики экстремального программирования

Разделение, повторюсь, весьма условное, но оно показывает, что экстремальное программирование имеет много общего со Scrum, однако есть и определенные отличия. Инженерные практики будут рассмотрены подробнее в соответствующем разделе, а управленческие практики применяются обычно из Scrum.

Канбан

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

1. Визуализируйте производственный процесс.

Для этого обычно используют доску, размеченную по этапам работы над задачей. Конечно, более продвинутым вариантом будет использовать плазму/проектор и выводить туда состояние трекера.

2. Ограничивайте количество незавершенной работы (WIP, Work In Progress).

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

Доска задач в рамках канбана

Среднее время реализации задачи (lead time) – метрика, показывающая, насколько быстро задача проходит весь поток.

3. Оптимизируйте процесс.

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

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

Сегодня самой популярной гибкой методологией разработки ПО является Scrum. Если вы спросите любого практика Agile, он обязательно подтвердит это, хотя каждое слово в предыдущей фразе – неправда.

Начнем с конца: Scrum используют не только для разработки ПО, он отлично подходит для многих процессов по созданию продукта, от венчурных до маркетинговых продуктов. Соответственно подбираемся ко второму пункту: Scrum – вовсе не методология, это гибкий управленческий фреймворк. Откуда следует и третий пункт: Scrum обычно дополняют инженерными практиками из других гибких методологий (например, практики разработки из экстремального программирования или практики анализа и сбора требований из ICONIX). В дальнейшем, если не оговорено иное, под Agile будем подразумевать семейство гибких методологий, а Scrum будем рассматривать в качестве управленческого фреймворка, дополненного практиками из других гибких методологий. Однако довольно буквоедствовать, начнем знакомиться со Scrum.

Официальное описание Scrum, The Definitive Guide to Scrum: The Rules of the Game («Исчерпывающее руководство по Скраму: Правила игры»), можно найти на странице , включая перевод на русский язык.

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

Классический Scrum состоит из следующих элементов.

Элементы Scrum

Роли

 

Скрам-мастер

Скрам-мастер – это член команды, который ответствен за понимание и реализацию Scrum и помогает в этом следующим субъектам.

Обязанности скрам-мастера

Процессы

 

Обзор спринта

Обзор спринта (Sprint Review, «демонстрация», или сокращенно «демо») – демонстрация владельцу продукта и заинтересованным лицам работающего функционала продукта, сделанного за спринт. Основная задача проведения обзора спринта заключается в получении обратной связи, общий цикл чего выглядит следующим образом.

Получение обратной связи в рамках Scrum

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

Если взглянуть еще раз на манифест Agile, в нем есть пункт, который непосредственно касается демонстраций: «Готовый продукт важнее документации по нему». Действительно, основной мерой прогресса является функционал нашего продукта, поэтому показывать на демонстрации надо именно программу. Если заказчик находится не в одном помещении с вами, используйте специальные средства демонстрации. Гораздо хуже будет отправить заказчику презентацию или отчет по сделанному функционалу, ведь мы хотим получить качественную обратную связь.

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

К паттернам можно отнести демонстрацию «чужих» реализованных элементов журнала пожеланий и привлечение к демонстрации аналитиков, тестировщиков, верстальщиков, UI-специалистов и т. д. Такой подход позволяет выработать командную ответственность за результат.

Ретроспектива

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

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

Структура ретроспективы. Обычно ретроспектива занимает от 30 минут до четырех часов и ее продолжительность зависит от таких факторов, как:

• длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;

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

• наличие проблем: со временем команда решает проблемы, и ретроспективы сокращаются по времени.

В процентном соотношении принято выделять такую структуру.

Структура ретроспективы

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

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения будем делать?

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

Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать вначале: «Вне зависимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал все, чтобы добиться успеха».

Если у команды отсутствуют серьезные проблемы, желательно следующие темы обсудить на ретроспективе:

• скорость команды и ее изменение по сравнению с предыдущими спринтами;

• нереализованные истории пользователей и причины опоздания;

• дефекты и их причины;

• качество процессов (нарушения, отступления).

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

Артефакты

В Scrum определены три артефакта.

• Журнал пожеланий продукта (Product Backlog) – фактически приоритезированный список требований. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-пользу и называются элементами журнала пожеланий.

• Журнал пожеланий спринта (Sprint Backlog) – часть журнала пожеланий продукта с самой высокой важностью и суммарной оценкой, не превышающей скорости команды, отобранная для спринта.

• Инкремент продукта – новая функциональность продукта, созданная во время спринта.

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

Построение бизнес-модели

Наиболее подробно построение бизнес-моделей описано в работе Александра Остервальдера (Alexander Osterwalder) и Ива Пинье (Yves Pigneur) «Построение бизнес-моделей. Настольная книга стратега и новатора» (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers). Бизнес-модели «Канвас» представляют собой способ визуализации бизнес-моделей, и их можно адаптировать к проектам по разработке ПО (табл. 3.1).

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

Персоны

Практика анализа персон пришла в управление продуктами из практик User Experience (опыт использования). Она заключается в описании пользователя создаваемого продукта как реального персонажа с конкретными ценностями и целями.

Таблица 3.1.

Бизнес-модель в виде Lean Canvas

Инструмент Story Mapping

После выявления персон нужно перейти к определению функционала, который необходимо реализовать для персон. Для этого используется Story Mapping (стори маппинг) – способ визуализации и планирования функционала.

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

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

• дополнительных возможностей;

• безопасности;

• удобства использования;

• производительности.

Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.

Визуализация журнала пожеланий продукта с помощью Story Mapping

Журнал пожеланий продукта

Как было сказано выше, журнал пожеланий продукта состоит из бизнес-требований, которые обычно оформляются в виде историй пользователей. Рассмотрим подробнее, что представляет собой отдельная история пользователя.

 Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя из трекера, которым пользуется команда. Этот идентификатор позволяет точно сказать, о какой истории пользователя в данный момент идет речь.

 Название истории пользователя – короткое (примерно до десяти слов) описание функционала с точки зрения пользователя, сформулированное в виде тройки «роль – действие – цель», например: «Пользователь вводит логин и пароль, чтобы авторизоваться на сайте».

 Важность – уникальный числовой приоритет истории пользователя. Чем она выше, тем раньше данную историю необходимо сделать.

 Оценка – числовая относительная оценка истории пользователя по специальной шкале.

Указанные поля удобно размещать на стикере, который прикрепляется на доску. Например, историю пользователя для авторизации на сайте с оценкой 10 очков (Story Points), важностью 200 и номером в трекере 1453 можно представить на стикере так.

История пользователя для авторизации на сайте

Эти четыре поля являются фактически обязательными, но часто используются и дополнительные поля, которые, например, заносятся в трекер.

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

 Демонстрация – достаточно подробный сценарий, позволяющий провести демонстрацию истории пользователя. Например, для приведенной выше истории пользователя с авторизацией можно использовать следующие краткие сценарии для демонстрации:

♦ пользователь вводит логин root и пароль pass и переходит на страницу личного профиля на сайте;

♦ пользователь вводит логин root и пароль wrongpass и получает сообщение Введен неправильный логин или пароль.

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

Размер журнала пожеланий и стратегическое планирование

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

Противоречие между тактическим и стратегическим планированием

Какой бы размер журнала пожеланий мы ни выбрали, все равно не получится разрешить конфликт – нужно прорывное решение. Оно достаточно просто и лежит на поверхности: использовать метод набегающий волны. В рамках Scrum такой подход означает, что мы разбиваем очень подробно истории пользователей на несколько ближайших спринтов, а остальные истории пользователей храним в виде больших фрагментов функциональности, подробно не описывая их. Такие большие истории пользователей, которые в дальнейшем будут разбиты на маленькие, называются эпиками (epic).

Более важные элементы журнала пожеланий определены точнее

Как видите, чем позднее планируется реализация того или иного функционала, тем более крупные фрагменты функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS (Keep it simple, stupid – «Не усложняй, тупица») и YAGNI (You аin’t gonna need it – «Вам это не понадобится»).

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

• рефакторинг модуля;

• оптимизация производительности;

• исправления сложного дефекта;

• настройка инфраструктуры.

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

Определение приоритетов историй пользователя

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

Рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано (Noriaki Kano) предложил ее в работе «Привлекательное качество и необходимое качество» (Attractive Quality and Must-Be Quality) еще в 1984 году.

Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта.

Типы функций продукта

Таким образом, можно выделить три типа функций продукта.

1. Обязательные функции – пользователь ждет этих функций от продукта, без них ему продукт не нужен. Например, для сотового телефона это возможность совершать звонки.

2. Линейные функции – чем больше и качественней они реализованы, тем больше доволен пользователь. К примеру, это долгая работа сотового телефона без подзарядки.

3. Привлекательные функции – функции, которые придают вашему продукту wow-эффект. В качестве примера можно рассмотреть эргономику и удобство использования (юзабилити) Apple IPhone.

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

1. Как вы отнесетесь к наличию данной функциональности в продукте?

2. Как вы отнесетесь к отсутствию данной функциональности в продукте?

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

В качестве ответов опрашиваемому пользователю предлагаются следующие варианты ответов:

• нравится;

• ожидаю этого;

• все равно;

• могу смириться с этим;

• не нравится это.

После такого опроса можно проводить анализ результатов с помощью следующей таблицы (табл. 3.2).

Таблица 3.2.

Анализ результатов

В результате функции продукта разобьются на шесть категорий:

• A (attractive) – привлекательные;

• O (one-dimensional) – линейные;

• M (must-be) – обязательные;

• R (reverse) – обратные (ненужные);

• Q (questionable result) – сомнительный/противоречивый результат;

• I (indifferent) – безразлично.

Первые три категории для нашего анализа являются самыми интересными и дают более глубокое понимание требований по нашему продукту:

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

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

По завершении опроса необходимо подвести итоги, просуммировав ответы пользователей (табл. 3.3).

Таблица 3.3.

Суммы ответов пользователей

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

Умные цели для спринта

 

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

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

Таблица 3.4.

Расшифровка SMART

 

Specific – точные и конкретные цели

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

Таблица 3.5.

Запись целей

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

 

Measurable – измеримые цели

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

Таблица 3.6.

Измеримость целей

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

 

Time-bound – цели со сроком

При обсуждении сроков выполнения задач или достижения целей нельзя не вспомнить еще один эмпирический закон – закон Паркинсона: «Любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время». Из личного опыта скажу, что, когда у задачи нет срока, она вытесняется срочными делами и шанс, что до нее когда-нибудь дойдут руки, падает, поэтому при постановке любой задачи необходимо устанавливать срок исполнения.

Срочность целей тесно связана с достижимостью: чем меньше срок исполнения задачи, тем более она труднодостижимая, что надо учитывать при постановке задач (табл. 3.7).

Таблица 3.7.

Срочность задач

Концепция ограничения по срокам встроена в Scrum: итерации всегда фиксированного размера и команда четко знает, когда будет проводиться демонстрация результатов спринта.

SMART

Лишняя функциональность

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

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

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

Зависимость стоимости разработки и поддержки от длительности проекта

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

FC = StoryPoints × StoryPointCost + SupportCost

Она фактически иллюстрирует графики в аналитическом виде: первое слагаемое, которое представляет собой стоимость разработки, при увеличении длительности проекта не изменяется, второе же растет.

Зависимость стоимости разработки и поддержки от времени жизни проекта

Из этого можно сделать следующие выводы:

• в бесконечном проекте важна только стоимость поддержки;

• чем длительнее проект, тем важней стоимость поддержки;

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

• чем длительнее проект, тем выгодней вырезать ненужные «фишки».

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

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

Что такое команда

Определений команды существует несколько десятков. Будем придерживаться следующего, которое дал Майкл Армстронг.

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

Этапы командообразования

Чтобы группа людей превратилась в сплоченную команду, она должна пройти несколько этапов. Наиболее распространенной моделью командообразования является модель Такмана.

Этапы командообразования

В своем развитии команды проходят несколько этапов.

1. Формирование.

На данном этапе происходит создание команды и постановка целей, распределение и закрепление ролей (в том числе социальных). Отдельные члены команды еще не очень понимают цель и задачи, которые перед ними поставлены.

Отсутствие направленности к цели у членов команды

2. Бурление.

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

Разнонаправленность членов команды

Цель также стала более четкой и понимаемой для команды.

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

3. Нормализация.

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

Сонаправленность членов команды

Основной задачей скрам-мастера является помощь команде для перехода на следующий этап.

4. Функционирование.

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

Сильная сонаправленность членов команды

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

5. Расформирование.

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

Рассинхронизация членов команды на этапе расформирования

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

Таблица 4.1.

Приблизительное время для различных этапов командообразования

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

Самоорганизация в командах

 

Стили управления

В зависимости от этапа командообразования необходимы различные стили лидерства. Попробуем использовать для этого модель ситуативного лидерства, которую разработали Херси и Бленчард, и объединим ее с моделью Такмана.

Стили лидерства по Херси и Бленчарду

Уровни команд соответствуют этапам командообразования из предыдущего раздела.

Лучшие практики управления командой в Scrum

 

Покер-планирование

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

• все элементы журнала пожеланий должны иметь уникальную числовую важность;

• самые важные элементы журнала пожеланий должны быть уточнены и понятны всей команде и владельцу продукта;

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

Основным результатом планирования спринта является журнал пожеланий спринта – список задач, которые команда планирует реализовать в рамках спринта. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов журнала пожеланий (объем работ), которые она может реализовать. Можно данную ситуацию отобразить на классическом треугольнике управления проектами.

Проектный треугольник в Scrum

Для определения, какие элементы журнала пожеланий войдут в спринт, можно использовать покер-планирование.

Покер-планирование (Planning poker) – консенсусная относительная оценка историй пользователей командой. Этот вид оценки не входит в классический Scrum, но является паттерном для оценки историй пользователей.

Покер-планирование проводится следующим образом.

1. Каждому участнику раздается колода карт с числовыми весами для оценки требований.

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

3. Каждый член команды дает свою оценку, кладя карту рубашкой вверх.

4. После того как все члены команды сделали оценку, все карты переворачиваются и оценки сверяются.

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

Покер-планирование

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

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

 

Выбор эталонной задачи

Для относительной оценки необходимо выбрать эталонную историю пользователей. Она должна быть:

• простой и понятной для команды;

• типичной для данного проекта;

• небольшого размера.

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

Тимофей Евграшин, тренер

Эту историю пользователя команда принимает за 1 «пункт». Тогда история пользователя, которая будет в два раза меньше эталонной, будет иметь размер 1/2 «пункта», а история пользователя, которая в пять раз больше эталонной, будет иметь размер 5 «пунктов». Таким образом, «пункт» – это относительная безразмерная единица измерения.

Для оценки используется дискретная логарифмическая шкала:

Причем оценки в 40 и 100 «пунктов» за пользовательскую историю применяются для эпиков и считаются неточными. Такая шкала относит к одному размеру истории пользователя в 20 и 21 «пункт», но к разным – задачи в 2 и 3 «пункта».

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

Шкала размеров историй пользователей

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

 

Ход покер-планирования

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

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

Ксения Колосова, руководитель проектов

Карты выкладывают рубашкой вверх

После этого все карты одновременно переворачиваются.

Карты одновременно переворачиваются

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

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

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

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

Обсуждение начинается с участников с минимальной и максимальной оценкой

Второй раунд

Консенсусная оценка

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

Ксения Колосова, руководитель проектов

 

Отбор задач на спринт

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

Скорость команды за последние восемь спринтов

На схеме, изображенной ниже, в спринт отбираются истории пользователей A, B, C, D и F.

Отбор элементов журнала пожеланий продукта в журнал пожеланий спринта

Диаграмма сгорания

Для мониторинга прогресса в Scrum используется специальный график – диаграмма сгорания (Burndown Diagram). По горизонтальной оси на таком графике откладываются дни спринта, а по вертикальной – количество оставшихся «пунктов» и/или закрытых историй пользователей. Дополнительно строится идеальная диаграмма сгорания, которая показывает запланированный ход работ.

Диаграмма сгорания показывает, что спринт завершился в соответствии с планом

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

Анализ производится путем сравнения реального графика с идеальным:

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

• если реальный график ниже идеального – команда опережает план.

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

Рассмотрим самую стандартную ситуацию – с отставанием от графика.

Отставание от плана

Команда должна на очередном скрам-митинге обсудить, почему очки за пользовательскую историю сгорают так медленно, и выработать контрмеры. Самые распространенные причины следующие:

• серьезная ошибка в планировании;

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

• недооценивание и реализация рисков (обычно технологических).

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

Обратной ситуацией является опережение плана.

Опережение графика

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

Доска задач

Самым наглядным инструментом мониторинга и управления внутри спринта является доска задач, которая по функционалу похожа на аналогичный инструмент из канбана. Однако, поскольку в Scrum имеются фиксированные итерации, доска по завершении спринта «обнуляется» – с нее убираются все стикеры.

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

Все истории в первом столбце и отсортированы по важности

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

Вид доски в середине спринта

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

Доска при завершении спринта, если все истории были реализованы

Еще одним способом использования доски является следующий подход:

• истории пользователей берутся достаточно большие (3–7 на спринт) и располагаются в отдельном столбце;

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

Истории пользователей разбиваются на продуктовые задачи

Теории X и Y

 

Существуют две фактически противоположные друг другу теории в мотивации людей: X и Y.

Теории X и Y

Эффект наблюдателя

Сроки и долгосрочное планирование в Agile

 

Оценка сроков релиза в Scrum-проекте

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

Диаграмма сгорания релиза показывает расчетную дату завершения проекта

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

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

Можно использовать и более изощренный подход: строить график добавления историй пользователя отдельно вниз, в отрицательные квадранты, и просчитывать вероятность завершения релиза в данном спринте (подробнее – в статье «Подвижная мишень и дрожащие руки» по адресу ).

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

• если штрафные санкции по проекту велики, а вознаграждение – не очень, мы можем ограничиться кумулятивной вероятностью 96,6 % и возьмем обязательства по завершению проекта за 12 спринтов;

• при малых штрафных санкциях и большем вознаграждении можно использовать более мягкие кумулятивные вероятности завершения: 93,4 % за 11 спринтов и 87,2 % – за 10 спринтов;

• при отсутствии штрафных санкций (например, для внутренних проектов) можно поставить в качестве срока завершения 9 спринтов с кумулятивной вероятностью 75,9 %.

Данная диаграмма сгорания дополнительно показывает дифференциальную и кумулятивную вероятность даты релиза

Подчеркну, что у самого вероятного исхода (завершение за 8 спринтов) кумулятивная вероятность составляет всего 57,3 %.

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

Scrum в заказной разработке

 

Нулевой спринт

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

Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т. д. Словом, он заменяет целый пакет документов, который принято использовать в тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.

Следующим этапом идет выявление персон и их активностей (вплоть до отдельных историй пользователя), которые фактически являются легковесным и более визуальным вариантом экторов и пользовательских сценариев. Уже традиционно данную активность Scrum-команды реализуют в виде построения карт историй (Story Mapping), результатом которого становятся доски и целые стены с визуализацией активностей в проекте.

Построение карт историй на практике

Обязательно нужно вытащить представителей заказчика на процессы по выработке видения и построение карт историй (а на последнее собрание – еще и потенциальных пользователей).

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

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

Можно взять ICONIX в качестве подмножества UML и процесса, но он будет скорее замещать построение карт историй, чем дополнять его.

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

«Вредные» клиенты

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

Давайте подумаем, как дифференцировать заказчиков по «вредности» и как (и стоит ли) работать с «вредными». Сначала определимся, кого считать «вредным» клиентом. Обычно в отношении заказчиков используется термин «лояльность». В самом простом случае клиентов можно разделить на три группы: нелояльные, средние и лояльные.

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

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

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

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

Следует хорошо подумать, нужен ли вам этот клиент, ведь с ним не получится работать на 100 % по Agile. Здесь подход должен быть комплексным: во внимание нужно принять как стоимость и сроки проекта, так и возможные риски.

Инженерные практики представляют собой проверенные временем решения, связанные непосредственно с реализацией требований заказчика. Большинство практик, которые мы рассмотрим ниже, взяты из экстремального программирования, но дополнены инспекциями кода и разработкой с тестами.

Непрерывная интеграция

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

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

Разработка через тестирование и разработка с тестами

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

Экстремальное программирование идет дальше и превращает проверку качества в инструмент для создания спецификации и архитектуры. Для этого этап написания тестов переносится в начало цикла разработки.

Цикл разработки в рамках TDD

Такой подход называется разработкой через тестирование или разработкой через тесты (Test Driven Development). Процесс работы разбивается на три этапа:

• красный – пишем неработающий тест;

• зеленый – минимальными усилиями заставляем тест работать;

• рефакторинг – устраняем дублирования и приводим код в порядок.

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

Схема для выбора кода

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

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

• Алгоритмы – это код, реализующий разного рода алгоритмы и бизнес-логику. Он достаточно независим от других частей, и тестировать его необходимо максимально тщательно.

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

• Сложный код – достаточно запутанный код, но для него нужны тесты. Как правило, его можно отрефакторить и сосредоточить в итоге свои усилия на алгоритмах.

В рамках TDD используется следующая практика из экстремального программирования – рефакторинг.

Рефакторинг

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

Структура процесса рефакторинга

Парное программирование

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

Роли разработчиков при работе в паре

Формальные инспекции кода

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

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

Простота архитектуры и метафора системы

Мы работаем итеративно, поэтому важно иметь максимально простую архитектуру, в которую быстро и дешево вносятся изменения.

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

Коллективное владение кодом и стандарт кодирования

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

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

Сорокачасовая рабочая неделя

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

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

Плюсы и минусы гибкого анализа требований

Роль системного аналитика

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

Функции владельца продукта

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

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

UML

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

• UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность;

• UML-диаграммы быстро теряют актуальность при начале разработки;

• UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга;

• UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста;

• UML неявно подразумевает водопадную модель разработки.

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

Процесс ICONIX

Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX.

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

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

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

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

ICONIX – подмножество UML

Структура процесса ICONIX

Диаграмма вариантов использования

Здесь отображаются роли пользователей (персоны из карт историй) и варианты применения, которые фактически являются более тяжеловесным вариантом историй пользователей. Обратите внимание на стереотипы «Эпик» и «Тема», которыми обозначены два варианта использования.

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

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

Диаграмма предметной области

Диаграмма классов

Для примера разберем один из вариантов использования и опишем его более подробно в виде диаграммы робастности, на которой будут отражены:

• граничные объекты – интерфейс взаимодействия с пользователями;

• котроллеры – бизнес-логика и различные алгоритмы;

• сущности – данные приложения.

Можно заметить, что данная диаграмма очень похожа на шаблон проектирования Model-View-Controller.

Диаграмма робастности

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

Диаграмма робастности нужна, чтобы:

• осуществить проверку полноты вариантов использования;

• выявить дополнительные объекты;

• проработать архитектуру на высоком уровне.

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

Пропасть между анализом и архитектурой

После такого анализа можно описать подробности алгоритма или логики в диаграмме последовательности.

Диаграмма последовательности

Стратегия актуализации документации

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

Фактически аналитик должен выбрать одну из трех стратегий актуализации требований.

Стратегии обновления требований

Несмотря на то что Аgile-процессы ставят готовый продукт выше документации, роль документации не исключается как таковая. Принятые решения, ограничения системы, описание бизнес-процессов должны быть зафиксированы и доступны любому участнику команды.

Если документация не обновляется полностью, с какого-то момента начинают накапливаться различия между моделью (требованиями) и кодом.

Рост количества различий между моделью и кодом

Роль аналитика в Scrum

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

Место аналитики в Scrum

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

Преимущества и недостатки

Роль аналитика в канбане

Плюсы и минусы работы в Scrum в канбане меняются местами: здесь аналитик работает наравне со всеми членами команды в потоке задач. Обычно ему выделяют дополнительный столбец на доске.

Столбец «Аналитика» для соответствующего состояния

Аналитик также попадает под третье правило канбана по оптимизации процесса с целью сокращения времени жизни задачи. По этой причине и из-за отсутствия спринтов время жизни при введении дополнительного этапа для аналитики в канбане так сильно не растягивается.

Прототипы

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

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

Различные варианты прототипов

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

Прототип для веб-страницы

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

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

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

Организационные структуры

Организационная структура (оргструктура) – это способ упорядочить сотрудников организации для достижения ее целей. Прежде всего, оргструктура создается и поддерживается для:

• координации деятельности работников;

• обозначения границ ответственности.

Хочу отметить, что оргструктура зависит от многих факторов и описанный здесь вариант можно (и нужно) адаптировать в соответствии с окружением и бизнес-процессами организации. Очевидно также, что оргструктура – это не монолит, который остается на весь жизненный цикл компании: она меняется с течением времени и развитием организации.

Виды оргструктур. Кратко рассмотрим, какие организационные структуры существуют и какие мы можем использовать для масштабирования Scrum.

 Дивизионная оргструктура объединяет в дивизионы полный коллектив для разработки связанного семейства продуктов или организации работ по географическому признаку.

 Функциональная оргструктура объединяет в функциональные единицы (обычно отделы) сотрудников одной специальности.

 Командная (проектная) оргструктура объединяет в небольшую группу работников разных специальностей для реализации проекта.

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

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

Scrum-команда: состав

Команда в Scrum состоит из небольшого количества людей – от пяти до девяти человек, чтобы можно было осуществлять эффективные коммуникации. Один из членов команды становится скрам-мастером (SM), ответственным за процессы и социальный климат в команде.

Владелец продукта (PO) не является членом команды в прямом смысле этого слова, но ставит команде цели с помощью требований в журнале пожеланий (BL).

Состав Scrum-команды

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

Масштабирование Scrum

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

Привлечение нескольких команд

Для организации разработки больших проектов или портфеля проектов необходимо масштабировать Scrum на следующий уровень. Со стороны команд разработки это выливается в проведение Scrum of Scrum.

На этот митинг собираются скрам-мастера (SM) в качестве представителей конкретных команд. Организует собрание руководитель программы (Program Manager, PM). При использовании дивизионной организационной структуры на данном уровне он также может являться руководителем соответствующего дивизиона (подразделения).

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

1. Что было сделано с прошлого Scrum of Scrum?

2. Какие были проблемы?

3. Что будет сделано к следующему Scrum of Scrum?

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

Scrum of Scrum of Scrum

 

Следующим уровнем масштабирования является Scrum of Scrum of Scrum. Для осуществления этого проводится соответствующее мероприятие, на которое собираются менеджеры программ и топ-менеджер (обычно технический директор подразделения).

Обсуждение на данном уровне ведется в масштабе спринтов и релизов. Из проблем обсуждаются только самые крупные.

Scrum of Scrum of Scrum

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

 

Управление продуктами

Для масштабирования деятельности продуктовых команд владельцы продуктов (Product Owner, PO) проводят Meta Scrum под руководством главного владельца продукта (Chief Product Owner).

Meta Scrum

Обсуждение требований происходит на уровне журналов пожеланий (BL) спринтов, а не отдельных историй пользователей. Соответственно определяются и высокоуровневые приоритеты.

На данном уровне можно рассмотреть также журнал пожеланий программы (Program Backlog, PBL). Он может быть как реальным, так и виртуальным (также возможны сочетания обоих подходов). Реальный журнал пожеланий программы получается при реализации большого проекта несколькими командами, а виртуальный – при выполнении множества независимых проектов.

Meta Scrum, рассмотрение журнала пожеланий программы

 

Scrum на уровне предприятия

Если объединить продуктовую и производственную схему масштабирования, то получится полноценная схема масштабирования Scrum на уровне предприятия.

Актуализация журналов пожеланий

Распределенный Scrum

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

Распределенный Scrum

Интеграция контроля и обеспечения качества в Scrum

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

• регрессионное тестирование функционала с предыдущих спринтов;

• приемочное тестирование спринтов и релизов.

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

Это же касается тестирования функционала очередного спринта, иначе вы рискуете попасть в «регрессионную спираль смерти», но его можно разбавить и ручным тестированием.

Структура спринта для тестировщиков

В рамках спринта у тестировщиков есть пять основных активностей:

• планирование итерации;

• автоматизация приемочного тестирования;

• тестирование историй пользователей;

• регрессионное тестирование;

• демонстрация.

Активности тестировщиков

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

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

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

Сколько необходимо тестировщиков

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

23 августа 2010 года на сайте habrahabr.ru среди 1835 человек, из которых 551 воздержался, был проведен опрос по соотношению количества разработчиков и тестировщиков. Следует отметить, что на сайте достаточно много представителей небольших компаний/веб-студий и фрилансеров, но общая картина все равно ясна.

Количество тестировщиков определяется многими факторами:

• количеством разработчиков;

• наличием автоматических приемочных тестов;

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

• общим качеством продукта.

Результаты опроса

На диаграмме видно, что в большинстве случаев тестировщиков в той или иной мере не хватает, поэтому их работу необходимо максимально автоматизировать, чтобы на выполнение тестов уходило минимум ручного труда.

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

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

Ценность – основа бережливого производства

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

Виды потерь

Классически выделяются семь видов потерь:

• перепроизводство;

• ожидание;

• ненужная транспортировка;

• лишние этапы обработки;

• лишние запасы;

• ненужные перемещения;

• дефекты.

В самой популярной книге о производственной системе Toyota «Дао Toyota» авторы обозначили восьмой вид потерь: нереализованный творческий потенциал сотрудников.

Традиционно выделяют также еще два вида потерь:

• му́ри (перегрузка);

• му́ра (неравномерность).

Инструменты бережливого производства. Бережливое производство ПО

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

Уменьшение потерь. Видов потерь в разработке программного обеспечения достаточно много: от переключения между задачами до реализации лишнего функционала. Помните правило 20/80: 20 % функционала продукта приносят 80 % ценности заказчику, и именно гибкие методологии позволяют эти 20 % функционала выявить и назначить им максимальную важность.

Фокусировка на обучении. Весь процесс создания программного обеспечения фактически состоит из обучения: с каждой новой функцией мы узнаем что-то новое, поэтому, как и для любой другой инженерной деятельности, следует сосредотачиваться на обучении.

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

 Позднее принятие решений. Очень важно принимать решения как можно позже. Самым ярким примером здесь является создание архитектуры приложения. В противоположность подходу Big Up Front Design мы создаем архитектуру только для текущего функционала, следуя принципам KISS и YAGNI.

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

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

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

Производственная система «Тойоты» (Toyota Production System, TPS)

Ниже приведены 14 принципов TPS.

1. Философия долгосрочной перспективы: можно пойти на убытки для достижения отдаленной цели.

2. Производственный поток должен быть непрерывным.

3. Канбан: производство по системе «точно вовремя» без промежуточных запасов.

4. Хейдзунка: равномерное распределение нагрузки на всех этапах технологического процесса.

5. Андон и дзидока: автоматическая остановка производства с целью решения проблем.

6. Формализация накопленных знаний: достигнутое нужно делать новым стандартом.

7. Визуальный контроль: иногда простая лампочка эффективнее компьютерного монитора.

8. Внедрять только проверенные технологии.

9. Воспитывать собственных лидеров, искренне исповедующих философию компании.

10. Формировать и воспитывать рабочие команды, в которых каждый искренне исповедует философию компании.

11. Уважать и развивать партнеров-поставщиков.

12. Генти гаубицу: перед тем как начать разбираться в ситуации, увидеть все своими глазами.

13. Немаваси: принимать коллективные решения только после согласия большинства, но внедрять немедленно.

14. Хансей и кайзен: любой процесс можно постоянно анализировать и совершенствовать.

Кайзен

Японское слово «кайзен» состоит из двух иероглифов, которые можно перевести как «изменения, направленные на улучшения».

Кайзен

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

 Фокус на клиентах – мы должны быть сфокусированы на клиентах, причем не только на словах, но и на деле.

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

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

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

 Управление проектами с помощью межфункциональных команд – команды в Scrum максимально многофункциональны и включают в себя всех необходимых специалистов для реализации проекта.

 Формирование поддерживающих взаимоотношений – для организации таких взаимоотношений необходимо уделять внимание социальной атмосфере в коллективе.

 Развитие самодисциплины – команды в Scrum самоуправляемы и могут определять, как они будут достигать целей, поставленных владельцем продукта.

 Информирование каждого сотрудника – информация (в том числе коммерческая) должна быть максимально прозрачна для каждого сотрудника.

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

Инструменты кайзена

 

Карта потока создания ценности

Карта потока создания ценности (Value Stream Mapping) – инструмент, который отображает стадии производственного процесса и время между ними. Затем производится подсчет эффективности процесса, как частное от полезного времени, когда добавлялась ценность продукту, и общего времени работы процесса.

Пример карты потока создания стоимости

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

 

Пять «почему»

Самый простой инструмент, который может применяться даже в устной форме. Его суть состоит в поиске коренных причин проблем (например, дефектов) и принятии многоуровневых контрмер. Для этого по отношению к проблеме задается пять раз вопрос «Почему?», чтобы проникнуть в ее суть (табл. 11.1).

Таблица 11.1.

Пять «почему»

 

Диаграммы Исикавы

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

• методология;

• требования;

• разработка;

• контроль качества.

Пример нотации для анализа причинно-следственной связи

Пример диаграммы Исикавы

 

Контрольные карты

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

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

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

Контрольные карты бывают разных видов, например классические контрольные карты Шухарта ((Госстандарт России, 1999) и (Уилер и др., 2009)). Различия касаются формул и значений для выбора среднего значения и контрольных пределов. В контрольных картах Шухарта для определения предела используется не стандартное отклонение, а размах. Существует также набор правил для трактовки контрольных карт, например правила Western Electric и правила Нельсона.

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

Контрольная карта по дефектам

Контрольная карта по дефектам в разрезе проектов

 

Диаграмма Парето

Этот инструмент позволяет выявить модули, которые содержат определенный процент дефектов. Обычно получается соотношение, близкое к 20/80: 20 % модулей содержат 80 % дефектов.

Именно на эти модули стоит обратить внимание:

• покрыть их дополнительно тестами;

• провести дополнительные инспекции кода.

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

Диаграмма Парето

Модули, в которые часто вносятся изменения, экономически выгодно сделать более гибкими:

• сделать более гибкую и настраиваемую архитектуру;

• активно использовать шаблоны проектирования для дополнительной гибкости.

Итоги

Водопадная модель разработки ПО

Начнем с основ и для этого возьмем машину времени и переместимся в 1970 год: доктор Уинстон Ройс пишет свою статью «Управление разработкой больших программных систем» (Managing the development of large software systems), которая и положила начало водопадной модели разработки ПО. Самое интересное, что он в своей статье описывает эту модель как антипаттерн.

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

1. Подробная проработка архитектуры программы до начала разработки (включая предварительную архитектуру).

2. Максимально подробная документация на каждом этапе.

3. Симуляция всего проекта в уменьшенном виде (фактически прототипирование).

4. Планирование, контроль и мониторинг тестирования.

5. Вовлечение заказчика.

Водопадная модель разработки ПО

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

Авторы Agile-манифеста

В феврале 2001 года в местечке под названием Сноуберд в штате Юта собрались 17 специалистов (консультантов и практиков), чтобы обсудить легковесные методики разработки. В результате родился документ «Манифест гибких методологий разработки» (Agile Manifesto). Позволю себе привести список авторов манифеста и краткую информацию о них.

Кент Бек – создатель разработки через тестирование и экстремального программирования. Автор нескольких книг на эти темы и соавтор JUnit.

Майк Бидл – основатель и генеральный директор e-Architects Inc., консалтинговой компании, которая специализируется на разработке распределенного ПО. Он также является соавтором книги Scrum, Agile Software Development, написанной совместно с Кеном Швабером.

Усовершенствованная водопадная модель разработки ПО

Эйри ван Беннекум – участвовал в разработке методологии DSDM с 1997 года. До этого активно работал над быстрой разработкой (Rapid Application Development).

Алистер Кокберн – известен исследованиями проектных команд и участием в разработке семейства методологий Crystal.

Уорд Каннингем – основатель Cunningham & Cunningham, Inc. Он также широко известен своим огромным вкладом в развитие объектно-ориентированного программирования, экстремального программирования и в концепцию вики.

Джеймс Греннинг – тренер и консультант по гибким методологиям. Является специалистом в области разработки и тестирования встроенного программного обеспечения и автором книги Test Driven Development for Embedded C.

Стивен Меллор – специалист в области разработки программного обеспечения, соавтор метода ООАП Шлаера-Меллора, работал над UML в составе Object Management Group.

Мартин Фаулер – главный исследователь в компании Thoughtworks. Автор многих работ и книг по паттернам анализа, UML, рефакторингу и экстремальному программированию.

Джим Хайсмит – ведущий разработчик методологии Adaptive Software Development и автор соответствующей книги.

Эндрю Хант – соавтор книги Pragmatic Programmer: From Journeyman to Master и других работ, связанных с разработкой ПО.

Рон Джеффрис – владелец сайта XProgramming.com, консультант в компании Object Mentor и соавтор книги Extreme Programming Installed.

Джон Керн – участвовал во многих проектах по исследованиям и разработке в области авиастроения. Он также является евангелистом объектно-ориентированного программирования с начала 90-х годов.

Брайан Мэрик – программист и консультант по тестированию программного обеспечения. Основной вклад Брайана заключается в исследовании процессов тестирования ПО в гибких методологиях разработки.

Роберт Мартин – работает в отрасли разработки ПО с 1970 года. Он является президентом и основателем фирмы Object Mentor Inc., которая специализируется на консалтинге в области экстремального программирования, гибких методологиях разработки, консалтинге по архитектуре ПО и т. д. Он также является соавтором книг по программированию и разработке программного обеспечения.

Кен Швабер – президент компании Advanced Development Methods (ADM), которая занимается улучшением методов разработки ПО. Он является опытным разработчиком, менеджером продуктов и консультантом. В начале 90-х годов он работал с Джеффом Сазерлендом над первыми версиями Scrum. Он также является соавтором книги Scrum, Agile Software Development.

Джефф Сазерленд – технический директор (CTO) компании PatientKeeper, которая занимается созданием ПО для медицинских учреждений. За свою карьеру был техническим директором (или вице-президентом по технологиям) в девяти компаниях. Известность приобрел как изобретатель методологии Scrum.

Дейв Томас – верит, что сердце проекта по разработке – не методология, а люди. По этой причине он является соавтором книги The Pragmatic Programmer.

Crystal Clear

Crystal Clear – это легковесная гибкая методология, созданная Алистером Кокберном. Она предназначена для небольших команд из 6–8 человек для разработки некритических бизнес-приложений. Как и все гибкие методологии, Crystal Clear больше опирается на людей, чем на процессы и артефакты.

Crystal Clear использует семь методов/практик, три из которых являются обязательными.

1. Частая поставка продукта.

2. Улучшения через рефлексию.

3. Личные коммуникации.

4. Чувство безопасности.

5. Фокусировка.

6. Простой доступ к экспертам.

7. Качественное техническое окружение.

Как видите, все практики характерны для семейства Agile-методологий. В графическом виде практики Crystal Clear можно изобразить таким образом.

Методы и практики Crystal Clear

Dynamic Systems Development Method (DSDM)

Методология DSDM (Dynamic Systems Development Method – метод разработки динамических систем) основана на подходе RAD (Rapid Application Development – быстрая разработка приложений) и включает в себя три стадии.

1. Предпроектная стадия, на которой авторизуется реализация проекта, определяются финансовые параметры и команда.

2. Жизненный цикл проекта представляет собой реализации проекта и включает в себя пять этапов.

3. Постпроектная стадия обеспечивает качественную эксплуатацию системы.

Общая схема DSDM

Жизненный цикл проекта включает в себя пять стадий (первые две фактически объединяются).

1. Определение реализуемости.

2. Экономическое обоснование.

3. Создание функциональной модели.

4. Проектирование и разработка.

5. Реализация.

Agile Unified Process

Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданная Скоттом Амблером (Scott Ambler) и состоящая из семи методов.

1. Моделирование используется для понимания бизнес-требования и предметной области.

2. Реализация – преобразование модели в исполняемый код с модульными тестами.

3. Тестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиям.

4. Размещение – доставка готовой системы пользователям.

5. Управление конфигурациями – управление доступом и версиями артефактов проекта.

6. Управление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, финансами и т. д.

7. Среда – совокупность процессов, инструментов, стандартов и правил.

Feature-driven development

Feature-driven development (функционально-ориентированная разработка) – методология, созданная Джеффом Де Люка (Jeff De Luca). Разработка ведется в пять этапов.

1. Построение модели.

2. Создание списка функций.

3. Планирование реализации функций.

4. Создание архитектуры для функций.

5. Реализация функций.

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

ICONIX

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

• диаграмма вариантов использования;

• диаграмма классов;

• диаграмма робастности;

• диаграмма последовательности.

Об использовании методологии ICONIX см. разд. «Процесс ICONIX» гл. 8.

Как внедрить Agile за четырнадцать недель

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

Основная цель составления данного плана по внедрению Agile – дать четкую и краткую инструкцию по трансформации компании/подразделения в гибкую и эффектную бизнес-единицу по производству программного обеспечения.

План рассчитан на небольшие компании размером 20–50 человек и нуждается в адаптации под конкретную организацию. Для компаний (или отдельных команд) меньшего размера можно использовать этот же план за исключением масштабирования методологий.

Будем считать, что в компании по исторически сложившимся обстоятельствам применяется «методология» Code&Fix. В качестве допущений будем использовать следующие положения:

• длина спринта – две недели;

• длина релиза фиксирована – три итерации;

• внедрение Agile поддерживается руководством.

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

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

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

• Реальный практический опыт работы по теме тренинга. Самым важным параметром при выборе компании и тренера является наличие практического опыта работы по теме тренинга. Дело в том, что тренеры-теоретики просто не способны понять многие вещи в силу отсутствия соответствующего опыта даже при наличии всех необходимых сертификатов.

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

Принципы внедрения

 

Цикл Деминга (PDCA-цикл)

При организационных изменениях очень помогает использование здравого смысла и научного подхода. Традиционным методом в данном случае является цикл Деминга, который состоит из четырех шагов.

• Plan (планирование). Производится анализ системы, вырабатываются возможные подходы к улучшениям, и определяются желаемые результаты.

• Do (исполнение). Решения, выработанные на предыдущем шаге, реализуются.

• Check (проверка). Производится анализ результатов, полученных на предыдущем шаге.

• Act (корректировка). Выполняются корректирующие действия для уменьшения отклонений от плана.

Цикл Деминга

График и содержание внедрения

План состоит из трех частей.

1. Подготовка компании к трансформации – сбор и анализ информации, получение знаний и навыков сотрудниками компании.

2. Первый релиз – знакомство с основными элементами Scrum и Lean.

3. Второй релиз – адаптация Agile к бизнесу компании.

Неделя № 1 (подготовка к трансформации)

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

1. Изучение и описание текущих бизнес-процессов компании: составление карты бизнес-процессов, касающихся разработки ПО/сайтов (в графическом или текстовом виде).

2. Изучение проектов и организация их в портфель проектов:

• составление списка проектов;

• разработка методологии приоритизации, принятие решений о запуске/завершении проектов;

• приоритизация и балансировка портфеля проектов.

3. Буткемп по основам Scrum (однодневный тренинг по основам скрама с деловыми играми): каждый участник тренинга должен понимать роли, процессы и артефакты Scrum.

4. Продвинутое обучение скрам-мастеров (четырехчасовой тренинг): скрам-мастера должны получить дополнительные знания и навыки по процессам Scrum, навыки фасилитации и организации работы команд.

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

Неделя № 2 (нулевой спринт)

Цели: выработать понимание продукта и создать высокоуровневую архитектуру.

1. Исследование продукта:

• выявление ролей и персонажей по проектам;

• построение карт историй;

• прототипирование основных интерфейсов;

• сессия для выявления основных рисков и выработки контрмер.

2. Создание высокоуровневой архитектуры продукта:

• выбор платформы реализации;

• диаграмма предметной области/высокоуровневая диаграмма классов.

Неделя № 3 (старт первого «калибровочного» спринта)

Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum.

1. Старт первого спринта с командами:

• проведение планирования спринта и разбиение user story на задачи;

• проведение покер-планирования для оценки user story.

2. Scrum of Scrum:

• определение сроков проведения Scrum of Scrum;

• проведение первого Scrum of Scrum;

• отработка механизма эскалации проблем;

• отработка механизма синхронизации деятельности команд.

Неделя № 4 (завершение первого «калибровочного» спринта)

Цели: отработать завершение спринта и провести ретроспективу на основе качественных показателей.

1. Проведение демонстрации и получение обратной связи.

2. Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений): определение скорости команды эмпирическим путем.

Неделя № 5 (старт второго спринта)

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

1. Планирование и старт второго спринта: планируем, исходя из скорости предыдущего спринта.

2. Тренинг и мастер-класс по практикам экстремального программирования:

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

• выработка и внедрение стандартов кодирования.

Неделя № 6 (завершение второго спринта)

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

1. Изучение практики инструментов бережливого производства (Lean):

• виды потерь при производстве;

• Value Stream Mapping для текущего процесса;

• пять «почему».

2. Демонстрация.

3. Ретроспектива с применением инструментов бережливого производства:

• разбор причин опоздания по невыполненным задачам;

• пять «почему» по каждому дефекту.

Неделя № 7 (старт третьего спринта)

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

1. Планирование и старт третьего спринта:

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

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

2. Внедрение модульных и приемочных тестов:

• проведение тренинга по приемочным тестам;

• покрытие 5 % основного бизнес-функционала продукта приемочными тестами;

• проведение тренинга по модульным тестам;

• покрытие 50 % кода, реализованного за спринт, модульными тестами.

3. Внедрение рефакторинга.

Неделя № 8 (завершение третьего спринта)

Цели: сделать первый Agile-релиз продукта и выработать серьезные меры по улучшению процессов на основе информации, полученной за три спринта.

1. Кайзен-сессия на ретроспективе: диаграмма Исикавы по глобальным проблемам проекта и выработка мер по устранению проблем.

2. Завершение третьего спринта: первый релиз продукта – обязательно, чтобы конечные пользователи его попробовали и предоставили обратную связь.

3. Post-mortem релиза в рамках ретроспективы.

Неделя № 9 (старт четвертого спринта)

Цели: научиться планировать релиз и управлять им.

1. Планирование релиза:

• начало ведения диаграммы burndown-релиза;

• отбор владельцем продукта пользовательских историй для релиза;

• возможная переоценка журнала пожеланий командой «на пальцах».

2. Внедрение (трех-) четырехзвенной архитектуры.

3. Планирование и старт четвертого спринта: скорость команды считаем эмпирически по трем предыдущим спринтам.

Неделя № 10 (завершение четвертого спринта)

Цель: внедрение статистического управления качеством.

1. Завершение четвертого спринта.

2. Внедрение основ статистического управления качеством:

• статистика по дефектам;

• диаграмма Парето по модулям;

• контрольные карты Шухарта.

Неделя № 11 (старт пятого спринта)

Цель: внедрение канбана для команды поддержки или основной команды.

1. Планирование и старт пятого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.

2. Переход на Scrumban команды поддержки или основной команды:

• тренинг по канбан (четыре часа) для членов команды;

• отказ от жестких итераций.

3. Внедрение разработки через тестирование:

• тренинг и мастер-класс по разработке через тестирование;

• покрытие тестами модулей ядра системы (не менее 50 % строк кода).

Неделя № 12 (завершение пятого спринта)

Цель: улучшение внутреннего качества ядра системы.

1. Частичный рефакторинг модулей ядра системы: определение стратегии рефакторинга и выбор модулей.

2. Завершение пятого спринта.

Неделя № 13 (старт «идеального» шестого спринта)

Цель: запуск «идеального» спринта.

1. Планирование и старт шестого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.

Неделя № 14 (завершение «идеального» шестого спринта)

Цель: завершение «идеального» спринта.

1. Завершение шестого спринта.

2. Релиз продукта.

3. Post-mortem релиза в рамках ретроспективы: анализ релиз-берндауна.