 |
Scream вместо Scrum. Реалии тестировщиков.
|
|
|
|
Как не налететь на рифы в море преимуществ Scrum? Организация и оптимизация тестирования в Scrum-team при работе с гос. заказчиками.
Основные тезисы:
· Scrum «по книжкам»;
· «Scream вместо Scrum» или что видят тестировщики на самом деле, работая по Scrum;
· Как заставить Scrum работать на вас, а не вас работать по Scrum. Тонкости организации процесса тестирования на крупных гос. проектах, или те самые рифы в том самом море;
Рассмотрим теперь все более детально и по порядку.
Тот самый Scrum, о котором нам рассказывают книжки
Не буду вновь всем вам «открывать Америку» – подавляющее большинство из вас и так отлично знакомо с данной методологией управления проектом. Все вы и так знакомы с определениями спринта, product owner, бэклогов спринта и проекта и так далее. Скажу только то, что в общедоступном многообразии литературы, посвященной Scrum, уделено огромнейшее внимание рассказам о командах, о том, как максимально эффективно их сформировать, о ролях, рассказам о коммуникациях, которые должны происходить для лучшего результата на проекте в целом. Рассказано обо всех преимуществах, наряду с прозрачностью результата, гибкостью разработки и прочее. Но практически нигде ни слова не сказано про то, как синхронизировать разработку и тестирование проекта в рамках запланированных на спринт задач. Не сказано ни слова о том, как правильно и грамотно организовать процесс тестирования и поставить его на поток. Там все рассказано с точки зрения идеального Scrum «из коробки». А как, например, справится с проблемой разрастающегося от спринта к спринту бэклога? Как быть, когда заказчику нет дела до тонкостей организации процесса разработки и тестирования, но ему подавай отличный результат?
|
|
|
И тут мы плавно переходим к тому, как выглядит настоящий Scrum, реальный. К тому как видят его, в частности, тестировщики и к тому, с какими проблемами они сталкиваются.
Scream вместо Scrum. Реалии тестировщиков.
Как бы ни был прекрасен Scrum, существует ряд проблем, с которым тестировщики сталкиваются каждый день…вернее, если выразиться точнее, каждый спринт. Рассмотрим лишь некоторые из них.
ü Сдвиг процесса тестирования относительно процесса разработки
Как правило, данная ситуация знакома всем. Всем знакомо то самое чувство, когда за один день до конца спринта, а еще хуже – в самый последний день перед его концом, «прилетает» от разработчика задача с гордым статусом Resolved, и заставляющая вас рвать на себе волосы с корнем, ибо протестировать ее до конца спринта вы явно не успеваете. Конечно, избежать данной ситуации практически невозможно, хотя бы потому, что физически невозможно взять на тестирование задачу, которая даже в разработку еще не поступила. Естественно можно и нужно максимально к этому подготовиться – писать тест-кейсы, приступить к автоматизации, если она имеет место быть на вашем проекте. Но в конечном итоге никто не может гарантированно сказать, что к концу спринта у вас не останется не закрытых, не протестированных задач, кто бы вам что ни говорил!
ü Достаточно большой объем задач, выполняемых тестировщиками на любом из проектов.
В зависимости от тех или иных требований к участникам проекта, тестировщики могут заниматься множеством различных задач, начиная от проработки требований, написания внутренней тестовой документации и заканчивая внедрением автоматизации тестирования, тестированием проекта на мощностях заказчика и дальнейшим сопровождением его в течении длительного отрезка времени.
ü Всегда «сложный» заказчик.
|
|
|
Возьмем, к примеру, гос. заказчика, скажем, Федеральную миграционную службу. Тонны макулатуры нормативной документации, десятки тысяч сотрудников по всей России (и у каждого из них свое видение, как должен выглядеть ваш продукт, который вы взялись для них разрабатывать), множество взаимодействующих с ним иных гос. структур, у каждой из которых так же свое видение того, как необходимо реализовать это самое взаимодействие – и это лишь вершина айсберга. В довершение ко всему – можно даже не думать о том, что заказчику есть дело до того, как именно вы организовали процесс тестирования на проекте и почему вы в текущей итерации не успеваете оттестировать то или иное – заказчика волнует лишь конечный результат, а в случае с гос. заказчиком особенно! Более того, гос. заказчики очень любят внедрять «хотелки» в самый неподходящий момент и удивляются, когда исполнитель либо объясняет, что это сдвинет сроки поставки релиза, либо потребует дополнительных «инвестиций» в проект.
Не стоит забывать, что, работая на государственную структуру, всем всегда приходится сталкиваться с непрошибаемой машиной тотальной бюрократии, где никому нет дела до того, как именно исполнитель будет оптимально организовывать процесс управления проектом и тестированием, в частности. Финансируются такие проекты, как правило, из государственного бюджета и трату каждой лишней копейки придется обосновывать, чуть ли ни при встрече с премьер-министром.
Все это, в конечном счете, приводит к тому, что backlog проекта разрастается от спринта к спринту. Дело в том, что при такой титанической «текучке» задач, практически всегда приходится прибегать к расстановке приоритетов – какая задача должна быть выполнена как можно скорее, а какая задача может подождать следующего апдейта или релиза. И каждый раз, каждый спринт происходит ровно тоже самое, что и выливается, в конечном счета, в так называемый технический долг, то есть то состояние проекта, когда «откладывать на потом» уже невозможно. Причинами тому могут быть либо большое количество «костылей», которые приходилось писать ранее, либо просто отсутствие возможности двигаться дальше, без пропущенных в свое время задач разработки. В итоге возникает необходимость «технического спринта», за который вам никто не заплатит, а возможно даже еще и оштрафует – вспоминаем Медведева.
|
|
|
Иными словами, рано или поздно на выходе будет либо некачественно протестированный продукт, релизить который можно только распрощавшись с головой, либо львиная доля требований заказчика просто-напросто не будет реализована, и вы потеряете контракт, что, конечно, не сможет не отразиться на вашем будущем. Ввиду всего этого и массы иных особенностей организации «качественного тестирования качества» - хочу поделиться с вами опытом перехода на Scrum на своем проекте. Я расскажу вам с какими проблемами сталкивались именно мы…какие проблемы удалось предотвратить и как удалось найти для себя «именно тот Scrum», отвечающий всем несомненным плюсам, о которых многое было сказано и который свел к минимуму, а в некоторых случаях и исключил вовсе, вышеописанные проблемы по коммуникациям с заказчиком. Более того, я постараюсь развеять миф о том, что Scrum не подходит для организации процесса тестирования при работе с крупными гос. заказчиками и в конце постараюсь ответить на все ваши вопросы. Приступим!
|
|
|
