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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если команда зрелая, а бюджеты позволяют (для сайтов это почти всегда не так – всем дорого), покрывайте рутинные проверки автотестами. Или, как минимум, формализуйте тест-план для критических маршрутов проведением смоук-тестов на продуктиве. Например, в интернет-магазинах покрываем тестами маршрут Каталог -> Карточка товара -> Добавление в корзину -> Корзина -> Чекаут. Критических тестов не должно быть много, и они не должны занимать много времени. Но должны вселять уверенность, что ключевые функции в порядке.

В заказной разработке редко, но встречается клиент, который не видит ценности в тестировании. Речь идет не о манипулятивном приеме, попытках отжать скидки или загнать разработчика под плинтус («Я что, должен за ваши косяки платить?!»). А об искреннем непонимании, как возможно, что после тестирования, тест-кейсов и всех этих довольно дорогих процедур – я, как заказчик, нахожу ошибки. Причем такие, которые кажутся мне очевидными. Они меня бесят! Я не понимаю, на что тратятся время и деньги.

Совет

Немного помогает, если у заказчика есть доступ на чтение баг-листов, и он видит, что команда нашла и исправила несколько сотен ошибок. Но утешение слабое, осадочек остается. Отправлять баг-листы нужно до того, как претензия созреет, а не после. Действовать от силы, а не от слабости. При этом должна быть определенная культура ведения баг-листов: смотрите главу «Правила письменной контрацепции». Однако лучше всего попадать в ожидаемое качество и давать гарантию на свою работу.

3.7. Демонстрация продукта. Завершение спринта

Говорят, в Царской России при испытании нового железнодорожного моста под него ставили всех строителей. А сверху пускали паровоз. Мосты век стояли. А разработчик – либо герой, либо – труп.

Нужно демонстрировать результат работы лично, ставить шкуру на кон! Это бодрит. Подстегивает ответственность и рост качества продукта. Боли, правда, будет больше. Но это полезная боль.

Согласуйте демонстрацию заранее. Если проект долгоиграющий – запланируйте стандартное время, в которое будете показывать спринты. Например, каждый вторник, 16:00. Времени резервируйте около часа. Нужна будет либо личная встреча, либо видеосвязь с демонстрацией экрана.

Со стороны бизнеса присутствует как минимум Product Owner. Пользователи и другие сочувствующие – допускаются. Со стороны разработки – вся команда. Понятно, что бывают исключения, но стремимся к этому.

Для начала я вкратце рассказываю, что успела команда за спринт. Вспоминаем цели спринта. Дальше, с экрана, показываю инкремент. Команда помогает, рассказывая, что, как и почему было сделано. В идеале каждый рассказывает про свой вклад. Разработчики помогают с ответами на технические вопросы и обоснованием решений.

Ради чего все это затевается: обратная связь в режиме реального времени. Пусть жесткая, но честная. По сути, обсуждается только первое впечатление, но оно не врет. WYSIWYG – What You See Is What You Get, или «если тебе кажется, что что-то не так, – скорее всего, тебе не кажется».

По опыту большая часть обратной связи будет конструктивной и позитивной. Особенно с англоговорящими заказчиками. Бояться демонстраций не надо. Надо готовиться. Продумайте чуть заранее:

По каким путям проведете зрителей в продукте.