Как команда TeamStorm работает в TeamStorm


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

Часто подобные системы используются в IT-компаниях
для формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.

TeamStorm – IT-компания, разрабатывающая одноименную систему TeamStorm. Одно дело – работать в зрелом стороннем инструменте, что мы и делали до определенного момента. Но когда продукт с нуля за 8 месяцев достиг предрелизного состояния, мы приняли решение отказаться от других инструментов в пользу своего для решения аналогичных задач. Ведь только пользуясь самостоятельно тем, что ты делаешь, можно лучше понять своих клиентов их потребности. И тут мы, похоже, в пух и прах разбиваем концепцию сапожника без сапог =)

Кратко о процессах в команде:

  • Наша команда разработки состоит из людей, выполняющих разные функциональные роли. Над одной фичей может работать одновременно владелец продукта, аналитик, дизайнер, frontend- и backend-девелопер.
  • Мы работаем по методологии Scrum и организуем общее пространство, где сначала формируем содержание продукта, а затем включенные в процесс люди с соответствующими компетенциями планируют и разделяют задачи на релизы и спринты.
  • Для релизов, дефектов и запросов мы создаем отдельные папки, чтобы каждый участник знал содержание каждого релиза и рассчитывал время на выполнение.
  • Самые полезные и быстро выполняемые задачи стараемся делать быстрее.
  • Двигаемся итеративно, не закапываемся в фичи и получаем обратную связь.

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

Список требований:

  • хотим иметь возможность создавать проекты и ранжировать уровни доступа к ним,
  • хотим формировать списки задач в виде структуры папок,
  • хотим управлять бэклогом, планировать и выполнять спринты,
  • хотим использовать удобное представление информации в виде Канбан-доски для перемещения по статусам, фильтрации по процессам, статусам и ответственным,
  • хотим создавать разные типы задач, которые необходимы команде,
  • хотим настраивать статусы и переходы между статусами для каждого типа задачи,
  • хотим назначать собственные атрибуты для разных типов задач,
  • хотим декомпозировать и связывать задачи внутри проекта,
  • хотим добавлять комментарии и прикреплять вложения,
  • необходим сквозной поиск задач из всех доступных пространств или папок
  • необходим учет рабочего времени: возможность указывать оценки по задачам и фиксировать фактические трудозатраты команды,
  • хотим выгружать задачи и строить по ним отчеты.

Этапы переезда:

  1. Перенос проектов и задач из используемой нами ранее Jira
  2. Кастомизация иерархии проектов под устоявшиеся у нас в команде бизнес-процессы
  3. Настройка процессов и типов задач на все команды
  4. Постоянное дополнение и анализ Бэклога

Как ведется работа в TeamStorm?

Стратегия и дорожная карта развития продукта

Любая идея, поступившая от команды или клиента, попадает в бэклог развития продукта, где проходит свой жизненный цикл от идеи до реализации. Мы стремимся разработать как можно больше фич, при этом доставить наиболее важные в максимально короткий срок. Поэтому идеи из бэклога проходят процедуру приоритизации. Мы упорядочиваем идеи из бэклога по важности – снизу вверх.
Что учитываем:
  • частоту получения запроса от компаний, с которыми мы ведем взаимодействие и проводим исследования,
  • насколько фича экономит время и снижает риски наших клиентов,
  • соответствие собственной продуктовой концепции,
  • соответствие архитектуре,
  • сложность реализации.

Стадии реализации идеи:
  1. ожидание рассмотрения,
  2. рассмотрение и описание,
  3. анализ и принятие решения о реализации,
  4. оценка и приоритезация,
  5. разработка,
  6. завершение.

Важно, чтобы бэклог идей не дублировался, и все члены команды могли видеть актуальный статус каждой идеи.

Формирование бэклога разработки и планирование релизов

На этапе анализа идеи мы получаем оценку сложности, приоритета и видим зависимости между ними. С этими атрибутами нам легче понимать, когда те или иные идеи будут реализованы. Мы облекаем наши планы в релизы – разбиваем последовательность разработки фич на временные периоды. Каждый релиз – список изменений, которые мы планируем осуществить. Мы создаем отдельную папку для каждого релиза.
Мы описываем будущие фичи в продукте как user story. User story или пользовательская история — это небольшой текст в формате пожелания, который помогает выяснить, кто такой пользователь, что он хочет и какова его цель. В настройках пространства мы задаем два разных процесса, где фиксируем этапы, чтобы задачи разного типа могли перемещаться по собственным процессам.
Регламенты и правила можно записывать в виде задач.

