Текст книги "Гибкое управление проектами и продуктами"

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

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

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

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

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

• http://www.facebook.com/borisvolfson;

• http://twitter.com/borisvolfson;

• [email protected].

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

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

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

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

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

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

Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты [email protected] (издательство «Питер», компьютерная редакция).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинальные принципы Agile на английском языке вы можете найти на странице http://agilemanifesto.org/principles.html.

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 («Исчерпывающее руководство по Скраму: Правила игры»), можно найти на странице http://www.scrum.org/Scrum-Guides, включая перевод на русский язык.

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

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

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

Элементы Scrum

Роли

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

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

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

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

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

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

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

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

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

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

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

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

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

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