Блистательный Agile. Гибкое Управление

Блистательный
Agile. Гибкое управление

проектами с помощью Agile, Scrum и Kanban
Эдвард Скотчер
Роб Коул
2018-02-15T00:00:00+00:00
Annotation
Что такое гибкое управление проектами?

Нужно ли оно вашему проекту?
Будет ли от этого выгода?
Хотите разобраться, как работает гибкое управление проектами и воспользоваться этим мощным подходом?
Тогда вы выбрали правильную книгу.
«Блистательный Agile» – это не очередной рассказ о методах и процессах, основное внимание уделено реальным
примерам использования Agile в бизнес-средах.
Здесь вы найдете практические советы и конкретные техники внедрения Agile, позволяющие сделать ваш проект
успешным и реализовать гибкое управление в организации.
Блистайте с Agile!
Роб Коул, Эдвард Скотчер
Об авторах
От издательства
Предисловие научного редактора
Глава 1. Новый мир, бросающий вызов: представляем Agile
Введение
Основы Agile
Манифест Agile
Положение дел
Заказчик должен быть доволен
Нет, спасибо, без изменений
Начните с малого, недорогого и быстрого
Agile-мышление
Становясь гибким
Гибкие итоги
Многообразие выбора
Другие варианты
Слишком хорошо, чтобы быть правдой
Завершающие слова
Глава 2. Agile совсем другой!
Введение
Тьма перед рассветом
Основы Agile
Анализ по-другому
Начало реализации проекта
Приветствуя перемены
Жизнь становится легче
Испытание для руководителя проекта
Не панацея
Глава 3. Начало: готовимся быть гибкими
Введение
Определение видения
Руководствуясь идеей бизнес-ценности
Формирование команды проекта
Создание журнала требований
Получение информации
Менеджмент рисков и ожиданий
Ведение журнала требований
Создание рабочей среды
Глава 4. Использование Канбана
Введение
Основы Канбана
К доске!
Определение «сделанного»
Больше чем просто доска
Дешевые и высокотехнологичные альтернативы
Создание журнала требований работ
Перетасовка колоды
Контроль работ в процессе (WiP)
Управление проектами с Канбаном
Глава 5. Просто лучшее: основы Скрама
Введение
Фреймворк
Самоорганизующиеся команды
Владелец продукта
Скрам-мастер
Команда разработки
Ключевые Скрам-события
Спринт
Планирование спринта
Ежедневная летучка
Обзор итогов
Ретроспектива
Артефакты Скрама
Глава 6. Пора в путь: Скрам день за днем
Введение
Подготовка
Доработка журнала
Критерии принятия
Приоритезация в действии
Оценивание в действии
Начало спринта
Достойная реализация механик
Избегайте личностных конфликтов
Выработка хороших практик
Рабочий процесс
Приближаясь к концу
Конец спринта
Глава 7. Agile в организации
Введение
Причины перехода на Agile
Влияние на влиятельных
Agile в массы!
Не только для IT
Оценка успешности
Двоякая польза отчетов
Избегайте повторения ошибок
Глава 8. Вспомогательные механизмы
Введение
С чего начать
Вспомогательные организации и другие сообщества
Конференции
Налаживание контактов
Будь готов
Формальная подготовка
Коучинг и менторинг
Подкасты и вебинары
Глава 9. Призыв к действию
Введение
Предоставление гибкости
Назад к истокам
Постоянное совершенствование
Не переставайте учиться
Будущее Agile
Не забывайте об азах
notes
1
2
3
4
5
6
7
Роб Коул, Эдвард Скотчер

Блистательный Agile. Гибкое управление
проектами с помощью Agile, Scrum и Kanban
Rob Cole
Edward Scotcher
Brilliant Agile Project Management. A practical guide to using Agile, Scrum and Kanban
© Lexray Limited and Agility in Mind Limited, 2015

© Перевод на русский язык ООО Издательство «Питер», 2019
© Издание на русском языке, оформление ООО Издательство «Питер», 2019
© Серия «IT для бизнеса», 2019
© Перевод с англ. Сидорова М. А., 2019
* * *
Посвящается Альфи и Сисси, Элле и Элис, Нкейру, Лизе, Амаре и Джо
Об авторах
Роб Коул (Rob Cole) – консультант по управлению проектами с более чем 20-летним опытом. Он
специализируется на устранении проблем в проектах и наставничестве. Роб был вовлечен в Agile-сообщество с
самых первых дней и является практикующим Скрам-мастером.
С Робом можно связаться по адресу: [email protected]
Эдвард Скотчер (Edward Scotcher) – ведущий менеджер по продуктам, менеджер проектов, тренер и коуч Agile.
Он специализируется на оказании помощи организациям, командам и отдельным лицам в адаптации Agile для
практического и долговременного применения.
C Эдом можно связаться по адресу: [email protected]
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер»,
компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Предисловие научного редактора

Когда мне предложили прорецензировать эту книжку, я очень обрадовался, поскольку всегда рад любой
возможности поддержать развитие Agile за пределами IT-применения. И именно это делает данная книга.
Она:
• про тот самый Agile, о котором все говорят;
• нужна тем, кто не знает про Agile ничего и очень хочет с этими подходами познакомиться;
• написана абсолютными приверженцами гибких подходов;
• написана в стиле Agile (авторы используют очень интересные образы, примеры и иллюстрации, которые редко
встречаются в академической литературе);
• подходит для универсального чтения и применения;
• не содержит того языка и терминологии, которые пугают нас в технической IT-литературе, и легко читается.
Вы получите ответы на ряд вопросов:
• Что такое гибкое управление проектами и принесет ли это пользу вам?
• Как извлечь выгоду из использования Agile?
• Какие методы и процессы исполняют в Agile?
• Подходит ли ваша организация или проект для использования Agile?
• Как решаются наиболее распространенные проблемы, связанные с Agile?
• И как, в конце концов, его реализовать в любом проекте?
Искренне рекомендую книгу «Блистательный Agile» для чтения и применения. Жалко, что такой книжки не было
у меня в руках лет пять назад, когда я все это начинал применять в своей деятельности…
Удачи вам, дорогие читатели, в гибких проектах вместе с Робом Коулом и Эдвардом Скотчером!
Фунтов Валерий Николаевич д.э.н., PMP, Agile-коуч и тренер
Глава 1. Новый мир, бросающий вызов:

представляем Agile
Введение
Agile, или гибкое проектное управление, сейчас привлекает к себе заслуженное и обоснованное внимание. Не
имеет значения, идет ли речь о коммерческих предприятиях, исследовательских задачах или любых других
проектах, – важно то, что все эти проекты требуют соответствующих методов разработки, и в большинстве
случаев эти методы были неправильными. Сейчас на поле появляется так называемый новый игрок, обещающий
все изменить, – и это ничуть не преувеличение. Многие полагают, что видели уже все возможные методы
управления проектами, – но времена меняются, и революция в этой сфере происходит прямо сейчас.
Скорее всего, вы уже слышали о мире Agile. Не было никакой многомиллионной рекламной кампании, но, тем не
менее, этот термин у всех на слуху. Может даже показаться, что все уже используют гибкую методологию
разработки или вот-вот перейдут на нее, но на самом деле есть много людей и компаний, все еще обдумывающих
применение Agile для своей работы.
«Блистательный Agile» предлагает видение этого бросающего вызов нового мира для того, чтобы вы могли
определить, подходит или нет это конкретно для ваших задач. Эта книга – не многостраничный том, и так
сделано намеренно. Будучи истинным эталоном гибкости, книга содержит именно тот минимум, который
необходим вам для достижения максимального эффекта.
Не все то золото, что блестит. Не все, кто блуждает, – потерялись.
Джон Р. Р. Толкин
Основы Agile
Несмотря на рост интереса к Agile и беспрецедентный уровень применения этих подходов в последнее время,
успех к ним пришел далеко не сразу. Идея Agile зародилась более двадцати лет назад на фоне постоянного
разочарования от неудачных проектов. И все же история того, как появлялась идея гибкости, может
интересовать нас только с академической точки зрения. Главное в том, что Agile совершила своего рода
революцию.
В нашем мире, где ничто не ново под солнцем, Agile-решения стали как раз чем-то совершенно новым.
На первый взгляд различий не так уж и много. Все те же проекты со своими целями, бюджетом, графиками и
многочисленными проблемами, неизбежно возникающими в процессе разработки. Однако, если копнуть глубже,
различия становятся очевидны. Конечная цель всегда одна и та же, но вот способов ее достижения – огромное
количество. Более того, если использовать наиболее предпочтительный способ достижения цели, то вероятность
того, что вы прибудете к вашей цели с довольной улыбкой на лице, куда выше.
Конечно, успешные проекты реализовывались и до появления Agile. Некоторые были еще и завершены вовремя и
с внушительными прибылями (но лучше не упоминайте об этом в кругу некоторых приверженцев Agile). Однако
несмотря на это, слишком многие проекты выходили за рамки установленных сроков или бюджета, а то и вообще
не достигали поставленных бизнес-целей. Agile делает вероятность положительного результата намного выше.
И все же это не значит, что в проектах, использующих Agile, все всегда идет как надо. Стопроцентную гарантию
успеха вам может обеспечить только джинн из лампы. Но с гибкими подходами можно забыть про проекты,
требующие неоправданных вложений времени и сил, и о случаях, когда единственный вариант – это вложить в
дело еще деньги, чтобы не потерять в итоге намного больше. Отказ от привычных принципов организации
проектов с Agile будет легким – и у вас останется время, чтобы развиваться дальше.
Блистательный пример
В рамках реализации программы по внедрению электронных услуг большая правительственная организация
приступила к дорогостоящей разработке технической инфраструктуры. Уже для первой версии приложения,
бюджет которого составлял несколько миллионов, было решено инвестировать еще больше средств в новое
оборудование. Так и было сделано несмотря на то, что первый результат был просто электронной версией формы,
на заполнение которой требовалось всего несколько минут.
Настал день введения проекта в эксплуатацию, и огромные затраты на разработку были забыты – менеджеры
открыли шампанское, поздравили друг друга и отправились искать ближайший бар, чтобы отпраздновать успех.
Однако несмотря на масштабное празднование, пользователи не использовали новую форму – это было тем, что
разработчики сознательно упустили из виду.
Современное оборудование. Высокотехнологичная альтернатива заполнению бумажной формы. Никто не
пользуется помощью новой системы. Поставляемая бизнес-ценность не достигнута. Зато изящество нового
решения и успешность запуска нового сервиса уже была отпразднована. И всем было безразлично,
действительно ли новая система используется.
Манифест Agile
Agile как движение зародился на основе концепции «бережливого производства», используемой в автомобильной
промышленности. Первоначально гибкие подходы были созданы для сферы информационных технологий (IT), в
которой проекты, на поддержку которых были потрачены миллионы, а в итоге они не принесли прибыли, не
являются чем-то необычным. Ключевым годом, когда были сформулированы основные идеи Agile, можно считать
2001 год.
В феврале 2001 года семнадцать независимых практикующих специалистов встретились на горнолыжном
курорте Сноуберд в штате Юта, чтобы обсудить принципы разработки программного обеспечения. Результатом
этой встречи стала публикация Манифеста Agile для разработки программного обеспечения. Разумеется,
участники далеко не во всем были согласны друг с другом, но сумели прийти к консенсусу относительно самых
главных принципов. До сих пор именно этот Манифест является основой всего Agile-движения.

Манифест Agile для разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения,
занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли
осознать следующее.
Люди и взаимодействие важнее процессов и инструментов.
Работающее программное обеспечение важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление.
Если вы не работаете в IT-индустрии, первый звоночек для вас зазвенел еще при упоминании программного
обеспечения. Один из постоянно задаваемых вопросов – работает ли Agile только для программного обеспечения
или же подходы можно применять более широко. Конечно, манифест Agile писался для улучшения процесса
разработки программ, но его принципы универсальны – достаточно в тексте манифеста просто заменить
«работающее программное обеспечение» на «работающие продукты».
Манифест дополняется также основополагающими принципами. Опять же, не обращайте внимания на
«софтверную» направленность текста; главное – выделить ключевые понятия.
Основополагающие принципы Манифеста Agile

Мы следуем таким принципам:
• Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и
ранней поставке ценного программного обеспечения.
• Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют
использовать изменения для обеспечения заказчику конкурентного преимущества.
• Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
• На протяжении всего проекта разработчики и бизнес-представители должны ежедневно работать вместе.
• Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и полностью доверьтесь им.
• Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как
с самой командой, так и внутри нее.
• Работающее программное обеспечение – основной показатель прогресса.
• Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм
бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
• Простота – искусство минимизации лишней работы – крайне необходима.
• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
• Команда должна систематически анализировать возможные способы улучшения эффективности и
соответственно корректировать стиль своей работы.
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление.
И наконец, приложение к манифесту – еще несколько важных утверждений, формирующих так называемую
Декларацию взаимозависимости. Это менее известное и реже упоминаемое дополнение, но с точки зрения
менеджера проекта оно суммирует основные принципы гибких подходов.
Декларация взаимозависимости
Гибкий и адаптивный подход заключается в связанности людей и проектов и их стоимости.
Мы – сообщество руководителей успешных проектов. Для достижения наших целей
• Мы увеличиваем отдачу от инвестиций за счет постоянного внимания нуждам проекта.
• Мы обеспечиваем надежные результаты, вовлекая заказчика в частые взаимодействия и совместную
работу над проектом.
• Мы ожидаем неопределенности и справляемся с ней с помощью прогнозирования и адаптации.
• Мы приветствуем креативность и инновационный подход, признавая, что основная ценность проекта –
это люди.
• Мы повышаем производительность за счет распределения обязанностей между группами и групповой
подотчетности.
• Мы повышаем эффективность и надежность посредством ситуационного применения конкретных
стратегий и практик.
©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna
Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith
and Robert Wysocki.

Главной причиной того, что Agile вызвал такой резонанс в мире бизнеса, было то, что он завоевывал сердца
очень быстро. В основном рекламой Agile служило сарафанное радио, а ключевые принципы были простыми,
четкими и очень привлекательными:
• Мы увеличиваем отдачу от инвестиций.
• Мы обеспечиваем надежные результаты.
• Мы ожидаем неопределенности.
• Мы приветствуем креативность и инновационный подход.
• Мы повышаем производительность.
• Мы повышаем эффективность и надежность.
Положение дел
Перечисленные принципы – замечательные, но какие же основные проблемы существуют сейчас в среде
управления проектами? Что именно Agile пытается исправить?
При завершении многих проектов часто оказывается, что разработка длилась дольше, чем ожидалось, затраты
оказались выше, чем изначально закладывалось в бюджет, и часто достигались не те результаты, о которых шла
речь вначале. В результате доверие к различным методам управления сильно уменьшилось. Традиционные
методы управления проектами опираются на так называемый «треугольник управления проектами»,
включающий взаимозависимые время, затраты и содержание. Но в этом треугольнике пропало столько проектов,
что его впору назвать Бермудским.
Рис. 1.1. Треугольник управления проектами
Так как треугольник представляет собой жесткую структуру, невозможно изменить одну из сторон, не влияя на
остальные. Если меняется любой из параметров – сроки, затраты или содержание, это обязательно повлечет за
собой последствия для разработки проекта. Зачастую это происходит, когда необходимо добавить новые
требования в задачу проекта – тогда резко замедляется скорость разработки или урезается бюджет. Само собой,
иначе и быть не может! Уже много лет команды, работающие над проектами, пытаются сохранять эти три
переменные в равновесии, но миссия явно невыполнима.
С самого начала работы над любым проектом заказчик пристально следит за тем, чтобы не было потрачено
слишком много средств или времени. Руководители проекта, таким образом, находятся сразу под двойным
прицелом. Стоит, наконец, выпустить окончательный продукт, фокус сразу смещается со «сколько» и «как долго»
на «а достаточно ли это хорошо?». Конечно, если заказчик получил, что хотел, задержка с выпуском продукта и
дополнительные затраты сразу забываются, но пробираться через эту полосу препятствий действительно тяжело.
В мире Agile все обстоит совершенно по-другому. С самого начала фокус направлен на создание качественного
продукта. Agile отодвигает в сторону традиционное беспокойство о бюджете или сроках и сосредоточивается в
первую очередь на том, что заказчик хочет или, что куда важнее, что ему действительно необходимо. Превращая
простые идеи в сложные, но элегантные решения, можно перестать беспокоиться о достижении совершенства.
Больше никаких дополнительных трат и никаких недовольных заказчиков.
Блистательная мысль
Заказчикам не нужно лучшее управление проектом, заказчику нужен лучший продукт. Все инструменты и
техники направлены именно на это. Используйте любые техники для достижения лучшего результата, главное –
не сосредоточивайтесь на самих техниках. Цель куда важнее, чем средства, которыми вы ее достигнете.
Заказчик должен быть доволен

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

Прежде подразумевалось, что после того, как все точки над i расставлены и все утверждено, изменения не
приветствуются – ну или, по крайней мере, тщательно контролируются. Многие популярные подходы к
управлению проектами, такие как PRINCE2 (PRojects IN Controlled Environments – проекты в контролируемых
средах), фокусируются в рамках четко определенных требований и строго регламентируют контроль изменений.
Изменение не одобряется и считается плохой новостью для бизнеса.
Тем не менее попытки работать по этой схеме не всегда успешны, потому что желание что-то поменять
наверняка будет возникать в любом проекте. Само собой, если изменений немного, традиционные
структурированные методы управления тоже работают достаточно плодотворно, но и тогда не обходится без
споров. К сожалению, в итоге всегда есть риск получить заказчика, не до конца довольного продуктом.
К тому же далеко не в каждом проекте процесс разработки представляет собой прямую от точки A до точки В,
где все требования совершенно четкие, а любые вносимые изменения – не больше чем слабое отклонение от
заданного курса. В большинстве случаев любая идея, как неоперившийся птенчик, нуждается в проверке в
реальных ситуациях и наверняка будет требовать различных дополнительных надстроек. Иногда приходится
менять курс или вообще возвращаться к началу разработки. Это естественный ход развития для бизнес-проектов,
и попытки двигаться против течения здесь точно не приведут ни к чему хорошему.
Agile совсем другой. Agile приветствует изменения и даже вдохновляет на них. Тут любые перемены – не ваш
враг, а неотъемлемая часть развития хорошей идеи. Проекты, выполненные с помощью гибких подходов, могут
быть представлены на рынке в короткие сроки, а значит, на тестирование будет больше времени. Эволюция – это
совершенно естественно, а изменения – не такая уж и проблема. Это именно то, чего хотят ваши заказчики, и
ничего удивительного, что для них это как глоток свежего воздуха.
Начните с малого, недорогого и быстрого

Тезисы Agile-манифеста, принципы и прочие элементы гибкой философии звучат отлично, но как именно
применять их на практике? Чем конкретно отличается Agile? Основное – это то, что с самого начала разработки
продукта подход совершенно другой. Вместо того чтобы составить список требований и ограничивать внесение
любых изменений, Agile начинает с определения необходимого минимума и работает уже с ним. Этот минимум
так и называется – минимально жизнеспособный продукт (minimum viable product, MVP), или минимальный набор
функциональности (minimum feature set, MFS).
На практике оба этих определения обозначают одно и то же. Минимально жизнеспособный продукт уже
отвечает основным требованиям бизнес-проекта и может быть успешно продан. Такой подход уменьшает затраты
и время, необходимые на разработку. Минимально жизнеспособный продукт также может стать основанием для
более сложного и функционального бизнес-решения. Чем меньше – тем лучше.
К первому рабочему дню на новом месте после окончания школы, колледжа или университета, несомненно,
нужно подготовиться заранее. Особенно если место работы – фирма со строгими правилами и дресс-кодом.
Если рассматривать подготовку как проект с традиционным методом подхода, получится список вещей, которые
необходимо купить, и это явно обойдется недешево:
• 3 костюма (чтобы их можно было менять);
• 10 рубашек (чтобы не стирать их каждую неделю);
• 5 галстуков (на выбор);
• 2 пары обуви (одна черная, другая коричневая);
• 1 пальто (зима всего-то через полгода);
• 10 комплектов нижнего белья;
• автомобиль, чтобы добраться до станции в восьми километрах от дома;
• велосипед в случае, если автомобиль сломается (и, конечно же, дождевик к нему).
Приобретение всего этого займет несколько уик-эндов – покупка костюма быстрой не будет. Таким образом,
понадобится три-четыре похода по магазинам; к тому же стоит выбирать вещи, которые можно будет вернуть.
Бюджет можно заложить около десяти тысяч фунтов.
Чтобы предусмотреть все обстоятельства, закупки желательно начать делать за два месяца до первого рабочего
дня. Проблема только в том, что вы должны выйти на работу в следующий понедельник. Поэтому составляем
более продуманный Agile-план: один костюм, две рубашки (постирать и погладить в течение первой недели), два
галстука, упаковка с носками и нижним бельем. Чтобы добраться до станции, используем общественный
транспорт или такси.
Начните с того, чего вам хватит для первого дня. В конце концов, уже даже самые консервативно настроенные
фирмы не так строго следят за дресс-кодом. Извините, что рассмотрели только набор одежды для мужчин, но его
с легкостью можно заменить на тот, что нравится вам.
Честно говоря, в реальных проектах постоянно возникают такие же преувеличения, причем с самого начала. В
приведенном выше примере более прагматичный и гибкий подход поможет спланировать гардероб в
дальнейшем, добавляя разные элементы по мере надобности. Внезапное похолодание повысит в приоритете
покупку нового пальто, а машина и велосипед могут быть признаны ненужными тратами. И вообще, как знать –
быть может, через несколько месяцев самым важным окажется приобретение путевки для отпуска?
Определение минимально жизнеспособного продукта, MVP, или минимального набора функциональности, MFS, –
стратегия для получения конкурентоспособного продукта и тестирования его возможностей. Эта идея может
быть применена практически к любой ситуации (и даже к выходу на новую работу). В примере выше минимально
жизнеспособный продукт – хорошо выглядящий специалист к первому дню на новом рабочем месте, и ничего
больше! Прочая одежда – не более чем приятное дополнение. Со временем будет понятно, приносит ли проект
прибыль, – и тогда, на основе этих сведений, можно уже решать, добавлять ли другие элементы. Если нет – будет
легко сменить направление разработки.
Agile прекрасно справляется с задачей определения правильного направления уже на ранней стадии работы над
проектом. Вычленение самого важного из списка требований предотвращает ненужные траты и помогает в
дальнейшем не упустить возможности.
Agile-мышление
Обобщения – это неблагодарное занятие, но есть некоторые ментальные особенности, которые подходят для
гибкого стиля жизни. Все Agile-подходы (фреймворки) ориентированы на командную работу на месте,
кооперацию и адаптацию; они хорошо подойдут тем, кто быстро сходится с людьми и легок на подъем, и они вряд
ли понравятся одиночкам и авторитарным особам.
В некоторых организационных культурах просто не получится принять или адаптировать Agile-мышление. Это не
критика, а просто жизненный факт. В конечном счете все зависит от людей, от их восприятия – для кого-то
предпочтительнее может оказаться такая методология, как PRINCE2. Просто они будут плавать в других лодках.
Любой может попробовать адаптировать среду Agile, но в некоторых сферах она раскрывается в полной мере.
Значительно помогают такие персональные особенности, как
• стремление к сотрудничеству;
• сосредоточенность;
• целеустремленность;
• открытость;
• взаимоуважение;
• смелость;
• честность.
Их мы ожидаем увидеть у любого из наших коллег или у кого угодно, если на то пошло. Сочетание всех этих
особенностей означает, что, скорее всего, работая по Agile, вы будете чувствовать себя как рыба в воде. Не стоит
волноваться, если кажется, что чему-то из списка вы не соответствуете, – Agile создает условия для развития
нужных качеств.
И (конечно, снова обобщая) большая часть приверженцев Agile очень увлеченные натуры. Некоторые могут
слишком буквально подходить к трактовкам, впадая в догматизм, но, опять же, это из-за чрезмерного
энтузиазма. Это не религиозная секта. На форумах, посвященных обсуждению Agile, новичка могут встретить не
слишком тепло – но это не значит, что тамошние обитатели недружелюбны, хотя они и могут быть очень
шумными.
Становясь гибким
Сложно сказать, с чего нужно начинать внедрение Agile в той или иной организации. Случается, что решение
принимает «Самый Главный Начальник» и, полный энтузиазма, с чековой книжкой наготове и с уже нанятым
Agile-коучем, возглавляет поход в землю обетованную, готовый претворять идеи в жизнь. Прекрасно, когда такое
случается, но происходит это довольно редко.
Обычно, когда компания устает от провальных проектов, один или несколько человек решают, что должен быть и
другой путь. Затем предпринимается пробный запуск Agile-проекта – с минимумом вовлеченных специалистов и
малым или вообще отсутствующим бюджетом, и этого зачастую оказывается достаточно, что позволяет нам
говорить о минимуме требований для организации Agile. И тут мы подходим к определению ключевых факторов
успеха, о которых следует поговорить особо.
Блистательное определение
Ключевые факторы успеха (КФУ) – те факторы, которые необходимы для достижения успеха. Их наличие
гарантирует правильный результат работы.
КФУ для Agile-проекта обычно включают:

• Соответствующий проект. Не беритесь за критически важный и самый приоритетный для вашей компании
«Проект № 1», который отстает от расписания даже в самом начале; начните с чего-то малого для того, чтобы
понять и доказать, как работают гибкие процессы, и исправлять любые перегибы.
• Подходящие люди. Не только для работы над проектом, но и для того, чтобы наблюдать за тем, как будет
происходить трансформация к Agile. Выбирать стоит коллег с гибким мировоззрением и готовых приложить
дополнительные усилия, чтобы испытать, как работает Agile. Это будет большой командный рывок, и для этого
потребуются командные усилия.
• Реалистичные ожидания. Будьте реалистами – результат можно ожидать незамедлительно, но для
действительно долгоиграющих достижений понадобится время. Иногда, чтобы идти по верному пути, нужно
сделать шаг назад прежде, чем сможете сделать два вперед. Устанавливайте планку на разумной высоте.
• Адекватное обучение. Чтобы начать применять Agile, достаточно ознакомиться с материалами в интернете,
но не стоит сбрасывать специализированное обучение со счетов. Agile-коучи помогут разобраться в необходимых
деталях. Если бюджет позволяет, начните с одного обучающего дня в неделю, а если нет – даже один такой день
в две недели лучше, чем ничего.
Проникнувшись философией Agile, попробуйте начать применять эти подходы и получить минимально
жизнеспособный продукт. Обращайте внимание на КФУ, выбирайте проект мудро и окружите себя правильными
людьми. Никто не гарантирует успеха, но склонить чашу весов в вашу пользу будет легко.
Для самоуверенной молодежи очень заманчивой выглядит перспектива приобрести автомобиль и сэкономить на
уроках вождения. Не составляет проблемы найти приятелей, которые уже сдали на права и могут дать советы.
Если уделять должное время тренировкам, возможно, удастся научиться водить, но такая экономия является
ложной. Привычные методы обучения будут более результативны.
Отказ от подготовки и обучения – ложная экономия. Неприятные последствия могут настигнуть в любой момент.
Гибкие итоги
Если генеральный директор на собрании совета директоров несколькими емкими фразами намерен обрисовать
достижения – что именно он будет говорить? Каких именно результатов могут ожидать руководство, акционеры и
ваши коллеги? Зачем начинать это все?
Грамотно реализованные Agile-подходы позволят получить следующие результаты.
• Раннее получение минимально жизнеспособного продукта или минимального набора
функциональности. Что-то, с чем можно выйти на рынок и быстро проверить работоспособность проекта.
Больше не нужно долго ждать.
• Продукт, отвечающий требованиям заказчика. Продукт будет делать именно то, что заказчик хотел.
Больше никакого «будем надеяться, все сработает как надо».
• Малые начальные инвестиции. Начните с приемлемого бюджета – в случае успеха продукта бюджет можно
увеличить. Это означает уменьшение рисков.
• Гибкость при любых обстоятельствах. Возможность приспосабливаться и адаптироваться к изменяющимся
обстоятельствам без кризисов и поисков, кто виноват.
• Повышение продуктивности команды. Довольные и мотивированные сотрудники – это повышенная
производительность.
Самое главное, что речь не идет об искусственном занижении планки. Уже в первый день вы получите
доказательства того, что работа будет сделана. Будьте благоразумны, конечно, но всего вышеперечисленного
можно ожидать незамедлительно.
Воспользуйтесь началом нового проекта как поводом для того, чтобы информировать коллег. Пусть
непосредственно занятые в разработке люди знают, чего ожидать и что именно будет по-другому, – в
особенности если это первый Agile-проект. Пара часов объяснений основ Agile улучшат понимание и будут
способствовать принятию нововведений. Этот образовательный пиар послужит только во благо проекту.
Многообразие выбора
Общее представление об Agile очень привлекательно, но когда дело доходит до запуска конкретной программы
или проекта, нужно выбирать что-то конкретное. Вариантов довольно много, но мы остановимся на трех наших
самых любимых.
1. Lean, бережливое управление

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

