Водопад, карты и баллы — 3 подхода планирования сроков в разработке ПО

Водопад, карты и баллы — 3 подхода планирования сроков в разработке ПО

В разработке ПО бывают ситуации когда нужно получить результат к определенному сроку. Чаще всего выбор падает на один из 3-х методов: Водопад, Баллы или Карта. Английский вариант: Waterfall, Roadmap и Story Points.

Водопад

«Древний» способ планирования, вышедший из теории Адама Смита про булавочную фабрику и разделение труда. Круто работает в сфера физического труда и материальных продуктов, но показал себя крайне плохо в сфера интеллектуального труда и разработки ПО.

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

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

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

Баллы или Сторипоинты

Этот метод описан в красной книге про Скрам. Есть опыт применения в достаточно сложных делах, в очень крупных компаниях с оценкой в миллиарды долларов.

В нем все хорошо. Но есть нюансы:

  1. Он очень дорогой в использовании и требует развитых компетенций управления в команде
  2. Имеет смысл применять его в задачах где срок находится на горизонте 6-12 месяцев. Если срок меньше — толку мало. Либо вообще не будет работать.
  3. Работает когда в команде есть 5-10 человек. Если в команде 1-3 человека — работать не будет.
  4. Им нельзя оценить срок отдельной задачи из всего множества задач в команде
  5. Им оценивается только 1 большая задача, над которой работает вся команда все время. Можно сказать что оценка срока по вехе — некой ключевой точке, к которой устремляется вся команда.

Более подробно описано тут:

Как оценивать сроки разработки в Scrum-команде? Используем Story Points, Burndown, Velocity & Capacity

Важно понимать что кроме сторипоинтов, надо вычислить velocity по команде & capacity по вехе. Тогда можно и срок получить.

Причем если оценивать сторипониты и получить велосити — можно относительно просто.

То вот для подсчета capacity — надо напрягаться, думать головой, в основном неокортексом. А это ппц как сложно и затратно. Большинство людей на это не способны. И птм часто эта штука просто не работает.

Дорожная карта

Вот это самый простой способ оценки сроков по задачам. Он же самый популярный. И на мой взгляд самый удобный.

Чаще всего встречал 3 уровня детализации периодов планирования по ДК:

  • помесячный
  • поквартальный
  • погодовой

Все зависит от сложности задач.

Все что нужно это делать 3 вещи:

  • распределять задачи по периодам: что пойдет в март, а что в апрель? а что в май? (ну или по кварталам или годам)
  • в конце каждого периода, делать обзор фактических результатов и проговаривать внутри команды что получилось хорошо, а что не получилось. обновлять план на следующие периоды. в разработке планы могут меняться и это нормально.
  • если план/факт сильно разлетелся, то стоит сделать разбор полета, выяснить причины, придумать что поменять, чтобы планы стали ближе к факту

Так тренируется мышца эмпирической оценки сроков внутри команды. Через 3-4 таких итерации, команда начнет плюс минус хорошо попадать в сроки.

Как именно они будут попадать в сроки — никто объяснить не сможет. Птм что это знание эмпирического типа.

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

Итого

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

Иногда их даже можно комбинировать и жонглировать. Если есть такие умения.

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

Планы бесполезны, процесс планирования бесценен

Дуайт Дэвид Эйзенхауэр, 34-й президент США (1953-1961)

Потому иногда можно планировать даже не правильно. Главное планировать хоть что то и общаться внутри команды 🙂 Зачастую это важнее для результатов чем сами планы.

Информация была полезна для вас?

Расскажите пожалуйста что мы можем улучшить?

оцените контент и участвуйте в выборе трендов