Как команда TeamStorm работает в TeamStorm
Как команда TeamStorm работает в TeamStorm
Использование инструментов класса систем управления совместной работой — это верное средство от головной боли, сорванных сроков сдачи проекта и других неприятных вещей.
Часто подобные системы используются в IT-компаниях
для формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.
TeamStorm — IT-компания, разрабатывающая одноименную систему TeamStorm. Одно дело работать в зрелом стороннем инструменте, что мы и делали до определенного момента. Но когда продукт с нуля за восемь месяцев достиг предрелизного состояния, мы приняли решение отказаться от других инструментов в пользу своего для решения аналогичных задач.
Ведь только пользуясь самостоятельно тем, что ты делаешь, можно лучше понять своих клиентов, их потребности. И тут мы, похоже, в пух и прах разбиваем концепцию сапожника без сапог =)
Часто подобные системы используются в IT-компаниях
для формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.
TeamStorm — IT-компания, разрабатывающая одноименную систему TeamStorm. Одно дело работать в зрелом стороннем инструменте, что мы и делали до определенного момента. Но когда продукт с нуля за восемь месяцев достиг предрелизного состояния, мы приняли решение отказаться от других инструментов в пользу своего для решения аналогичных задач.
Ведь только пользуясь самостоятельно тем, что ты делаешь, можно лучше понять своих клиентов, их потребности. И тут мы, похоже, в пух и прах разбиваем концепцию сапожника без сапог =)
Кратко о процессах в команде:
Кратко о процессах в команде:
- Наша команда разработки состоит из людей, выполняющих разные функциональные роли. Над одной фичей может работать одновременно владелец продукта, аналитик, дизайнер, frontend- и backend-девелопер.
- Мы работаем по методологии Scrum и организуем общее пространство, где сначала формируем содержание продукта, а затем включенные в процесс люди с соответствующими компетенциями планируют и разделяют задачи на релизы и спринты.
- Для релизов, дефектов и запросов мы создаем отдельные папки, чтобы каждый участник знал содержание каждого релиза и рассчитывал время на выполнение.
- Самые полезные и быстро выполняемые задачи стараемся делать быстрее.
- Двигаемся итеративно, не закапываемся в фичи и получаем обратную связь.
Мы хотели осуществить переезд, не ломая собственные процессы. Для этого мы провели анализ и приняли решение, что текущая версия TeamStorm соответствует минимальным требованиям для переезда и работы.
Список требований:
Список требований:
- Хотим иметь возможность создавать проекты и ранжировать уровни доступа к ним.
- Хотим формировать списки задач в виде структуры папок.
- Хотим управлять бэклогом, планировать и выполнять спринты.
- Хотим использовать удобное представление информации в виде Канбан-доски для перемещения по статусам, фильтрации по процессам, статусам и ответственным.
- Хотим создавать разные типы задач, которые необходимы команде.
- Хотим настраивать статусы и переходы между статусами для каждого типа задачи.
- Хотим назначать собственные атрибуты для разных типов задач.
- Хотим декомпозировать и связывать задачи внутри проекта.
- Хотим добавлять комментарии и прикреплять вложения.
- Необходим сквозной поиск задач из всех доступных пространств или папок.
- Необходим учет рабочего времени: возможность указывать оценки по задачам и фиксировать фактические трудозатраты команды.
- Хотим выгружать задачи и строить по ним отчеты.
Этапы переезда:
Этапы переезда:
- Перенос проектов и задач из используемой нами ранее Jira.
- Кастомизация иерархии проектов под устоявшиеся у нас в команде бизнес-процессы.
- Настройка процессов и типов задач на все команды.
- Постоянное дополнение и анализ бэклога.
Как ведется работа в TeamStorm
Как ведется работа в TeamStorm
Стратегия и дорожная карта развития продукта
Стратегия и дорожная карта развития продукта
Любая идея, поступившая от команды или клиента, попадает в бэклог развития продукта, где проходит свой жизненный цикл от идеи до реализации. Мы стремимся разработать как можно больше фич, при этом доставить наиболее важные в максимально короткий срок. Поэтому идеи из бэклога проходят процедуру приоритизации. Мы упорядочиваем идеи из бэклога по важности, снизу вверх.
Что учитываем:
Стадии реализации идеи:
1. Ожидание рассмотрения
2. Рассмотрение и описание
3. Анализ и принятие решения о реализации
4. Оценка и приоритизация
5. Разработка
6. Завершение
Важно, чтобы бэклог идей не дублировался и все члены команды могли видеть актуальный статус каждой идеи.
- Частоту получения запроса от компаний, с которыми мы ведем взаимодействие и проводим исследования.
- Насколько фича экономит время и снижает риски наших клиентов.
- Соответствие собственной продуктовой концепции.
- Соответствие архитектуре.
- Сложность реализации.
Стадии реализации идеи:
1. Ожидание рассмотрения
2. Рассмотрение и описание
3. Анализ и принятие решения о реализации
4. Оценка и приоритизация
5. Разработка
6. Завершение
Важно, чтобы бэклог идей не дублировался и все члены команды могли видеть актуальный статус каждой идеи.
Формирование бэклога разработки и планирование релизов
Формирование бэклога разработки и планирование релизов
На этапе анализа идеи мы получаем оценку сложности, приоритета и видим зависимости между ними. С этими атрибутами нам легче понимать, когда те или иные идеи будут реализованы. Мы облекаем наши планы в релизы — разбиваем последовательность разработки фич на временные периоды. Каждый релиз — список изменений, которые мы планируем осуществить. Мы создаем отдельную папку для каждого релиза.
Мы описываем будущие фичи в продукте как user story. User story или пользовательская история — это небольшой текст в формате пожелания, который помогает выяснить, кто такой пользователь, что он хочет и какова его цель. В настройках пространства мы задаем два разных процесса, где фиксируем этапы, чтобы задачи разного типа могли перемещаться по собственным процессам. Регламенты и правила можно записывать в виде задач.
Типовые шаги:
Идея может быть реализована не сразу, а в несколько этапов: mvp-функциональность — в ближайшем обновлении, расширенная функциональная версия — в будущих релизах.
Типовые шаги:
- Аналитик пишет требования
- Дизайнер готовит макеты
- Задача с user story попадает в список готовых к реализации
- Задачу берут в разработку
Идея может быть реализована не сразу, а в несколько этапов: mvp-функциональность — в ближайшем обновлении, расширенная функциональная версия — в будущих релизах.
Планирование спринта и командная оценка задач
Планирование спринта и командная оценка задач
Спринт создается на основе заранее сформулированных целей. Цели же формируются исходя из пожеланий пользователей продукта — они добавляются в бэклог на постоянной основе и проходят через процесс приоритизации. Лидер команды разработчиков организует спринт, добавляя туда те задачи, которые находятся у компании в приоритете и должны быть решены раньше остальных.
Скрам-доски помогают организовывать спринты, следить за прогрессом команды и анализировать проведенную работу.
Скрам-доски помогают организовывать спринты, следить за прогрессом команды и анализировать проведенную работу.
Мы проводим регулярные встречи для планирования и приоритизации задач: анализируем содержание продукта и выбираем наиболее приоритетные user story, забираем user story из бэклога релиза в спринт.
Тут user story разбиваются уже на детальные подзадачи. Например, разработка дизайна, доработка сервисной части, разработка пользовательского интерфейса. Каждая подзадача имеет своего ответственного исполнителя, оценку трудозатрат. В ходе планирования мы смотрим на содержимое спринта с точки зрения разработчиков: нет ли перегруженных членов команды, у всех ли есть задачи. В спринте также расставляем приоритеты — какие задачи важнее довести до пользователя в этом спринте.
Тут user story разбиваются уже на детальные подзадачи. Например, разработка дизайна, доработка сервисной части, разработка пользовательского интерфейса. Каждая подзадача имеет своего ответственного исполнителя, оценку трудозатрат. В ходе планирования мы смотрим на содержимое спринта с точки зрения разработчиков: нет ли перегруженных членов команды, у всех ли есть задачи. В спринте также расставляем приоритеты — какие задачи важнее довести до пользователя в этом спринте.
Выполнение спринта
Выполнение спринта
Мы запускаем запланированный спринт и отслеживаем прогресс. Каждый участник команды видит свои задачи и их статус на рабочем столе. Задачи перемещаются по заранее настроенному процессу, в соответствии с этапами/контрольными точками.
(Не выполнена, в разработке, на ревью, ждет тестирования и т.д.). Каждая команда легко может настроить под себя процесс работы.
На доске в TeamStorm видно не только движение подзадач отдельного разработчика, но и прогресс разработки самих фич. Это важно, т.к. выполнение отдельной подзадачи редко приближает команду к выполнению целей спринта.
Каждый член команды периодически фиксирует время, которое он затратил на задачу. В задаче на дейли на карточке задачи можно отследить сдвиги в подзадаче, блокеры или смещение целей спринта. Под каждой задачей можно оставлять комментарии и задавать вопросы.
(Не выполнена, в разработке, на ревью, ждет тестирования и т.д.). Каждая команда легко может настроить под себя процесс работы.
На доске в TeamStorm видно не только движение подзадач отдельного разработчика, но и прогресс разработки самих фич. Это важно, т.к. выполнение отдельной подзадачи редко приближает команду к выполнению целей спринта.
Каждый член команды периодически фиксирует время, которое он затратил на задачу. В задаче на дейли на карточке задачи можно отследить сдвиги в подзадаче, блокеры или смещение целей спринта. Под каждой задачей можно оставлять комментарии и задавать вопросы.
Тестирование и приёмка
Тестирование и приёмка
Результаты нескольких спринтов объединяются в релиз. и происходит поставка обновления пользователям новых функций и исправлений. Конечно, перед тем как передать очередную фичу пользователя, мы тщательно ее тестируем, что проблема пользователя полноценно решается и система продолжает стабильно работать.
В задачах мы фиксируем ключевые результаты: критерии приёмки, которые позволяют понять, что задача выполнена на 100%.
В процессе приёмки или регрессионного тестирования возникают дефекты, куда же без них. Критичные дефекты, которые возникают при приёмке фич, попадают в тот же спринт и исправляются незамедлительно. Для некритичных дефектов мы создали отдельную папку дефектов, куда помещаем все дефекты.
Периодически с командой тестирования мы устраиваем смотрины: смотрим свежие баги, определяем их важность и приоритет, связываем с задачами которые могут исправить ту или иную проблему. Дефекты, как правило, содержат не только описание шагов воспроизведения, но и полезные скриншоты и видео. Также в рамках дефектов появляются полезные комментарии.
Критичные для пользователей проблемы тут же отправляются в активный спринт.
Сами тесты и тест-планы мы ведем в Test IT, куда есть непосредственный переход прямо из ТШ. Мы планируем расширять интеграцию с инструментами тестирования и репозиториями.
В задачах мы фиксируем ключевые результаты: критерии приёмки, которые позволяют понять, что задача выполнена на 100%.
В процессе приёмки или регрессионного тестирования возникают дефекты, куда же без них. Критичные дефекты, которые возникают при приёмке фич, попадают в тот же спринт и исправляются незамедлительно. Для некритичных дефектов мы создали отдельную папку дефектов, куда помещаем все дефекты.
Периодически с командой тестирования мы устраиваем смотрины: смотрим свежие баги, определяем их важность и приоритет, связываем с задачами которые могут исправить ту или иную проблему. Дефекты, как правило, содержат не только описание шагов воспроизведения, но и полезные скриншоты и видео. Также в рамках дефектов появляются полезные комментарии.
Критичные для пользователей проблемы тут же отправляются в активный спринт.
Сами тесты и тест-планы мы ведем в Test IT, куда есть непосредственный переход прямо из ТШ. Мы планируем расширять интеграцию с инструментами тестирования и репозиториями.
Завершаем спринт
Завершаем спринт
Спринт завершает демонстрация результатов команды. На демонстрации мы показываем завершенные в спринте задачи и новую функциональность. Перед завершением мы с командой актуализируем статусы работ и финализируем фактические трудозатраты.
При завершении спринта вся незавершенная работа переносится обратно в беклог разработки, где они приоритизируются к планированию следующего спринта.
Выгружаем задачи и можем построить отчет по спринтам, показать насколько точные оценки мы даём, оценить фактическую емкость команды к планированию следующего спринта.
При завершении спринта вся незавершенная работа переносится обратно в беклог разработки, где они приоритизируются к планированию следующего спринта.
Выгружаем задачи и можем построить отчет по спринтам, показать насколько точные оценки мы даём, оценить фактическую емкость команды к планированию следующего спринта.
13.12.2022
Нажимая кнопку "Заказать демо", я соглашаюсь на обработку моих персональных данных
Запросить демо
Ответим на все вопросы
и покажем продукт
и покажем продукт
БЛОГ TEAMSTORM