1. Оптимизируйте целостное видение.
2. Исключите потери.
3. Обеспечьте качество.
4. Постоянно учитесь.
5. Предельно быстро осуществляйте поставку заказчику.
6. Вовлекайте команду.
7. Постоянно совершенствуйтесь.
2. Скрам
Нынешний любимчик для применяющих Agile – не в последнюю очередь потому, что этот Agile-подход изменил
многие бизнес-процессы и способы работы, эдакий «агент бархатной революции» и наш выбор.
Подходит для проектов всех типов и размеров.
3. Канбан
Несмотря на нашу почти абсолютную поддержку Скрама, и Канбану нашлось место в этой книге – ему
однозначно есть что предложить в определенных ситуациях. Это отличная альтернатива Скраму, которую очень
легко применять. Иногда что-то излишне упрощается, но это тоже черта Канбана.
Канбан прекрасно работает в случае необходимости организации прозрачной на всех этапах разработки для
любых сред.
Другие варианты
Есть и другие подходы Agile – особенно в области информационных технологий. Не удивляйтесь, если где-то
услышите о разнообразных вариациях в Agile – на уровне фреймворков можно встретить такие методы, как
Скрамбан, SAFe (Scaled Agile Framework, масштабированный гибкий фреймворк) и другие. Они все очень
интересны, но сначала мы советуем ограничиться проверенными техниками.
Где не стоит применять Agile:

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

Положительные отзывы об Agile и, в частности, о Скраме – палка о двух концах. Положительной чертой тут
является то, что людей легко убедить попробовать Agile. Отрицательной – то, что ожидания зачастую завышены.
Менеджерам очень нравятся эти постулаты – быстрее, дешевле, лучше, – и они зачастую забывают, что
бесплатный сыр бывает только в мышеловке. При верном подходе ожидания становятся вполне реалистичными –
нет ничего плохого в поощрении энтузиазма, главное – не переусердствуйте.
Будьте готовы к тому, что кто-то обязательно станет высказывать сомнения. Подвешенное состояние –
неизменный спутник любых значительных нововведений вместе с критикой и неприятием перемен. Пусть ваши
успехи говорят за вас.
Я проработала половину своей жизни, чтобы добиться успеха, и все равно он застал меня врасплох.
Джессика Савитч (американская телеведущая)
Новые проекты жизненно важны для развития любой организации, но сейчас новые проекты слишком часто
терпят неудачу. Иногда это позволяет нам потрепать друг друга по плечу и сказать, что такова жизнь. В других
случаях неудача приводит к потере денег и других ресурсов, что, в свою очередь, приводит к утрате бизнес-
возможностей по мере того, как наши ресурсы превращаются в прах.
Однако так не должно быть. Agile предлагает альтернативу бизнес-энтропии и позволяет добиваться нужных
результатов на постоянной основе.
Сделать первый гибкий шаг несложно, и при необходимости вы можете получить поддержку или консультацию.
Эта книга поможет вам начать путешествие. Она не содержит советы на все случаи жизни – это было бы
невозможно, в конце концов, в ней чуть меньше страниц, чем в «Войне и мире». Тем не менее в этой книге есть
все, что нужно для того, чтобы отправиться в путь, и достаточно указателей для того, чтобы добраться до цели.
Поднять паруса!
Блистательный итог
• Изучите Манифест Agile и ознакомьтесь с семью принципами бережливого управления – это краеугольный
камень гибких методологий.
• Agile – это особенные подходы, которые требуют определенного мировоззрения для получения наилучших
результатов.
• Если это возможно, начните с малого проекта и сосредоточьтесь на создании работоспособного продукта.
• У вас есть полное право ожидать непосредственного результата, но будьте реалистами.
• Тут в бой вступает тяжелая артиллерия… но не стоит переоценивать ее возможности!
Глава 2. Agile совсем другой!

Введение
Мало что остается постоянным – изменения неизбежны. Это справедливо для людей, бизнеса и даже для всего
общества. Быть способным изменяться и развиваться – не просто хорошая черта, а свойство, необходимое для
выживания. Сто миллионов лет назад динозавры были доминирующим видом на нашей планете, но не смогли
эволюционировать – и это то, что о них запомнили. Сейчас динозавром уничижительно называют того, кто
отказывается развиваться и идти в ногу со временем.
В начале XX века сеть ресторанов Дж. Лайонса и сеть розничной торговли Ф. Вулворта процветали и до
пятидесятых годов были примером классического британского предпринимательства. Тем не менее обе эти
марки неизвестны подрастающему поколению – теперь это просто приятные воспоминания о юности для их
бабушек и дедушек: от подъема до спада менее чем за полвека. Эти компании не смогли приспособиться к
меняющемуся миру и под конец сделались чем-то вроде динозавров в среде корпораций.
В XXI веке все складывается даже более серьезно. Компьютерная сфера бизнеса должна развиваться со
скоростью света. Клиенты, пользователи и спрос на рынке могут измениться за несколько недель. Время – это
все; больше не может быть и речи о плане развития на пять лет. «Время до рынка» – вот что важно; компании
должны иметь возможность поменять направление разработки быстро, развивая идею от концепции до
прибыльного проекта почти в одночасье, чтобы оставаться актуальными и платежеспособными.
Традиционное управление проектами с трудом адаптируется к этому быстроразвивающемуся миру, потому что
такая скорость изменения направления не появляется из ниоткуда. Гибкое управление проектами основано на
совершенно иных методах и отлично с этим справляется, так как базируется на принципах, подходящих для
нужд современных предприятий, и обеспечивает все, чтобы компания не закончила так же, как динозавры.
У Tesco 40 тысяч наименований продукции. Они торгуют всем – от автомобильных страховок до картофельных
чипсов, а еще закрывают филиалы, увольняют персонал и выписывают штрафы работникам гораздо чаще, чем
раздают бонусы. Aldi, новая компания на рынке Великобритании, работает только с двумя тысячами
наименований продукции, но Aldi нанимает новых сотрудников, открывает магазины и получает прибыль. Вопрос
в том, слишком ли велика Tesco, чтобы успеть адаптироваться до того, как Aldi захватит рынок?
Компания может сбиться с нужного курса в любой момент. Упустишь что-то важное или просто перестанешь
следить за важными тенденциями – и путь с вершины может стать очень быстрым.
Тьма перед рассветом

Быстроразвивающиеся темпы современного делового мира выводят ситуацию на другой уровень, но и
организации в течение очень долгого времени были недовольны результатами сделок при традиционных методах
управления.
С завидной регулярностью проекты не срабатывали, и для инвесторов стала обычной ситуация, когда нужно что-
то делать, но, по сути, хорошего выбора нет. Бизнес-команда называет проект не иначе как «тот чертов проект»,
но обычно просто пожимает плечами и смиряется со своей судьбой. Часто в попытке сохранить хоть что-то в
проект бросаются новые средства и другие ресурсы, но это почти никогда не срабатывает.
Есть и другие плохие новости. Традиционные методы управления проектами используют жестко
регламентированные процессы; устанавливают процедуры, которым надлежит следовать, документы, которые
необходимо оформить, и встречи, которые нужно посещать. Таким образом, фаза планирования сама по себе
может занять несколько недель или месяцев. Каждый этап проекта выполняется отдельно, а соблюдение всех
правил кажется самым важным. В результате первоначальную идею проекта часто забывают.
Наконец, что еще хуже, «заключенные регулярно захватывают власть и принимают свои законы». Конечно же,
руководители и их команды нечасто идут на это сознательно, но это все равно случается с завидной частотой.
Введение регламентированных процедур и жесткого контроля процесса нередко приводит к тому, что вместо
бизнеса, контролирующего процесс разработки, процесс начинает контролировать бизнес.
Но темнее всего ночь перед рассветом. Когда проекты завершаются неудачей, а компании пытаются уцелеть,
необходима большая встряска. Agile может все изменить.
Основы Agile
Некоторые люди думают, что Agile – это какое-то новое изобретение. Другие считают, что Agile – это старый
метод, но просто переделанный на новый лад. Есть те, кто руководствуется здравым смыслом, и те, кто говорит,
что гибкие подходы не работают, вы даже можете встретить восторженных сторонников, которые полагают Agile
чудесным решением абсолютно всех бизнес-проблем. Есть много разных мнений, но главное, что это невероятное
изменение в подходе к выполнению проектов с:
• взаимодействием людей друг с другом и творческими подходами к решению проблем;
• участием бизнес-представителей и заказчика во всем процессе работы над проектом, начиная от концепции и
заканчивая получением прибыли;
• сокращением «времени до рынка» для получения или сохранения конкурентоспособности;
• ранним получением работающего продукта и, как следствие, быстрой обратной связью;
• поэтапным добавлением улучшений с целью сохранить актуальность продукта;
• атмосферой гибкости и способности к изменениям;
• возможностью вносить значительные изменения, чтобы «оставаться в игре»;
• требованиями заказчика и конечного пользователя как основой для принятия решений;
• выпуском продукта, который является самым главным!
Мерой интеллекта является способность меняться.
Альберт Эйнштейн
Важнейшей частью философии Agile является ранний и частый выпуск продукта; разработка окончательного
продукта от основной идеи путем постоянного добавления улучшений. Первый выпуск продукта отвечает
требованиям бережливого управления и экономически эффективен. Главные идеи проекта испытываются уже на
ранней стадии, при этом всегда есть место для более тонкой настройки продукта или полного изменения
направления разработки. Это позволяет компании:
• начинать с самых важных требований и не более того;
• урезать стартовый бюджет до минимума;
• предполагать прибыли;
• расширять возможности команды;
• быстро приступать к разработке;
• изменять направление разработки, как только возникнет такая необходимость.
Лакмусовая бумажка для Agile-проекта – удалось ли воплотить концепт в реальность.
Agile требует, чтобы мы нашли более простой способ для выпуска продукта, ставя людей и взаимодействие
между ними во главу всего. Основные подходы и фреймворки очень легко применить, и в них уже заложены
гибкость и возможность изменений. Это оправдано здравым смыслом, потому что, чем сложнее методика, тем
тяжелее ее освоить. Если использовать Agile разумно, результат будет лучше заранее спланированных схем.
Agile уделяет больше внимания значимости, прозрачности и взаимодействию между людьми, и меньше –
сосредоточенности на правилах. Agile стремится к тому, чтобы расширять возможности людей, работающих над
проектом, чтобы позволить им концентрироваться на выпуске продукта. Гибкие подходы описывают всю схему
работы целиком, но не являются пошаговым руководством. Часто говорят, что философии Agile легко следовать,
но сложно делать это хорошо. Именно прозрачность, организация и дисциплинированность делают разработку
успешной.
Может возникнуть ощущение, что Agile-проекты выглядят как жизнь на Диком Западе – почти никакого
управления, никакой документации, слабо разграниченные роли и обязанности. Но на самом деле все обстоит не
так. Все организовано более легковесно, чтобы не перегружать рабочий процесс.
Есть тонкая грань между фреймворком и процессом. В данном контексте фреймворк – это серия гибких
ориентиров, а процесс проекта – более жесткая и негибкая схема. Фреймворк позволяет, процесс – ограничивает.
Анализ по-другому
Перегрузка процесса, характеризуемая уровнем контроля и общего вмешательства в работу, используется во
многих проектах. Многие компании настолько сильно озабочены тем, как у них все делается и организован ли
процесс верно, что забывают о результате. Это особенно справедливо для крупных государственных организаций,
которые применяют методологию PRINCE2. Этот способ аудита процедур позволяет определить успешность
применения метода и идентифицировать аспекты для улучшения. При этом не так важно, что именно должен
поставить проект.
Механизм поставки – вторичный вопрос для Agile-проекта. Используемые инструменты и методы важны, однако
методики очень гибкие и могут быть изменены в соответствии с проектом и организацией. Нет двух абсолютно
одинаковых реализаций Agile, но они будут очень похожими. Нет никакой «полиции Agile», зато есть множество
рекомендаций, и соблюдение сути подходов важнее, чем любые правила. В основной философии Agile
упоминаются важные для соблюдения моменты, но сейчас их уже полагают менее критичными к исполнению,
чем ранее.
Для любого, кто привык к кажущейся защите тяжелых процессов, связанных с обычными проектами, такой
подход может оказаться непривычным. Но Agile-проекты саморегулируются куда более прозрачным и
эффективным способом. Agile берет проект малого размера и быстро выпускает рабочий продукт, получая на
него обратную связь. Заказчика и конечного пользователя рабочий продукт интересует куда больше, чем
документация, потому что именно продукт они могут видеть и использовать. Идеальный сценарий – раннее
обнаружение хорошего, плохого и ужасного: глюки в коде программы намного проще найти и исправить на
ранних этапах разработки, чтобы впоследствии они не привели к катастрофе.
Agile-вариант позволяет меньше волноваться о соблюдении правильности процесса и сосредоточиться на
конечном продукте.
В большом правительственном агентстве случался переполох каждый раз, когда наступало время годового
аудита по PRINCE2. Проектный офис лихорадочно старался найти любой проект, соответствующий критериям
PRINCE2; при обычных обстоятельствах этих проектов было не слишком много. Успешное прохождение такого
аудита считалось нормальной заслугой, но проблема заключалась в том, что для «полиции проектных нравов»
основным условием было максимально точное следование принципам PRINCE2.
Непосредственные результаты проектов и качество этих результатов не имели особого значения.
Начало реализации проекта

Время до рынка (time-to-market) имеет решающее значение, но сама разработка продукта занимает только часть
времени от момента высказывания идеи до ее успешной реализации. Часто бывает, что само начало разработки
сопряжено с определенными усилиями, и этот период простоя сам по себе проблема и является частью процесса
под названием технико-экономическое обоснование (feasibility study).
Если говорить откровенно, то основная причина, почему оценки потенциала разработки считаются
необходимыми, – это высокая стоимость проектов. Они пытаются спрогнозировать жизнеспособность и
примерный доход от идеи в случае серьезных инвестиций, чтобы трата средств была оправданной. Однако на
практике технико-экономическое обоснование уже потеряло свое первоначальное значение инструмента для
независимого оценивания, потому что решение по обоснованию зачастую политизировано и заранее
предопределено.
Agile частично решает эту проблему, так как первоначальные затраты на разработку невысоки, а демонстрация
работающего продукта возможна в ранние сроки. Вместо того чтобы терять время и деньги, размышляя над
оценкой и принятием проекта, намного логичнее вложить эти средства в разработку базовой версии. Такое
испытание идей обойдется намного дешевле, и итоги будут более убедительными, чем в теории, потому что они
будут основаны на реальных результатах.
Лучше попробовать и потерпеть неудачу, чем не пробовать вообще, – тот урок, который мы выучили.
Бесконечные обсуждения, ревью и презентации только затягивают ход работы. Ничегонеделание обойдется вам
дороже, чем попытка – ведь нет ничего более разочаровывающего, чем хорошая идея, отвергнутая без должного
обоснования. И неудача, и доказательство того, что идея рабочая, – оба варианта не обойдутся дорого, и они
точно лучшая альтернатива бесполезным мечтаниям.
Уже с самого начала разработки Agile подходит к процессу работы над проектом совершенно по-другому. Каждая
новая идея получает свой шанс, а плохие идеи отсеиваются очень рано, и все решения основываются на фактах,
а не на догадках.
В начале нового тысячелетия в некоей большой правительственной организации была создана команда,
специализирующаяся на проведении технико-экономических обоснований для новых IT-проектов.
Предполагалось, что новые идеи вернут весь объем затраченных на них инвестиций. Поскольку бюджет был
ограничен, шансы имели только те проекты, которые могли потенциально принести большую прибыль. Бизнес-
группа была слишком занята, чтобы постоянно заниматься таким оцениванием, и IT-специалисты разработали
рекомендации, основанные на их собственном понимании делового мышления. Это было неплохой идеей и
делало IT-команду несомненно полезной, но в конечном результате проекты отклонялись по некорректным
причинам. Иногда это работало нормально, а иногда – не совсем и напоминало скорее попытки попасть пальцем
в небо.
Печально, когда проекты осуществляются плохо. Еще хуже, когда проект не принимают по ложным
соображениям.
Приветствуя перемены
Изменения неизбежны и зачастую случаются неожиданно. Перемены необязательно происходят внутри
организации или под чьим-то влиянием извне: технологические достижения и постоянно меняющиеся подходы
сами по себе гарантируют, что даже малейшая неспособность реагировать на перемены может означать потерю
конкурентного преимущества на рынке. Традиционным схемам управления проектами в процессе разработки
изменения создают лишние препятствия. В конечном счете плыть против течения оказывается непродуктивно.
Agile, напротив, поощряет гибкость и облегчает принятие изменений.
Изменения – это основа Agile. Чтобы стать и оставаться гибким, придется измениться. Разработка продукта
упростится, если большую проблему разбить на несколько маленьких, которые проще понять, обсудить и решать.
Предполагается, что проект будет продвигаться вперед маленькими шажками – потому что сотне маленьких
лодочек маневрировать легче, чем нефтяному танкеру. И по-настоящему гибок тот, кто понял эту простую
истину.
Некоторые трактуют эту способность изменяться так, что Agile-проекты сталкиваются с тем, что изменения
приходится вносить в последнюю минуту. Но, безусловно, такая проблема может случиться в любом проекте,
даже в Agile-проекте, если гибкая методология в нем применена плохо. Но уже давно в бережливом управлении,
Lean, принята концепция принятия решения точно в срок (just in time). Без сомнений, принятое решение будет
лучше, если основано на фактах, а не на догадках, а чтобы уточнить детали, может понадобиться время. Agile
приветствует решения, принятые поздно, но это должна быть такая задача, неразрешение которой вовремя
может создать еще больше проблем. Более традиционные методы управления с этим не справляются.
Вот что происходит, когда мы сопротивляемся изменениям.
Жизнь становится легче

Это отличные новости для генерального директора, совета директоров и старших менеджеров. Это не означает,
что они могут откинуться на спинку кресла и расслабиться, но Agile позволяет им больше сосредоточиться на
стратегии, а не постоянно беспокоиться о том, окончатся ли проекты выпуском продукта. Высокая прозрачность
Agile-проектов и ранний и поэтапный выпуск продукта – это находка для руководства.
Тем не менее основные трудности при переходе на гибкие подходы ждут саму команду проекта. Своему всплеску
популярности Agile обязан тому, что люди начинают получать больше удовлетворения от результатов своей
работы, а значит, это уже само по себе идет на пользу карьере – в этом смысле нет ничего плохого в стремлении
к соблюдению собственных интересов. Agile также предлагает лучшую операционную среду.
Ясные роли и обязанности. Гибкие подходы – не для уклоняющихся от работы и передающих дела кому-то
другому; они для правильных людей, которые принимают решения. Бизнесу дают слово тогда, когда это нужно, а
во всех остальных случаях решение остается за членами команды.
Расширение возможностей. Больше никаких перекладываний решения на вышестоящее руководство, тем
более что оно зачастую не понимает, о чем речь. Возможность принимать важные решения является
эффективной и раскрепощающей для любого ответственного человека.
Сила в единстве. В гибкой команде присутствует атмосфера общности – одиночный героизм ценится меньше.
Конечно, у любого найдется возможность поблистать – но только если это пойдет на благо коллектива. Без
взаимопомощи – никуда.
Позитивная атмосфера и энергичность. Операционная среда является оптимистичной, поддерживающей,
конструктивной и расслабленной. Это вызывает убежденность команды в их коллективной способности получить
результат проекта. И это большой бонус.
Лучшие результаты. Никто не любит терпеть неудачи – и, само собой, быть частью успешной команды уже
замечательно. Привыкайте побеждать — успех порождает успех.
Блистательный эффект
Наиболее важной повторяющейся деятельностью в Agile является устранение любых препятствий, которые
мешают команде работать. Эти факторы могут варьироваться от незначительных раздражителей до сложных
организационных проблем, которые существенно снижают производительность.
Возможность сосредоточиться исключительно на выполнении работы и не отвлекаться ни на что другое – это как
глоток свежего воздуха.
Испытание для руководителя проекта

Переход к Agile должен быть естественным – не революцией, а возвращением домой. Неудобным это будет для
тех, кто привык к стилю управления, связанному с выдачей указаний и контролем, – в Agile-команде в нем
попросту нет надобности. Одна из наиболее частых ошибок тех, кто начинает работать с Agile, – поставить во
главу первого проекта одного из прежних руководителей проекта.
Конечно, многие руководители проекта легко справляются с переходом – в основном потому, что, по сути, они
уже сторонники Agile. Идея того, что управленец должен сосредоточиться на том, чтобы команда показала себя с
лучшей стороны, а не «выкрикивать приказы», далеко не нова. Очень многие руководители не считают себя
лучше других и рассматривают свою роль скорее как вспомогательную и фасилитирующую; таким в команде
будут только рады. Руководствуйтесь здравым смыслом — одной из основополагающих черт Agile.
Но момент перехода к гибкости – как раз то время, когда одна ложка дегтя может испортить всю бочку меда. Нет
ничего хуже, чем кто-то, привносящий старые привычки в новое и свежее Agile-окружение. Руководители
проектов никогда не признаются, что одержимы контролем или что признают только свое и ничье больше
мнение, но такое встречается повсеместно. Модель поведения очень сложно изменить – а это именно то, чего в
данном случае требует Agile. Будьте осторожны, запуская лису сторожить курятник.
Не переходите на Agile, если:

• Вы получаете удовольствие, говоря людям, что им нужно делать.
• Вы привыкли присваивать заслуги команды себе.
• Вы первым делом начинаете искать козла отпущения, если что-то идет не так.
• Коллеги, которые рады своей работе, вызывают у вас подозрение.
• Вы полагаете, что гибкость – для слабаков.
Не панацея
Помните, что, несмотря на все положительные аспекты, Agile не может быть решением всех проблем и много
чего может пойти не так. С этой точки зрения Agile не так уж и отличается от других подходов. Злоупотребить
можно любой возможностью, особенно если непреднамеренно неверно истолковать Agile. В восторженных
приверженцах, не имеющих достаточного опыта в применении чего-либо, нет ничего необычного. Гарантировать,
что люди будут действовать в духе Agile, но оставить им свободу действий – нелегкая задача.
Не всякий имеет нужный образ мышления, чтобы использовать Agile. Большинство адаптируется быстро, но есть
те, кто так и не сможет влиться в эту методологию. Некоторых скептиков можно убедить, продемонстрировав им
Agile в действии, – так что первоначальные суждения коллег еще можно будет изменить; главное, не затягивать с
этим, потому что критические высказывания могут деморализовать команду. Да, что-то может пойти не так, но
совсем необязательно, что это недостаток гибких подходов или вовлеченных в Agile-проект людей.
Один из побочных эффектов перехода на Agile – это то, что обнажаются уже существующие проблемы и правда
выходит наружу. Часто становится понятно, кто не прилагает достаточно усилий в ходе работы, кто придирчив,
потерял связь с настоящим ну или просто сплетник.
Agile не создает новые проблемы, а лишь делает их явными. Будьте аккуратны, если некомпетентным в
результате окажется старшее руководство команды.

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

• Неподходящая организация: не ожидайте, что военно-морской флот перейдет на Agile.
• Неверный проект: строительство авианосца точно не подходит.
• Неправильный подбор работников: диктаторы и одиночки не смогут адаптироваться.
Сможете привести пример бизнеса, компании или услуги, которых больше не существует или не имеющих той
доли рынка, которая была у них раньше? Недавний экономический спад дал нам много таких примеров: HMV,
Blockbuster, Woolworths, Myspace, Nokia, Blackberry и прочие. Почему казавшийся непотопляемым бизнес
внезапно теряет свои позиции? Что происходит с мировым брендом, если его продают по скидочной цене?
Есть и те, кто не мгновенно, но медленно приходит к спаду. Tesco – не единственное дитя фондовой биржи,
выписывающее штрафы, чтобы избежать потери успеха. Потерянные возможности ничуть не лучше откровенных
неудач, и в обоих случаях причины нередко одни и те же. Возможно, финансовый кризис плохо сказался на
продажах или же продукты просто потеряли популярность. Или, возможно, кто-то нашел способ производить
продукты быстрее, дешевле и лучше. Во всех этих случаях причина неудачи одна: нежелание или неспособность
меняться.
Agile помогает двигаться к цели быстро и с наименьшими затратами. Это не волшебная палочка, но если вы
стоите на распутье, как Tesco, то вам пригодится любая помощь. В сути своей, гибкие подходы – это общий
термин для набора инструментов и техник, которые позволяют вам добиться гибкости: способности реагировать
на изменения и адаптироваться. Однако не забывайте, что, несмотря на все эти отличия, Agile не совершенен.
Всегда будут ситуации, в которых что-то пойдет не так, как должно. Жизнь – это череда поражений и побед.
Лучше выиграть войну, чем пытаться выиграть каждую битву.
• Изменения – часть жизни; не будьте динозавром.
• Всесторонние и сложные процессы подходят, только если пункт назначения вам известен.
• Нет такого средства, которое помогает от всего. Agile подходит не всем… и особенно не всем руководителям
проектов.
• Гибкость – это способность реагировать на изменения и адаптироваться.
• Может, Agile и не нов, но он очень отличается!
Глава 3. Начало: готовимся быть гибкими

