Привет, это Аня Устина, проджект-менеджер Joy Dev. Работаю в компании чуть больше двух лет и хочу поделиться с вами выводами, которые сформировала за это время. Цель любого спринта - добраться до финишной прямой быстро и качественно, избежать травм и выйти на следующую дистанцию. Я расскажу, как мы набивали шишки в поисках идеального спринта и к каким выводам пришли.
Как появился Scrum
Принципы методологии Scrum впервые были сформулированы еще в 1989 году в Harvard Business Review. Не последними в рождении этой методологии стали концерн Тойота и цикл OODA концепции боевой авиации. А если учесть, что Тойота вместе со всей Японией по сей день впереди планеты всей, то можем сделать выводы, что в стране восходящего солнца что-то знают о планировании, постановке и выполнении задач. И если мы исповедуем принципы Scrum, то точно знаем, что основой основ являются спринт и итерация
У каждого урагана есть своё имя
Я выделила 4 типовые проблемы со стороны заказчиков из различных проектов и типизировала их. В целом можно выделить такие категории:
Исходя из таблицы, делаем вывод, что во всех вышеперечисленных случаях итог примерно один: потери рабочего времени, снижение рейтинга приложения из-за багов, снижение прибыльности разработки и большое количество затраченных нервов на решение этих проблем.
На деле проблем гораздо больше, но в рамках данной статьи мы говорим об идеальном спринте, а не проекте.
Подходы к решению проблемы
а) Детальная декомпозиция: составляется для того, чтобы сформировать порядок работ по проекту и оценить затраты рабочего времени на разработку. Соответственно, формируется и понимание бюджета.
б) Обсуждение с заказчиком большого числа юзкейсов: на этапе формирования пользовательских историй выявляется значительное число функциональных и нефункциональных требований.
в) Постоянный контроль работоспособности back-end: внесение изменений на сервере должно происходить максимально незаметно, в противном случае это может вызвать отток части пользователей.
г) Постоянный контроль актуальности документации: речь и о техническом задании, и о свагере и его аналогах; разработчик всегда имеет возможность сверить фактическое поведение с тем, какое подразумевалось, а если на сервере происходят изменения, то их необходимо и очень важно отражать в документации.
д) Постоянный контроль актуальности дизайна и адекватности комментариев: доработки дизайна возможны только по согласованию сторон и в части не рассмотренных ранее кейсов одной фичи; если дизайн дорабатывается после того, как команда с ним ознакомилась, это может привести к рассинхрону реализации функциональных требований между платформами, что в свою очередь ведёт к неоправданным доработкам.
Инструменты решения проблем с точки зрения управления проектами:
чек-лист ведения проекта - когда команда договаривается о порядке ведения задач, всем становится понятна последовательность действий;
постоянная отчётность тестирования сборок и точный график её подачи;
дейли, проработка планов и ежедневное снятие статусов - эти процессы позволяют в каждый момент времени понимать, кто чем занят на проекте;
журнал изменений - если не получается в первоначальной постановке задач и декомпозиции учесть все нюансы реализации, то стоит завести журнал изменений и согласованных договоренностей;
реестр учёта рисков - прогнозируемые риски могут быть подсвечены из декомпозиции проекта и должны быть задокументированы с прогнозами изменения эстимейтов; внезапные риски связаны с изменениями дизайна, корректировками пользовательских историй и неактуальной документации проекта.
А теперь перейдём к математике: формула разработки и почасового планирования того самого идеального спринта.
… и вот начинается разработка
Наш совет: записывайте абсолютно все ваши гениальные идеи в блокнот. Команда обязательно их воплотит в жизнь, т.к. для разработки в принципе нет ничего невозможного. Кроме как делать в 5 раз больше в те же самые сроки и постоянно переделывать - вот именно это невозможно.
Немного математики
Уравнение идеального спринта будет выглядеть так:
IS = WP + Dev + B + T + BF + RT + R
где 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
Итак, идеальный спринт состоит из:
Это только в инди-играх мы можем ускорять и замедлять время. В реальной жизни это невозможно. Как показывает исследование, плотно упакованный спринт - это, в первую очередь, чуть больше недели разработки (количественный показатель). А всё остальное время - работы, связанные с улучшением качества: отладка и тестирование. Таким образом, мы имеем несжимаемый показатель «время» и все составляющие спринта.
ТОП-10 ошибок проджект-менеджера при работе с планированием спринтов
1. Брать в работу задачи, постановку которых ты не понимаешь.
2. Брать в разработку задачи, для которых нет даже документации Backend
3. Брать в работу задачи, если дизайн ещё не утвержден.
4. Брать в работу задачи, если заказчик постоянно вносит “улучшения”.
5. Брать в работу задачи, если дизайнер или аналитик не понимают, что такое “платформо-зависимые фичи”
6. Нарочно урезАть сроки разработки, надеясь, что “успеем”.
7. Вносить коррективы в постановку задач на финальной стадии разработки.
8. Добавлять задачи в спринт, когда начат регресс.
9. Пытаться затолкать “ещё эту маленькую задачку” в спринт, длительность которого ограничена временнЫми рамками.
10. Игнорировать важность составления и актуализации технической документации проекта.
Заключение
В общем, за 2 с лишним года я познала науку спринтов (и до сих пор продолжаю познавать), и постаралась поделиться с вами своими выводами и полезными инструментами для планирования. Если вам нужны грамотные специалисты по ведению, аналитике и разработке проектов, обращайтесь на почту hello@joy-dev.com.
В комментариях буду рада обсудить ваши проектные и спринтовые истории)