Типовые шаги:
  1. Аналитик пишет требования
  2. Дизайнер готовит макеты
  3. Задача с user story попадает в список готовых к реализации
  4. Задачу берут в разработку.
При переводе задачи в разработку она декомпозируется на подзадачи. Разработчики дают более точную оценку, приоритет и получают свою форму в виде требований, прототипов, макетов, которая понятна и пользователям и разработчикам.

Идея может также быть реализована не сразу, а в несколько этапов – mvp-функциональность в ближайшем обновлении, расширенная функциональная версия – в будущих релизах.

Планирование спринта и командная оценка задач

Спринт создается на основе заранее сформулированных целей. Цели же формируются исходя из пожеланий пользователей продукта – они добавляются в бэклог на постоянной основе и проходят через процесс приоритезации. Лидер команды разработчиков организует спринт, добавляя туда те задачи, которые находятся у компании в приоритете и должны быть решены раньше остальных.

Скрам-доски помогают организовывать спринты, следить за прогрессом команды и анализировать проведенную работу.

Мы проводим регулярные встречи для планирования и приоритизации задач: анализируем содержание продукта и выбираем наиболее приоритетные юзер стори, забираем юзер-стори из бэклога релиза в спринт.

Тут юзер-стори разбиваются уже на детальные подзадачи, например, разработка дизайна, доработка сервисной части, разработка пользовательского интерфейса. Каждая подзадача имеет своего ответственного-исполнителя, оценку трудозатрат. В ходе планирования мы смотрим на содержимое спринта с точки зрения разработчиков – нет ли перегруженных членов команды, у всех ли есть задачи. В спринте также расставляем приоритеты - какие задачи важнее довести до пользователя в этом спринте.

Выполнение спринта

Мы запускаем запланированный спринт и отслеживаем прогресс. Каждый участник команды видит свои задачи и их статус на рабочем столе. Задачи перемещаются по заранее настроенному процессу, в соответствии с этапами/контрольными точками.
(Не выполнена, в разработке, на ревью, ждет тестирования и т.д.). Каждая команда легко может настроить под себя процесс работы.

На доске в TeamStorm видно не только движение подзадач отдельного разработчика, но и прогресс разработки самих фич. Это важно, т.к. выполнение отдельной подзадачи редко приближает команду к выполнению целей спринта.

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

Тестирование и приёмка

Результаты нескольких спринтов объединяются в релиз. и происходит поставка обновления пользователям новых функций и исправлений. Конечно перед тем, как передать очередную фичу пользователя мы тщательно ее тестируем, что проблема пользователя полноценно решается и система продолжает стабильно работать.
В задачах мы фиксируем ключевые результаты - критерии приемки, которые позволяют понять, что задача выполнена на 100%.

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

Периодически с командой тестирования мы устраиваем смотрины - смотрим свежие баги, определяем их важность и приоритет, связываем с задачами которые могут исправить ту или иную проблему. Дефекты как правило содержат не только описание шагов воспроизведения, но и полезные скриншоты и видео. Также в рамках дефектов появляются полезные комментарии.

Критичные для пользователей проблемы тут же отправляются в активный спринт.
Сами тесты и тест-планы мы ведем в Test IT, куда есть непосредственный переход прямо из ТШ. Мы планируем расширять интеграцию с инструментами тестирования и репозиториями.

Завершаем спринт

Спринт завершает демонстрация результатов команды. На демонстрации мы показываем завершенные в спринте задачи и новую функциональность. Перед завершением мы с командой актуализируем статусы работ и финализируем фактические трудозатраты.
При завершении спринта вся незавершенная работа переносится обратно в беклог разработки, где они приоритизируются к планированию следующего спринта.
Выгружаем задачи и можем построить отчет по спринтам, показать насколько точные оценки мы даём, оценить фактическую емкость команды к планированию следующего спринта.

13.12.2022

БЛОГ TEAMSTORM