Введение
Большинство привычных методов управления проектами основаны на скрупулезном расставлении всех точек над
i еще до начала разработки. Требования к проекту должны быть разработаны, прописаны и проанализированы со
всех возможных точек зрения еще до начала непосредственной работы над проектом. Противники этого подхода
считают, что основным залогом успеха является гибкость, которая заключается в том, чтобы планировать на
ходу, начав с приблизительной идеи, а затем внося изменения в процессе разработки. Тем не менее обе точки
зрения весьма далеки от истины. Да, основная цель проекта заключается в том, чтобы получить обратную связь
уже после первого релиза. Вполне естественно, что последующие изменения должны вноситься исходя из
полученных отзывов. И, разумеется, в процессе разработки необходима определенная гибкость для внесения
корректировок или даже полной смены направления разработки, если это необходимо. Тем не менее эти задачи
должны быть реализованы упорядоченным образом, в соответствии с общим видением цели проекта и на основе
успешных бизнес-решений. На первый взгляд гибкость и хаотичность могут казаться двумя сторонами одной
медали, однако на самом деле гибкость позволяет реализовать более продуманный подход к управлению
проектом, чем традиционные методы. Гибкие подходы требуют меньше усилий на подготовку, что, в свою
очередь, ведет к более разумному распределению ресурсов. Вместо того чтобы планировать все заранее, Agile
создает возможность получения результата уже на ранних этапах и позволяет добиваться стабильного прогресса
на протяжении всего проекта. Гибкие подходы определяют конкретную цель с самого начала и предоставляют
инфраструктуру для ее реализации, при этом не тратя времени на то, чтобы углубляться в детали до начала
работы.
Определение видения
Недальновидные люди обречены на гибель. Моисей сказал это четыре тысячи лет назад, но большинство
руководителей проектов до сих пор не понимают, что он имел в виду. Если мы не знаем, куда идем, то мы вряд ли
доберемся куда-либо – и это особенно верно, когда речь идет о проектах. Люди часто имеют различные
представления о том, чего и как они хотят добиться, и в итоге получают различные результаты. Четкое
определение видения необходимо для успешного проекта. К сожалению, большинство проектов дают
определение видению с помощью расплывчатых заявлений миссии, которые при более пристальном
рассмотрении нередко оказываются бессмысленными:
• Мы предлагаем исключительное качество.
• Интересы наших покупателей для нас на первом месте.
• Мы будем лучшими в нашей сфере, и нас все будут любить.
Утверждения хорошие, но абсолютно бесполезные: с ними сложно поспорить, но использовать их для реализации
практических бизнес-задач не представляется возможным.
Удача – это пересечение пространства возможностей и готовности ими воспользоваться.
Дензел Вашингтон
Видение должно быть инструментом для вас. Вы можете его использовать для любых коммуникационных целей.
Также видение полезно, когда вам нужно решить, что именно вы собираетесь делать, а чего не собираетесь.
Наконец, оно важно в тех случаях, когда вам необходимо определить приоритетность задач. Видение проекта –
это не столько общая формулировка целей, сколько практический инструмент для того, чтобы помочь вам
сконцентрироваться на их реализации. Вы всегда должны быть готовы изменить или обновить видение, когда оно
перестанет быть актуальным (а это рано или поздно обязательно произойдет).
В качестве примера использования видения давайте представим, что мы – компания, которая собирается
продавать овощи в рестораны. Видение поможет нам понять, что конкретно это значит.
В конце сентября компания Project VegBox разработает новое приложение для iOS, с помощью которого
покупатели смогут заказать доставку овощей в их рестораны, выбрав из десяти возможных наборов. В результате
этого наш бизнес создаст новую линию продукции, расширив отдел, занимающийся овощами, а наши клиенты
получат возможность быстро и удобно закупать овощи по оптовым ценам.
Видение объясняет, что именно мы собираемся сделать. Оно должно учитывать особенности целевой группы,
платформы и продукта, как, впрочем, и сроки. Однако самое главное, чтобы видение могло объяснить значимость
проекта для компании и потребителя.
Определение видения проекта

• Как называется проект или продукт, который вы производите?
• Для кого он предназначен?
• Когда он должен быть закончен?
• Что он делает?
• Чего он не делает?
• Какая выгода для вашего бизнеса от использования этого продукта?
• Какую выгоду получит клиент от использования этого продукта?
Описание видения должно быть составлено так, чтобы даже ваши мама и папа могли понять, что вы собираетесь
сделать.
Семейный уик-энд не требует тщательного планирования. Более чем достаточно сойтись в основном: место
назначения, что с собой брать и как добраться. Нет необходимости расписывать все по минутам и прорабатывать
все возможные сценарии. Самое главное – это определиться, пойдете ли вы в тематический парк, будете
отдыхать на пляже или посвятите день шопингу. Если конечная цель определена, все остальное – уже вопрос
выбора методов, как до нее добраться.
Руководствуясь идеей бизнес-ценности

Слишком многие проекты начинаются с не до конца оформившейся идеи. Кому-то на руководящей должности
или с деньгами, которые можно потратить, внезапно приходит в голову идея – и вот уже этот локомотив, который
невозможно остановить, мчится неведомо куда. Конечно, далеко не всегда проекты начинаются с чьей-то
прихоти, но не исключайте и того, что не всегда есть хорошие основания для старта проекта, несмотря на
убедительные рассказы главного менеджера или полных энтузиазма умников компании. Всегда проявляйте
должную осмотрительность – существует вероятность того, что было принято неразумное инвестиционное
решение.
Гибкие подходы полностью сосредоточены на наибольшей бизнес-ценности. С начала и на протяжении любого
проекта бизнес-команда должна точно знать, на что она собирается тратить свои деньги.
Люди упоминают получение отдачи от проекта так часто, что это уже стало бессмысленным. Что значит эта
«отдача»? Рассуждайте в понятиях выгоды. Какую выгоду проект принесет заказчику или бизнесу? Успешный
проект выгоден для всех.
Agile не определяет четко, что такое бизнес-ценность или «красота в глазах зрителя». Гибкие подходы служат
основой того, чтобы деньги, заработанные с определенным трудом, были инвестированы с пользой. Agile
облегчает и обеспечивает принятие разумных решений, но ничего более. Можно привести лошадь на водопой, но
нельзя заставить ее пить.
Каждый выпуск продукта, каждая особенность, каждый нюанс – все это должно быть обговорено. Прошли те
времена, когда от человека к человеку передавался лист с требованиями на техническом жаргоне или
иностранном языке, который бизнесмены не до конца понимают. И совсем в прошлом времена, когда заказчик
слепо доверялся людям, которых едва знает. В Agile бизнесмен описывает, что ему нужно, и затем работает с
командой проекта, чтобы убедиться в том, что видение реализовано именно так, как задумано.
Кроме того, определив в точности, что необходимо, заказчик определяет это как необходимый минимум – и с
этого начинает добавлять другие кирпичики. Первый выпуск продукта может не иметь всех «свистулек», но он
должен быть работающим, реализовывать товар или услугу и быть выпущен как можно быстрее. Инвестируем в
X, затем в Y – получаем последовательный выпуск продукта; это правило должно соблюдаться в течение всех
этапов разработки и быть совершенно прозрачным.
Если вы не знаете, что хотите построить (видение), какую выгоду получите (реализация товара или услуги) и для
кого ваш проект (конечный потребитель), то, будь у вас даже лучшие эксперты в мире, вы все равно не получите
никакого стоящего результата.
Формирование команды проекта

Многие люди старательно собирают в команду лучших людей, которых могут найти, – специалистов с
соответствующим опытом, экспертов в своей области – и затем все портят, не предоставляя адекватного
понимания бизнеса и лидерства. Не ставьте телегу впереди лошади! Важно достичь правильного уровня участия
бизнеса в проекте – включить одного человека, который понимает видение бизнеса. Это не просто практично и
прагматично, но и логично с точки здравого смысла.
В Agile этого человека обычно называют «владельцем продукта» (Product Owner), но существуют и варианты
названия. Конечно, в этой блистательной книге его стоило бы называть «руководителем продукта», но для
начала остановимся на простом определении. Владелец продукта представляет интересы бизнеса и конечного
пользователя. Владелец продукта живет, дышит и мечтает о продукте и о том, каким он должен быть. Такие люди
знают, чего именно хотят, даже если не знают способа, как этого достичь. Они лидеры, способные быстро
принимать решения и отстаивать их.
Agile-команда – разнообразная, многофункциональная группа индивидуумов, способных воплотить видение от
имени бизнеса. Проще говоря, у них есть все, чтобы выполнить работу надлежащим образом. Владелец продукта
указывает путь только в плане бизнес-видения, но и это большой вклад в работу команды. Команда состоит из
людей с гибким мышлением, не боящихся изменений и не считающих, что бюрократия – решение всех проблем.
Уверенно принимающие решения, проявляющие инициативу деятельные люди подойдут лучше всего.
В определение видения и всех аспектов, касающихся выпуска продукта, должна быть вовлечена вся команда.
Если поступать не так, возникнут сложности.
Создание журнала требований

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

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

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

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

Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого
дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть
сложным и в конце концов зависеть от мнения, но мнение заказчика – или того, кто представляет собой его
бизнес, – имеет решающую роль. Конечный результат шагов – тот приемлемый минимум для заказчика, которого
проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum
viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).
Один из больших плюсов – быстрое получение важной обратной связи от конечных пользователей, однако, чтобы
составить свое мнение, им необходимо что-то довольно существенное. Невозможно получить значимую обратную
связь о техническом процессе, но о новой форме заказа VegBox – вполне. Естественно, это будет частью
минимально жизнеспособного продукта.
Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени
потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно
информации для получения обратной связи. Вам придется найти баланс между прибылью и риском – никакого
универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то,
что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.
Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для
использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните,
что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт
соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет
абсолютно правильных подходов – выберите тот, что лучше подходит вам.
Добавление характеристик
Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально
жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые
характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется
инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого
выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же,
именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну
характеристику, проверенную практикой.

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

Пользовательские истории (user story) – короткие простые описания характеристик продукта с точки зрения
человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские
истории обычно следуют простому формату.
Будучи <тип пользователя>, мне нужно <цель> по <причина>.
Пользовательская история – это абстрактная концепция, которая предоставляет достаточно информации, чтобы
команда могла реалистично оценить ресурсы, необходимые для реализации проекта. Пользовательские истории
часто записываются на стикерах или карточках, которые затем развешиваются на стенах или раскладываются на
столах, чтобы облегчить процесс планирования.
Пользовательская история позволяет сфокусироваться на обсуждении характеристик продукта, что является
важным шагом после выработки основного представления об этих характеристиках.
Никто не заставляет вас использовать пользовательские истории. Однако эти истории напоминают нам о
важности коллективных обсуждений, и результаты этих коллективных обсуждений нередко важнее подробного
плана работ.
ДАТА ДОСТАВКИ
БУДУЧИ НЕПОСТОЯННЫМ ПОКУПАТЕЛЕМ
МНЕ НУЖНА ГАРАНТИРОВАННАЯ ДАТА ДОСТАВКИ В МОМЕНТ СОВЕРШЕНИЯ ЗАКАЗА
ПО ПРИЧИНЕ ТОГО, ЧТО Я ДОЛЖЕН ЗНАТЬ, КОГДА ОЖИДАТЬ СВОЙ ЗАКАЗ, ЧТОБЫ ОН НЕ СГНИЛ ПОД
ДВЕРЬЮ
В ходе этих обсуждений определяются ключевые аспекты главнейших характеристик продукта. Помните, записи
сами по себе ничего не значат, однако живое коллективное общение позволяет нам не только выработать
основополагающие детали, но и сохранить свежий взгляд на проект. Выигрышно во всех отношениях.
Выработка критериев принятия

Как мы узнаем, что мы сделали все? Это ключевой вопрос, и именно с него следует начинать дискуссию,
следующую за обсуждением пользовательской истории. Чтобы действовать эффективно, нужно знать, когда
остановиться. Когда заканчивается наш проект? Сколько сил мы должны вложить в него? Как избежать
переработки и неизбежной фрустрации? Для успешного использования пользовательских историй мы должны
выработать критерии принятия – предпосылки к проекту, которые должны быть реализованы, чтобы история
была оценена как выполненная.
Не существует единственно правильных критериев принятия. Они могут быть как простыми, вроде условий
удовлетворенности работой, так и очень подробными. В рамках Agile лучшими критериями принятия являются
односложные оценки, написанные простым и понятным языком. Рассмотрим пользовательскую историю,
связанную с датой доставки, и применим к ней критерии принятия:
• Дата доставки – всегда будет на следующий рабочий день после заказа.
• Если заказ был оставлен в субботу, то доставка будет в понедельник.
• Заказы на следующий рабочий день принимаются до трех часов по полудню.
• Клиент получает подтверждение о заказе по электронной почте.
• Все продукты в наличии доставляются по этим правилам.
• Мы сообщаем день заказа, но не точное время.
• У пользователя должна быть возможность оставить комментарий для курьера.
• Ожидаемый день доставки будет показан на экране при заказе.
Критерии принятия, написанные командой разработки, являются самым предпочтительным способом учесть все
мелочи. Под руководством владельца продукта или бизнес-представителя команда может обсуждать
пользовательские истории, устранять любые двусмысленности и определять конечный результат. Это лучший
способ добиться согласованной работы, и эти обсуждения не должны быть длительными или трудоемкими. Их
можно сделать как раз перед началом основной работы над проектом; цель состоит именно в том, чтобы начать с
конца!
Кроме того, по критериям принятия можно отслеживать прогресс выполнения работ. Зачастую бизнесменов
беспокоят расплывчатые фразы вроде «мы почти закончили» или «полагаю, мы на верном пути». Поэтому
критерии принятия могут служить вехами на пути к завершению работ: мы реализовали половину из заявленных
критериев принятия. Если критерии сформулированы должным образом, отслеживание прогресса будет легким –
и все будут понимать, следует беспокоиться или нет.
Разделяя истории
Иногда в результате плодотворных обсуждений появляется очень много материала. Это хороший признак, не
волнуйтесь и продолжайте записывать обсуждение. Некоторые идеи могут не подходить пользовательской
истории, над которой вы сейчас работаете, или быть для нее слишком продвинутыми. Как только вы это поймете,
сможете такие идеи отфильтровать и в дальнейшем добавить в более подходящие истории.
Другой подход заключается в том, чтобы написать новую историю – так называемое разделение историй.
Типичный пример – ситуация, когда владелец продукта считает некоторые из критериев принятия
необязательными и хочет выработать новую историю, включающую в себя дополнительные характеристики
продукта. Как только новая история написана, она может быть включена в журнал требований (бэклог) вместе со
всем остальным.
При написании историй очень важно знать, когда остановиться. Чем сложнее история, тем меньше вероятность
того, что она будет полезна. Чрезмерно широкие критерии принятия – важный индикатор того, что что-то пошло
не так. Обычно это значит, что историю надо разделить. Нередко вам придется разделять истории несколько раз,
и в этом нет ничего плохого – наоборот, это прекрасный способ сделать работу над проектом более
реалистичной.
– И нашему пользователю сразу будет понятно, где аварийный выход!
Когда размер имеет значение

Итак, у нас есть видение, бэклог, MVP, также набор продуманных пользовательских историй вместе с четкими
критериями принятия. Отличная работа. Теперь стоит задаться вопросом: сколько времени и сил потребует
практическая реализация всего этого? Обычно ответ на этот вопрос дают руководители проекта или профильные
специалисты. Однако в Agile-проектах этим вопросом занимаются люди, непосредственно ответственные за
реализацию проекта. Они не только смогут предоставить более реалистичную оценку. Это также позволит
сплотить команду. Конечно же, от размера каждой пользовательской истории зависят сроки реализации MVP,
как и проистекающие из этого характеристики. Тем не менее это все еще прекрасный способ оценить возможные
проблемы с реализацией конкретных этапов проекта. Если вы видите, что члены команды чешут затылки,
тяжело вздыхают и качают головами, то это не очень хороший знак.
Ряд оценочных техник исключительно хорошо подходит для Agile-проектов, например:
• Размеры одежды. Присвойте ярлычки S, M, L, XL и XXL каждой составляющей проекта, чтобы оценить
приблизительное количество ресурсов, которое потребует ее реализация. Отличный способ для начинающих,
который, впрочем, далеко не всегда точен.
• Оценочный подход. Используйте фиксированную шкалу, чтобы оценить трудозатраты для реализации
составляющих проекта, например, на шкале от одного до ста 1 будет означать «очень легко», а 100 –
«исключительно сложно». Данный подход начинает работать далеко не сразу, но у него много приверженцев.
• Принцип схожести. Распределите все истории в зависимости от их размера – от малых до больших. Затем
присвойте значение 1 самой маленькой истории, после чего оцените все последующие истории соответственно.
Прекрасный способ, чтобы оценить MVP.
Лучший способ выработать здравые оценки:

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

За пределами мира Agile-проектов практически всегда начинаются с игры в кошки-мышки. Бизнес-команда
инстинктивно чувствует, что она должна просить все на свете и немножечко больше, потому что когда еще это
делать, как не в начале проекта. Она также осознает, что, когда проект летит под откос – а это происходит всегда
в той или иной форме, – это негативно скажется на количестве и качестве результатов. Поэтому основная
стратегия бизнеса – просить все, чтобы на выходе получить хоть что-то.
Разработчики прекрасно понимают это и вполне положительно относятся к закладыванию в проект пространства
для маневра. Проблемы начинаются тогда, когда проект предсказуемо катится в тартарары, но ряд изначально
заложенных результатов уже находится в стадии реализации, и перед разработчиками встает дилемма
относительно того, что делать с вложенными в эти промежуточные результаты ресурсами и усилиями. Когда
время и (или) деньги разработчиков начинают подходить к концу, нередко оказывается, что самые важные
задачи до сих пор не выполнены: например, в случае с реновацией дома не имеет смысла вкладывать последние
деньги в высокотехнологичную кухню, если в ванной еще даже не начиналась побелка. Конечно же, здравый
смысл подсказывает нам, что всегда стоит начать с реализации самых минимальных требований к проекту, но не
стоит думать, что после их выполнения работа автоматически заканчивается. Обе стороны – и заказчик, и
разработчики – должны быть уверены в том, что проект не заканчивается после первого рабочего прототипа и
процесс улучшения и доведения до ума финального продукта продолжится и в дальнейшем. Доверие – важный
залог успеха, но понимание важности поэтапной реализации задачи является основой Agile. При наличии этого
понимания вероятность того, что проект скатится под откос вместе со всеми ресурсами, затраченными на его
реализацию, сравнительно невелика, если, конечно же, первоначальная идея проекта не была абсолютно
нереалистичной – но в этом случае проблема отнюдь не в Agile.
MVP – это абсолютный минимум, необходимый для начала использования или работы. Использование каждой
функциональности или нюанса должно быть результатом рационального выбора. Критерий отбора прост: если
MVP работает без этой характеристики, то она не нужна. На практике вы безусловно можете допустить наличие
пары не совсем необходимых характеристик – до тех пор, пока их реализация не начинает отнимать ресурс у
основной цели. Ваша цель – выработать набор требований к проекту, который можно быстро и беспрепятственно
реализовать.
Как только команда и заказчик привыкают использовать этот подход, его преимущества становятся абсолютно
очевидны: ускоренное время выхода продукта на рынок является ключевым элементом конкурентоспособного
бизнеса. Кроме того, очень сложно предсказать идеальный профиль будущего продукта, поэтому гораздо
разумнее вносить изменения в уже реализованный продукт. Гораздо приятнее обсуждать возможные улучшения
продукта после того, как он вышел на рынок и его основные характеристики уже реализованы. Ничто не
помешает команде вернуться к длинному списку дополнительных характеристик, которые ожидают своего
воплощения.
Отдел финансов редко выступает инициатором перехода к Agile, но его работники обычно очень положительно
воспринимают данный переход, если объяснить им все его преимущества. Сокращение периода адаптации
проекта для выхода на рынок, поэтапная реализация проекта и быстрый возврат инвестиций – все это звучит как
райская музыка для людей, которые привыкли работать с деньгами. Достаточно сказать им, что гибкие подходы
положат конец бесконечным спиралям бессмысленных бюджетных трат, – и эти люди ваши. Не забывайте о том,
что они могут быть очень полезными союзниками!
Менеджмент рисков и ожиданий

В случае правильной реализации Agile-проекты должны быть избавлены от типичных проблем, которые
преследуют обычные проекты. Менеджмент рисков и ожиданий является неотъемлемой частью Agile-подходов,
которые построены на максимальной прозрачности рабочего процесса. Основной риск для Agile-проектов
заключается в отсутствии понимания того, как именно функционирует гибкая разработка, поэтому повторите это
еще раз.
• Не забрасывайте испробованные и надежные практики. Многие разработчики пытаются менять
слишком многое слишком часто. Придерживайтесь плана и вносите изменения по одному. Если изменения не
работают, откажитесь от них.
• Говорите. Говорите. ГОВОРИТЕ. Отсутствие взаимодействия между людьми – источник всех зол. Отсутствие
информации является не менее губительным, чем плохая информация. Используйте регулярные отчеты о
проделанной работе для гарантии того, что вы обсуждаете что нужно и когда нужно.
• Избегайте чрезмерно масштабных задач. Чем больше требований, тем сложнее их понять. Всегда
старайтесь разбить большие задачи на несколько маленьких и более доступных задач.
• ПРОДОЛЖАЙТЕ ГОВОРИТЬ. Лучший способ избежать рисков при использовании гибкой системы
разработки – это постоянно поддерживать контакт с окружающими вас людьми.
Лучший способ привести все к краху – это формально адаптировать проект под Agile, продолжая работать с ним,
как с обычным проектом. Бойтесь овец в волчьих шкурах.
Ведение журнала требований

Значение журнала требований невозможно переоценить. Это краеугольный камень вашего проекта. Тем не
менее даже самый лучший журнал требований будет бесполезен, если вы его не ведете. Журнал требований – это
живой организм, требующий внимания. Если использовать его должным образом, то журнал требований
поможет вам понять, что происходит, найти общий язык с другими участниками проекта, уменьшить риски и
контролировать ожидания. Если вы не уделяете журналу достаточно внимания, он будет просто отнимать время
и сбивать с верного пути. Ведите ваш журнал требований!
В начале проекта журнал будет полон функциональных требований и характеристик, записанных в виде
пользовательских историй. По мере развития проекта там будут появляться новые записи и пользовательские
истории – это лишь один из возможных примеров создания элементов журнала. Основная задача журнала –
сделать работу над проектом видимой, включая неудачи, бесполезные характеристики, возможные улучшения,
новые идеи – вообще все. Записывайте и перерабатывайте их, а затем сортируйте в зависимости от их ценности.
Журнал требований принадлежит владельцу продукта, который несет за него ответственность. Владелец
продукта не должен прекращать работу над журналом, он должен постоянно обновлять и использовать его как
основу для ведения дел со всеми заинтересованными сторонами. Вносить изменения в журнал постоянно
нелегко, но плюсы перевешивают неудобства. Прозрачность разработки – залог доверия, и лучший способ ее
добиться – вести открытый для всех журнал.
Лучше всего, если владелец продукта и команда просматривают журнал каждый день. Это может быть частью
постоянной рабочей практики или частью любой презентации, посвященной проделанной работе. Иногда
ведение журнала занимает часы, а иногда минуты, однако важно обновлять записи постоянно.
Создание рабочей среды

Успех проекта, использующего Agile, в наибольшей степени зависит от его участников и того, как они
взаимодействуют друг с другом. Нередко заставить людей эффективно взаимодействовать друг с другом довольно
трудно, и рабочая среда играет в этом процессе ключевую роль. Самые успешные проекты – это те, участники
которых сфокусированы на результате, работают в одном офисе и не имеют проблем с доступом к владельцу
продукта. Не менее важно, чтобы у разработчиков перед глазами всегда была доска с задачами и, что особенно
важно, журнал требований продукта. Работа в одном помещении снимает основную часть проблем, связанных с
коммуникацией, позволяя не только эффективно взаимодействовать, но и налаживать личные связи, обсуждая то,
кто и как провел выходные.
Статичный журнал требований – признак грядущих неудач. Стоит обеспокоиться, если журнал не обновляется.
Впрочем, давайте будем реалистами. В идеальном мире мы все работаем в одном офисе, часто смеемся,
остроумно шутим и не имеем проблем с зубами, но на практике некоторые из нас регулярно опаздывают на
работу, мы часто работаем в разных городах и нередко целыми днями пропадаем в офисе заказчика. Независимо
от обстоятельств, видимость и прозрачность взаимодействия является залогом успеха, но добиться этого на
практике часто оказывается нелегко. Видеозвонки, электронные списки задач на гигантских тачскринах и
переговоры в Скайпе далеки от идеала, однако лучше иметь что-то, чем ничего. Если, и это действительно очень
важно, при всем при этом мы регулярно делаем записи в журнал, то все эти ухищрения могут сработать.
Для тех команд, которые не уверены в достижимости целей проекта и члены которых не знают своих точных
обязанностей и последовательности выполнения задач, нет оправданий. Если между собой команда не
разговаривает, значит, что-то пошло не так, и горькая правда состоит в том, что из-за этой рабочей среды падает
производительность. Значимость эффективной коммуникации сложно переоценить; если у команды есть желание
обсуждать рабочий процесс, они обязательно найдут способ, как это сделать.
Если вы не знаете, куда идете, то и придете куда-нибудь.
Йоги Берра (американский бейсболист)
Любая попытка начать проект без четкого видения приведет к неудаче, так как в этом случае вам придется
вырабатывать видение на лету. Прочный фундамент исключительно важен для любого созидательного процесса.
Даже самая лучшая команда не сможет добиться успеха, не имея точной цели с самого начала. Выработать
представление о конечном результате до начала проекта нелегко, но это единственный вариант.
Однако даже при наличии фундамента реализация проекта не похожа на легкую прогулку. Для успешной
реализации поставленных задач вам понадобится журнал требований продукта; к счастью, для его создания вам
не нужно составлять полный и детальный список требований. Не имеет смысла тратить время на создание гор
документации для проекта, который, возможно, не увенчается успехом. Создание журнала требований может
быть относительно быстрым примером коллективной работы, которая, при должной реализации, может
оказаться интересной.
В случае с Agile-проектами сдача первых результатов не должна восприниматься как приговор. Первый
результат представляет собой тот минимум, который необходим для того, чтобы запустить бизнес. Чем быстрее
вы сможете реализовать последующие этапы проекта, тем продуктивнее будут первые результаты. Не
откладывайте на завтра то, что можно сделать сегодня. Следите за развитием бизнеса и с удовольствием
включайтесь в новый мир Agile.
• Начните с конкретного и рационального видения. Избегайте неясных и нереалистичных целей.
• Бизнес-ценность превыше всего, поэтому убедитесь, что вы и ваши коллеги имеют общее представление о том,
что это такое.
• Любите ваш журнал требований продукта. Поддерживайте журнал на должном уровне и убедитесь, что в нем
хватает пользовательских историй, понятных всем.
• Определитесь с MVP! Успех проекта зависит от того, как хорошо и быстро вы справитесь с этой задачей.
• Выработайте критерии принятия и всегда держите в голове конечный результат.
Глава 4. Использование Канбана
Введение
Есть множество причин для того, чтобы перейти на Agile-подходы. Возможно, работа над проектами едва
движется или вообще не доходит до стадии выпуска продукта или стимулом стал услышанный где-то рассказ об
Agile. Причины, по которым вы пришли в Agile, могут различаться, но важный вопрос состоит в том, что нужно
откуда-то начинать. Ничто не помешает сразу нырнуть туда с головой, и есть успешные примеры именно такого
подхода, но бывают ситуации, когда сначала воду хочется попробовать – и нет ничего плохого в том, чтобы
применять Agile постепенно. Один из прекрасных вариантов такого начала – Канбан.
Канбан – это слово переводится с японского как «вывеска» или «рекламный щит» – был разработан как система
расписаний работ в автомобильной промышленности, а сейчас представляет собой одну из самых
быстрорастущих областей Agile. Его легко понять, просто применять и можно внедрить практически без затрат.
Большим плюсом Канбана является то, что он может быть использован как командами для полномасштабных
проектов, так и индивидуумами, чтобы контролировать объемы работ.
Не считайте Канбан просто очередной ступенькой на пути к Скраму. Да, это может быть частью путешествия по
Agile, но Канбан имеет свою собственную ценность. Это не дополнительная возможность или легкий путь. Это
прекрасный способ начать работу над проектом по-гибкому, и у Канбана есть масса скрытых достоинств.
Жизнь – игра. Если вы хотите добиться чего-то, вам стоит довериться своему сердцу и инстинктам и
сделать первый шаг.
Алисса Урбано (блогер)
Основы Канбана
Канбан появился как система расписания для автомобильной индустрии. Первоначальная задача Канбана
заключалась в обеспечении высокого уровня производительности на заводах «Тойота» посредством
предоставления возможностей для самосовершенствования и адаптации в ходе рабочего процесса. Со временем
Канбан трансформировался в набор общих принципов работы, использующихся в различных бизнес-секторах.
Несмотря на эти изменения, Канбан верен своей первоначальной философии; с течением времени он улучшался
и адаптировался, чтобы стать надежным и гибким инструментом. Изначальная простота основополагающих
принципов остается важным преимуществом, и основой Канбана является идея плавного перехода от
планирования к реализации. Суть Канбана в том, чтобы добраться из точки А в точку Я.
Это эволюция, а не революция. Канбан предлагает командам начать с существующего статус-кво и развиваться
уже оттуда, советуясь с людьми, уже вовлеченными в процесс.
Изменения происходят по обоюдному согласию, что увеличивает вероятность добровольного использования
Канбана. Помните три основополагающих принципа:
1. Определитесь с постановкой задачи.
2. Выработайте последовательные этапы задачи.
3. Следуйте согласованным процессам, ролям, обязанностям и условностям.
Будьте внимательны, если предложение перейти к Канбану исходит от команды, которая уже использует один из
фреймворков Agile.
Это может быть отличным знаком, потому что Канбан недостаточно оценен и его кажущиеся простыми процессы
скрывают в себе значительный потенциал. Однако есть люди, которые считают, что главной особенностью
Канбана является отсутствие необходимости планировать задачи или оценивать риски, и именно это
положительно отличает Канбан от Скрама.
Попытки забивать гвозди микроскопом не приводят ни к чему хорошему. Канбан не исключение.
В сущности, реализация Канбана состоит из пяти ключевых этапов: сначала необходимо визуализировать
рабочий процесс, затем определить рабочую нагрузку для каждого момента времени, а потом выработать меры
контроля, оценивания и улучшения рабочего процесса.
1. Визуализация рабочего процесса. Начните с представления рабочего процесса от статуса «сделать» до
статуса «сделано». Многие предпочитают включить как минимум еще один дополнительный этап в эту схему:
«работа в процессе». Другие стараются разбить рабочий процесс на серию процедурных, таких как план,
разработка, прототип, сборка, тестирование, имплементация, помимо начального и завершающего шагов.
2. Определение рабочей нагрузки. Попытки сделать все и сразу – лучший способ потерпеть неудачу как на
индивидуальном, так и на командном уровне. Канбан ограничивает количество задач, которые находятся в
работе в момент времени – этот показатель также известен как «работа в процессе» (work-in-progress WiP), –
чтобы добиться максимальной эффективности. На этом этапе достаточно руководствоваться здравым смыслом, и
со временем вы легко сможете выработать сбалансированную оценку WiP.
3. Контроль рабочего процесса. Ваша основная задача – добиться плавного перехода от начала и далее, вплоть
до завершающего этапа. Это обычно означает, что рабочий процесс должен иметь максимальную эффективность,
что, в свою очередь, позволяет добиться максимальной бизнес-ценности в кратчайшие сроки. При этом все ваши
действия должны быть воспроизводимы и логичны.
4. Конкретизация рабочего процесса. Конкретные представления о рабочем процессе исключительно важны
для объективного оценивания его успешности. При наличии коллективного понимания сути проекта гораздо
легче обсуждать его непредвзято и достигать консенсуса относительно его развития. В конце каждого этапа у
вас должны быть четкие критерии оценки его успешности и того, что вы будете делать следующим.
5. Совместная работа. Как только вы сосредоточитесь на рабочем процессе, у вас начнут появляться идеи о
том, как можно его улучшить. Показатель WiP играет ключевую роль в подобных дискуссиях, позволяя команде
сконцентрироваться на приоритетных задачах. Начальный максимум не более чем двух задач на человека
позволит идентифицировать проблемы, замедляющие рабочий процесс; после этого команда может
сосредоточиться на этих проблемах и решить их.
Канбан отлично подходит для

