Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.

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

Начну с причин, потому что без их разбора нет смысла давать советы. Мне кажется из первой причины стоило копнуть еще глубже. Почему происходит столько много задержек? Почему команда целый день тратит на ревью результатов спринта, причем сборку надо залить за день до ревью? Откуда берутся многочисленные задержки, которые даже вынудили команду последний день итерации сделать не совсем рабочим? Первопричин может быть много, не берусь судить однозначно. Возможно не полностью автоматизирована сборка и установка приложения, может быть некоторые процедуры делаются по шаблону и из-за этого занимают много времени.

Вторая причина, указанная командой, является очень классической. Она пришла из поэтапного подхода к разработке, когда тестирование делается после завершения кодирования. При этом часто задачи на кодирование требуют несколько дней, что еще больше откладывает тестирование. И не меняя подхода, нереально ничего поменять.

Scrum предлагает комбинировать итерационный и инкрементальный подходы. А это значит, что в итерации команда делает одну фичу и только потом переходит на следующую. Такой подход заставляет распределять работу между членами команды и концентрироваться на достижении результата. Что делать тестировщикам пока нечего тестировать? Писать автоматизированные тесты, собирать тестовые данные, подготавливать необходимые процедуры и артефакты. Как только что-то готово, сразу передавать разработчику. Как только у разработчика что-то готово, сразу отдавать тестировщику. Таким образом, после завершения работы над задачей требуется минимальное время на ее тестирование.

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

Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:

• Планируйте ровно на столько, сколько вы можете полностью закончить в итерацию. Не тратьте время на планирование остального. Это и сэкономит вам время и не будет никому давать несбыточных обещаний. Лучше возьмите еще работы, если все закончите в срок. Это будет гораздо приятнее и команде и заказчику, чем в очередной раз получить часть обещанного не готовым.
• Для более плотной командной работы над задачами и инкрементальности внутри итерации установите лимиты на количество задач, которые находятся в прогрессе. Причем жесткие и непоколебимые лимиты. Они будут вас заставлять помогать друг другу, делить большие задачи на маленькие, автоматизировать ручную работу и не распыляться на много задач сразу. Это повысит вашу эффективность.
• Для решения проблем с циклом тестирования внедряйте активно автоматизацию. Причем не просто автоматизацию, а различные вариации TDD (Test Driven Development). Чем больше тестов будет написано до завершения реализации задачи, тем меньше времени уйдет на тестирование. Еще одна практика, которая очень сильно может помочь – Slicing Development. Не разрабатывайте по несколько дней целиком готовую фичу. Вместо этого выкатывайте несколько промежуточных реализаций с урезанной функциональностью и отдавайте на тестирование.
• Ну и последний совет очевиднее всех – проведите ретроспективу и разберитесь в том, что происходит. Если команда или руководство не понимают зачем это все нужно, то все предыдущие усилия будут просто бесполезны. Возможно, в результате разбора окажется, что Scrum в вашем случае совершенно не подходит. Такое тоже бывает. Scrum – не серебряная пуля.

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