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

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

Размер задач зависит от опыта команды. Мне нравится, когда каждый день можно глазами посмотреть, что поменялось в проекте. Постарайтесь делать декомпозицию, чтобы задачи было просто проверить, а трудоемкость была от 1 до 8 часов (если вы оцениваете в часах, а не в Story Points). Опять же, не всегда получается, да и опытная команда будет сопротивляться такой мелкой разбивке. Опытным нужны крупные куски. Но для молодых и дерзких управляемость сильно возрастает.

Сугубо технические задачи, типа «Удали поле id из таблицы Users» – дрянь. Формулировки лучше делать на уровне фич: «Форма обратной связи» или «Отправка письма о восстановлении пароля».

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

Не старайтесь забить время спринта под завязку. Например, в двухнедельный спринт команды из трех человек засунуть задач на 240 часов. Лучше иметь небольшую подстраховку на код-ревью, рефакторинг, отладку и закон Мерфи. Про него известно, что он точно случится. Сколько взять подстраховки – зависит от опыта команды и задач. Нужно подбирать эмпирически. Начните с 20 %: не 240 часов, а 190. Через пару спринтов нащупаете свою реальную производительность.

Такая подстраховка не нужна, если вы работаете в Story Point. Она зашита внутри оценки.

Кроме разработчиков, на планирование я приглашаю тестировщика. Так он будет в контексте и меньше рисков, что под видом «багов» он насыплет команде отсебятины.

Фиксируем цели спринта. Две-три, не больше. Кратко описываем будущий прирост функциональности. «Реализовать личный кабинет дилера», например. Хорошо бы их вывесить на стене, чтобы спотыкаться о них глазами.

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

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

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

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

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

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

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

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

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