• введения в Agile с минимальными затратами и рисками;
• характеристики имеющихся рабочих процессов и идентификации проблем для их реализации;
• контроля над множественными и несвязанными задачами;
• ограничения количества задач для их успешной реализации;
• привития гибкого мышления команде.
К доске!
В центре метода – интересный инструмент: канбан-доска. Называть такие доски «визуализированным списком
дел» – слишком большое упрощение, но они могут стать хорошей отправной точкой. Доска – это графическое
представление работы от статуса «делать» к статусу «сделано». Простейший вариант канбан-доски состоит из
трех колонок: «Сделать», «В процессе» и «Сделанное». Такой простой формат универсален и подойдет любому
проекту.
Со временем вы станете быстрее определять, как распределить задачи по статусам работы. Популярным
является вариант, когда еще не принятые в работу идеи выделяются в отдельный столбец. Имеет смысл отделять
задачи со статусом «в процессе работы», если над ними работает не один человек. Также изменение статуса
каждой задачи в процессе работы должно быть понятным и заметным. Начните с четырех колонок: «Идеи»,
«Сделать», «В процессе» и «Сделанное». Границы между этими колонками обозначают условие для перемещения
задачи в следующую зону.
1. «Идеи» – сюда помещаются задачи, которые могут пойти в дальнейшую разработку, а могут и нет.
2. «Сделать» или «в процессе» – уже принятые идеи, насчет которых нужно определить, кто именно будет над
ними работать.
3. «В процессе» – как только исполнитель (или группа) для задачи определены, задача отправляется в эту
колонку, чтобы обозначить, что работа над ней идет.
4. «Сделанное» – полностью завершенная задача.
Рис. 4.1. Канбан-доска
Каждый год The Sunday Times публикует в декабре список под названием Fast Track 100. Этот список включает в
себя наиболее быстро развивающиеся частные компании Великобритании за последние три года. Критерием
оценки является рост продаж.
Однажды одна из этих компаний была выставлена на продажу, что вызвало незаурядный интерес в бизнес-
кругах. Интерес был настолько значителен, что повлек за собой ожесточенное противостояние инвесторов.
Следуя стандартной процедуре, каждый из инвесторов должен был оценить офисы и производственные мощности
в ходе экскурсии, которую проводил менеджерский состав. Маршрут экскурсии не был прописан заранее, но
каждый из главных менеджеров использовал канбан-доску для представления стратегических внутренних
проектов.
Это еще одно свидетельство того, что несколько колонок могут представить потенциал компании.
Определение «сделанного»
В управлении проектами одна из самых больших проблем – присвоение задаче статуса завершенной. Крайне
важно определить критерии того, когда задача выполнена, для каждой задачи. И всегда уточняйте способы
доставки продукта и способы оплаты. На этом этапе зачастую возникает непонимание – Agile заостряет на этом
внимание отдельно.
Единственный способ сделать все верно – советоваться с заказчиком или бизнес-представителем; это еще одна
крайне здравая идея, лежащая в основе Agile. Простой пример можно привести из области розничных продаж.
Когда вы заказываете новую посудомоечную машину в магазине, включает ли это доставку и установку?
Предполагается ли самовывоз, или, наоборот, сделка включает в себя все, даже быструю демонстрацию основных
функций? Когда местный водопроводчик приходит к вам с предложением сделать ванную вашей мечты, входит
ли в это определение облицовка стен плиткой?
Определение четких критериев «сделанного» — совместный процесс и зачастую достигается путем проб и
ошибок. Не пренебрегайте возможностью выделить время для определения этих критериев, но и не слишком
углубляйтесь в эту проблему – в процессе работы все шероховатости будут устранены.

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

Когда начальный формат канбан-доски определен, первый и, практически, важнейший аспект, который должен
быть определен, – будет ли это физическая доска или цифровой вариант. И то и другое имеет свои плюсы и
минусы. Доступ к виртуальной доске может быть осуществлен отовсюду – не нужно ничего, кроме смартфона или
планшета. Но, по нашему мнению, главная характеристика доски – это то, что она в центре внимания, в этом
плане физическую доску ничто не заменит.
Качественная и заметная доска притягивает взгляд, как камин в гостиной. Спустя некоторое время она станет
центром действий команды. Задачи планируются, перемещаются и определяются на доске. Кроме того,
физической доской заинтересуются и другие – руководству очень понравится наглядность доски и возможность
отслеживать ход работ напрямую, не через среднее руководящее звено и не по еженедельным отчетам, так что
ожидайте визита директора в течение недели.
Для начала достаточно будет старой доброй пробковой доски, ручек, бумаги для заметок и кнопок; или белой
доски и стикеров. Можно даже попробовать найти лучшее применение вон той доске объявлений, на которой
полтора года висит всеми забытый и совершенно неразборчивый график. Трех или четырех колонок будет
достаточно, но помните, что вам может понадобиться еще пространство.
Как сделать идеальную канбан-доску:
• Приобретите два рулона разноцветных обоев 3 × 1 метр, набор из 50 разноцветных карточек 12 × 8
сантиметров и 6 маркеров.
• Выберите центральную стену, которая хорошо видна всем сотрудникам из любой части офиса. Важно, чтобы на
стене было два-три метра свободного пространства и перед ней было достаточно места, чтобы там могло стоять
несколько человек.
• Приклейте две полосы обоев параллельно полу одну над другой.
• Разбейте получившееся пространство 6 × 2 на четыре колонки, используя хорошо заметные цветные полосы.
• Прикрепите карточку над каждой колонкой: «Идеи», «Сделать», «В процессе» и «Сделанное».
• Оставьте достаточно места для расширения доски; вам может понадобиться изменить количество колонок,
чтобы отобразить этапы рабочего процесса.
• Запишите задачи на карточки и прикрепите их на колонки «Идеи» или «Сделать».
• Переместите карточки в колонке «Сделать», пока они не окажутся в нужной последовательности.
• Готово!
Поместите вашу доску в приметное место, а не туда, где коллеги бывают редко. Доска скоро станет центром для
действий команды, поэтому убедитесь, что около нее осталось достаточно места для тех, кто будет к ней
подходить. Вне всяких сомнений, реальная доска понравится всем.
Будьте решительны: мы во всеуслышание заявляем, что переходим на Agile.
Дешевые и высокотехнологичные альтернативы

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

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

Список «Сделано» – ключевой для канбан-доски и используется для создания журнала требований в различных
гибких подходах. Все задачи, прямо или косвенно, должны быть направлены на выпуск продукта и достижение
высокой результативности рабочего процесса. Установка канбан-доски – важный этап, но совещания для
обсуждения хода работ – только часть рабочего процесса. Конкретные задачи должны быть сосредоточены на
результатах, а не на их обсуждении. Если задача на доске не направлена на конкретное действие, ее оттуда
нужно убрать.
Журнал требований в Канбане очень похож на журналы в прочих методологиях Agile, задачи так же
каталогизируются, как и пользовательские истории. Тем не менее в Канбане есть некоторые важные отличия:
• Задачи должны быть равного размера. Лучше иметь истории меньше, но примерно одинакового размера.
Разделение больших объемов работы на меньшие, приблизительно равные куски – подтвержденный метод для
улучшения производительности и прогнозирования времени завершения работы, как и сравнение аналогичных
показателей.
• Журнал требований обновляется регулярно, и в Канбане он куда более динамичен, особенно если работа
идет хорошо. В других средах Agile журналы требований изменяются часто, но не настолько. Журнал в Канбане
может обновляться каждый день.
Переход на Agile не всегда проходит гладко. Иногда даже получить проект для того, чтобы опробовать на нем
техники Agile, – недостижимая мечта. Но, даже если вы столкнулись с противниками гибких подходов, не
отчаивайтесь. Начните с малого и просто сделайте свою собственную канбан-доску. Все аспекты вашей работы
станут видны коллегам, что позволит упредить вопросы насчет того, над чем вы сейчас работаете.
Сомневающихся можно переубедить, продемонстрировав им на личном примере, как работает Канбан.
• Задачи выбираются, а не навязываются. Команда ориентируется не по следующей задаче, а по жесткому

расписанию – задаче будет присвоен наивысший приоритет, как только ресурсы для ее выполнения станут
доступны.
Перетасовка колоды
Как только вы обсудили идеи, сформировали доску и журнал требований, следующий шаг – организовать
разумную последовательность работы. Никто в здравом уме не расставит задачи в алфавитном порядке, но
просто удивительно, как часто приоритет задач присваивается в случайном порядке – в зависимости от того, что
вам нравится, или под давлением со стороны, или даже и то и другое, но совсем не по разумным и взвешенным
поводам.
Главная идея всех гибких подходов – обеспечение результата, и именно эта мысль должна быть основной в
определении приоритетности задач. Задача, которая направлена на результат, должна выбираться первой. Если
две разные задачи кажутся одинаково равными по бизнес-ценности – выбирайте ту, которая легче.
Не тратьте много времени на определение бизнес-ценности задачи – сравнения ее с другими должно быть
достаточно; на этом этапе значение имеет сравнительная оценка, а не детальный анализ. Проведите простой
подсчет расходов на реализацию задачи, включающий в себя такие факторы, как время, необходимые усилия и
затраты. Перемножив эти цифры, получите некий общий балл, который будет определять приоритетность
задачи.
Существует пять простых шагов для определения приоритета задачи:
• Разделите истории в журнале на равные по объему задачи.
• Присвойте каждой бизнес-ценность (от 1 до 10, где 10 – максимальная).
• Определите расходы на реализацию (от 1 до 5, где 1 – самая «дорогая» и 5 – самая «дешевая»).
• Найдите произведение «бизнес-ценность × расходы на реализацию» и упорядочите полученные результаты в
порядке убывания.
• Просмотрите полученный список с точки зрения здравого смысла!
– А еще вы обещали сварить мне чашечку кофе!
Одним из больших преимуществ канбан-доски является легкость перераспределения карточек во время

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

В идеальном мире каждая задача вверху списка «В процессе» должна перейти в список «Сделано», прежде чем
будет начата работа над следующей. На деле все не так просто, и большинство решает сразу несколько задач в
одно время. Это не многозадачность, а простая необходимость.
Канбан устанавливает лимит на количество задач, одновременно находящихся в работе. Это значение можно
применять и при одиночной работе, и для команд. Одному человеку не рекомендуется работать более чем над
тремя задачами в один момент времени; для команды это значение равняется количеству членов команды,
умноженному на два.
Периодически можно заметить тенденцию работать с удовольствием над задачей в самом начале и терять к ней
интерес по мере продвижения к завершению. Канбан справляется именно с этим установкой предела WiP. Это
помогает не утонуть во множестве задач, которые застряли в состоянии «завершено на 99 %». Обеспечение
надлежащей результативности работы невозможно без ее завершения.
Для успешного применения Канбана установление предела WiP совершенно необходимо. Без этого колонка
«Сделано» на доске так и не превратится во впечатляющий список завершенных дел. Предел WiP обеспечивает
непрерывность рабочего процесса вплоть до его завершения и получения выплат. Члены команды будут
вынуждены разбираться со сложными задачами, а не задвигать их в дальний угол.
Постоянное совершенствование процесса работы является важной частью Канбана и в основном будет
происходить само по себе. Предел WiP вынуждает команды быть более вдумчивыми, когда это необходимо, и
понимать, что тормозит производственный процесс. Это создает атмосферу постоянного поиска улучшений и
всевозможных корректировок, чтобы машина работала более плавно, – прямо как в индустрии, из которой
Канбан появился.
Канбан страдает от
• Ни от чего, если подойти к нему с умом.
Управление проектами с Канбаном

Еще один ключевой тезис Agile – непрерывный выпуск продукта. Не нужно долго ждать улучшений – продукт
выпускается постоянно. Канбан схватывает самую суть этой идеи, потому что каждая часть проекта
обрабатывается по отдельности. Это и будет лакмусовой бумажкой для идеальной пользовательской истории.
Сохраняется ли в ней смысл, если осуществить ее отдельно? Порадует ли она в таком виде кого-то?
Конечно, и весь проект можно осуществить, использовав Канбан. Проект можно разделить на меньшие части или
пользовательские истории, работа над которыми будет вестись поэтапно. Канбан побуждает бизнесменов
рассматривать и составные части проекта, и ориентироваться на выпуск таких продуктов, которые обеспечат
отдачу сами по себе, а не только как часть общего проекта. В этом случае отличным примером служит
добавление новых характеристик к уже созданному продукту.
Жизнь, проведенная на краю пирса, – это жизнь, полная сожалений и страха.
Райан Лилли (бизнес-спикер, автор)
Одна из прекрасных особенностей Канбана – это то, что он приносит минимальные изменения в статус-кво.
Отталкиваясь от уже существующих принципов рабочего процесса, гораздо легче избежать ситуаций, когда
процесс окажется нарушен или его положительные стороны окажутся утеряны. Канбан отдает предпочтение
эволюции, а не революции, стремясь не потерять то, что уже есть.
Изменения, привносимые Канбаном, на первый взгляд незаметны, но их влияние сложно переоценить. Кто в
здравом уме будет спорить с ограничениями на число рабочих задач? Использование Канбана приводит к
непосредственным улучшениям в работе и нередко сопряжено с рядом внезапных озарений. Возможно, вы
столкнетесь с несколькими фомами неверующими, но результаты очень быстро сумеют их переубедить.
Переход к новой революционной методике работы нередко оказывается неординарной задачей. После пары
бокалов вина довольно легко убедить собеседника в преимуществах Agile, но на практическом уровне
адаптировать работу коллектива к гибким подходам сложнее. Некоторые люди сумеют адаптироваться очень
быстро и будут рады это сделать, но остальных придется подталкивать в нужном направлении. Вопрос
заключается в том, как.
Канбан – отличный способ это сделать. Его легко понять и еще легче использовать. Несмотря на свою легкость,
Канбан не является компромиссным решением. Он вполне способен фундаментально изменить командную
работу и продемонстрировать преимущества Agile. Использование Канбана может быть самостоятельным
решением или промежуточным этапом на пути к Скраму или любому другому гибкому фреймворку.
И последнее важное замечание: Канбан очень легко понять и применять, но его также довольно легко применять
неправильно. Не стоит обманываться его простотой. Начать использовать Канбан довольно просто, но, чтобы
извлечь из него максимум эффективности, понадобится приложить некоторые усилия.
• Канбан-доска – центр всего проекта.
• Начните с визуализации рабочего процесса.
• Определитесь с пределом WiP для наибольшей эффективности.
• Несмотря на кажущуюся простоту, Канбан – исключительно мощный инструмент.
• Канбан может быть вашим пунктом назначения или остановкой на пути к чему-то большему.
Глава 5. Просто лучшее: основы Скрама
Введение
Скрам (Scrum) стал популярен, потому что он работает. Правда, эта техника достигла нынешней известности не
мгновенно. Скрам развился как технология разработки продуктов в середине 1980-х годов в Японии и был
усовершенствован в США в 1990-х годах. Скрам пробовали, писали о нем – и статьи, и просто в блогах, – но
наиболее важным было то, что в процессе этого он постоянно улучшался. В конечном итоге была получена
какая-то критическая масса успешных проектов, и про Скрам заговорили.
Теперь Скрам занял свое заслуженное место среди других фреймворков Agile и остается самым популярным
прежде всего потому, что он имеет достаточно директивный характер, но не топит команду в обременительных
правилах, процессах и догмах. Более того, это один из самых удачных способов начать работу с новичками в
Agile, поскольку Скрам четко определяет роли и обязанности, но при этом обеспечивает достаточную гибкость в
их реализации, чтобы позволить своим пользователям чувствовать поддержку, но и не запутаться.
В настоящее время Скрам является наиболее распространенным фреймворком Agile, поэтому есть много
вариантов, чтобы научиться ему – от сертифицированных и несертифицированных учебных курсов до
внутригруппового или индивидуального обучения и множества вариантов для самообразования. Опытные
пользователи согласны с тем, что легко начать работать в Скраме, но нелегко в нем преуспеть, потому так важно
хорошо разобраться в ключевых моментах.
Нет плохого способа начать работать со Скрамом – главной ошибкой будет вообще не пробовать.
Рис. 5.1. Фреймворк Скрам
Рис. 5.2. Цикл спринта
Фреймворк
Как и все хорошие идеи, Скрам часто интерпретируется неверно. Чтобы снизить вероятность того, что идеи будут
поняты неправильно, Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) создали «Руководство по
Скраму» (Scrum Guide). Оно постоянно обновляется, доступно бесплатно на www.scrumguides.org и является
единственным документом, объясняющим суть Скрама. Изменения вносятся редко; весь текст занимает 16
страниц вместе с содержанием и стоит того, чтобы с ним ознакомиться.
Скрам объединяет принципы «бережливого управления» и принципы Agile. Это не инструмент управления
проектами, это принципы организации выпуска продукта – между этими двумя понятиями есть важные
различия. Когда все идет хорошо, легко даже позабыть, что используется Скрам. Он предназначен только для
поддержки хода работ, и об этом важно помнить.
Конечная цель – выпуск качественного продукта с помощью Скрама, а не получение идеально работающего
Скрама. Скрам только помогает в работе, но для этого невозможно использовать только его часть, придется
работать со всем сформированным пакетом целиком.
• Теория: главное, знать фундаментальные принципы, не нужно особенно в нее углубляться.
• Роли команды: Владелец Продукта, Скрам-мастер и команда разработки: это основные роли.
• События: спринты, планирование спринтов, обзор итогов спринта и ретроспективное совещание со
знаменитыми ежедневными дневными встречами в середине.
• Артефакты: журнал требований (бэклог) продукта, журнал требований спринта и другие.
Согласно Шваберу и Сазерленду, Скрам – это фреймворк, с помощью которого люди могут решать сложные
проблемы и организовывать выпуск продукта продуктивно, креативно и с наибольшей выгодой.
Мы не могли бы дать лучшее определение.
Управляйте не временем, а приоритетами.
Деннис Уэйтли (мотивационный спикер)
Самоорганизующиеся команды
В основе Скрама лежит концепция самоорганизующейся команды – самоуправляющейся группы экспертов,
которая необходима для выполнения работы. Три роли в команде Скрам – Владелец продукта, Скрам-мастер и
команда разработки – предназначены для того, чтобы каждый мог работать по отдельности, не наступая другим
на пятки, но не настолько обособленно, чтобы роли стали негибкими и неспособными адаптироваться к
изменениям.
Владелец продукта
В начале списка команды находится Владелец продукта (Product Owner, PO), который единолично решает, в чем
заключается суть проекта и как должен выглядеть конечный результат. Владелец продукта воплощает в себе как
бизнесмена, спонсирующего проект, так и потребителя, который использует его результаты. Стратегически
деньги концентрируются здесь.
Когда у представителя бизнеса появляется идея нового проекта или услуги, он понимает, что для практической
реализации ему придется потратить немало денег и времени. Команда менеджеров или стратегов, которые
работают на бизнесмена, с удовольствием возьмут деньги, но им нередко не хватает времени на реализацию
проекта в той мере, в которой им хотелось бы. Любая попытка предоставить команду проекта самой себе
обречена на провал и является полным антиподом Agile. Разумным решением будет назначить представителя
бизнесмена и делегировать ему контроль над процессом разработки. Эта идея далеко не нова, но только гибкие
подходы сумели превратить функцию Владельца продукта в форму искусства.
Владелец продукта представляет бизнес во всех его проявлениях, определяя масштаб и направление нового
проекта. Эта роль не теряет своей ценности с окончанием проекта, так как она представляет также интересы
конечного пользователя. Владелец продукта всегда заботится об извлечении максимальной выгоды, представляя
интересы как бизнесмена, так и конечного пользователя и гарантируя пользу для обоих.
В то же время бизнесмены и конечные потребители – явления не одного порядка. У бизнеса всегда есть
значительные причины для новых разработок, которые основаны на необходимости возврата инвестиций, будь то
финансовые или какие-либо иные вложения. Хотя у одного проекта может быть несколько заинтересованных
сторон от бизнеса, их количество неизбежно будет уступать количеству пользователей продуктом. Основной
загвоздкой является то, что владелец продукта должен равноценно представлять оба лагеря.
В этом отношении Владелец продукта подобен политику, идущему по лезвию бритвы. С одной стороны, он
должен действовать в рамках закона и политики компании, стремясь соблюсти интересы бизнеса, который он
представляет. Обычно эти интересы вращаются вокруг небольшой группы людей или одного человека.
С другой стороны, Владелец продукта должен представлять интересы потребителей. Вряд ли когда-либо ему
доведется встретиться со всеми потребителями продукта, однако он может встретиться со статистически
репрезентативной группой и принять решение, основываясь на том, что будет лучше для основного большинства.
От владельца продукта зависят все ключевые решения: хотя эти решения могут лоббироваться всеми
участниками проекта и варьироваться в зависимости от приоритетов, но именно за владельцем продукта
остается последнее слово. Эти решения, которые относятся как к бизнесу, так и к конечным пользователям,
должны обязательно заноситься в журнал требований – бесценный инструмент, использующийся владельцем
продукта для принятия решений.
Ответственность исключительно важна на этапе перехода от журнала требований к рабочему продукту. У
команды разработчиков будет немало вопросов, и владелец продукта должен быть готов на них ответить, чтобы
быть уверенным, что проект двигается в верном направлении и команда принимает правильные решения. Кроме
того, бизнесменам время от времени требуется убедиться в том, что их деньги расходуются с пользой, и владелец
продукта должен уверить их в том, что стратегические задачи проекта будут выполнены.
Это самая сложная и важная роль в скрам-команде. В теории она может показаться легкой, но на практике
требует смекалки и ясного понимания целей проекта. Как и в целом со Скрамом, быть владельцем продукта не
слишком сложно, но еще легче быть плохим владельцем продукта.
Хороший Владелец продукта всегда заботится об извлечении максимальной выгоды, представляя интересы как
бизнесмена, так и конечного пользователя и гарантируя пользу для обоих.
В идеале Владелец продукта должен быть маяком для скрам-команды, но когда что-то идет не так, в этом
нередко вина именно Владельца продукта.
Скрам-мастер
Скрам-мастер – главный организатор проекта. Его часто называют первым помощником, потому что он разделяет
власть с владельцем продукта, заботится о нуждах других и помогает участникам проекта развиваться. Скрам-
мастер – полная противоположность руководителю проекта, который ведет дела, подчиняясь строгой иерархии.
Скрам-мастер – переговорщик, который помогает самостоятельной команде с производством работающего и
ценного продукта. На первый взгляд это может показаться легкой ролью, но это не так.
Скрам-мастер несет ответственность за всю коллективную работу. Он убеждается в том, что встречи проходят
вовремя, что на них присутствуют правильные люди, что информация, необходимая для принятия правильных
решений, доступна для участников проекта и что цели и задачи проекта реализуются. В случае необходимости
Скрам-мастер может помочь владельцу продукта в общении с бизнесменами и нередко помогает владельцу
продукта придерживаться рабочего плана.
Более того, Скрам-мастер следит за тем, чтобы все работы выполнялись соответствующим образом – например,
написание пользовательских историй, – и минимизирует любые отвлекающие факторы для команды.
Скрам-мастер – это масло, смазывающее маховик работы любой команды. Он работает вместе с командой,
поэтому из первых рук получает информацию о том, как идет разработка проекта, и старается найти способы,
как улучшить этот процесс.
Самая важная часть работы Скрам-мастера – это быть инструктором в вопросах гибких подходов для владельца
продукта и команды, а иногда даже для организации, а также фокусироваться на долгосрочном планировании,
эффективных отчетностях и получении обратной связи.
Если Владелец продукта – это мозг проекта, то Скрам-мастер отвечает за ежедневное функционирование
проекта, создавая наилучшее окружение для работы команды. Главная задача – убедиться в том, что команда
способна справиться с настоящей работой.
Скрам-мастера – невоспетые мастера на все руки: посредники, помощники, советники и разрешители проблем.
Хороший Скрам-мастер делает работу над проектом намного проще.
Команда разработки
В Agile «команда разработки» – собирательное понятие, обозначающее всех, кто нужен, чтобы работа была
выполнена. Основная роль команды – взять идеи из журнала требований и претворить их в жизнь. Команда
способна самоорганизоваться – это означает, что каждый участник полагает остальных профессионалами,
способными выполнять свою работу хорошо без дополнительного микроменеджмента.
Команда разработки – это двигатель проекта, это талантливые и многоплановые люди, полностью
сосредоточенные на выпуске продукта. Ключевой способностью команды является обладание смежными
навыками – это означает, что ситуации, когда кто-то один способен сделать работу в одиночку, должны возникать
редко: члены команды используют свои знания, чтобы помогать друг другу.
Само собой, команда разработки должна быть мотивирована на наилучшие результаты. Контроль работы
осуществляется самими членами команды, и никто, кроме самой команды, не знает, может ли она работать еще
лучше. У Владельца продукта есть видение проекта, Скрам-мастер предоставляет необходимую помощь, но за
результаты своей работы члены команды отвечают перед собой и друг другом.
Собирать огромную команду неэффективно и нерационально. Общение, отношения и, следовательно,
работоспособность команды страдают, если она слишком велика. «Руководство по Скраму» советует
оптимальный размер команды в шесть человек – плюс-минус трое; время от времени эти рекомендации
варьируются.
Исследования подтверждают эту мысль, так что не позволяйте команде разрастись до двузначного числа.
Ключевые Скрам-события
События в Скраме простые, однозначные и всегда ограничены по времени. Они предназначены для создания
структуры для проверки и адаптации участников к рабочему процессу без добавления бессмысленных
формальностей. Скрам декларирует, что для правильной работы необходимо выполнить все пять мероприятий;
отсутствие любого из них означает, что вы работаете не по методологии Скрам, и приводит к неэффективным
методам работы, отсутствию прозрачности и путаницам. Обычно, если команда разочарована неким Скрам-
событием и оно кажется бесполезным, это значит, что что-то идет не так.
Пять Скрам-событий:
• спринт – общий цикл для остальных событий;
• планирование спринта – происходит в самом начале работы;
• ежедневная летучка (дейли Скрам) – происходит каждый день (без исключений);
• обзор итогов – проводится в конце спринта;
• ретроспектива – подводит итоги.
Спринт
Спринт – жестко фиксированный по времени, от одной до четырех недель, временной период (time-box) для всех
остальных Скрам-событий. Обычно команды выбирают длину спринта в две недели, но идеальной
продолжительности нет – во всех вариантах будут присутствовать и плюсы, и минусы. Если есть сомнения, лучше
начать с одно- или двухнедельного спринта и посмотреть, как пойдут дела.
Спринты могут рассматриваться как возможность реализовать мини-проекты или могут быть обычной практикой
в большом проекте по разработке, но не стоит часто изменять продолжительность новых спринтов. Поначалу
ориентируйтесь на постоянство. Спринт начинается с решения о том, что именно поступает в работу, и
заканчивается подведением итогов о созданном продукте. Ретроспектива поможет команде оценить
результативность совместной работы и предложить улучшения.

