Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

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

Карточки задач в канбан-доске спринта

Внутри каждой карточки уже развернутое описание.

Карточка задачи с детальным описанием

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

3.4. Planning Poker

Planning Poker – инструмент для оценки задач. Карты удобны тем, что участники команд не могут ориентироваться на мнение своих коллег – так оценки получаются максимально очищенными от субъективизма и влияния «авторитетов».

В колоде 4 разноцветных набора для 4 участников. Если участников больше – добавляем колоду.

Достоинства карт: 0 (значит задача готова или слишком мелкая), 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. Бывают карты с числами Фибоначчи или другой развесовкой, но мне нравятся эти.

Цифры – это либо часы, либо Story Point, в зависимости от того, как вы привыкли. Нам не нужно пытаться сделать сверхточную оценку. Это невозможно, скоро будут доказательства. Нам нужна адекватная оценка.

Итак, ведущий планинга зачитывает задачу. Участники выкидывают карты с оценкой. Рубашкой вверх! – это важно, иначе самый авторитетный товарищ продавит свои оценки, а робкие тихони отсидятся.

Карты Planning Poker (planningpoker.ru)

Далее карты вскрываются. Если оценки плюс-минус совпали – фиксируем их в задаче спринта. Если нет – надо обсудить дополнительно.

Например, кто-то выкидывает оценку гораздо большую, чем остальные. Он либо про эту задачу что-то знает-замышляет. Например, был хреновый опыт в прошлый раз или там в коде ТАКООООЕ! И надо его расспросить. Либо спит (разбудим). После обсуждений – уточняем нюансы и переигрываем кон.

Еще две специальные карты: Coffee/beer – если все затянулось, и надо сделать перерыв, и WTF – для джуниоров, которые вообще ни в чем не уверены.

При планировании спринта я предпочитаю физические карты. С удаленными – online-сервис или простой видеочат, куда на «раз-два-три» все скидывают свои оценки задач.

3.5. Стендапы. Burn Down Chart

Это простая диаграмма «сгорания» спринта. Ее удобно держать под рукой на стендапах.

Синяя линяя – фактически оставшееся время оцененных задач. Красная – плановое время. Мы видим, как по ходу спринта «сгорала» работа. Команда доделала все намного раньше плана, однако во второй трети спринта линии совпали. Тут нужно внимание.

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

3.6. Стратегии тестирования

Две крайности: отложить тестирование на конец спринта или тестировать каждую закрытую свежевыполенную задачу. Как говорил товарищ Сталин – обе хуже.

Откладывать на потом – плохая идея, однозначно! Вы можете забуксовать в самом конце, и у вас получится сырой спринт. Сдавать стыдно, выбросить жалко. Product Owner будет недоволен. А баги все равно придется фиксить.

Тестировать каждую мелочь сразу – тоже не круто. Во-первых, проверенную задачу могут поломать, когда будут делать какую-то другую. Это называется регрессией (regression bugs). Брукс в «Мифическом человеко-месяце» писал, что это фундаментальная (значит, толком нерешаемая) проблема – исправление одной ошибки с вероятностью 20–50 % влечет появление новой. Полное покрытие автотестами стоит неоправданно дорого, да и никто не даст на него времени. Надо дело делать, а не абстракциями заниматься.

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

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

Вы помните, мы добавили к задачам критерии приемки. Этакий чек-лист. Пусть его один раз прочекает разработчик при переносе задачи на проверку. Для самоконтроля. А затем еще раз проверит тестировщик.