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

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

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

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

Тезисы Agile-манифеста, принципы и прочие элементы гибкой философии звучат отлично, но как именно применять их на практике? Чем конкретно отличается Agile? Основное – это то, что с самого начала разработки продукта подход совершенно другой. Вместо того чтобы составить список требований и ограничивать внесение любых изменений, Agile начинает с определения необходимого минимума и работает уже с ним. Этот минимум так и называется – минимально жизнеспособный продукт (minimum viable product, MVP), или минимальный набор функциональности (minimum feature set, MFS).

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

Блистательный пример

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

Если рассматривать подготовку как проект с традиционным методом подхода, получится список вещей, которые необходимо купить, и это явно обойдется недешево:

• 3 костюма (чтобы их можно было менять);

• 10 рубашек (чтобы не стирать их каждую неделю);

• 5 галстуков (на выбор);

• 2 пары обуви (одна черная, другая коричневая);

• 1 пальто (зима всего-то через полгода);

• 10 комплектов нижнего белья;

• автомобиль, чтобы добраться до станции в восьми километрах от дома;