В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и
другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.
Не распыляйтесь, тратя время на другие варианты, – идите по проторенному пути.
Планирование спринта
Планирование происходит в начале каждого нового спринта. Это возможность для команды просмотреть
пользовательские истории, которые Владелец продукта уже уточнил и распределил по приоритетности, и
решить, в каком порядке обрабатывать задания. Все обсуждения насчет сложности, рисков, размера,
трудозатрат, бизнес-ценности и прочих нюансов проходят на этом этапе. Цель команды – во всем разобраться и
прийти по этим вопросам к согласию.
Главной характеристикой планирования является то, что основное управление отдано команде, а Скрам-мастер
только помогает. Раньше руководитель проекта просто говорил команде, что должно быть сделано и когда, в то
время как планирование в Agile позволяет команде решать, что должно быть снято из списка приоритетных
задач, что позволяет специалистам планировать реальные сроки выполнения.
Это не значит, что нужно выбрать легкую цель, – Скрам-мастер для того и работает вместе с командой, чтобы
сложная конечная цель была достижимой, – но последнее слово все равно остается за командой, если они
говорят, что за данное время невозможно выполнить больше задач.
Также во время планирования нужно убедиться в том, что каждая задача в журнале требований должна быть
проверена на понимание перед включением в спринт. Очень важно, чтобы бизнес отметил этот момент до того,
как работа начнется, – любые недопонимания нужно устранять; именно для этого тут и присутствует Владелец
продукта. Старайтесь не начинать спринт с сомнительных обещаний.
И как только пользовательские истории, которые войдут в спринт, согласованы – для команды и Скрам-мастера
заканчивается время обсуждений и раздумий и начинается работа.
Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже
принимают в этом участие.
• Начните с четкой цели спринта. Всем должно быть ясно, в чем эта цель заключается и как может быть
измерена.
• Выберите пользовательскую историю с наивысшим приоритетом. Проверьте критерии успеха – всем они
должны быть понятны.
• Спросите у команды, может ли эта история быть воплощена в течение этого спринта. Если ответ «да» и на этот
счет ни у кого нет серьезных сомнений, тогда история включается в этот спринт.
• Если ответ «нет», разберитесь в причинах. Например, если история слишком большая, ее следует разбить на
подзадачи. Если ответ все еще «нет», продолжайте обсуждение.
• Повторяйте этот процесс, пока журнал спринта не станет, возможно, непростым, но главное – выполнимым.
• Владелец продукта должен подтвердить, что журнал спринта соответствует цели спринта. Если нет, работайте
сообща с ним, чтобы выяснить, чего именно не хватает.
• Сделано!
Ежедневная летучка
Ежедневная летучка, или дейли скрам (иногда стендап-встреча) – небольшая встреча, длящаяся не более
пятнадцати минут, но происходящая каждый день, – сориентирована на текущей работе. Чем раньше команда
привыкнет к такому графику, тем лучше. Главная идея летучки – сделать так, чтобы члены команды
предоставляли друг другу информацию о работе каждого из них каждые 24 часа, чтобы быть уверенными: работа
сосредоточена на текущих задачах и выпуске продукта в целом.
Спринты – мини-проекты, которые, как и большие спринты, редко проходят гладко. Ожидайте этого – и сможете
использовать эти летучки для того, чтобы разрешать любые возникшие проблемы. Здесь в игру вступает Скрам-
мастер – его роль в том, чтобы предложить решения для возникших трудностей, препятствующих дальнейшей
работе. Это не означает, что с проблемами нужно разбираться с наскока, но в случае ежедневного совещания
можно рассчитывать на совет и помощь коллег.
– Да, иногда наши совещания бывают весьма динамичными
Ежедневное совещание придерживается очень простого формата: каждому члену команды задается три вопроса.
• Что вы делали вчера? Отслеживание прогресса.
• Что вы будете делать сегодня? Обсуждение плана.
• Какие затруднения у вас возникают? И это – самый главный вопрос.
Просто собрать всех на ежедневную Скрам-встречу вовремя и следить, чтобы все были сосредоточены на
обсуждении, – уже работа сама по себе. Любая встреча может пойти неправильно, тем более если график работ
очень плотный. Скрам-мастер должен убедиться в том, что команда не отвлекается от участия в совещании и что
все сосредоточены на рабочих вопросах. Это может показаться легким и само собой разумеющимся – и так и
будет, если все сфокусированы на том, что происходит. Скрам-мастер не должен быть нянечкой и ставить
непослушных в угол. Ну по крайней мере, не буквально.
Ежедневная летучка – барометр, указывающий на состояние спринта, эффективность команды и множество
других вещей. Опытному наблюдателю, такому как тренер, достаточно будет посетить только одну или две
летучки, чтобы уже оценить успешность работы над проектом. Конечно, даже у специалистов такие ежедневные
встречи редко проходят полностью гладко, но когда что-то постоянно мешает нормальному ходу встречи – это
серьезный повод обеспокоиться, особенно если это происходит постоянно.
Чтобы ежедневная Скрам-встреча прошла как надо, нужно быть бдительным. В конечном счете все зависит от
людей, вовлеченных в процесс, – и есть определенные типы характера, которые способны серьезно помешать:
• Шумный наблюдатель – тот, кто не входит в состав команды, но будет пытаться встать и вмешаться в
обсуждение. Скрам-мастер должен объяснить, что любые посторонние могут только наблюдать! Любые
замечания можно выслушать потом.
• Опоздавший – приходит на встречу поздно, а затем просит пересказать ему то, что он пропустил. Не делайте
этого (разве что это совершенно необходимо), поскольку уступка только поощрит эту дурную привычку.
• Отвлекающий – прерывает встречу, часто непреднамеренно, но всегда с отрицательными последствиями.
Совет: придерживайтесь сценария; все послушают о вашем неудачном свидании в другое время.
• Скептик – не хочет находиться на встрече и, как следствие, ничем не помогает. Либо вы тут, либо нет, потому
что все в команде должны играть по правилам.
• Тихоня – даже если кто-то немного застенчив, он должен выступить. Правило: каждый вносит свой вклад. Это
не тот случай, когда молчание – золото.
• Футуристы – пытаются заглянуть в будущее, вместо того чтобы сосредоточиться на здесь и сейчас. Оставьте
все концепты Владельцу продукта и сконцентрируйтесь на следующем выпуске.
• Непрошеный помощник – любой, кто хочет проводить стендап-встречу, разрешая проблемы других.
Поощряйте совместное обсуждение проблем, но возможные варианты разрешения трудностей нужно пробовать
уже после совещания.
Следите за такими нарушителями, особенно за теми, кто проявляет несколько черт из этого списка.
Обзор итогов
Обзор продукта, более известный как обзор спринта, является возможностью для команды показать плоды своих
трудов владельцу продукта. Есть много мнений о том, что именно должен включать в себя обзор, но, по существу,
это всего лишь способ получить жизненно важную обратную связь о том, что команда сделала. Обратная связь
служит таким целям:
• Облегчение контроля над выпуском продукта: команда знает, является ли то, что они делают, в корне
верным или нет.
• Обзор стратегических целей: проверка выполненности целей спринта с возможностью обсудить любые
проблемы.
• Удовлетворение ожиданий заинтересованных сторон: уже на ранней стадии разработки они видят, что
получат! И никаких сюрпризов в последнюю минуту.
Есть утверждающие однозначно: в конце спринта пользовательские истории должны превратиться в
тестируемый, потенциально полезный продукт, и это правильно и достойно восхищения. Но даже если все
складывается не так замечательно, владельцу продукта все равно стоит все просмотреть. Лучшая стратегия в
данном случае – честность, и не стоит скрывать никакие проблемы или неудачи. Рассматривайте их как
возможность провести соответствующую переоценку WiP.
Обзор итогов открыт для всех (в разумных пределах, конечно). Команда со Скрам-мастером представляет работу,
которую они согласились делать на этапе планирования спринта. Все заинтересованные стороны и конечные
пользователи должны также присутствовать на этой сессии, но в основном просто в качестве наблюдателей, а не
активных участников.
Не пренебрегайте организацией – зарезервируйте подходящее помещение со всем оборудованием, необходимым
для презентации, настройте его заранее и подготовьте саму презентацию. Будет очень неприятно, если результат
двухнедельных трудов будет испорчен неудачной презентацией.
Придерживайтесь простого формата и не слишком углубляйтесь в детали – представьте, что среди слушателей
сидит ваша пожилая и нетерпеливая тетушка Роуз и вам нужно говорить понятно, но в то же время
профессионально. И не слишком увлекайтесь – нет ничего плохого в том, чтобы управиться за 15 минут.
• Скрам-мастер представляет команду, определяет обстановку и озвучивает согласованную цель спринта.
• Все карточки помещаются на стол, а Скрам-мастер поясняет, все ли было закончено, а если нет, то почему.
• Скрам-мастер обновляет пользовательские истории, входящие в спринт.
• Пользовательские истории разбираются одна за другой. Член команды, ответственный за историю,
рассказывает о том, что было сделано. Владельца продукта просят прокомментировать каждый такой мини-
отчет.
• Подчеркивается еще что-то актуальное, включая второстепенные функции, достойные упоминания, и любые
связанные с ними вопросы.
• Скрам-мастер дает Владельцу продукта последний шанс прокомментировать или внести какие-то предложения,
прежде чем принимать решение о том, готов ли он принять рабочий пакет.
• Прочим присутствующим предоставляется возможность высказать свое мнение.
• Скрам-мастер утверждает дату следующего обзора итогов, формально закрывает сеанс и, если все прошло по
плану, облегченно выдыхает.
Ретроспектива
В конце каждого спринта, как только обзор итогов закончен и Владелец продукта и прочие заинтересованные
уходят, довольные, команда собирается вместе, чтобы обсудить прошедшую работу. Это называется
«ретроспектива», и она проводится непременно, даже если все прошло точно в соответствии с планом. Можно
многое почерпнуть как из ошибок, так и из гладко прошедшей работы. Никогда не предполагайте, что это пустая
трата времени, и не бросайтесь тут же в следующий спринт.
Конечно, эта фраза повторялась тут уже не раз, но сделать это просто, сложно – сделать хорошо. Основная цель
ретроспективы – объединить команду для разговора о том, как они работают, взаимодействуют друг с другом и
обеспечивают выпуск продукта. Это прекрасная возможность проиллюстрировать принципы Agile – то, как
команда работала вместе и как находила способы улучшить продукт, проводила проверки и адаптировалась. Это
краеугольный камень для самоуправления и самоорганизации, и поэтому ретроспектива должна быть принята
всерьез. Как и другие события Скрама, она является обязательной, поэтому не совершайте типичную для
новичка ошибку и не считайте ее бесполезной.
Сосредоточивайтесь на том, что впереди, а не оглядывайтесь постоянно назад.
Колин Пауэлл (бывший государственный секретарь США)
Результатом ретроспективы будет набор конкретных действий, которые помогут команде улучшить ее
способность выпускать качественный продукт. Нет необходимости генерировать длинный список идей; несколько
хорошо отобранных рекомендаций будут реализованы с куда большей вероятностью, чем множество сырых и
умозрительных предложений. Чтобы максимально увеличить шансы на успех – выберите не более пяти идей.
Во время ретроспективы стоит записывать и сохранять информацию. Соберите команду в помещении, где есть
стикеры, маркеры и доска для записей. Предложите всем записать все мысли насчет последнего спринта.
Каждый пункт стоит помещать на один стикер и читать вслух, помещая на доску.
Как только команда все записала, предложите просмотреть записки и сгруппируйте их по темам. Каждой теме
дайте название.
Обсудите темы в порядке их важности и определите четкий план действий по каждой теме, назначив члена
команды, который будет за этот план ответственен, – это вовсе не означает, что этот член команды должен в
одиночку разрешить проблему, он просто следит за тем, чтобы план так или иначе выполнялся. Если вы уделяете
время ретроспективе – постарайтесь сделать так, чтобы результаты были осязаемыми.
Так как ретроспектива проводится в конце каждого спринта, не генерируйте много идей. Ориентируйтесь на
разрешение одной или двух больших или пяти малых проблем, не более.
Артефакты Скрама
Артефакты Скрама – это элементы, необходимые команде для успеха. Обязательная большая тройка – это журнал
пожеланий продукта, журнал пожеланий спринта и диаграмма сгорания задач. Есть и другие инструменты, но
эти основные. Большинству более чем хватает и этих трех.
Журнал требований продукта

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

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

Одной из самых сильных сторон Скрама является метрика текущих задач. Вы можете навсегда попрощаться с
долгими днями споров о прогрессе или замораживании работ в состоянии «практически готово». Диаграмма
сгорания задач – это простое и наглядное отображение прогресса, и она используется командой для
отслеживания хода разработки продукта во время спринта.
Необновляющийся журнал требований продукта – однозначный признак того, что что-то идет не так; изменения
естественны и более чем ожидаемы. Но и другая крайность – когда журнал обновляется излишне часто – тоже
указывает на проблемы.
Когда вы обновляете статус выполненных в спринте работ, реальный прогресс будут отображать только
полностью завершенные задачи. Те, что закончены на 25 %, 50 % или 75 %, в данном случае не учитываются.
Особенно будьте внимательны в случае задач, которые завершены на 99 %.
Переход на Agile похож на обучение вождению. Пока вы на пассажирском сиденье, все выглядит довольно
просто; если вникнуть в основы, главные принципы тоже будут для вас ясны. Но только сумасшедший запрыгнет
за руль и устремится на улицу с интенсивным движением после того, как прочтет несколько статей в интернете.
Разумный человек сначала как минимум разберется с теорией. Эта книга – как правила дорожного движения.
Прежде чем применять Скрам, нужно не только разобраться в его основах, но и понять, как именно все элементы
методологии работают вместе. Можно встретить так называемые Скрам-команды, работающие без каких-то
ключевых ролей или артефактов; некоторым из них это даже вполне удается. Но для стабильного успеха
необходимо предварительно всесторонне изучить теорию. Не забывайте: причина номер один всех аварий на
дорогах – неопытные водители.
• Скрам популярен, потому что он работает. Не думайте, что вы можете игнорировать важные составляющие и
все еще добиваться нужного результата.
• Вам нужны четкое видение и журнал требований проекта; убедитесь в том, что только Владелец продукта
определяет их содержание и расставляет приоритеты.
• Выпускайте продукт с бизнес-ценностью в конце каждого спринта. Единственное мерило успеха – работающий
продукт.
• Разрабатывайте рабочие практики, требования, критерии успеха как одна команда. В идеале эта команда
должна состоять из специалистов различных профилей.
• Избегайте чрезмерного давления на команду разработки продукта. Команда, работающая в щадящем режиме,
выдает лучшие результаты, чем команда, находящаяся в постоянном напряжении.
• Лучший способ начать – это просто начать!
Глава 6. Пора в путь: Скрам день за днем

Введение
Скрам – отличный инструмент, но все же это лишь инструмент. Все его достоинства проявляются тогда, когда он
в работе. И как с любым инструментом, чем больше вы им пользуетесь, тем более искусно его применяете.
Мастерство приходит с практикой, и Скрам очень соответствует этому утверждению – ведь он ориентирован на
постоянное повторение циклов.
Доведение до совершенства не способствует прогрессу, так что не стоит планировать применение Скрама до
мелочей еще до того, как вы начали его использовать. Намного лучше изменять тактику на ходу. Вы можете
столкнуться с чем-то, что кажется не совсем очевидным, и придется подстраиваться уже в процессе. Или не
совсем правильно будет составлена команда, или скептично настроенные коллеги будут излишне мешать. Со
временем большие проблемы будут решены, и на их место придут меньшие, но решаемые куда легче.
Если вы не будете привносить свои изменения, пусть даже небольшие, то вы не поняли сути. Случается так, что
желание менять что-то отступает, сменяясь готовностью принимать неудобный статус-кво. Иногда боязнь
раскачивать лодку препятствует даже незначительным изменениям. Иногда, что может показаться абсурдным,
люди даже считают текущее положение дел близким к идеальному!
Примите цикл жизни Скрама, но не идите ради этого на компромиссы или отказ от изменений. С одной стороны,
этапы Скрама очень легко предсказать, так как в теории они остаются одними и теми же, но в то же время на
практике они всегда очень сильно различаются.
Нет! Не пробуй. Сделай.
Мастер Йода
Подготовка
Часто люди, не понимающие гибкого способа мышления, считают, что в Agile не предполагается никакого
планирования. Но это не касается ни гибких подходов в целом, ни Скрама в частности. Планирование имеет
первостепенное значение, и это справедливо не для единичных случаев, а постоянно. Скрам-мастер и владелец
продукта определяют, что нужно сделать, а что реализовать будет невозможно. Все эти обсуждения отражены в
журнале требований продукта. Он является самым важным артефактом, основой работы над любым проектом.
Часто наполнение журнала напрямую отражает то, как идет работа над проектом, и наоборот. Даже самые
лучшие команды не смогут добиться впечатляющих результатов без журнала требований продукта, и он
постоянно пересматривается и обновляется в зависимости от актуальной информации.
Девяносто девять из ста Скрам-команд начинают свой первый спринт на излишне оптимистичной ноте и не
особенно уделяют внимание планированию. Либо пользовательские истории не до конца проработаны, либо не
сформирован план действий, либо не хватает критериев принятия – а то и все вместе. Девять из десяти команд
повторят те же ошибки и на втором спринте.
Избегайте такого.
Доработка журнала
Раньше доработку или уточнение журнала называли «причесыванием» (grooming) по аналогии с причесыванием
волос, но со временем термин сменился по очевидным причинам. Кто-то продолжает использовать это старое
название, но вне зависимости от этого сама практика поддержания журнала требований продукта в актуальном
состоянии только положительно сказывается на бизнесе и впоследствии на конечном пользователе.
Окончательное решение насчет распределения приоритета задач принимает владелец продукта, поэтому, так
как это творческий процесс, точные рекомендации тут дать сложно. Не пытайтесь расположить все в идеальном
порядке. Куда важнее поддерживать актуальность бизнес-требований, например пользовательских историй.
Встречи с обсуждением всех доработок журнала и подготовки пользовательских историй для спринта должны
проходить регулярно, и в идеале на них должны присутствовать по одному представителю каждой дисциплины из
команды.
Некоторые команды просматривают журнал на предмет возможных обновлений каждый день, другие – намного
реже. Но отсутствие доработки, без сомнений, приведет к проблемам на ближайшем спринте. Постоянная работа
над журналом обязательно принесет свои плоды, но тут необходимо достичь определенного равновесия.
Некоторые спринты будут посвящены реализации необходимых функций, а не тому, что полагают важным на
данный момент бизнесмены.
Владелец продукта отвечает за качество пользовательских историй и состояние журнала требований продукта.
Если он делает свою работу хорошо, планирование спринта пройдет гладко. Если нет, то в ходе встречи по
планированию скрипта постоянно нужно будет отвлекаться на уточнения.
Критерии принятия
Самый быстрый способ для команды разработки начать работу не так – это не до конца разобраться в
требованиях.
Явное недопонимание – самая большая проблема, но, как правило, с нею разбираются быстро во время сеансов
доработки журнала. Однако неявные недоразумения встречаются куда чаще; и так как они накапливаются, то
могут выясниться на поздних этапах работы. Простейший способ избежать этого – совместно определить
критерии принятия заранее; создать совместное представление того, как Владелец продукта будет судить о том,
что выпуск продукта соответствует его видению. Это должно быть сделано не только на макроуровне (каждый
спринт), но и для каждого требования (например, каждая пользовательская история).
Лучший способ избежать проблем – определить всей командой эти критерии принятия. Есть много вариантов,
как это сделать, но, если у вас возникают проблемы, можно просто ответить на вопрос: я знаю, что я получу
<что-то>, когда <что-то сделано>. Это «что-то» оказывает ощутимое влияние, а «что-то сделанное» может быть
положительным или отрицательным. Используйте это для прогнозирования того, что скажет о продукте
Владелец продукта, когда вы предоставите ему результат. Начинайте сначала.
Типы критериев успеха могут включать в себя:
• простое описание желаемого результата;
• ключевые тезисы;
• условия принятия работы;
• стиль языка Gherkin[1] в формате «Дано», «Если», «То».
Очень заманчиво начать спринт на оптимистичной ноте, пообещав себе, что вы все сделаете как надо, только
чуть позже. Иногда в начале спринта энтузиазм перевешивает здравый смысл. Само собой, как же можно
занудствовать, когда намечается что-то новое и интересное, – почему бы попросту не надеяться на лучшее? А
потом неизбежно что-то случается – и неизвестно, как плохо все будет складываться потом.
Некоторые команды могут так и не оправиться после неправильного старта. Первая неудача в выпуске продукта
может безвозвратно подорвать доверие, особенно если ожидания были высоки. Неверное начало может повлечь
неудачи и во втором спринте, вовлекая вас в замкнутый круг. Проблемы и так возникнут – поэтому не
игнорируйте хорошие советы и не увеличивайте шансы на возникновение неудач с самого начала.
Приоритезация в действии
При определении очередности нет необходимости излишне углубляться в детали. Это не Олимпиада, где разница
между первым, вторым и третьим местом имеет значение, а четвертое может означать, что поездка сюда была
впустую потраченным временем. Неважно, будет ли пользовательская история первой в списке, когда спринт
начинается; все, что имеет значение – входит она в спринт или нет? Или, точнее, включена в этот выпуск
продукта или нет.
Поскольку спринты относительно короткие, это больше похоже на ожидание автобуса. Скоро будет следующий.
Это уменьшает давление, и нет необходимости бесконечно мучительно расставлять приоритеты. Владельцу
продукта придется просто подождать еще две недели – или какой будет согласована стандартная длина спринта –
до следующего выпуска продукта. Не нужно нервничать.
Лучшее – враг хорошего.
Вольтер
Оценивание в действии
Очень важно, чтобы каждый элемент в журнале имел шанс попасть в следующий спринт – поэтому проводится
приблизительное оценивание затрат на практическую реализацию. Не очень хорошо, когда оценки просто не
могут быть согласованы по одной или нескольким причинам. Плохо, когда команда не может определиться с
задачами на следующий спринт, но если члены команды никак не сойдутся в оценке задач, это может указывать
на более фундаментальные проблемы:
• Неясные требования: расплывчатые пользовательские истории сложно оценить и, что куда более важно,
сложно реализовать. Получите разъяснения.
• Слишком большая и сложная задача: если часть работы требует для реализации больше, чем несколько
дней, сроки выпуска продукта станут излишне неопределенными. Разбейте задачу на части! Кроме того,
требования к таким объемам работы обычно менее понятны.
• Неверно определенные критерии принятия: если пункт назначения неясен, трудно измерить, сколько
времени потребуется, чтобы попасть туда. Даже с четкими критериями принятия кому-то может показаться, что
эта часть работы огромна, в то время как другие решат, что она совсем невелика.
Оценка должна быть коллективной. Тут надо повторить в очередной раз: разговаривайте друг с другом.
Разношерстная группа людей, обсуждающих проблему со всех сторон, снимет завесу таинственности со всех ее
аспектов и определит, что нужно для выпуска продукта. Этот процесс не нужно доводить до совершенства;
вполне достаточно обозначить широкими мазками самое главное.
Мы уже рекомендовали в качестве оценочной техники размеры одежды и оценочные подходы, но, возможно,
новичкам проще будет использовать для оценки затрат времени старые добрые минуты, часы и дни. По опыту,
приноровившись к Скраму, вчерашние новички впоследствии выбирают какую-то другую оценочную технику.
Прежде чем углубиться в спринт и его проблемы, нет необходимости в многочисленных проверках. Главное,
убедитесь в трех вещах:
1. Задачи в журнале распределены по порядку их выполнения, и журнал согласован с владельцем продукта.
2. Критерии принятия (по крайней мере, некоторые из них) написаны совместно с командой.
3. Все пользовательские истории оценены.
В случае оценочного подхода один из наилучших вариантов – повышать баллы в соответствии с
последовательностью чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 100… Все на меньшем конце
последовательности будет означать задачу с наименьшими трудозатратами, и по возрастающей до самых
объемных задач в конце. Такой метод прекрасно работает со многими Скрам-техниками, особенно с
использованием для планирования покерных карт[2].
Все задачи, которые очень сложны, получают оценку 100, чуть менее сложные пользовательские истории – 55, а
34 – те, которые требуют особого внимания.
Начало спринта
Спринт всегда должен начинаться с планирования спринта. Это планирование отличается от планирования
релиза и особенно от планирования проекта. Планирование спринта – очень важный шаг, на котором должна
присутствовать вся команда. Именно планирование является залогом успеха спринта, но оно же нередко
становится причиной неудачи.
Задача команды при планировании – убедиться в том, что она приступает к спринту с четким осознанием того,
что его задачей является получение рабочего продукта, который можно предоставить владельцу продукта. Если
команде не хватает времени на подготовку, то постарайтесь сделать так, чтобы планирование обязательно
включило доработку и «причесывание» как подготовку продукта к реализации. Подобная ситуация далека от
идеала, но даже она лучше, чем начинать спринт вслепую, руководствуясь надеждами на лучшее.

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

