Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban (pdf+epub) Коул Роб

Введение

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:

• закупаясь к свадьбе;