Как команда TeamStorm использует собственную платформу в работе

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

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

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

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

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

• Наша команда разработки состоит из людей, выполняющих разные функциональные роли. Над одной фичей может работать одновременно владелец продукта, аналитик, дизайнер, 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-функциональность — в ближайшем обновлении, расширенная функциональная версия — в будущих релизах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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