Если подготовка была проведена на соответствующем уровне, в частности, пользовательские истории, критерии
принятия и условные баллы оценивания задач прописаны заранее, то планирование сводится к достаточно
недолгому обсуждению, где команда разработчиков убеждается в том, что все ее члены понимают, чего хочет
владелец продукта, и приходит к консенсусу относительно того, какой результат команда ожидает выдать в ходе
спринта. Основная задача на этом шаге уже очерчена, поэтому команде достаточно реализовать ее
соответствующим образом, использовав для этого следующие механики.
• Логистика. Одна из основных задач Скрам-мастера во время планирования заключается в том, чтобы
обеспечивать сотрудничество между участниками. Однако Скрам-мастер также должен позаботиться о вопросах
логистики. На первый взгляд эти вопросы малозначительны, однако их важность сложно переоценить; примеры
подобных вопросов включают в себя резервирование комнаты, пересылка приглашений Владельцу продукта и
команде, проверка того, что пользовательские истории и цель спринта зафиксированы заранее и что Владелец
продукта хорошо представляет себе, зачем он встречается с командой. В ходе самой встречи Скрам-мастер
сосредоточивается непосредственно на переговорах.
• Продолжительность. Планирование – отличная возможность для прицельного обсуждения деталей проекта и
поэтому требует особого внимания. Однако на практике невозможно поддерживать концентрацию участников на
протяжении нескольких часов, поэтому с прагматической точки зрения лучше ограничить продолжительность
встречи двумя часами. Если встреча подходит к концу прежде, чем команда добивается максимальной
успешности, то не беда – в дальнейшем команда всегда сможет наверстать упущенное. На начальных этапах
всегда лучше оставлять пространство для маневра и сохранять гибкость, вместо того чтобы чрезмерно
фокусироваться на цели и терпеть неудачу.
• Результат. Основная задача планирования заключается в том, чтобы команда и владелец продукта сошлись на
том, какой результат будет предоставлен в конце спринта; соответственно, этот процесс в основном вращается
вокруг формирования ожиданий. Практически всегда владелец продукта будет хотеть больше, чем команда
может дать. В силу этого команде стоит четко понимать свои возможности и здраво оценивать количество
работы, которое они могут выполнить в разумные сроки. Первые несколько раз подобные оценки могут даваться
нелегко, и это еще один повод держаться безопасной стороны.
Избегайте личностных конфликтов

Механики безусловно представляют собой важную часть подготовки спринта, однако гораздо большую угрозу
представляют собой межличностные отношения. Планирование непосредственно связано с отношениями между
членами команды, и всегда есть много моментов, которые могут пойти и, скорее всего, пойдут не так, как надо.
• Потеря интереса. Планирование должно быть быстрым, интересным и мотивирующим. Обычно если команде
скучно, это значит, что команда либо не видит пользы в планировании, либо же Скрам-мастер не сумел
заинтересовать ее участников. Несколько наиболее распространенных причин включают отсутствие понимания
того, что требуется от команды, а также эгоистическое поведение отдельных участников, которые хотят, чтобы
оставшиеся участники беспрекословно следовали их указаниям.
• Споры. Здоровое обсуждение – важная часть планирования, но споры исключительно контрпродуктивны и
очень отвлекают от насущных задач. Не забывайте, что на этом шаге главное действующее лицо – это владелец
продукта, от решений которого зависит то, как будет действовать команда.
• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же
контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию
проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать,
лучше дать им такую возможность.
• Поиск решений. Если команда разработчиков начинает вдаваться в большое количество деталей при
планировании, то существует вероятность того, что они пытаются найти решение. Задача планирования
заключается в том, чтобы решить, что команда может выдать в конце спринта. Подробности того, как это
сделать, лучше оставить для следующих этапов.
• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить.
Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит
беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия
будут отрицательными.
Выработка хороших практик

Скрам-мастер несет ответственность за налаживание взаимоотношений между участниками и за формальные
составляющие фазы планирования, но выработка хороших практик является коллективной задачей. Скрам-
мастер должен стараться предотвратить возникновение плохих практик, но если это произойдет, то команде
придется приложить усилия, чтобы преодолеть их. Один человек не может нести ответственность за работу всего
коллектива.
• Никогда не переходите к планированию в отсутствие Владельца продукта и представителей ключевых
отраслей.
• Избегайте соблазна принять плохо написанные или неподготовленные пользовательские истории, даже если
вам кажется, что у вас будет время доработать их в дальнейшем.
• Не пытайтесь спасти ситуацию, интерпретируя истории, пытаясь связать их и вырабатывая критерии оценки на
лету.
• Убедитесь в том, что все проблемы и возможные вопросы разрешены прежде, чем вы будете двигаться дальше.
Иногда Владельцу продукта и команде может потребоваться для этого время.
• Если процесс забуксовал, примите меры. Старайтесь сохранять темп. Перейдите к следующему этапу и, если
нужно будет, вернитесь к проблемному этапу позже.
• Не разрешайте никому и особенно Скрам-мастеру решать за команду, что делать и диктовать другим свои
решения.
Скрам-команда выпустила новый электронный инструмент для управления корпоративными данными, и
Владелец продукта запросил добавление новой функциональности. Во время планирования спринта ведущий IT-
специалист оценил, что для реализации функциональности понадобится не больше 10 минут. Несмотря на то что
график спринта был уже довольно напряженным, команда согласилась включить в работу эту небольшую задачу.
На практике оказалось, что для реализации задачи требуется имплементация нескольких сложных процессов.
Понадобились дни, чтобы учесть все возможные проблемы и провести необходимые тесты. Причиной было то,
что представители команды по тестированию не присутствовали при планировании.
Небольшое изменение так и не удалось реализовать в ходе спринта, и две другие исключительно важные задачи
пострадали от этого. Отсутствие представителей команды по тестированию означало, что решение было принято
на основе недостаточной информации. Соответственно, невзирая на все старания, спринт закончился неудачей.
Владелец продукта был крайне недоволен, но вся команда получила очень полезный урок: в отсутствие
представителей всех направлений вы можете полагаться только на удачу, а она улыбается далеко не всегда.
Рабочий процесс
Как только планирование завершено, наступает время для самой работы. С точки зрения команды, то, что
происходит в это время, очень зависит от самой сути проекта. Главная цель команды – выпустить тот продукт,
который был запланирован и утвержден. Скрам-мастер в это время играет важную роль, помогая команде
следующим образом.
• Сохранение заданного темпа. Это кажется очевидным, но слишком часто упускается из виду. Всем ясно, что
именно они должны делать? Нужна ли команде какая-то дополнительная информация? Чего члены команды
ожидают друг от друга, как связана работа одних с другими? Даже опытным специалистам может понадобиться
напоминание, что нужно обсуждать проблемы. Скрам-мастеру придется постоянно разрешать эти вопросы.
• Устранение препятствий (блокеров). Это наиболее широко известная задача Скрам-мастера и вопрос номер
один на ежедневной встрече: есть ли у вас какие-то затруднения? Речь идет о том, что нужно сделать, чтобы
работа шла постоянно. Задачи могут приходить в любой форме, от распутывания проводов под столами до
помощи Владельцу продукта в составлении отчета для старшего руководства.
• Обеспечение обмена информацией. В обе стороны – как из команды, так и в команду. От команды
ожидается информация обо всех взаимодействиях, трудностях и, разумеется, отчеты о ходе работы. В свою
очередь, команда разработчиков будет ожидать ответы на вопросы со стороны владельца продукта и ясный и
доступный журнал. Содействие этому двустороннему потоку информации, работа с людьми и обработка всех
данных могут занимать весь рабочий день и быть непростой задачей.
• Отслеживание прогресса. Диаграмма сгорания и диаграмма сжигания – два наиболее полезных инструмента
для отслеживания прогресса проекта. Диаграмма сгорания показывает, сколько задач осталось сделать, а
диаграмма сжигания – сколько работы было уже сделано. Мы рекомендуем использовать как минимум
диаграмму сгорания задач и обновлять ее на ежедневной основе.
• Подготовка к следующему спринту. Обновляется ли журнал регулярно? Хорошо ли сформулированы и
проработаны пользовательские истории? Зарезервированы ли необходимые помещения для следующей встречи и
приглашены ли на них необходимые люди? Все ли нормально с логистикой проекта? Ничего сложного, но это
постоянно требующие внимания вопросы, за которыми нужно следить для избежания неприятных ситуаций.
Лучше все продумать наперед.
Для отслеживания и демонстрации прогресса работы наиболее широко применяется диаграмма сгорания задач.
Эта диаграмма показывает, сколько задач осталось до завершения спринта. На диаграмме изображены два
графика:
• история выполнения задач во времени;
• целевая линия выполнения задач.
Начальная точка – это все задачи, которые должны быть выполнены за отведенное время. На рисунке ниже
точками показана диагональная линия, начинающаяся от суммарной оценки задач до нуля, проходящая через
все время, отведенное на спринт. Это целевая линия выполнения задач, на которую и следует опираться.
Упрощенно, если линия, отображающая прогресс работы, окажется выше этой диагонали – значит, налицо
отставание от графика, а если ниже – команда выполняет работу раньше срока.
Точки, которые соединяет пунктирная линия, – это количество оставшейся работы. Как только задача выполнена,
ее «стоимость» в баллах сложности отнимается от прошлого числа и отображается на графике. Некоторые
задачи могут не быть выполнены в срок, поэтому график наверняка не получится ровным.
На примере ниже видно, что вначале команда испытывала некие трудности, но смогла завершить работу
вовремя. Нет ничего необычного в том, что прогресс отклоняется от идеальной линии – но любые заметные
отклонения свидетельствуют о том, что дела идут слишком хорошо или очень плохо.
Рис. 6.1. Блистательная диаграмма сгорания задач
Если в конце спринта вас могут ожидать плохие новости, например, связанные с невыполнением поставленных
задач, то владелец продукта должен узнать об этом как можно раньше, чтобы ожидания всех сторон
соотносились с реальной ситуацией. Никогда не забывайте о важности перспективы.
Приближаясь к концу
Конец спринта всегда ближе, чем может показаться, и поэтому всегда стоит подготовиться к нему заранее.
Скрам-мастер должен приготовить все для обзора продукта, ретроспективы для анализа действий команды и,
конечно же, следующего спринта. Помимо планирования самих собраний необходимо учитывать вопросы,
связанные с логистикой. Часто приходится прикладывать значительные усилия для того, чтобы собрать всех в
одном месте и в одно и то же время.
В одном вы можете быть уверены наверняка: что-нибудь обязательно пойдет не по плану. Никто не может
предсказать будущее, и поэтому невозможно предвидеть миллионы причин, которые могут нарушить план
спринта. Начиная с непредвиденной болезни и заканчивая внезапным компьютерным вирусом, всегда будут
вещи, которые сумеют сорвать самый совершенный план. Именно поэтому ключевой результат спринта –
реализация договоренностей с владельцем продукта вместе с получением ценной обратной связи. Команда
должна быть заинтересована в том, чтобы реализовать цели, поставленные в начале спринта, даже если для
этого потребуется потратить чуть больше усилий, чем предполагалось первоначально.
За день или два до окончания спринта Скрам-мастеру следует перейти в состояние повышенной готовности и
постараться определить список вопросов, которые должны быть разрешены для успешной реализации спринта.
Планируйте заранее и старайтесь забронировать все, что нужно для Скрам-событий, как можно раньше,
особенно когда речь идет о спринте, растянутом во времени. Старайтесь придерживаться одного и того же дня
недели и того же времени. Постарайтесь сделать так, чтобы спринт стал частью привычного распорядка
участников, и не меняйте этот распорядок без крайней нужды.
То же время и то же место – залог идеального спринта.
Это самое лучше время для того, чтобы обратить внимание группы на текущие проблемы и обсудить их в ходе
ежедневной Скрам-встречи. Более того, это оптимальное время для определения и решения дополнительных
проблем. Следите за поведением членов команды и обращайте особое внимание на тех, кто выглядит беспокойно
или прячет глаза. Не забывайте задавать наводящие вопросы и помните, что Скрам-мастер является ключевым
лицом в организации проекта, от деятельности которого зависят взаимоотношения команды разработчиков и
Владельца продукта.
Конец спринта
Если результаты спринта не достигнуты, то это не очень хорошие новости, однако и не конец света. Конечно же,
было бы неплохо понять, что именно пошло не так, и избежать этой проблемы в дальнейшем: этот принцип
заложен в основу Agile с упором на наблюдения и адаптацию. И, конечно же, есть большая разница между
факторами, которые невозможно контролировать (например, болезнью), и факторами, которые поддаются
нашему контролю (например, разумное дозирование работы). Любые пользовательские истории, которые не были
проработаны, могут быть перенесены на следующий спринт, но не стоит думать, что их проработка окажется
легкой задачей. Обычно наилучшим подходом считается тот, при котором проработку этих историй придется
начинать с нуля, чтобы избежать недооценки предстоящего массива работ.
В конце каждого спринта общее количество баллов сложности выполненных пользовательских историй называют
скоростью работы команды. Со временем средняя скорость становится более достоверным показателем.
Команда может в дальнейшем оценивать, сколько задач имеет смысл брать на следующий спринт.
В конце спринта вы уже имеете то, что имеете. К тому времени Скрам-мастер и опытные члены команды уже
подумали о том, как прошел спринт, и сделали заметки о том, что прошло хорошо и плохо и на что нужно
обратить особое внимание в следующий раз. Ведение этих заметок не обязательно должно быть буквальным – нет
необходимости стоять у доски и измерять производительность труда.
Изучение уроков – жизненно важная составляющая гибкого процесса разработки, и лучшие Скрам-команды
постоянно анализируют и улучшают свои рабочие практики. Мысленных замечаний обычно вполне хватает, и
динамика взаимоотношений в команде представляет собой отличный источник информации. Как члены команды
взаимодействуют друг с другом во время дневного Скрама? Как они разговаривают друг с другом и как обстоят
дела в офисе? Кто настойчиво делает вид, что ему все равно, а кто явно обеспокоен? Что насчет групповой
динамики, слухов и громких заявлений?
Стоит сосредоточиться на сообщении членов команды о том, что было закончено. Вне зависимости от того, какой
был результат (или какого не было) – будут высказаны комментарии и вопросы. Иногда обсуждения
продуктивности и результатов команды бывают даже слишком бурными. Наилучшая стратегия здесь – быть
реалистами, однако картина сделанной работы должна быть позитивной. Расскажите о том, как прошел спринт и
как вы пришли к этим результатам.
Окончание спринта – обычно самая напряженная и загруженная часть для Скрам-мастера и команды. Все
напряжены, так как ожидания должны быть оправданы. Нужно осветить много тем, а еще потом предстоят обзор
итогов, ретроспектива и планирование спринта. Важно, чтобы команда держалась вместе и стояла на своем,
даже если ее приперли к стенке. Будьте профессиональны и последовательны; сосредоточьтесь на самых важных
аспектах. Успокойтесь. Будьте терпеливы. И все будет хорошо.
Неопытному Скрам-мастеру необходимо выйти к группе из приблизительно 30 человек, включая нескольких
высокопоставленных членов организации, которые ожидают оценки спринта, и сообщить им, что за последний
трехнедельный спринт не была проработана ни одна пользовательская история. Скрам-мастер выглядит очень
усталым после бессонной ночи, и очевидно, что ему очень неприятно сообщать о провале.
Невзирая на это, Скрам-мастер подробно объясняет, что произошло, и сообщает, какие выводы команда вынесла
из спринта и как она собирается избегать неудач в дальнейшем. За этим следует нечто неожиданное. Начальство
хвалит Скрам-мастера и его команду. Высокопоставленные члены организации оценили их честность и
готовность учиться на ошибках. Более того, они предлагают им поддержку и ресурсы, чтобы выйти из этой
ситуации.
Даже Скрам-проекты иногда терпят неудачи. Открытость – лучший подход в этих случаях, использование
которого вызывает уважение. Всегда лучше выработать план по исправлению ошибок, чем потратить это время
на придумывание оправданий.
Если в конце спринта Скрам-мастер и Владелец продукта выглядят спокойными, значит, дела идут хорошо. Мир
и спокойствие – это священный Грааль Скрама: все его ищут, но мало кто находит. Когда Скрам работает хорошо,
он выглядит очень легким в применении. В реальности идеал недостижим. Нет верного или неверного способа
применять Скрам, но это всегда можно делать лучше. Даже если дела идут прекрасно, постоянно ищите способы
для усовершенствования.
Скрам-команду в первую очередь будут оценивать по результату, но есть и другие положительные признаки.
Один из них – полное взаимопонимание между командой разработки и владельцем продукта. Второй –
самоорганизующаяся команда, способная принимать решения. Еще один – когда старшим менеджерам,
конечным пользователям и прочим заинтересованным сторонам нравится, а главное, совершенно понятен ход
работ над продуктом. Чего еще желать, если рабочий продукт выпускается в срок, ретроспективы выявляют
только легко устранимые проблемы? Разве что не заскучать, почивая на лаврах.
Дух Скрама побуждает искать улучшения. В самом начале Скрам-проекта может быть очень много вариантов для
совершенствования – иногда даже будет казаться, что некоторые проблемы слишком серьезные, но решать их
интересно и даже иногда весело. Парадоксально, но и сам Скрам может стать препятствием. Команда может
обнаружить, что именно эта методология сдерживает их дальнейшее развитие. Не все добираются до этой точки.
Для большинства из нас важно искать что-то новое. Не останавливайтесь в своем поиске лучшего.
Именно практика приводит к совершенству.
• Устанавливайте планку высоко. Постоянно обновляйте журнал, выработайте критерии принятия и используйте
в спринтах только хорошо написанные пользовательские истории.
• Скрам-мастер организует команду, помогает ей, разрабатывает новые практики и решает проблемы.
• Хорошие показатели помогают принимать взвешенные решения и обеспечивают отличный доклад.
• Не вмешивайтесь в работу команды – они прекрасно знают, как решить проблемы.
• Учитесь на ошибках и просчитывайте наперед.
Глава 7. Agile в организации

Введение
Одна из главных причин неудач в реализации проектов – их разработка в отрыве от реального мира и бизнес-
нужд. Существует много причин, почему это может произойти, но это всегда приводит к одному результату –
недовольству заказчика и конечного пользователя. Для Agile главное – не допускать этого. Вся суть Agile
строится на сотрудничестве и участии. Заказчики вовлечены в разработку на каждом этапе и участвуют в
каждом принимаемом решении. Многие техники управления проектами отмечают, что это очень важно для
разработки, но только гибкие подходы делают участие заказчика в процессе создания продукта обязательным.
Это одно из ключевых отличий Agile. Получение первоначальной поддержки и заинтересованность в запуске
проекта в гибкой разработке – очень важный момент, но постоянное участие в процессе – важнейшая
составляющая успеха. После принятия гибких подходов на вооружение они вполне способны позаботиться о себе
сами, органично развиваясь вместе с коллективом; но, чтобы создать условия, в которых это возможно, придется
потрудиться.
Необязательно начинать с чего-то грандиозного – первый шаг может быть малым. Но для надежного старта
необходимо завоевать сердца и умы правильных людей. Понимание того, чего хотят люди в компании, какие у
них есть проблемы и как гибкие подходы могут им помочь, – важная часть процесса. Цель – это не
изолированный эксперимент с Agile, даже если речь идет об одном блестяще проведенном проекте, а внутреннее
гибкое преобразование всей организации. Это вполне достижимо, но для этого потребуется помощь и поддержка.
Чем больше людей будут осознавать преимущества Agile, тем лучше. Важная составляющая стратегии принятия
гибкости – убеждение ключевых игроков в ее необходимости. Что же может предложить им Agile?
Очень многое!
Причины перехода на Agile

Есть множество личных причин, по которым можно заинтересоваться гибкими подходами – от желания найти
лучший подход к работе и до корыстных интересов. Некоторые выступают в крестовый поход с целью
преобразить мир бизнеса, другие просто видят в этом отличный карьерный ход. На самом деле личные мотивы
тут не имеют значения – всё равно все останутся в выигрыше.
Над личными целями здесь куда более практичные корпоративные стремления для принятия Agile. Они не столь
расплывчаты: это увеличение количества довольных заказчиков, вывод организации на мировой уровень или
создание инновационного окружения – цели, которые являются конкретными и измеримыми. Бизнесмены от
внедрения гибкости ожидают умных, или, точнее, SMART-целей.
Главный аргумент, убеждающий всех сомневающихся, – это то, что гибкие подходы дают результаты в течение
нескольких месяцев, чаще недель, и все, от руководства до команды, действительно заняты делом.
Мудрый способ побудить человека что-то сделать – заставить его поверить, что это была его идея.
Нельсон Мандела
БЛИСТАТЕЛЬНое определение
SMART-цель – это
S – specific: конкретная; significant: значительная; stretching: растягиваемая.
M – measurable: измеримая; meaningful: полная определенного смысла; motivational: мотивирующая.
A – agreed upon: согласованная; attainable, achievable: достижимая; acceptable: принятая; action-oriented:
ориентированная на действия.
R – realistic: реалистичная; relevant: релевантная; reasonable: приемлемая; rewarding: полезная; results-oriented:
ориентированная на результаты.
T – time-based, time-bound, timely: ограниченная во времени; tangible: осязаемая; trackable: отслеживаемая.
Десять Smart-целей Agile

1. Продукты, отвечающие требованиям. Начиная с MVP и постепенно его развивая, вы даете заказчикам
возможность видеть последовательное формирование продукта и изменить что-то, если это необходимо. Это
обеспечивает наилучший результат и выпуск качественного продукта.
2. Сокращение времени выпуска продукта. Больше никакого бесконечного ожидания вплоть до истечения
всех возможных сроков. MVP – уже работающий продукт, который выпускается скоро, а дополнения к которому
выходят часто.
3. Ранняя окупаемость инвестиций (return on investment, ROI). Продукт выпускается быстро, что позволяет
реализовать преимущества на раннем этапе разработки. Продукт начинает окупаться уже на этом этапе и
продолжит с дальнейшим развитием. Таким образом, прибыль может быть получена быстрее.
4. Гибкость. Изменения – постоянная часть жизни. Вместо того чтобы плыть против течения, Agile принимает и
даже поощряет перемены. Это намного больше соответствует естественному ходу (деловой) жизни.
5. Уменьшение рисков. Начиная с малого и развивая продукт постепенно, мы значительно уменьшаем риски. В
тех редких случаях, когда дела идут плохо, затраты на исправление проблемы будут невелики. При таком
подходе возникающие проблемы незначительны и разрешаются не в пример проще.
6. Высокая прозрачность процесса. Agile обеспечивает отличную прозрачность хода работ для ключевых
заинтересованных сторон в отношении как прогресса разработки, так и самого продукта. Непрерывное участие и
сотрудничество помогают устранить бессистемный подход и необсуждаемые темы в разработке.
7. Большая эффективность. Постоянное улучшение – важная часть Agile. Широко известные техники для
измерения производительности помогают командам отслеживать свой прогресс. Быстрее, дешевле, лучше – все
это реализуется не за счет качества продукта.
8. Предсказуемость. Положительный результат в целом гарантирован: бизнес получает то, что он хочет.
Результативность достигается в короткие сроки, что, в свою очередь, обеспечивает нужный настрой. Успех
приносит уверенность и приводит к большему успеху – такой позитивный замкнутый круг.
9. Удовлетворенные заказчики. Какие бы критерии ни применялись для оценки удовлетворенности, стоит
ожидать необходимости добавления улучшений уже на раннем этапе. Гибкие подходы делают этот процесс
проще. Любые негативные отзывы – лакмусовая бумажка для вашей работы.
10. Лучший настрой. Последнее в списке, но не по значимости. Довольный бизнес, счастливая команда – все
это означает здоровое рабочее пространство и вырабатывает привычку к успеху, где нормой становятся
успешные, а не провальные проекты.
Влияние на влиятельных
Даже если в текущих проектах организации царит полный хаос и множество проблем, сейчас нельзя никого
заставить разрешать эти неприятности именно с помощью Agile. В большинстве случаев все не совсем ужасно, а
просто плохо, и с помощью Agile нужно просто немного помочь получить первый важный шанс показать, на что
способны гибкие подходы. Иногда получение такой возможности не является большой проблемой – особенно в
небольших организациях, но в целом Agile может быть не единственным кандидатом.
– Денег нет, но вы держитесь. (А моя зарплата неприкосновенна.)
Крайне важно получить поддержку руководства для первого проекта. Нет необходимости настаивать на
полномасштабном преобразовании – гибкость вполне может быть применена в малом проекте. Сама суть Agile –
определить MVP и развивать его постепенно, и в этом смысле одного проекта более чем достаточно. Даже если
вам предложат большой проект с самого старта, работайте по той же схеме: начинайте сначала с малого, а затем
наращивайте скорость.
Может быть, у вас есть возможность решать, как именно будет структурирован ваш следующий проект.
Замечательно, если так. Не всегда, но довольно часто достаточно согласия одного человека. Быть может, вам
нужно убедить человека, ответственного за выполнение проектов, например официального руководителя всей
программы, у которого постоянно несколько текущих проектов. Даже в больших компаниях будет кто-то с
достаточным влиянием, чтобы принять решение. Если все остальное терпит неудачу, рискните и постучите в
дверь генерального директора или ближайшего доступного старшего менеджера.
Есть только три ключевых фактора успеха для запуска любого Agile-проекта:
• выбор подходящего проекта;
• заинтересованность представителя бизнеса в активном участии;
• участие людей с гибким мышлением.
Даже если вам и придется дойти до генерального директора, суть не поменяется и не сможет быть изложена за
несколько минут. Вооружитесь нашими десятью SMART-целями для гибких подходов, чтобы изложить, что
можно достичь. Выберите подходящий для начала проект – и вероятность того, что вы получите одобрение, будет
очень высока.
Четыре способа все испортить

• Заявите, что Agile – единственный вариант.
• Объявите, что все настолько очевидно, что любой дурак сможет справиться и не потребуется никакого
обучения.
• Скажите, что гибкие подходы безошибочны, а причина неудач – недостатки отдельных людей.
• Выберите невыполнимые сроки и цели, заявив, что в дивном новом мире Agile нет ничего невозможного.
Agile в массы!
Даже до того, как вы возьметесь за продвижение идеи попробовать гибкие подходы в действии, начинать вы
будете не с нуля – почти каждый что-то да слышал про Agile, и большая часть этого услышанного весьма
положительна. Сама идея не нова, но в последние годы переживает очередной всплеск интереса – так что
сейчас, на этой волне популярности, самое время предлагать ее испробовать. В некоторых кругах даже считается
неприличным предполагать, что гибкие решения – не наилучший вариант.
Неофициальный пиар Agile работает так же и может помочь и вам. Есть целый ряд организаций, страстно
приверженных Agile, так почему бы не упомянуть несколько названий? Как насчет Intel? Spotify? Google? Старых
добрых Waitrose[3]? Сейчас сложнее будет найти организацию, которая не заинтересована в поиске новых
способов улучшения производительности. Ну а Agile у себя внедряют хорошие компании.
Убедитесь в том, что ваши попытки по внедрению гибких подходов воспринимаются всерьез. Определенное
недоверие относительно успешной реализации многообещающих перспектив Agile вполне естественно, но никто
в здравом уме не будет отказываться от этих перспектив, если они подтверждены на практике; а если это все-
таки происходит, возможно, вам стоит поискать другую работу. Скорее всего, вам дадут зеленый свет, а в худшем
случае попросят рассказать больше об Agile. Вероятность полного отказа весьма незначительна.
В крайнем случае не бойтесь пустить в ход знаменитый девиз Agile: быстрее, дешевле, лучше. Возможно, вам
понадобится объяснить, как вы собираетесь этого добиться, однако звучит он просто превосходно.
Предзапуск Agile для начинающих

