Представьте ситуацию. Scrum команда: 3 back-end разработчика, Scrum-мастер, front-end разработчик и тестировщик. Все работают в режиме двухнедельных итераций, осуществляют командное планирование в начале каждой.
На очередном планировании итерации команда собралась, чтобы обсудить задачи и составить план задач.
Идет оценка следующей User Story:
Как менеджер системы учета платежей, я хочу иметь возможность удалять заказы, время неактивности которых превышает 25 дней.
Приемочные критерии:
Команда использует Planning Poker для планирования. Scrum-мастер объявляет начало голосования. Спустя 5 секунд команда делает первые оценки:
Scrum-мастер (вопрос первому программисту): Почему ты оценил задачу в 3 Story Points?
Back-end программист: Нам нужно всего лишь добавить удаление с условием и написать несколько юнит-тестов для тестирования этого функционала.
Scrum-мастер (вопрос тестировщику): Почему 7 Story Points?
Тестировщик: Два спринта назад мы выпускали User Story по редактированию неактивных платежей, чтобы менеджеры могли исправлять ошибки в тех заказах, где пользователи допустили ошибки. На этапе тестирования этой задачи была выявлена критичная ошибка, которая повлияла на взаимодействия модулей PMM (Payments Management Module) и URM (User Relations Module). Этот дефект подробно описан в нашем командном менеджере задач. Мы потратили целый день на рефакторинг и исправления этой части системы. Скорее всего, нужно учесть эти риски при оценке задачи.
Scrum-мастер на ноутбуке, через подключенный проектор открывает систему учета задач и находит дефект, о котором говорит тестировщик.
Back-end программист: Да, точно, мы не успели закончить рефакторинг части URM. Там и правда может выскочить все что угодно.
Scrum-мастер: Отлично, давайте переголосуем.
После второго этапа голосования команда озвучила следующие оценки:
Scrum-мастер: Оценка задачи – 5 Story Points. Идем дальше.
Как видно из примера, тестировщик смог отстоять свою оценку, аргументируя ее предыдущим опытом. У тестировщика «не замылен глаз» и иногда его точка зрения может заставить программистов задуматься о нюансах на этапе оценки задач.
Как вы думаете, было ли эта дискуссия полезна для проекта? Действительно ли тестировщик помог команде с правильной оценкой задачи или внес дополнительные разногласия? Какие еще истории встречались в вашей практике?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
@Katoo Верно подмечено, сразу видно, что тестировщик! Смена оценки, психологический аспект переговоров. Когда видно, что остальные заколебались, но приняли пересмотреть общее решение, человек может немного смягчить свои условия. В статье я нарочно поставил такие оценки, чтобы кто-то задал этот вопрос. Ведь программисты могли бы проголосовать с оценками 7, почему не проголосовали? Могли опровергнуть слова тестировщика, аргументируя это сложными связями внутри логики кода, о которых тестировщик даже не догадывается. Почему не сделали?
Тестировщик всегда находится в невыгодной позиции, ведь он хуже знает структуру кода приложения, и обычно тестировщиков меньше чем программистов. В ситуациях, когда нужно отстоять свою точку зрения, тестировщику нужно оперировать теми связями, которые заставлять программистов пересмотреть свою точку зрения, а не противостоять им. Иначе есть риск оказаться некомпетентным в своей зоне некомпетентности. А еще, хороший тестировщик имеет очень важное достоинство – виденье системы с точки зрения конечного пользователя.
по моему все замечательно, мне кажется хороший зрелый тестировщик должен задавать такие “неудобные” вопросы. прошлый опыт, представление о структуре проекта в общем должно помогать выявлять такого рода риски.
Чего-то я не поняла, а почему тестировщик во втором раунде изменил свою оценку. Он разве что-то новое узнал?
Судя по диалогу, первый программист гораздо хуже знает архитектуру разрабатываемого ПО, чем тестировщик.
)))Весьма своеобразная команда.
И еще вопрос. Они (в смысле все 6 человек, принимающих участие в разработке) архитектуру ПО в голове держат?
ПС, Ставлю на 10 стори-поинтов. Поскольку программист архитектуру в расчет не берет, а значит в проекте куча заплат)))
Самая засада в том, что все равно будет 7 стори-понитов. Потому что риски и т.д. не оценены правильно, а просто аппроксимировались из прошлых итераций 🙂
Но это уже другая материя. А тестировщик – молодец, доказал!
спасибо, поправил
Все по теме!
“Команда использует Pnanning Poker” опечатку поправте.