Спринт, от которого конч*т заказчик - вывели свою формулу

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

Принципы методологии Scrum впервые были сформулированы еще в 1989 году в Harvard Business Review. Не последними в рождении этой методологии стали концерн Тойота и цикл OODA концепции боевой авиации. А если учесть, что Тойота вместе со всей Японией по сей день впереди планеты всей, то можем сделать выводы, что в стране восходящего солнца что-то знают о планировании, постановке и выполнении задач. И если мы исповедуем принципы Scrum, то точно знаем, что основой основ являются спринт и итерация.

Я выделила 4 типовые проблемы со стороны заказчиков из различных проектов и типизировала их. В целом можно выделить такие категории:

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

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

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

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

в) Постоянный контроль работоспособности back-end: внесение изменений на сервере должно происходить максимально незаметно, в противном случае это может вызвать отток части пользователей.

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

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

А теперь перейдём к математике: формула разработки и почасового планирования того самого идеального спринта.

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

Уравнение идеального спринта будет выглядеть так:

где IS - Ideal Sprint

WP - week planning

Dev - development

B - ПРы, МРы, билды и прочие прелести ПО

T - testing

BF - bugfix

RT - regress testing

R - release

Если говорить о нормировании, то тестирование должно составлять в общей сложности 30% от времени разработки, а отладка и багфикс - 20%. Таким образом:

Преобразуем формулу:

80 = 4 + Х + 3 +0,15Х + 0,2Х + 0,15Х + 5

1,5 Х = 80 - 4 - 3 - 5

1,5 Х = 68

Х = 45,3

Итак, идеальный спринт состоит из:

Это только в инди-играх мы можем ускорять и замедлять время. В реальной жизни это невозможно. Как показывает исследование, плотно упакованный спринт - это, в первую очередь, чуть больше недели разработки (количественный показатель). А всё остальное время - работы, связанные с улучшением качества: отладка и тестирование. Таким образом, мы имеем несжимаемый показатель «время» и все составляющие спринта.

1. Брать в работу задачи, постановку которых ты не понимаешь.

2. Брать в разработку задачи, для которых нет даже документации Backend

3. Брать в работу задачи, если дизайн ещё не утвержден.

4. Брать в работу задачи, если заказчик постоянно вносит “улучшения”.

5. Брать в работу задачи, если дизайнер или аналитик не понимают, что такое “платформо-зависимые фичи”

6. Нарочно урезАть сроки разработки, надеясь, что “успеем”.

7. Вносить коррективы в постановку задач на финальной стадии разработки.

8. Добавлять задачи в спринт, когда начат регресс.

9. Пытаться затолкать “ещё эту маленькую задачку” в спринт, длительность которого ограничена временнЫми рамками.

10. Игнорировать важность составления и актуализации технической документации проекта.

В общем, за 2 с лишним года я познала науку спринтов (и до сих пор продолжаю познавать), и постаралась поделиться с вами своими выводами и полезными инструментами для планирования. Если вам нужны грамотные специалисты по ведению, аналитике и разработке проектов, обращайтесь на почту hello@joy-dev.com. В комментариях буду рада обсудить ваши проектные и спринтовые истории)