Используйте запуск нового проекта как повод, чтобы рассказать о гибких подходах. Пусть заинтересованные
стороны знают, чего ожидать и что именно будет по-другому, особенно когда это первый проект такого рода.
Несколько часов, проведенных за объяснением основ Agile, улучшат понимание и будут способствовать
принятию.
Это так называемый образовательный пиар, и он исключительно важен перед началом проекта.
Если вы пытаетесь убедить людей что-то сделать или купить, вы должны использовать тот язык, на
котором они говорят и думают каждый день.
Дэвид Огилви
Не только для IT
Одно из самых распространенных заблуждений заключается в том, что Agile подходит только для проектов в
области информационных технологий (IT). В действительности это далеко не так, и большая часть концепций, с
которыми вы можете ознакомиться в этой книге, отлично подходит и для других сфер деятельности. Одним из
основных исключений является экстремальное программирование (XP, eXtreme Programming), что, впрочем,
неудивительно, учитывая название. Автоиндустрия в этом плане является лидирующей с их технологией
бережливого производства, а практика показывает, что IT в этом плане несколько более консервативны. Нет
никаких сомнений в том, что масса IT-команд использует гибкие подходы. Их опыт был бесценен для их
совершенствования, но это не означает, что IT имеет эксклюзивное право на применение Agile.
Помимо этого следует упомянуть распространенное убеждение, что некоторые отделы внутри крупных
организаций менее предрасположены к Agile, но это совершенно не означает, что эти отделы ни при каких
обстоятельствах не перейдут на гибкую сторону. Отдел финансов – один из типичных примеров отделов, которым
нелегко свыкнуться с мыслью о гибкости, но если поискать, то вы без труда найдете массу примеров, когда
отделы финансов используют ее исключительно продуктивно. Более того, использование гибкого подхода к
финансам является ключевым залогом успеха гибкого проекта, так как попытки реализации гибкого проекта с
фиксированным бюджетом, результатами и расписанием и полным отсутствием гибкости обречены на провал.
При этом нет никаких сомнений в том, что легче всего начать путешествие в мир Agile с наиболее легкого
варианта. IT-проекты, безусловно, не являются единственным вариантом, но это одна из самых доступных
возможностей.
Прежде чем перейти к реализации проекта, следует обговорить фундаментальные культурные условия,
необходимые для реализации гибких принципов и гибкого мышления. Без гибкой атмосферы проект неизбежно
зачахнет или же вернется к старым и исключительно негибким подходам. Ниже представлены условия,
необходимые для успешной реализации Agile в проекте:
• принятие гибкой философии перед началом проекта – включая сегментированный подход,
сотрудничество и все итерации разработки;
• принятие решений внутри команды – расширение полномочий участников команды;
• заинтересованность представителя заказчика в постоянном участии в проекте – гарантированный
доступ к нужному ресурсу;
• согласие на инкрементную поставку – принятие того, что это желаемый и практичный вариант;
• постоянный доступ ко всем участникам команды – предпочтительно работающим на доступном
расстоянии друг от друга или при налаженной системе связи;
• постоянный состав команды – на протяжении всей работы над проектом;
• правильно подобранные специалисты с гибким мышлением – команда профессионалов с
коммуникативными навыками;
• необходимый размер – маленькая команда для обеспечения наилучшего взаимодействия и сотрудничества;
• благоприятная коммерческая база – сначала доверие и сотрудничество, а потом уже любые оговорки.

Важно помнить, что нельзя быть гибким только на словах. Достаточно легко согласиться с идеями Agile в теории,
но переход от теории к практике в данном случае вряд ли дастся легко. Довольно бессмысленно с практической
точки зрения назначать младшего менеджера в качестве бизнес-представителя, а затем заставлять его
обращаться за подтверждением к начальству перед тем, как принимать любое решение. Аналогично нет
никакого смысла в том, чтобы передавать полномочия команде, а затем заставлять их обращаться за
разрешениями к вышестоящему руководству. Чтобы подходы Agile работали успешно, необходимо, чтобы у
участников команды слова не расходились с делом.
Оценка успешности
Упоминание показателей эффективности работы обычно имеет негативный эмоциональный окрас. Было время,
когда простое упоминание этого термина вызывало в памяти образ надзирателя с секундомером, заносящего в
блокнот результаты производительности. Давно уже было высказано утверждение: если вы не можете что-то
измерить, оно не может быть улучшено – но убедить в этом большинство людей почти невозможно. Суть в том,
что показатели эффективности всегда были инструментом руководителей для того, чтобы выжать как можно
больше из сотрудников.
Гибкая революция в реализации метрик показателей эффективности и тут перевернула все с ног на голову.
Любые характеристики принадлежат команде и используются ими для выполнения работы. Из-за этого сдвига
акцентов показатели эффективности лучше воспринимаются, поскольку команды могут теперь посмотреть, как
именно идет работа. Без этих характеристик гибкие подходы – особенно Скрам и Канбан – не смогут
функционировать должным образом.
Характеристики в Agile по-прежнему чрезвычайно полезны для организации, но они больше не рассматриваются
как инструмент контроля работников.
Основные принципы 1–2-3 для определения метрик показателей эффективности:
• определите важнейшие процессы или требования заказчика;
• определите специфический, измеримый результат работы;
• установите цели, по которым можно измерить результаты.
Мантра любых метрик: измерь, проверь и улучши. Без измерения ничего не выйдет.
Если команда управляет всеми метриками, это говорит о том, что они намного надежнее и имеют большое
значение для компании. Это особенно заметно при измерении скорости работы (характеристика Agile-команды),
где команда рассчитывает свою скорость выпуска продукта и использует эту информацию для прогнозирования
работы в заданных временных ограничениях. Такой прогноз намного надежнее, потому что он основан на
прошлом опыте. Члены команды довольны выбранными задачами, потому что они не навязаны им, а бизнесмены
заранее имеют представление о том, что они получат за свои деньги.
Поскольку гибкие подходы сосредоточены на бизнес-ценности, показатели всегда должны быть понятными для
заинтересованных сторон. Процесс расчета выполняется для команды, и значение скорости будет разниться,
однако конечный результат вполне точен. Это субъективное значение может быть использовано для вычисления
того, что именно и через какое время может быть выпущено. Например, «Agile-команда A реализует функции A,
B и C через X недель». Заказчик точно знает, чем занята команда в этот период времени и на что именно уходят
его денежки.
Краткое пособие по использованию скорости работы команды в Agile.
• Согласуйте шкалу от одного до пяти для измерения масштабов работы (например, 1 = незначительная, 5 =
большая).
• Оцените по этой шкале все задачи, которые должна выполнить команда в определенный временной
промежуток (например, две недели).
• Сосчитайте общее количество баллов реализованных задач (скорость работы команды).
• Определите минимальные и максимальные значения, чтобы определить предельные значения скорости для
команды.
• Исключите самое большое и самое маленькое значение и высчитайте среднее значение для оставшихся (общее
количество баллов реализованных задач, поделенное на общее количество временных промежутков).
• Планируйте выполнение будущих задач на основе средней скорости. Повторяйте до тех пор, пока
запланированное и фактическое значения скоростей не будут совпадать.
Вы можете использовать это значение для прогнозирования выполнения задач.
Двоякая польза отчетов

Плохую коммуникацию обычно называют одной из главных причин неудачных проектов. В традиционных
методах управления была замечена тенденция к тому, чтобы в начале любого начинания руководители были
чрезмерно оптимистичны, а затем игнорировали проблемы, появляющиеся во время работы до тех пор, пока не
становилось слишком поздно. Это создает неопределенность в отношении реального состояния дел, а иногда и
плохое предчувствие с самого начала. Плохо, когда единственная обратная связь по прогрессу работ
осуществляется через нерегулярные, неясные отчеты.
И здесь гибкие подходы все меняют. Представителям заказчика не нужно постоянно спрашивать о прогрессе,
потому что они полностью вовлечены в процесс. Вместо того чтобы тратить время на отслеживание хода работы,
бизнес может сосредоточиться на более важных вещах. Время тратится на более полезную деятельность.
Даже если люди, непосредственно вовлеченные в разработку, точно знают, как обстоят дела, все равно
необходимо доносить информацию и до оставшейся части компании. Например, использование статусов по
цветам светофора (RAG: Red, Amber, Green. Красный, желтый, зеленый) резко отличает Agile от традиционных
методов управления, в которых людям, не участвующим в проекте, используемые метрики обычно непонятны. От
Agile-команды ожидается, что она будет представлять плоды своих трудов в формате бизнес-ценности, по
которому можно будет сделать прогноз о будущей производительности.
Доклады о ходе работы обычно используют систему цветов светофора или «RAG-статус» как визуальный сигнал
для суммирования производительности для всех заинтересованных лиц:
Красный – серьезные проблемы, блокирующие дальнейшую разработку.
Желтый, или янтарный, – препятствия, которые могут быть устранены.
Зеленый – все в порядке.
Гибкие отчеты по проекту – это регулярные новости, обновляющиеся каждые несколько недель. Они полностью
сосредоточены на том, что было выпущено или что скоро планируется выпустить, – настоящие новости, которые
понятны организации и в которых нет места отговоркам и попыткам что-то скрыть.
Полезным инструментом для отслеживания прогресса является диаграмма сжигания задач. Она показывает
прогресс выполнения проекта в наиболее распространенном варианте в виде двух линий на графике:
• общая работа – суммарная оценка сложности проекта – в динамике;
• выполненные задачи – в динамике.
Она очень отличается от диаграммы сгорания задач. График показывает общую работу по проекту (обычно в
условных баллах) в сравнении с выполненной работой в течение определенного периода времени. Это визуальное
отображение прогресса работы над проектом, отслеживающее выпуск продукта и оставшуюся работу.
На графике ниже пунктирной линией показано общее количество баллов по пользовательским историям,
которые команда должна завершить в течение восьминедельного спринта, чтобы обеспечить быстрый и
качественный выпуск продукта. Линия из точек отображает суммарное количество задач, выполненное
командой.
Рис. 7.1. Блистательная диаграмма сжигания задач
На графике видно, что после несколько неуверенного старта команда вышла на постоянную скорость работы,
однако владелец продукта постоянно добавлял новые задачи. Можно сделать вывод, что проект будет закончен
вовремя, если в последние две недели не будут добавлены новые требования.
Избегайте повторения ошибок

В конце концов, Agile не обеспечивает полную защиту от типичных ловушек, так что будьте человеком широких
взглядов и учитесь на трудном опыте других, будь они приверженцами Agile или нет. В некоторых кругах есть
тенденция пренебрегать старой школой, но там есть что почерпнуть, особенно в отношении их наиболее
распространенных оплошностей. Самые известные проблемы уже исправлены самой гибкой философией, но не
обманывайтесь предположением, что она способна защитить вас от всего.
В разгар битвы за внедрение Agile важно сохранять реалистичность при предоставлении гарантий насчет «что» и
«как». Не увлекайтесь идеей быстрее, дешевле, лучше. Будьте особенно осторожны в чрезмерно оптимистичных
оценках преимущества внедрения Agile и не игнорируйте минусы. Блестящие результаты не нужны, если очень
хороших более чем достаточно. Если вы ожидаете идеального результата, даже оценка 9 из 10 может
разочаровать.
Будьте осторожны с людьми, которые не поняли все аспекты работы в Agile. Для СЕО возникает соблазн не
слышать ничего за пределами прекрасной картины быстрее, дешевле, лучше. Или просто настроиться на
обещания работающих продуктов, скорейшего выхода на рынок, ранней окупаемости инвестиций, гибкости,
меньшего риска, большей эффективности, довольных заказчиков, а совершенствование культуры и изменение
настроя компании попросту проигнорировать. Не предполагайте, что все читают в договоре использования
условия, напечатанные мелким шрифтом, – никто этого не делает.
Стандартные ошибки могут объявиться и в мире Agile. Не берите с собой в новый мир старые проблемы. Нет
ничего более грустного, когда ваши коллеги думают: ну вот, опять. Предупрежден – значит вооружен!
• Нечеткие цели и задачи – начинайте всегда с понятным видением проекта.
• Неопределенные требования заказчика – пользовательские истории должны быть ясными.
• Недостаточное обучение – обеспечьте соответствующие тренировки и коучинг.
• Нереалистичные цели – даже гибкие подходы ничего не смогут сделать с навязанными извне
невыполнимыми сроками.
• Пренебрежение ресурсами – позвольте команде решать, какие цели можно будет выполнить.
• Повторение ошибок – смертный грех любых решений; всегда проверяйте и приспосабливайтесь.
Невозможно сыграть симфонию в одиночку. Для этого нужен целый оркестр.
Хэлфорлд Лаккок (американский методист, министр и профессор)
Обычно разработчики проектов считают легким планирование задач так, как если бы проект находился в
вакууме – и иногда это даже кажется распространенной нормой. Однако такой подход приводит к тому, что
проект оказывается оторван от реального положения вещей. Agile исповедует другую философию и основывается
на сотрудничестве и взаимодействии. Как минимум гибкие подходы гарантируют активное участие заказчика в
проекте, но в идеале они подразумевают также вовлеченность всей организации, к которой разработчики
принадлежат, особенно если в дальнейшем вы собираетесь фактически использовать Agile как основные решения
для будущих проектов.
Agile-проекты по определению будут более прозрачными и наглядными – в конце концов, это одна из целей
гибких подходов. Очень поможет, если суть и принципы Agile будут понятны всем, кто вовлечен в процесс, – даже
таким отделам, как финансы и маркетинг, которые в традиционных методологиях обычно игнорируются.
Открытость в основах гибких решений приводит к тому, что о них узнают и другие люди, так что вполне можно
ожидать повышенного интереса. Не удивляйтесь, если генеральный директор или финансовый директор придут
на презентацию. Наоборот, стоит опечалиться, если этого не произойдет.
Нет необходимости вовлекать вообще всех, это не крестовый поход. Но обращайте внимание и на не столь
очевидных кандидатов.
• Ознакомьтесь с причинами, которые могут заинтересовать всех принимающих решения насчет введения
Agile, – с каждым нужно говорить на его языке.
• Agile – больше чем термин из IT; не оставляйте без внимания ни один аспект.
• Отчеты, фокусирующиеся на выпуске продукта и конкретных достижениях, – это именно то, чего все хотят.
• Даже «старая школа» может пригодиться; она уже давно столкнулась с большинством проблем.
• Не переоценивайте себя; даже блестящий результат может разочаровать, если настроиться на идеальный.
Глава 8. Вспомогательные механизмы

