Ключевые идеи книги: Agile. Оценка и планирование проектов. Майк Кон

Краткое содержание книги: Agile. Оценка и планирование проектов. Майк Кон
Smart Reading

Smart Reading. Ценные идеи из лучших книг
Этот текст – сокращенная версия книги Майка Кона «Agile. Оценка и планирование проектов». Только самые ценные мысли, идеи, кейсы, примеры.

О книге

Каждый, кто хоть раз сталкивался с проектами, знает, как сложно на протяжении всей жизни проекта придерживаться плана, созданного в самом его начале. Часто это вообще невозможно. С тех пор как в 1970-х американские компьютерщики догадались, что разработка ПО не должна походить на работу сборочной линии, подход agile успел завоевать мир. Майк Кон – мировой консультант и коуч, стоявший у истоков метода, написал книгу «Agile. Оценка и планирование проектов» – отличное руководство по построению командной работы исходя из принципов гибкости и приоритета задач.

Люди и их взаимодействие важнее, чем процессы и инструменты. Работающее ПО важнее, чем документация. Клиенты и сотрудничество важнее, чем контракт и обсуждение условий. Готовность к изменениям важнее, чем первоначальный план. Эти принципы могут применяться далеко за пределами разработки компьютерных программ. «Agile» Майка Кона учит формировать и менять планы, превращать их в живой удобный инструмент, который не сковывает процесс, а помогает создавать отличный продукт и достигать любой цели.

Зачем читать

• увидеть разницу между объемом работы в проекте и его продолжительностью;

• научиться планировать работу на уровне проекта, итерации и рабочего дня;

• начать правильно расставлять приоритеты в проекте;

• построить эффективную командную работу в соответствии с принципами agile.

Об авторе

Майк Кон (MikeCohn). Основатель Mountain Goat Software – компании, оказывающей консалтинговые услуги и проводящей тренинги в области проектного менеджмента и построения процессов. Начинал карьеру в одной из крупнейших в мире IT-компаний, стоит у истоков разработки методологии agile и имеет более чем 20-летний опыт ее внедрения. Уйдя из бизнеса, продолжил работу в качестве консультанта и коуча по agile для команд IT-разработчиков и стал автором ряда книг по этой теме: User Stories Applied: For Agile Software Development (2004), Agile Estimating and Planning (2005), Suceeding with Agile: Software Development Using Scrum (2009).

Краткое содержание книги: Agile. Оценка и планирование проектов. Майк Кон

Оригинальное название:

Agile Estimating and Planning

Автор:

Mike Cohn

Тема:

Менеджмент

Правовую поддержку обеспечивает юридическая фирма AllMediaLaw

www.allmedialaw.ru (http://www.allmedialaw.ru/)

Не гибкий план, а гибкое планирование

Методология agile (гибкая методология разработки ПО) появилась около 20 лет назад. Она была создана в соответствии с международными стандартами проектного менеджмента специально для проектов по разработке программного обеспечения.

Традиционный подход к планированию проекта состоит в поэтапном построении плана, с указанием стадий осуществления проекта и дедлайнов. Метод agile отличается от этого подхода тем, что ориентирован не на финальный согласованный план, а на сам процесс планирования.

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

Что такое agile-планирование

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

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

Цель планирования – не расписать до мельчайших деталей весь список задач и назначить четкое время начала и окончания каждой. Это в принципе нереализуемо.

Планирование нужно, чтобы:

• оценить общий объем задач в проекте, предвидеть основные риски и попытаться их минимизировать;

• более четко сформулировать конечную цель всего проекта;

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

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

Именно поэтому планирование более важно, чем план. Гибкое планирование, а не гибкий план – это основа методологии agile.

Основные черты гибкого планирования:

• фокусируется на процессе планирования, а не на плане как документе;

• позволяет вносить изменения в план и поощряет их;

• приводит к созданию планов, которые легко изменить;

• распространяется на весь проект, а не на его отдельные части.

Недостатки традиционного планирования

Типичные планы ориентированы на список действий, а не на список предоставляемых результатов. Широко распространенная диаграмма Гантта, которую используют для построения большинства планов проектов, расписывает конкретные действия членов проектной команды с привязкой к календарю. Но на самом деле заказчик ожидает от нас не выполнения определенных действий, а предоставления ему определенных результатов.

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

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

Сетевое планирование не дает пространства для изменений. Это очень важно. У заказчика нет возможности изменить список целей проекта, не разрушив весь план. У команды тоже нет возможности поменять порядок работы. В итоге такой план, созданный еще до начала проекта, превращается в обязательство, а его изменения становятся нарушениями.

Чем планирование agile отличается от традиционного метода

Agile, прежде всего, базируется на другом наборе ценностей: на людях, а не на процессах, на сотрудничестве, а не на торге, на результатах, а не на плане.

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