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

Как и большинство команд разработки, наша команда пользуется доской для систематизации, приоритезации и разбивки по этапам всех задач. Мы выделяем для задач шесть этапов.

Когда мы только берём задачу в работу, она попадает в Tech Design, затем задача перемещается в Development — основной этап разработки. После того, как разработка фичи окончена, задача отправляется на Review, где мы проверяем написанный разработчиком код. Затем два этапа тестирования, и, соответственно, две колонки — QA (Quality Assurance) и UAT (User Acceptance Testing). Финальная колонка — Ready to Release, то есть, фича, попавшая в неё, уже готова к выпуску в прод.