Цикл "Agile: Планирование": Зачем нужно планирование?

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

Я решил эту сложную тему разделить на части. Мини-сериал, ага. Где во время обучения буду внедрять практики из книг и писать фидбек что получилось и что к чему привело.

Но начну с самого простого. С убеждения для чего нужно планирование. Поехали

Когда я прочитал это, то первым делом я спросил себя: "Что это за бред?". Зачем нам планировать, если планы в 90% случаях полетят в мусорку?

А потом всё же очень просто. Нужно не бояться планирования и быть максимально гибким на любое изменения.

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

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

Если оценка и планирование настолько трудны и если точную оценку невозможно получить вплоть до последней фазы выполнения проекта, то зачем этим заниматься?

Оценка и планирование - это не просто определение сроков или календарных графиков. Планирование, особенно непрерывное планирование итераций, - это поиск стоимости.

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

Хороший процесс планирования поддерживает такой подход, обеспечивая:

Планирование повышает вероятность успеха проекта, обеспечивая идентификацию проектных рисков. Одни проекты настолько рискованны, что лучше не браться за них.

На обсуждениях поднимаются вопросы, которые позволяют выявить подводные камни проекта.

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

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

Частая надежная поставка обещанной функциональности рождает доверие между разработчиками и заказчиками продукта. Достоверные оценки обеспечивают надежность поставки. Оценки нужны клиенту для распределения приоритеттов и принятия компромиссных решений.

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

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

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