Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер Страница 3

Перечисленные принципы – замечательные, но какие же основные проблемы существуют сейчас в среде управления проектами? Что именно Agile пытается исправить?

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

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

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

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

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

Блистательная мысль

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

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

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

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

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

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

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

Прежде подразумевалось, что после того, как все точки над i расставлены и все утверждено, изменения не приветствуются – ну или, по крайней мере, тщательно контролируются. Многие популярные подходы к управлению проектами, такие как PRINCE2 (PRojects IN Controlled Environments – проекты в контролируемых средах), фокусируются в рамках четко определенных требований и строго регламентируют контроль изменений. Изменение не одобряется и считается плохой новостью для бизнеса.

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

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

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