Текст книги "Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban"

Роб Коул, Эдвард Скотчер
Блистательный 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 прекрасно справляется с задачей определения правильного направления уже на ранней стадии работы над проектом. Вычленение самого важного из списка требований предотвращает ненужные траты и помогает в дальнейшем не упустить возможности.