Как-то незаметно пролетели первые три модуля онлайн курса «Agile своими силами», и на подходе следующая встреча, где мы все больше и больше погружаемся в детали работы Agile команды. Одной из характерных особенностей первых модулей было огромное количество вопросов, и за отведенное время я успеваю ответить в лучшем случае на половину из них. Что-то будет рассмотрено позже в ходе следующих модулей, а что-то нет. Еще раз обращаюсь к участникам и предлагаю задать вопросы мне лично – тогда я смогу ответить в виде статьи и уточнить детали при необходимости.
Сегодня я отобрал несколько вопросов, которые так или иначе были связаны с качеством. Хочу ответить на них отдельно.
Первая порция:
Q: фаза тестирования входит в спринт? Или же результат спринта “уходит” в отдел качества, у которых “свой” спринт?
Q: Возможно, забегаю вперед, но очень хочется знать о взаимодействии в Скраме между разработчиками и тестировщиками?
Итак, прежде чем погрузиться в холивары тему, предлагаю вам поискать в Google «QA в Agile» или «тестирование в Agile» – статей, презентаций и даже книг на эту тему огромное множество.
Если отвечать коротко, то Спринт (итерация) – это мини-проект, в течение которого вы выпускаете потенциально готовую к «отгрузке» версию вашего продукта/системы. Исходя из этой максимы, мы должны сделать все необходимые технологические действия в рамках итерации, включая и тестирование.
Работая по итеративно-инкрементальному принципу, мы развиваем продукт, оставаясь максимально близкими к конечному состоянию. Каждый раз после окончания Спринта, представители бизнеса решают продолжать дальше или уже пора «отгружать». В модуле 9 «Оценка и планирование Agile проектов» мы поговорим о планировании всего проекта в виде цикла итераций, и какие при этом могут быть компромиссы.
По сути, роль QA и других специалистов не особо меняется – меняется интенсивность взаимодействия между разными специалистами :-). Достигается это уже с помощью разных инструментов. С одной стороны, требования нужно дробить до приемлемого размера, чтобы успевать сделать за итерацию все технические действия и в тоже время выпустить что-то заметное. С другой стороны, нужно обращать внимание на количество работы в прогрессе – таким образом уходить от «больших пачек работы», переходящих из отдела в отдел и приходить к работе малыми порциями. Есть еще много аспектов и инструментов, чтобы оптимизировать работу Scrum команды – среди них не стоит забывать об автоматизации тестирования и других способах разгрузить тестировщиков от рутины и оставить время на действительно полезную работу.
В ходе тренинга я рассматриваю целостную картину работы по Scrum методологии и с помощью упражнений подчеркиваю разные аспекты Agile разработки. Одно из моих любимых упражнений «Переверни монетку» – оно помогает сделать интересные наблюдения.
Вторая порция вопросов поможет нам немного погрузиться в детали:
Q: Тим, как вы учитываете багфикс после тестирования? отдельный спринт?
Q: Как поступать, если к окончанию спринта выполняются не все требования бэклога?
Q: Если возникает потребность сделать изменения в спринте, как быть в таком случае?
Учитывая выше сказанное, в конце Спринта мы должны завершить полный цикл разработки, включая и исправления найденных ошибок (багфикс). Бывают исключения в виде ошибок, не относящихся к тому, что вы делаете прямо сейчас – это следует учитывать в виде отдельных элементов Бэклога и давать Владельцу Продукта принять решения о приоритетах в целом. Главное, что по окончании итерации мы показываем что-то, что ГОТОВО исходя из наших «критериев готовности», а про остальное принимаем решение: переносить в следующий цикл, отложить пока или вообще забыть.
При правильном подходе, я рекомендую командам завершать то, что они начали, т.е. исправлять ошибки пока не будет готово, вместо того, чтобы начинать работать над следующим элементом Бэклога Продукта (списка требований). Да, может оказаться, что не все из того, что планировали, будет сделано. Зато фокус на «завершенности» и «работающем софте» помогает в целом оптимизировать выпуск проекта, а «свой ритм» (или скорость) вы сможете найти после нескольких итераций и уже более реалистично планировать (см. модуль 5: «нюансы планирования и работы внутри спринта»).
Отдельно стоит отметить, бывает так, что сообщения о внешних проблемах и незапланированных работах поступают во время работы в Спринте – подробно об этом я писал в статье «Что Agile команде делать с авралами» :-).
Ну и напоследок, вопрос к модулю 3 про роли в Scrum:
Q: а программисты + тестировщики? как быть с базовыми навыками?
Я рассказывал о том, что в Scrum есть роль «участник Scrum команды» и разные специалисты должны работать вместе, чтобы достигнуть целей проекта. Получается, что «базовым» навыком, необходимым всем специалистам, является работа в команде. Об этом мы и поговорим в ближайшем модуле 4: «Как организовать работу Scrum команды?» :-).