В силу своих обязанностей я каждую неделю пишу план работы каманды QA на неделю. (Следует сказать,что вместо методологии разработки - только хаос). Столкнулась с тем, что задачи с пятницы редко когда не приходится переносить на понедельник в связи с изменением в расписании.
Переносить задачи приходится потому, что возникают непредвиденные (для меня в момент написания плана) дополнительные задачи, например, баги от юзверей; заказчику предоставилась возможность презентовать свой продукт на конференции или тренинге,и ему срочно нужен новый билд с пофикшенными багами #x, #y, #z ("Да,я знаю,что вы должны были в пятницу выложить билд с пофикшенными 10 тикетами, но мне нужны только 5 и завтра!"); фидбек билда, запланированного на тестирование, а потом его внезапный приход, когда программист справился быстрее,чем ожидал и обещал; и т.д. и т.п, все то,с чем маленькая аутсорсовая компания сталкивается довольно часто.
Я думала о том,что было бы хорошо планировать какое то резервное время (так называемая "неопределенность") с учетом рисков, которые могут возникать, на n часов в неделю в зависимости от проектов, над которыми ведется работа. Такой подход позволил бы выдерживать эстимейты и приходить к концу недели с выполненным планом. Но в плане пустые поля уж точно будут выглядеть странно.
Строгие эстимейты, пожалуй, должны привязываться к итерациям, а не к неделям (в моей компании итерация редко длится неделю), ведь это гораздо критичней. Однако недели складыаются в итерации...
В данный момент ведение плана и организация работы, как есть сейчас, устраивает всех, кроме меня - с такой организацией работы отдел тестирования с трудом проэстимейтит выполнение какой-либо задачи и с еще большим трудом завершит ее в срок.
Думая о том, как решить эту проблему, я нашла несколько вариантов, которые имеют свои плюсы и минусы.
1. Заключение "мирного договора" между программистами и тестировщиками.
Такой договор может быть составлен на основе мастер тест плана или в любом другом виде. Суть в том, что документ должен определять сколько билдов мы ждем на тестирование и примерное время их выдачи. Также могут быть описаны правила поведения обеих сторон при появлении, снова-таки, форс-мажорных обстоятельств - например, время, которое тестировщики готовы дать программистам на переделывание фидбекнутого обещанного ранее билда. Не успел - извини...
Однако такой подход не приемлем для ПМов и вообще пагубно сказывается на фактической разработке, хоть и делает программистов более дисциплинированными.2. Приоритизация задач.
При появляении новой внезапной задачи просить ПМа приоритизировать ее (если реально сложно сделать это самому), при этом обьяснив, что работа над проектами А и В сдвигается на n дней,если делать новую задачу срочно и всеми тестерами. Здесь могут найтись новые варианты распределения людей по задачам :) Пожалуй, у этого метода минус только в том, что необходимо отвлекать ПМа от его обязанностей. А с другой стороны, он ведает всей информацией о приоритетах и планах, так что без него тут не обойтись.
3. Планирование буфера неопределенности на основе имеющейся статистики.
