«Гибкое управление проектами и продуктами»

Гибкое управление проектами и продуктами (fb2) - Гибкое управление проектами и продуктами 3857K скачать: (fb2) - (epub) - (mobi) - Борис Львович Вольфсон

Борис Вольфсон Гибкое управление проектами и продуктами

Предисловие ко второй версии

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

• 12 338 раз с Dropbox (посчитано через Google);

• 7553 раза c «Яндекс. Народ».

Распределение скачиваний по странам, по данным Google

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

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

• обновлено описание Scrum на основе последней версии Scrum Guide от июля 2013 года;

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

Предисловие к первой версии

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

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

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

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

• разработчиков, ведущих разработчиков и архитекторов;

• скрам-мастеров и руководителей проектов;

• владельцев и менеджеров продуктов;

• руководителей отделов;

• аналитиков;

• тестировщиков;

• верстальщиков;

• дизайнеров и специалистов по интерфейсу.

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

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

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

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

Об авторе

У меня есть обширный и разнообразный опыт в области разработки программного обеспечения и веб-разработки, чем я, собственно, и занимаюсь на постоянной основе с 2003 года. За это время я успел поработать на разных должностях, начиная с верстальщика и разработчика и заканчивая руководителем крупного подразделения разработки с коллективом более 100 человек в компании Softline. Сейчас я работаю в компании HeadHunter техническим директором лучшего рекрутингового сайта в Интернете, который помогает находить свое предназначение миллионам людей.

С гибкими методологиями (Agile software development, Аgile-методы) я познакомился в середине 2000-х годов, а Scrum практикую с 2009-го. Мое видение гибких методологий (и Scrum в частности) прошло путь от набора лучших практик до философии производства программного обеспечения.

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

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

• ;

• ;

• borisvolfson@gmail.com.

Благодарности

Спасибо всем, кто помогал мне в работе над данными материалами, в том числе по плану внедрения Agile. Полужирным шрифтом выделены авторы наиболее обширных и ценных комментариев, предложений и замечаний: Тимофей Евграшин; Максим Гармаш; Егор Ковязин; Илья Козлов; Ксения Колосова; Евгений Кривошеев; Наталья Лукьянчикова; Дмитрий Паньшин; Михаил Подоплелов; Михаил Подурец; Сергей Рогачев; Андрей Свердлов; Евгений Сорокин; Ирина Сурикова; Анна Тарасенко; Асхат Уразбаев; Лия Шабакаева.

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

Благодарности компаниям и организациям

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

Хочу выразить огромную благодарность компаниям HeadHunter и Softline, в которых мне довелось работать и, надеюсь, сделать разработку в них гибкой и эффективной. Большое спасибо также компании ScrumTrek и лично Асхату Уразбаеву и Никите Филиппову за бесценные знания и идеи!

Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты vinitski@minsk.piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

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

Глава 1. Гибкие методологии

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

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

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

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

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

В более строгом варианте эти тезисы были сформулированы отцами-основателями гибких методологий в документе, который получил название 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, см. соответствующий раздел).

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

Глава 2. Scrum – гибкий управленческий фреймворк

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

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

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

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

Хенрик Книберг. Scrum и XP: Заметки с передовой

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

Элементы Scrum

Роли

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

Владелец продукта (Product Оwner, менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и управление его журналом пожеланий.

Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы, координацию работы и поддержание социальной атмосферы в команде.

Команда разработки (Development Team) – это многофункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта.

Владелец продукта

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

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

• приоритизацию элементов журнала пожеланий;

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

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

Команда разработки

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

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

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

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

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

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

Процессы

Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях. Все встречи жестко ограничены по времени (time-boxed).

Спринт

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

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

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

Планирование спринта

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

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

Скрам-митинг

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

1. Что было сделано с предыдущего скрам-митинга?

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

3. Что будет сделано к следующему скрам-митингу?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты

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

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

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

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

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

Владельцу продукта 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 – «Вам это не понадобится»).

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

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

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

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

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

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

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

I can’t get no satisfaction, I can’t get no satisfaction. ‘Cause I try, and I try, and I try, and I try. I can’t get no, I can’t get no. The Rolling Stones

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

Рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано (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.

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

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

Achievable – достижимые цели

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

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

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

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

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

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

Relevant – релевантные цели

Релевантность целей нужно рассматривать с двух сторон: релевантность для исполнителя и для компании. Релевантность (значимость) для исполнителя тесно связана с его мотивацией. Например, сотруднику, который любит изучать новые технологии, можно и нужно поручить исследовательский проект, а не рутинную работу. Когда команда понимает, что цель важна, усилия, которые она направит на ее достижение, будут заведомо больше усилий, направленных на «неважную» цель. Отмечу также, что букву R (и другие буквы аббревиатуры SMART) расшифровывают по-разному.

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

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

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

Таблица 3.7.

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

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

SMART

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

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

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

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

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

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

FC = StoryPoints × StoryPointCost + SupportCost

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

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

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

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

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

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

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

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

Глава 4. Управление командой

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

Антуан де Сент-Экзюпери

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

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

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

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

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

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

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

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

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

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

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

2. Бурление.

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

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

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

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

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

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

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

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

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

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

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

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

Х. Такеучи и И. Нонака. Разработка нового продукта. Новые правила игры

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

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

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

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

Таблица 4.1.

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

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

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

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

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

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

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

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

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

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

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

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

Команды уровня 1

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

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

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

Команды уровня 2

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

Эти команды могут стать гибкими, но им требуется сильный тренер или скрам-мастер, который научит их вырабатывать свои решения и полагаться на них. Конечно, часть решений команды будут ошибочными. В этом нет ничего страшного, ведь именно на ошибках учатся. Особое внимание нужно уделить ретроспективам как основному методу выработки улучшений в Scrum.

Команды уровня 3

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

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

Команды уровня 4

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

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

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

Посмотрим, какие лучшие практики и инструменты рекомендуется использовать команде и скрам-мастеру для наиболее эффективного создания продукта. Эти практики отлично интегрируются в 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

Теория X

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

Что делать руководителю

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

Теория Y

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

Что делать руководителю

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

X + Y

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

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

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

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

Э. Гольдратт

Самые важные вещи нельзя измерить.

У. Деминг

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

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

Не навреди

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

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

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

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

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

Что делать

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

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

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

Глава 5. Управление контрактами

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

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

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

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

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

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

Необходимо отметить, что недоверие преодолеть очень непросто.

Оценка сроков методом PERT

Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.

Метод заключается в получении трех оценок:

• оптимистичной (Мин);

• вероятной (Сред);

• пессимистичной (Макс).

Вычислить наиболее вероятную дату завершения можно по формуле:

(Мин + 4 × Сред + Макс) / 6.

Отклонение высчитывается по формуле:

(Макс – Мин) / 6.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как продать Scrum заказчику

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

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

• каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО;

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

Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте. Наилучшим вариантом здесь будет заключение контракта типа «время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но следует отметить, что при таком подходе и риски перекладываются на него. Еще скажу, что при таком варианте резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.

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

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

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

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

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

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

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

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

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

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

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

Практики Scrum, или Как посадить заказчика на итеративную иглу

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

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

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

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

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

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

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

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

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

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

Глава 6. Управление рисками

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

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

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

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

Цикл управления рисками

Для стимуляции мозгового штурма крайне рекомендую использовать один из следующих риск-воркшопов:

• SEI Taxonomy-Based Risk Identification – таксономия рисков и опросник от Software Engineering Institute;

• дисциплина управления рисками MSF вер 1.1 – более легковесная версия категоризации софтверных рисков от Microsoft.

Риски надо визуализировать, чтобы их знала вся команда (и заказчик) и полноценно участвовала в управлении ими. Худший вариант – создать Excel-файл с рисками (в самом укромном уголке) и при провале проекта сказать: «Этот риск у меня есть в реестре под номером 37». Самый гибкий вариант – сделать доску с рисками и отслеживать их жизненный цикл.

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

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

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

Таблица 6.1.

Оценка вероятности и рисков

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

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

Что касается Lessons Learned, для этого идеально подходит ретроспектива. Только замечу, что эти уроки и лучшие практики также необходимо распространять между командами, например на Scrum of Scrum.

Глава 7. Инженерные практики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лия Шабакаева, разработчик

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

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

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

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

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

Рефакторинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 8. Анализ требований

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 прототипы рекомендуется делать к конкретным историям пользователей в сочетании с текстовым описанием и диаграммами.

Глава 9. Масштабирование Agile

Классическая 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

Глава 10. Контроль и обеспечение качества

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 11. Бережливое производство

Бережливое производство пришло к нам из США. Фактически бережливое производство – это осмысление производственной системы 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.

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

Диаграммы причинно-следственной связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

Глава 12. Agile-методологии

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

Начнем с основ и для этого возьмем машину времени и переместимся в 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 (корректировка). Выполняются корректирующие действия для уменьшения отклонений от плана.

Цикл Деминга

ShuHaRi

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

• Shu (защита, подчинение) – изучение традиционной мудрости – изучение методологии, работа строго по книжкам, руководствуясь предписаниями тренера/внедренца;

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

• Ri (покидание, отделение) – превосходство над традицией – осознанное отступление от методологии, например переход со Scrum на Scrumban.

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

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

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

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 релиза в рамках ретроспективы: анализ релиз-берндауна.

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

• A Practical Guide to Feature-Driven Development [Текст] / Stephen Palmer, John Felsing.

• A Practical Guide to Seven Agile Methodologies, Part 2 [Электронный ресурс] / Rod Coffin, Derek Lane. – .

• Advanced Topics in Agile Planning [Электронный ресурс] / Cohn Mike. – -Topics-Agile-Planning-Cohn-NDC2010.pdf?1276713148.

• Agile Development with the ICONIX Process: People, Process and Pragmatism [Текст] / Rosenberg Doug, Stephens Matt и Collins-Cop Mark. – 2005.

• Agile Metrics [Текст] / Алименков Николай.

• Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process [Текст] / Ambler Scott W. – 2002.

• Agile Project Management with Scrum [Текст] / Schwaber Ken.

• Agile Retrospectives: Making Good Teams Great [Текст] / Esther Derby, Diana Larsen.

• Agile Software Development with Scrum (Series in Agile Software Development) [Текст] / Ken Schwaber, Mike Beedle. – 2001.

• Cause-effect diagrams [Текст] / Книберг Хенрик. – 2009.

• Crystal Clear – Alistair Cockburn (2005) [Электронный ресурс] / Björkholm Tomas. – .

• Crystal Clear: A Human-Powered Methodology for Small Teams [Текст] / Cockburn Alistair. – 2004.

• DSDM: Business Focused Development [Текст] / DSDM Consortium.

• Kano Model – How to delight your customers [Электронный ресурс] / Phillips Lawrence (Laurie). – -model-rev-1.

• Leading a Self-Organizing Team [Электронный ресурс] / Cohn Mike. – 2011. – -leading-a-selforganizing-team.

• Prioritizing Your Product Backlog [Электронный ресурс] / Cohn Mike. – -Product-Backlog-Cohn-ADP2010.pdf.

• QA in Agile [Электронный ресурс] / Алименков Николай. – 2008. – -in-agile.

• Retrospectives [Электронный ресурс] / Дмитриев Сергей. – 2011. – -agiledays-2011.

• Scaling Agile to Work with Distributed Teams [Электронный ресурс] / Cohn Mike. – -Distributed-Agile-Cohn-NDC2010.pdf.

• Scrum и Kanban: выжимаем максимум [Текст] / Книберг Хенрик и Скарин Матиас.

• Scrum и XP: заметки с передовой [Текст] / Книберг Хенрик.

• Scrum. Гибкая разработка ПО [Текст] / Кон Майк. – 2011.

• Small Hyper-Productive Teams [Электронный ресурс] / Алименков Николай. – 2011. – -hyper-productive-teams-it-brunch-10150627.

• Test Driven Development for Embedded C [Текст] / Grenning James.

• The Enterprise and Scrum [Текст] / Schwaber Ken.

• The Pragmatic Programmer: From Journeyman to Master [Текст] / Andrew Hunt, David Thomas. – 1999.

• Use Case Driven Object Modeling with UML: Theory and Practice [Текст] / Rosenberg Doug, Stephens Matt. – 2007.

• User Stories [Электронный ресурс] / Cohn Mike. – -Stories-Cohn-NDC2010.pdf?1276712524.

• User Stories Applied: For Agile Software Development [Текст] / Cohn Mike.

• Vision Crafting [Электронный ресурс] / Филиппов Никита и Лобасев Дмитрий. – 2011. – /2-bmg.

• Бережливое производство программного обеспечения. От идеи до прибыли [Текст] / Мэри Поппендик, Toм Поппендик. – 2010.

• Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании [Текст] / Джеймс Вумек, Дэниел Джонс.

• Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения [Текст] / Том Де Марко, Тимоти Листер.

• Выход из кризиса. Новая парадигма управления людьми, системами и процессами [Текст] / Деминг Эдвардс.

• Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд [Текст] / Лайза Криспин, Джанет Грегори.

• ГОСТ Р 50779.42–99 (ИСО 8258-91) [Текст] / Госстандарт России. – М.: [б. н.], 1999.

• Кано-взвешивание [Электронный ресурс] / Дмитриев Сергей. – -7654382.

• Машина, которая изменила мир [Текст] / Вумек Джеймс и Джонс Даниел. – М.: Попурри, 2007.

• Подвижная мишень и дрожащие руки [Электронный ресурс] / Дорофеев Максим. – 2010. – -moving-target.

• Построение бизнес-моделей. Настольная книга стратега и новатора [Текст] / Александр Остервальдер, Ив Пинье.

• Практика дао Toyota. Руководство по внедрению принципов менеджмента Toyota [Текст] / Майер Жеффри и Лайкер Дэвид.

• Практическое руководство по экстремальному программированию [Текст] / Дэвид Астелс, Гранвилл Миллер, Мирослав Новак.

• Рефакторинг баз данных. Эволюционное проектирование [Текст] / Скот В. Эмблер, Прамодкумар Дж. Садаладж. – [б. м.]: Вильямс.

• Рефакторинг с использованием шаблонов [Текст] / Кериевски Джошуа. – [б. м.]: Вильямс.

• Рефакторинг. Улучшение существующего кода [Текст] / Фаулер Мартин. – 2009.

• Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта [Текст] / Уилер Дональд и Дэвид Чемберс. – М.: Альпина Бизнес Букс, 2009.

• Цель. Процесс непрерывного совершенствования [Текст] / Элияху М. Голдрат, Джефф Кокс.

• Цель-2. Дело не в везении [Текст] / Голдратт Элияху.

• Человеческий фактор. Успешные проекты и команды [Текст] / Листер Том и Демарко Тимоти.

• Экстремальное программирование [Текст] / Бек Кент.

• Экстремальное программирование: планирование [Текст] / Кент Бек Мартин Фаулер.

• Экстремальное программирование: постановка процесса. С первых шагов и до победного конца [Текст] / Кент Ауэр, Рой Миллер.

• Экстремальное программирование: разработка через тестирование [Текст] / Бек Кент.

• Эффективная работа с унаследованным кодом [Текст] / Физерс Майкл К. – [б. м.]: Вильямс, 2009.

Оглавление

Предисловие ко второй версии

Предисловие к первой версии

Об авторе

Благодарности

Благодарности компаниям и организациям

Глава 1. Гибкие методологии

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

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

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

  Канбан

Глава 2. Scrum – гибкий управленческий фреймворк

  Роли

    Владелец продукта

    Команда разработки

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

  Процессы

    Спринт

    Планирование спринта

    Скрам-митинг

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

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

  Артефакты

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

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

  Персоны

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

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

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

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

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

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

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

    Achievable – достижимые цели

    Relevant – релевантные цели

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

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

Глава 4. Управление командой

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

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

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

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

    Команды уровня 1

    Команды уровня 2

    Команды уровня 3

    Команды уровня 4

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

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

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

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

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

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

  Доска задач

  Теории X и Y

    Теория X

    Что делать руководителю

    Теория Y

    Что делать руководителю

    X + Y

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

    Не навреди

    Что делать

Глава 5. Управление контрактами

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

    Оценка сроков методом PERT

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

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

    Как продать Scrum заказчику

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

    Практики Scrum, или Как посадить заказчика на итеративную иглу

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

Глава 6. Управление рисками

Глава 7. Инженерные практики

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

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

  Рефакторинг

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

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

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

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

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

Глава 8. Анализ требований

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

  UML

  Процесс ICONIX

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

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

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

  Прототипы

Глава 9. Масштабирование Agile

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

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

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

  Scrum of Scrum of Scrum

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

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

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

Глава 10. Контроль и обеспечение качества

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

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

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

Глава 11. Бережливое производство

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

  Виды потерь

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

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

  Кайзен

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

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

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

    Диаграммы причинно-следственной связи

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

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

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

Глава 12. Agile-методологии

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

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

  Crystal Clear

  Dynamic Systems Development Method (DSDM)

  Agile Unified Process

  Feature-driven development

  ICONIX

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

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

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

    ShuHaRi

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

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

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

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

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

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

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

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

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

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

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

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

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

  Неделя № 13 (старт «идеального» шестого спринта)

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

Список литературы Fueled by Johannes Gensfleisch zur Laden zum Gutenberg