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