Введение
Одной из наиболее приятных характеристик Agile является беспрецедентное количество материалов, большая
часть из которых совершенно бесплатна. Чувство принадлежности к сообществу поразительное – настолько легко
найти помощь. Интернет полон полезной информации, и единственная сложность тут – понять, с чего начать.
Кажется, рассмотрены все возможные нюансы и освещены все темы – есть даже материалы, как сбросить вес или
заниматься альпинизмом с помощью Agile. Для сравнения можно проверить, как много в интернете материалов
по PRINCE2.
Но и это не все. Есть некоторое количество некоммерческих организаций мирового уровня, предлагающих
больше вариантов обучения, чем любой профессионал может пожелать. Форумы можно найти на самых
неожиданных сайтах; Agile охватывает все возможные аспекты современных медиа, включая вебинары и
«Твиттер». Agile на YouTube посвящено больше видео, чем PRINCE2 и «Маппет-шоу» вместе взятым. Есть и
отличные книги по теме[4]!
Конечно, не все преследуют альтруистические мотивы. Есть несколько организаций с сомнительными
полномочиями и явно не имеющих никакого отношения к Agile, но в этом нет ничего зловещего. Эджайлисты
могут относиться к своему делу чрезмерно ревностно, но это не всемирный религиозный культ. И есть много
людей, сосредоточенных на создании чего-то своего на основании Agile, поэтому стоит ожидать встречи с теми, у
кого есть и другие мотивы. Если вы разместите вопрос на онлайн-форуме с просьбой дать рекомендации по
обучению, не все ответы могут быть бескорыстными.
Мир Agile предлагает фантастический выбор, и нужно приложить минимум усилий, чтобы найти полезную
информацию. Если у вас ограниченный бюджет, вполне можно начать практически без ничего.
Много информации по теме – это палка о двух концах. Что бы вы ни искали, малоизвестную информацию или
основы, – найдется все. Вопрос на миллион – что лучше всего изучить после прочтения этой книги? Не то чтобы
на этот, без сомнения, замечательный вопрос было легко ответить, но мы дадим один совет: проверьте группы в
LinkedIn[5].
В наше время предполагается, что у каждого международного специалиста есть аккаунт в LinkedIn; в 2015 году у
этой сети было 400 миллионов пользователей, и мы рискнем предположить, что вы слышали об этом сайте.
Настоящий учитель не будет вести тебя за руку через дверь, а лишь подведет к ней.
Никки Роу (актриса)
Там найдется больше групп об Agile, чем даже можно вообразить. Большинство из них открыты для всех,
особенно для любознательных новичков. Вы можете присоединиться к одной из групп по управлению проектами
для более широкого кругозора. Наши фавориты – Scrum Practitioners (https://www.goskills.com/Course/Agile-Scrum-
Practitioners) и Project Managers Network (http://network.projectmanagers.net/).
Вопросы по гибким подходам рассматриваются обстоятельно и со всех сторон, так что приготовьтесь читать
бурные обсуждения, раскрывающие тему. Не стесняйтесь запостить свой вопрос – эти группы одни из самых
дружелюбных к новичкам, однако не забывайте о здравом смысле. Если, к примеру, попросить порекомендовать
тренинг, вы получите хорошие советы, но, разумеется, на вас тут же налетят и стервятники.
Новичок задает вопрос в популярной группе по Скраму: нормально ли делать записи во время ежедневных
Скрам-встреч, а потом рассылать участникам эти заметки как памятку?
На первый взгляд довольно простой и однозначный вопрос.
Помимо нескольких ответов «Да, почему бы и нет?», начинается подробное углубленное изучение причин и
мотивов самого желания делать заметки. Не стоит ли за отправкой заметок после встречи скрытое желание все
контролировать и всем управлять? Не подчеркивает ли это фундаментальную проблему с ежедневными скрам-
встречами или даже со всей системой Скрам в организации?
Даже если вы зададите кажущийся простым вопрос, он будет разобран со всех сторон.
Вспомогательные организации и другие сообщества

Agile Alliance (https://www.agilealliance.org/) – одна из самых больших организаций; кое-кто заявляет, что самая
большая и самая лучшая. Они позиционируют себя как некоммерческую организацию, с участниками со всего
мира, занимающуюся развитием принципов и практик Agile. Стоимость – около $100 за одного человека, и в два
раза меньше – за корпоративное членство от пяти человек; отличная цена для доступа к необходимым ресурсам.
И к тому же это прекрасно смотрится в резюме!
Scrum Alliance (https://www.scrumalliance.org/) и Scrum.org[6], как можно понять из названий, ориентированы на
обсуждение Скрама, но и другие темы по гибким подходам там тоже обсуждаются. Обе организации
предоставляют членство вместе с сертификатом. В общем, замечательные ресурсы, которые доступны и
предлагают вдобавок огромное чувство общности. Наверное, есть такие коллекционеры сообществ, которые
состоят в обеих организациях, но в целом членства в одной из них более чем достаточно.
Другой интересный вариант для интересующихся Agile – это доски обсуждений Yahoo! Groups, на которых все так
же разбирается до мелочей. Если вы разработчик программного обеспечения, использующий гибкие решения и
знающий испанский, или более заинтересованы в бережливом управлении или Канбане – тут найдется что
почитать. Проблемы могут возникнуть, только если вам нужно что-то специфическое – но, скорее всего, и это
отыщется после непродолжительных поисков.
Наконец, нельзя не упомянуть, что и очень уважаемые организации тоже признают Agile. Ассоциация по
вопросам управления проектами (Association for Project Management, https://www.apm.org.uk/) и Институт
управления проектами (Project Management Institute, https://www.pmi.org/) – авторитетные источники, к которым
тоже стоит обратиться. Список можно продолжать бесконечно; в целом сообществ огромное количество[7].
Конференции
Конференции по Agile в наше время напоминают музыкальные фестивали. Поблизости от вас всегда происходит
что-нибудь связанное с Agile, и чем больше у вас возможностей для путешествий, тем больше возможностей
найти конференцию по вкусу. Конференции Agile не рассчитаны исключительно на экспертов, и ознакомление с
данной книгой предоставит вам необходимый минимум знаний для участия в одной из них. Есть немало
конференций, посвященных общим принципам Agile, но в последнее время все больше событий связано с
конкретными специализациями или фреймворками, как, например, бережливое управление, Шесть сигм, Канбан,
Скрам, управление продуктом и тестирование.
До сих пор нам не встречались события, организованные специально для поклонников Agile из числа любителей
хэви-металл, но, помимо этого, сложно представить что-то, применения чего в контексте гибких подходов нам не
доводилось бы видеть. Хороший пример разнообразия Agile – проект «Agile на пляже» (www.agileonthebeach.com).
Это событие достаточно велико для того, чтобы удовлетворить самые разнообразные вкусы, но в то же время
достаточно компактно, чтобы эти вкусы удовлетворялись в дружеской обстановке. Оно прекрасно подойдет для
начинающих, но специалисты узнают там очень много нового (плюс оно происходит в отличном месте). Вы
можете получить хорошее представление об «Agile на пляже», посмотрев видео с конференции на YouTube –
ссылки указаны на веб-сайте организаторов, – и это будет очень полезно как для новичков, так и для
специалистов. В плане соотношения цены и качества это однозначно наше любимое событие!
Другие, намного большие конференции, похожие на фестивали, организовывает Agile Alliance в США. Наш опыт
подсказывает, что существует достаточно местных мероприятий, для посещения которых совершенно не нужно
лететь через океан, но нет никаких сомнений в том, что международные Agile-конференции – отличное
времяпрепровождение. Возможности для общения на таких больших событиях просто феноменальны, а
организация настолько хороша, что у вас будет много шансов пообщаться с настоящими знатоками Agile. Что-то
интересное найдется для каждого.
Не забывайте о том, что любая серьезная конференция публикует материалы, так что наш совет: пробуйте,
прежде чем покупать. Целесообразно проверить, подходит ли вам данная конференция, перед тем как подавать
туда заявку.

Советы для посещающих конференцию по Agile

Люди, которые посещают конференции, обычно гораздо важнее того, о чем они там рассказывают. Несомненно,
лучшая IT-конференция в мире – ежегодное событие QA&TEST в Бильбао, Испания (www.qatest.org). У этой
конференции отличные организаторы и превосходный отборочный комитет, и они привлекают массу прекрасных
специалистов со всего мира. Конференция проводится в отличном месте, где все продумано до мелочей.
Основная тема – качество программных разработок и его тестирование – звучит не очень привлекательно, но за
счет разнообразия аудитории организаторам удается добиться исключительных результатов. Дополнительным
преимуществом является то, что многие из числа известных специалистов по Agile регулярно выступают там в
качестве спикеров.
Основной урок, который стоит вынести из этого: всегда читайте между строк программы конференции и
внимательно прислушивайтесь к отзывам тех, кто побывал там до вас.
Налаживание контактов
Попытки изучить Agile сидя дома, исследуя интернет и читая форумы, имеют ряд серьезных ограничений.
Подобный подход является весьма несоциальным и не самым гибким – в конце концов, основная идея Agile
основана на взаимоотношениях с другими людьми. Участие в конференциях обычно требует значительных
временных (а иногда и финансовых) затрат, поэтому встречи на местном уровне могут оказаться наилучшим
вариантом. Прошли те времена, когда собрание местных экспертов считалось чем-то невыразимо скучным и
вызывало зевоту у уважающего себя бонвивана.
Практически все организации, использующие гибкие подходы, устраивают регулярные события, и это одна из
дополнительных причин наладить контакты с подобными организациями – вы вряд ли пожалеете об этом.
Конечно же, если вы уже являетесь членом этой организации, то вы так или иначе познакомитесь с Agile. Однако
если это не так, то возможность поучаствовать в собраниях – отличный повод завязать отношения с этими
организациями. Другая возможность, о которой не стоит забывать, это использование https://www.meetup.com/ru-
RU/ для поиска Agile-групп. Ну и наконец, вы всегда можете просто поспрашивать знакомых.
Где бы вы ни находились, существует очень большая вероятность того, что где-то неподалеку окажется группа
людей, интересующихся Agile. Не бойтесь, если в описании этой группы фигурирует слэнг типа Канбан, Скрам
или бережливое производство. Люди, посещающие собрания Agile, всегда очень открыты и отзывчивы.
– Мне кажется, он не совсем понимает, что такое близкие контакты…
Собрания на местном уровне обычно меньше, менее формальные и предоставляют отличную возможность
завязать отношения с региональными экспертами в области Agile. Более крупные собрания дают отличную
возможность познакомиться с организациями, использующими гибкие подходы, специалистами международного
уровня и интересными примерами использования. При этом не забывайте, что люди, говорящие со сцены, не
всегда правы. Помните о том, что у многих людей есть свои причины придерживаться определенных взглядов, а
некоторым даже платят за то, что они говорят. Немного критичного мышления никогда не повредит!
И наконец, не перепутайте www.meetup.com с сайтом знакомств www.meetme.com. Гибкость, указанная в списке
интересов на одном из них, значит кое-что совершенно иное на втором.
Будь готов
Из-за низкого порога вхождения в мир Agile всегда есть большой соблазн прочитать пару статей и остановиться
на этом. В обучении посредством практики нет ничего плохого, и этот подход исключительно важен в случае с
Agile. Сочетание здравого смысла и упорства позволит вам без труда добиться необходимого уровня
компетентности в использовании Agile. Однако не стоит забывать о том, что легкость понимания гибких подходов
не значит, что их легко применить должным образом.
Основная идея этой книги заключается в том, чтобы дать каждому читателю достаточно для того, чтобы начать
использовать Agile: в сути своей, это наш эквивалент минимально жизнеспособного продукта.
Нет ничего плохого в том, чтобы использовать эту книгу как основу. Более того, она рассчитана именно на это.
Есть масса дополнительных бесплатных материалов, которые могут раскрыть рассматриваемые здесь темы:
например, на сайте www.scrumtrainingseries.com.
Эта книга вместе с видеолекциями должна дать достаточно пищи для ума. Материалы по Agile и Скраму на
YouTube также довольно неплохие и заслуживают вашего внимания. В конце концов, это лучше, чем ничего.
Когда дело доходит до официального обучения, все превращается в минное поле. Есть хорошие курсы, и они, как
правило, охватывают все возможные нюансы. И вот тут мы, можно сказать, избалованы выбором. Это та область,
в которой нет единственно верного ответа, но однозначно стоит попробовать зарекомендовавшие себя курсы с
практическими упражнениями. Сидеть и просто два дня слушать тренера вряд ли имеет смысл. Главный
критерий, который мы рекомендуем применять, – подумайте, выполняет ли тренинг свою работу и улучшает ли
он ваше резюме.
Большинство стандартных тренингов, к сожалению, сосредоточены на фиксированной программе, которая может
быть изложена за несколько дней. Это хороший формат для обучения Скраму для групп, но для индивидуальной
подготовки есть другие приемлемые варианты. В стандартных тренингах нет ничего плохого, но они помогут
больше вашему резюме, чем вам.

Есть мнение, что в мире Agile никто ничего не записывает. Это действительно так в случае с древними
цивилизациями и современной мафией, но в отношении Agile – это заблуждение.
Зайдите на Amazon и введите в поиск слово Agile. Вас ожидает масса книг, многие из которых были
опубликованы сравнительно недавно.
Формальная подготовка
Существует немало курсов Agile-подготовки, но все они предоставляют схожие преимущества, главным из
которых является подготовка специалистов, способных обсуждать гибкие подходы на одном и том же языке,
параллельно с обучением их полезным техникам в безопасных условиях. Практически невозможно
рекомендовать конкретные курсы из-за большого количества возможных комбинаций – очень многое зависит от
конкретных нюансов или запросов. Однако следует учитывать два основных фактора.
1. Сертифицированные или несертифицированные. Сертифицированные курсы выдают сертификат на
выходе, тогда как несертифицированные не дают. Сертифицированные курсы обычно более дорогие и менее
гибкие в плане выбора контента – по сути, вы просто следуете плану курса. Несертифицированные курсы
позволяют подстраиваться под конкретные нужды, они обычно дешевле и редко следуют формальным
требованиям. Сертифицированные курсы лучше смотрятся в резюме, но при должном старании вы сможете
найти несертифицированные курсы, которые дадут вам больше.
Далеко не все любят играть в игры сертификатами, особенно если принять во внимание важный вопрос, который
нередко остается без ответа: кто сертифицирует людей, которые сертифицируют людей, преподающих на
сертифицированных курсах?
Это одна из причин выбрать несертифицированный курс и потратить сэкономленные деньги на отпуск.
2. Открытый или корпоративный. Корпоративный курс проводится на базе организации; многие из этих
курсов рассчитаны на конкретные команды. Эти курсы организовываются на индивидуальной основе и могут
быть сертифицированы, но часто используются для подачи специфического и несертифицированного материала.
Открытые курсы обычно проводятся по расписанию в соответствующих центрах, где на них может записаться кто
угодно. У этих курсов обычно больше участников, но они не учитывают специфику компании, проекта или
продукта, так как участники с большой долей вероятности будут иметь разный бэкграунд. Хороший открытый
курс предоставляет массу возможностей для налаживания связей; общение с другими людьми с похожими
интересами и аналогичными задачами исключительно полезно для самообразования и позволяет очень хорошо
оценить преимущества от работы с Agile-сообществом.
Поиски хорошего сертифицированного курса по Agile напоминают прогулку по минному полю. Большинство
аккредитованных курсов используют похожую программу, но некоторые преподаватели имеют более
качественное представление о своем материале, чем другие. Как и в других областях, рекомендации могут иметь
решающее значение. И стоит отметить, что в сообществе Agile есть настоящие звезды преподавания, так что
если вы хотите получить сертификат с подписью мастера, то у вас, безусловно, будет такая возможность.
Коучинг и менторинг
Мы питаем смешанные чувства относительно некоторых аспектов формальной Agile-подготовки, но это ни в коей
степени не распространяется на менторинг и коучинг. Наличие опытного коуча, который помогает и направляет
команду с первого дня, исключительно полезно. Лучшие коучи всегда находятся на низком старте: они знают,
что большинство команд нуждаются в помощи, чтобы разобраться с гибкими механиками и подходами, и решают
очень конкретные вопросы. Хороший коуч исключительно полезен в данной ситуации; в то же время, если
проблемы команды связаны с пониманием фундаментальных аспектов Agile, коуч всегда должен быть готов
объяснить основы подходов и заложить прочное основание для их понимания.
Коуч Agile обычно не работает на полную ставку, даже если у команды достаточно денег, чтобы оплатить его
время. Работа на полную ставку создает опасность зависимости, и поэтому гораздо полезнее ограничить
взаимодействие команды с коучем одним или двумя днями в неделю. Даже меньшее количество часов
оказывается вполне достаточным для большинства организаций. В том случае, если вы все-таки хотите нанять
коуча на полную ставку, оптимальным вариантом будет предоставить ему место в проекте, чтобы он служил
примером для команды.
Если вы собираетесь перевести целую организацию на Agile, наличие коуча значительно увеличит вероятность
успеха. Не стоит зацикливаться на затратах, которые повлечет за собой найм коуча, – лучше подумайте о том, во
сколько вам обойдется его отсутствие. Если у вас все равно остаются сомнения, посмотрите, чего коуч сможет
добиться за 48 часов, растянутых на месяц. Вероятность того, что команда добьется значительного прогресса на
индивидуальном и коллективном уровне, очень велика. Вы вполне можете ожидать практических результатов
очень быстро; как минимум затраченные деньги на коуча должны гарантированно окупиться.
Добиться максимума от тренера с персональной точки зрения несложно. Успешность в данном случае зависит от
объективных достижений, а не личных мнений. Agile-коучинг – это больше личные консультации; коучи тут не
для того, чтобы оценивать, а чтобы направлять. Их советы помогают подчеркнуть ключевые моменты, которые
могут привести к успеху или к провалу. Например, неэффективные ежедневные совещания куда легче будет
исправить под руководством опытного профессионала.
Если нанять индивидуального коуча невозможно, предпочтительной альтернативой является поиск поддержки в
рамках организации и создание внутреннего Agile-сообщества. Эджайлисты обычно дружелюбны, а поиск
помощи расценивается как шаг к развитию, а не признак отчаяния. Ну а если и это не сработает, ищите ответы в
интернете на форумах и сообществах. Даже самые глупые вопросы будут встречены с пониманием – а некоторые
из них далеко не такие глупые, как может показаться на первый взгляд.
Блистательный совет
Вы всегда можете расслабиться и посмотреть фильм, который напомнит вам о преимуществах Agile:
• «Титаник» – история о том, как проект с большим бюджетом пошел ко дну (в буквальном смысле).
• «День Сурка» – история о пользе обучаемости.
• «Психо» – вот что бывает, если менеджеры не изучают принципы Agile.
• «Бункер» – печальные последствия иерархии управления.
• «12 разгневанных мужчин» – пример того, как влиять на свое окружение и добиваться консенсуса.
• «Кунг-фу панда» – история о том, как неожиданное сочетание коллег позволяет добиться успеха.
Подкасты и вебинары
Подкасты и вебинары являются характерным примером ключевых проблем современной техноэры. Несомненно,
в Сети существует масса материалов, но вопрос в том, насколько они качественны. Безусловно, есть несколько
очень хороших подкастов и вебинаров, но для того, чтобы найти их, понадобится немало времени. Сеть
заполнена маркетинговыми кампаниями и рекламными продуктами, так что вам придется перецеловать слишком
много лягушек, прежде чем одна из них превратится в Agile.
Есть определенные признаки того, что эта ситуация изменится в обозримом будущем, и на рынке уже
присутствует несколько отличных продуктов, но в целом текущее положение дел заставляет нас испытывать
скептицизм. Мы будем очень рады изменить наше мнение, так что не забудьте сообщить нам, если у вас найдутся
примеры, доказывающие обратное!
Agile-сообщество построено на доверии, взаимоподдержке и сотрудничестве. Сложно найти другое
профессиональное сообщество, которое оказывало бы такую же значительную поддержку своим членам.
Мировоззрение людей, которые занимаются Agile, отличается стремлением помогать, поддерживать и защищать
коллег – это отличные новости для всех, кто настроен на серьезное сотрудничество с этими людьми, и не очень
хорошие для тех, кто хочет воспользоваться ими для производства халтуры. Шарлатаны и обманщики не
задерживаются в Agile-сообществе надолго.
Добиваются успеха лишь те, кто всегда стремится помогать другим. Те, кто ищет лишь свою выгоду,
обречены на поражение.
Брайан Трейси
Большое количество доступного материала – одна из немногих проблем гибких подходов, поэтому
избирательность очень важна. Многие площадки учитывают это, используя механизмы самомодерации, где
пользователи голосуют за качественные материалы, тем самым продвигая их, тогда как менее качественные
материалы уходят в небытие. Благодаря этому найти полезную информацию не составит большого труда. То же
самое относится к другим источникам Agile-знания: их число внушительно, но, как и везде, источники есть
хорошие, а есть и плохие. Никто не сможет сделать правильный выбор за вас.
В силу всего этого источники информации по Agile могут отчасти напоминать минное поле, но умение
сориентироваться на нем является важной частью путешествия. То же самое относится и к постепенному
осознанию различий между полезными советами и личными предпочтениями. Количество доступной
информации и поддержки в освоении Agile делает наше время золотой эрой для вхождения в гибкость.
Не медлите!
• В Сети есть масса доступной информации; в худшем случае вы всегда можете задать вопрос в
профессиональном сообществе.
• Не все то золото, что блестит; не стоит слепо верить всему, что вы слышите: постарайтесь выработать свое
собственное мнение.
• Формальная подготовка полезна для резюме, но если вам нужен результат, то есть более удачные – и
неформальные – варианты.
• Менторинг и коучинг требуют затрат, но эти затраты обычно окупаются.
• Ищите новую информацию и идеи, но всегда оставайтесь верны себе.
Глава 9. Призыв к действию

Введение
Наверняка вы взялись читать эту книгу не из-за мимолетного интереса к теории гибких подходов или из-за
шумихи вокруг них. Возможно, вам предложили роль в Agile-проекте или появилась вероятность того, что проект,
в котором вы участвуете, будет запущен по-другому. Вне зависимости от причин, абстрактного исследования
основ гибких решений и размышлений о том, как перейти на Agile, недостаточно. Лучший способ изучить все
должным образом – засучить рукава и начать.
Главное, что нужно помнить, – Agile в первую очередь правильный способ мышления, майндсет. Придется думать
по-другому и решать традиционные проблемы новыми способами. Процессы могут быть строго ограничены – а
гибкие подходы освобождают и поощряют нас быстро и изобретательно адаптироваться к изменениям. В самой
сути Agile лежит идея «проверь и приспособься», а вовсе не некий набор правил и предписаний.
Гибкое мышление уникально, потому что может быть приспособлено к любой ситуации. Интересный вариант –
начать с планирования свадьбы или переезда; тут может помочь персональный Канбан. Это может быть запуск
бизнес-проектов или благотворительных проектов или даже работа в рамках определенных дисциплин, таких как
маркетинг или продажи. Вне зависимости от области применения, нет практически никаких сфер, в которых бы
Agile не работал, потому что это набор принципов, которые применяются, чтобы вдохновлять людей, устранять
лишнее и повышать качество.
Так что после длинного пройденного пути будущее кажется более радостным для проектов и для людей, которые
над ними работают. Будущее выглядит неплохо; оно становится более гибким. Давайте приниматься за работу.
Опробуем все в действии.
Предоставление гибкости
Лучше всего к работе с применением гибких фреймворков подходят люди, которые прекрасно представляют
себе, как достигать целей. Они знают, как добиться нужных результатов, практичны, но гибки в подходе. Всегда
пробуют что-то новое, но несколько идей за раз; затем оставляют то, что работает, и отбрасывают остальные. Те,
у кого есть гибкое мышление, не тратят время на рефлексию, когда что-то идет не так, а пробуют другую идею в
поисках лучшего варианта.
Эти прирожденные пользователи Agile знают простую вещь: все дело в людях, а не в технологиях или процессах.
Если собрать правильных людей, эффективно работающих вместе над четко поставленными целями, успех не
заставит себя долго ждать. Agile позволяет этому случиться – в конце концов, в чем смысл собрать отличную
команду экспертов вместе, а затем убить весь потенциал произвольными управленческими решениями и другими
ложными ограничениями?
Если мы посмотрим вперед, в следующее столетие, мы увидим, что лидерами будут те, кто поддержит
других.
Билл Гейтс
Чтобы люди справились с задачей наилучшим образом, нужно обеспечить несколько важных вещей:
• Точно определить видение. Обозначьте цели и опишите нужные результаты в видении с логичными и
достижимыми критериями.
• Обозначить роли и обязанности. Чтобы работа велась эффективно, соберите всех профессионалов вместе и
убедитесь, что каждый представляет, какую роль он будет исполнять.
• Убрать любые препятствия. Сделайте процесс работы над проектом простым для команды. Наблюдайте и
только затем действуйте.
Назад к истокам
Что бы ни случалось, всегда помните об основных принципах Agile. Не углубляйтесь в тонкости и хитросплетения
Скрама или Канбана – сосредоточьтесь на соблюдении Манифеста Agile и принципах бережливого управления,
которые лежат в его основе. Их легко понять и просто применять, и они суммируют все самое основное. Все
гибкие решения построены вокруг этих основных идей, и любые новые концепции, методы или практики будут
разделять их на уровне ДНК.
Начать Agile-проект – все равно что выйти на прогулку. Нужно знать, куда идешь, и просто ставить одну ногу
перед другой.
И быть готовым обойти любое встретившееся препятствие.
– Смит, вам нужно стать более гибким!
Люди, похоже, склонны чрезмерно все усложнять. Многие годами пытались переименовать, переосмыслить или
переопределить основные концепции в яркие, блестящие, изысканно упакованные и обычно дорогие продукты,
услуги или даже новые идеи. Легко с негодованием сказать, что все дело в простом зарабатывании денег, но
такое развитие стоит на весьма прочном фундаменте. Главное, убедитесь, что новые идеи совпадают с
исходными принципами, прежде чем инвестировать время или деньги в них. И помните: если что-то звучит
слишком хорошо, чтобы быть правдой, возможно, так и есть.
Если в какой-то момент все становится слишком сложным, вы что-то упускаете. Если дела становятся плохи
только время от времени, это вполне естественно, так как время от времени стоит ожидать неудач. Начать, а
затем постепенно понемногу улучшать дела – нормально. Ожидайте результатов, но не мгновенного разрешения
всех проблем.
Золотое правило для начала любого дела с Agile гласит: начинайте с простого. Не забывайте, что основные
процессы Agile не требуют таких фреймворков, как Скрам или Канбан. Чтобы начать, вам нужен только список
требований, отсортированный по их значимости. Начинайте с первого пункта. Не забывайте о Манифесте Agile и
материалах, изложенных в этой книге.
Можно работать уже прямо с этим, но мы рекомендуем использовать один из фреймворков – или Канбан, или
Скрам. Это прекрасные инструменты, предоставляющие ряд принципов, подтвердивших свою эффективность.
Вдобавок это еще и сообщество, готовое бесплатно помочь советом. Конечно, даже лучшие техники несколько
ограничены, если строго их придерживаться, так что держите в памяти их плюсы и минусы. Чтобы все
складывалось отлично, не забывайте – проверяем и приспосабливаемся.
Не отбрасывайте ничего без весомой причины. И ничего не добавляйте для красоты или потому, что кто-то
сказал, что это отличная мысль. Добавляйте какой-то элемент, только если он необходим для упрощения
процесса выпуска продуктов или услуг.
Блистательные «можно» и «нельзя»

Основываясь на опыте, можно выделить несколько вещей, которые стоит и которые не стоит делать с самого
начала:
Стоит:
• Выбрать небольшой проект с малыми рисками, чтобы на нем опробовать Agile.
• Объяснить людям, почему вы считаете, что Agile будет полезен.
• Четко представлять себе видение, цели или задачи.
• Делать то, что вы делаете, понятным и прозрачным.
• Начать прямо сейчас.
Не стоит:
• Пытаться все сделать самостоятельно.
• Зацикливаться на самом процессе.
• Брать на себя слишком много.
• Пробовать слишком много новых техник за раз.
• Усложнять.
Постоянное совершенствование
Agile предлагает нам быстро учиться на своих ошибках. Как часто вы думали: «Если бы я только знал то, что
знаю сейчас»? Обучаемость – ключ к успеху как в плане избежания ошибок, так и в плане повторного
использования удачных идей. Именно ее закладывают в свою основу гибкие подходы. С момента самого
появления принципов бережливого производства предполагается, что всегда есть пространство для улучшения
всего, что мы делаем, а непредвзятый подход к совершенствованию процесса приносит свои плоды.
Во многом это отражает разницу между гибкими и более традиционными подходами к управлению проектами.
Agile поощряет тщательное изучение и рассматривает полученные уроки как положительный опыт, а не
раздражающую проблему. Слабые стороны превращаются в преимущество. Вместо того чтобы попытаться
замести следы или искать козла отпущения, обучение и полученные уроки рассматриваются как естественная
часть процесса. Вам не нужно самостоятельно делать все ошибки; учитесь на опыте остальных.
Подобно тому, как изменения поощряются Agile, ошибки также действуют положительно и никогда не считаются
трагедией. Суть гибких подходов – постоянно находиться в поиске возможных улучшений.
Томас Эдисон испробовал 2000 различных материалов для нити накаливания. Когда ни один из этих материалов
не подошел, его помощник пожаловался: «Вся наша работа напрасна. Мы ничего не узнали». Эдисон очень
уверенно ответил: «О, мы прошли долгий путь и многому научились. Мы знаем, что есть 2000 элементов, которые
мы не можем использовать, чтобы создать хорошую лампочку».
Рассказ из темных (буквально) веков
Не переставайте учиться
Совершенно естественно, что большинство людей не любят учиться на ошибках. Не слишком-то приятно
оглядываться назад и переживать прошлые неудачи, поэтому многие команды предпочитают этого избегать.
Более того, встречи, посвященные работе над ошибками, часто рассматриваются как возможность для сведения
счетов. Коллеги тычут друг в друга пальцами и разбрасываются обвинениями. Разочарование усугубляется тем,
что результаты подобных обсуждений редко принимаются во внимание и рекомендации исчезают в
киберпространстве, чтобы никогда не возвратиться.
С бережливым управлением и Канбаном учеба на ошибках становится не досадным отвлекающим фактором, а
смыслом. Основной целью их использования является улучшение производственного процесса, и рассмотрение
прошлых успехов и неудач является важной его составляющей. В силу культуры Agile поиск козлов отпущения
исключен, и благодаря этому вырабатывается открытая и честная рабочая обстановка. Попытки унизить коллег
и возвысить себя являются исключительно негибкими.
В случае со Скрамом ретроспективы являются важной составляющей процесса. Вместо того чтобы дожидаться
окончания проекта, ошибки рассматриваются в конце каждого спринта, что позволяет сразу же вносить
изменения. Команда прикладывает совместные усилия, чтобы предоставлять обратную связь на ранних этапах и
решать проблемы по мере их поступления. Если это не происходит, то это один из первейших сигналов, что
команда работает не так, как надо.
Счастливые команды работают лучше. Любой предпочтет работать там, где его чувства принимают во внимание,
а коллеги постоянно стараются облегчить выполнение задач. Это дает уверенность в своих силах и ведет к
успеху. Более того, это приводит к формированию спирали счастья. Улучшение рабочего окружения, процесса,
продукта, общения и боевого духа стимулирует команду работать еще лучше.
Будущее Agile
Одно можно сказать совершенно точно: Agile – это не просто однодневное явление. Появлялись и исчезали
разные методологии, но в случае Agile все не так просто. Основу Agile составляет здравый смысл, а остальные
аспекты логичны и усваиваются на лету. Многие люди, которые впервые знакомятся с Agile, оказываются
поражены его простотой. Оценки успешности гибких решений остаются феноменальными и не ухудшаются с
течением времени. А все потому, что Agile дает именно то, что обещает.
Итак, что же ждет Agile дальше? В некотором смысле гибкие решения стали жертвой собственного успеха.
Многие уже попытались приспособить их под свои правила, принципы и убеждения. Другие пытались превратить
их в товар для продажи или даже запатентовать их как свою интеллектуальную собственность. Это текущий
процесс, но нет никаких свидетельств того, что Agile теряет свою репутацию или отрывается от своих основ и
ключевых принципов.
Нет никаких сомнений в том, что Agile подходит не только для маленьких проектов, однако для адаптации к
большим организациям потребуется приложить некоторые усилия. Существует довольно большая разница между
количеством информации, заносимым в журнал в случае с большими организациями, а также количеством
координации, необходимой для налаживания работы между несколькими Agile-командами.
Более объемный журнал – не такая большая проблема, и его наличие иногда само по себе последствие успеха.
Проблема возникает тогда, когда одной команды недостаточно для выполнения всего массива работ.
Налаживание отношений между несколькими взаимосвязанными Agile-командами – неординарная задача. Очень
важно поддерживать между ними диалог.
Скрам предлагает решение, которое может быть применено везде. Команды состоят из рекомендованного
количества профессионалов, и каждая команда выбирает представителя, который будет участвовать в
ежедневной встрече с представителями других команд, называющейся «Скрам Скрамов». Такой метод может
быть использован и в любом другом фреймворке.
Рис. 9.1. Зонтик Agile
Расширение и массовое принятие нередко влекут за собой проблемы. Массовость означает больше возможностей
для непонимания и искажения идей. Например, крупные корпорации пытались использовать Agile, потому что
считали, что он даст отличные результаты при минимальных усилиях, но на практике это оказалось не так.
Другие отказывались от Agile после неудачной попытки использования, предпочитая винить в своих неудачах
инструмент, а не тех, кто его применяет. Все это указывает на то, что медовый месяц Agile подходит к концу и
наступает время критики, обычно связанной с недопониманием.
У PRINCE2 более надежное будущее, потому что он находится в собственности и под контролем. Он не менялся с
течением времени и вряд ли будет меняться в дальнейшем – он безопасен, надежен и постоянен. В свою очередь,
у Agile нет владельцев, а только приверженцы. С Agile может случиться все что угодно. Это делает его
прекрасным, но менее предсказуемым. Следите за тем, что происходит.
Не забывайте об азах
Независимо от того, как идут дела, не упускайте из виду основные принципы Agile и старайтесь от них далеко не
отступать. Лучше взять перерыв и поразмышлять над основополагающими вещами – Манифестом Agile и его
ценностями и принципами, ценностями бережливого управления, Декларацией взаимозависимости,
Руководством по Скраму и всем, что является фундаментом гибкого мышления. Не слишком концентрируйтесь
на мелочах – главное, следуйте основной идее. Agile прежде всего – образ мышления.
• Сосредоточьтесь на конкретных результатах. Самое главное – это обеспечение бизнес-ценности и выгоды.
Имейте мужество признать, когда что-то идет не так, постоянно старайтесь улучшить жизнь пользователей и
всегда держите в голове бизнес-видение, которое лежит в основе.
• Сделайте процесс работы прозрачным. Лучший способ гарантировать успех – дать другим понять, что
происходит, чтобы они могли использовать свои навыки и опыт. Скрытая работа не вариант. Проблемы, которые
не видны, не будут рассмотрены. Команда не может помочь с проблемой, о которой не знает.
• Делитесь всем. Без обмена не может быть никакой проверки и адаптации, не может быть непрерывного
улучшения. Выслушайте, поощряйте и развивайтесь – не отбрасывайте идеи. Именно обмен мыслями – основа
для обучения.
• Сотрудничайте и взаимодействуйте. Сила Agile – в самоуправляющейся команде, работающей совместно
над общей целью. Будьте открытыми и честными, поддерживайте друг друга и действуйте как команда – и успех
не заставит себя ждать. Вы хороши настолько, насколько хороши ваши коллеги.
Аудиторы хотели изучить два проекта в рамках общей проверки состояния здоровья. Это была смешанная среда,
использующая гибкие, а также более традиционные методы работы. Аудиторов особенно интересовала
сопровождающая документация, которая была доступна.
Agile-команда была открыта для сотрудничества. Количество документов было незначительным и касалось
только самых важных моментов. Напротив, руководитель проекта привел аудиторов в кабинет, заваленный
папками с бумагами. В дальнейшем руководитель проекта признался в приватной беседе, что большую часть
этих папок никогда не открывал.
Аудиторы высоко оценили работу этого руководителя проекта, тогда как оценки Agile-команды были не очень
высоки.
Иногда вы сталкиваетесь с непреодолимыми препятствиями. Открытость и честность иногда могут сыграть не в
вашу пользу, но это не делает их хуже.
Итак, это конец нашего совместного путешествия. Что же дальше? Ну, ничего не делать – тоже вариант для
любого проекта, будь он личный или профессиональный, так что, возможно, вы просто отложите эту книгу и
забудете о ней. Как бы нам ни нравился Agile, мы понимаем, что он не для всех. Может, вам помешают
непреодолимые организационные препятствия или гибкие подходы – это не то, что нужно именно сейчас. Нам
известно, что Agile не лекарство от всех болезней.
Мы надеемся, что многие из вас захотят отправиться в это путешествие, а еще больше наших читателей уже
находятся в пути. Это не самый легкий маршрут; гибкие решения легко понять, но еще легче трактовать
неверно. С помощью гибкого мышления и поддержки Agile-сообщества вы достигнете цели. Ведите личный
бэклог: это поможет вести счет вещам, которые вы попробовали, и оценить их пользу.
Канбан и Скрам просто блистательны, но не забывайте, что они не самоцель, а средство для достижения вашей
цели. Не усложняйте и готовьтесь меняться – рано или поздно это придется сделать. Взаимодействуйте с
другими, так как это методики для работы в команде, которые не так полезны в изоляции. Поддерживайте
отношения с людьми, которые думают так же, как и вы, – это весело и продуктивно. Живите и учитесь вместе.
К счастью, у Agile очень низкий порог вхождения. Некоторые начинают использовать Agile, даже не понимая
этого! Для этого не нужно готовиться, получать сертификаты и тратить деньги. Все, что вам необходимо, – это
желание начать.
Удачи!
Совершенствоваться – значит меняться; быть совершенным – меняться часто.
Уинстон Черчилль
notes
Примечания
1
Gherkin – это описательный вспомогательный язык для сценариев программ; его можно редактировать как
нарратив (повествование), т. е. «почти на человеческом языке» в простой, лаконичной форме и доступном
формате. – Примеч. пер.
2
Покер планирования (planning poker) – техника оценки, основанная на достижении договоренности, главным
образом используемая для оценки сложности предстоящей работы или относительного объема решаемых задач
при разработке программного обеспечения. – Примеч. пер.
3
Сеть британских супермаркетов, основана в 1904 году. – Примеч. ред.
4
Например: Стиллмен Эндрю, Грин Дженифер, Head First Agile. Гибкое управление проектами. СПб.: Питер, 2019.
– Примеч. ред.
5
На момент издания книги сеть LinkedIn по-прежнему остается заблокированной в РФ. В качестве альтернативы
читатели могут поискать информацию об Agile в таких деловых социальных сетях, как «Мой круг», E-xecutive.ru,
Viadeo, «Профессионалы. ru», XING. – Примеч. ред.
6
Сертификаты ScrumAlliance и Scrum.org можно получить в России. – Примеч. ред.
7
Из русскоязычных крупных сообществ стоит отметить Agile Russia (http://agilerussia.ru/), где есть возможность
подготовиться к сертификации по ScrumAlliance и Scrum.org. – Примеч. ред.

Блистательный Agile. Гибкое Управление

Загружено:

Авторское право:

Доступные форматы

Блистательный Agile. Гибкое Управление

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Блистательный Agile. Гибкое Управление

Загружено:

Авторское право:

Доступные форматы

Блистательный

Agile. Гибкое управление

Что такое гибкое управление проектами?

Роб Коул, Эдвард Скотчер

Роб Коул, Эдвард Скотчер

© Lexray Limited and Agility in Mind Limited, 2015

Посвящается Альфи и Сисси, Элле и Элис, Нкейру, Лизе, Амаре и Джо

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

Фунтов Валерий Николаевич д.э.н., PMP, Agile-коуч и тренер

Глава 1. Новый мир, бросающий вызов:

Не все то золото, что блестит. Не все, кто блуждает, – потерялись.

Основополагающие принципы Манифеста Agile

Рис. 1.1. Треугольник управления проектами

Заказчик должен быть доволен

Нет, спасибо, без изменений

Начните с малого, недорогого и быстрого

КФУ для Agile-проекта обычно включают:

1. Lean, бережливое управление

Семь принципов бережливого управления:

Где не стоит применять Agile:

Слишком хорошо, чтобы быть правдой

Джессика Савитч (американская телеведущая)

Глава 2. Agile совсем другой!

Тьма перед рассветом

Мерой интеллекта является способность меняться.

Начало реализации проекта

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

Жизнь становится легче

Испытание для руководителя проекта

Не переходите на Agile, если:

Классические примеры, где не подойдет Agile:

Глава 3. Начало: готовимся быть гибкими

Удача – это пересечение пространства возможностей и готовности ими воспользоваться.

Определение видения проекта

Руководствуясь идеей бизнес-ценности

Формирование команды проекта

Создание журнала требований

Как сделать так, чтобы с самого начала все пошло наперекосяк

Определите базовую функциональность

Создайте функциональные группы

Определение первого выпуска

Расскажи мне историю

Выработка критериев принятия

– И нашему пользователю сразу будет понятно, где аварийный выход!

Когда размер имеет значение

Лучший способ выработать здравые оценки:

Меньше значит больше

Менеджмент рисков и ожиданий

Ведение журнала требований

Создание рабочей среды

Если вы не знаете, куда идете, то и придете куда-нибудь.

Йоги Берра (американский бейсболист)

Алисса Урбано (блогер)

Канбан отлично подходит для

Рис. 4.1. Канбан-доска

Больше чем просто доска

Дешевые и высокотехнологичные альтернативы

Блистательный совет для сохранения времени

Создание журнала требований работ

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