13 декабря, 2022
Дарья Васина
Проверенный
1 письмо в неделю со свежими статьями, кейсами и обновлениями.
Использование инструментов класса систем управления совместной работой — это верное средство от головной боли, сорванных сроков сдачи проекта и других неприятных вещей.
Часто подобные системы используются в IT-компанияхдля формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.
TeamStorm — IT-компания, разрабатывающая одноименную систему TeamStorm. Одно дело работать в зрелом стороннем инструменте, что мы и делали до определенного момента. Но когда продукт с нуля за восемь месяцев достиг предрелизного состояния, мы приняли решение отказаться от других инструментов в пользу своего для решения аналогичных задач.
Ведь только пользуясь самостоятельно тем, что ты делаешь, можно лучше понять своих клиентов, их потребности. И тут мы, похоже, в пух и прах разбиваем концепцию сапожника без сапог =)
Мы хотели осуществить переезд, не ломая собственные процессы. Для этого мы провели анализ и приняли решение, что текущая версия TeamStorm соответствует минимальным требованиям для переезда и работы.
Любая идея, поступившая от команды или клиента, попадает в бэклог развития продукта, где проходит свой жизненный цикл от идеи до реализации. Мы стремимся разработать как можно больше фич, при этом доставить наиболее важные в максимально короткий срок. Поэтому идеи из бэклога проходят процедуру приоритизации. Мы упорядочиваем идеи из бэклога по важности, снизу вверх.
Что учитываем:
Стадии реализации идеи:1. Ожидание рассмотрения2. Рассмотрение и описание3. Анализ и принятие решения о реализации4. Оценка и приоритизация5. Разработка6. Завершение
Важно, чтобы бэклог идей не дублировался и все члены команды могли видеть актуальный статус каждой идеи.
На этапе анализа идеи мы получаем оценку сложности, приоритета и видим зависимости между ними. С этими атрибутами нам легче понимать, когда те или иные идеи будут реализованы. Мы облекаем наши планы в релизы — разбиваем последовательность разработки фич на временные периоды. Каждый релиз — список изменений, которые мы планируем осуществить. Мы создаем отдельную папку для каждого релиза.
Мы описываем будущие фичи в продукте как user story. User story или пользовательская история — это небольшой текст в формате пожелания, который помогает выяснить, кто такой пользователь, что он хочет и какова его цель. В настройках пространства мы задаем два разных процесса, где фиксируем этапы, чтобы задачи разного типа могли перемещаться по собственным процессам. Регламенты и правила можно записывать в виде задач.
Типовые шаги:
При переводе задачи в разработку она декомпозируется на подзадачи. Разработчики дают более точную оценку, приоритет и получают свою форму в виде требований, прототипов, макетов, которая понятна и пользователям, и разработчикам.
Идея может быть реализована не сразу, а в несколько этапов: mvp-функциональность — в ближайшем обновлении, расширенная функциональная версия — в будущих релизах.
Спринт создается на основе заранее сформулированных целей. Цели же формируются исходя из пожеланий пользователей продукта — они добавляются в бэклог на постоянной основе и проходят через процесс приоритизации. Лидер команды разработчиков организует спринт, добавляя туда те задачи, которые находятся у компании в приоритете и должны быть решены раньше остальных.
Скрам-доски помогают организовывать спринты, следить за прогрессом команды и анализировать проведенную работу.
Мы проводим регулярные встречи для планирования и приоритизации задач: анализируем содержание продукта и выбираем наиболее приоритетные user story, забираем user story из бэклога релиза в спринт. Тут user story разбиваются уже на детальные подзадачи. Например, разработка дизайна, доработка сервисной части, разработка пользовательского интерфейса. Каждая подзадача имеет своего ответственного исполнителя, оценку трудозатрат. В ходе планирования мы смотрим на содержимое спринта с точки зрения разработчиков: нет ли перегруженных членов команды, у всех ли есть задачи. В спринте также расставляем приоритеты — какие задачи важнее довести до пользователя в этом спринте.
Мы запускаем запланированный спринт и отслеживаем прогресс. Каждый участник команды видит свои задачи и их статус на рабочем столе. Задачи перемещаются по заранее настроенному процессу, в соответствии с этапами/контрольными точками.(Не выполнена, в разработке, на ревью, ждет тестирования и т.д.). Каждая команда легко может настроить под себя процесс работы.
На доске в TeamStorm видно не только движение подзадач отдельного разработчика, но и прогресс разработки самих фич. Это важно, т.к. выполнение отдельной подзадачи редко приближает команду к выполнению целей спринта.
Каждый член команды периодически фиксирует время, которое он затратил на задачу. В задаче на дейли на карточке задачи можно отследить сдвиги в подзадаче, блокеры или смещение целей спринта. Под каждой задачей можно оставлять комментарии и задавать вопросы.
Результаты нескольких спринтов объединяются в релиз. и происходит поставка обновления пользователям новых функций и исправлений. Конечно, перед тем как передать очередную фичу пользователя, мы тщательно ее тестируем, что проблема пользователя полноценно решается и система продолжает стабильно работать.В задачах мы фиксируем ключевые результаты: критерии приёмки, которые позволяют понять, что задача выполнена на 100%.
В процессе приёмки или регрессионного тестирования возникают дефекты, куда же без них. Критичные дефекты, которые возникают при приёмке фич, попадают в тот же спринт и исправляются незамедлительно. Для некритичных дефектов мы создали отдельную папку дефектов, куда помещаем все дефекты.
Периодически с командой тестирования мы устраиваем смотрины: смотрим свежие баги, определяем их важность и приоритет, связываем с задачами которые могут исправить ту или иную проблему. Дефекты, как правило, содержат не только описание шагов воспроизведения, но и полезные скриншоты и видео. Также в рамках дефектов появляются полезные комментарии.
Критичные для пользователей проблемы тут же отправляются в активный спринт.Сами тесты и тест-планы мы ведем в Test IT, куда есть непосредственный переход прямо из ТШ. Мы планируем расширять интеграцию с инструментами тестирования и репозиториями.
Спринт завершает демонстрация результатов команды. На демонстрации мы показываем завершенные в спринте задачи и новую функциональность. Перед завершением мы с командой актуализируем статусы работ и финализируем фактические трудозатраты.При завершении спринта вся незавершенная работа переносится обратно в бэклог разработки, где они приоритизируются к планированию следующего спринта.Выгружаем задачи и можем построить отчет по спринтам, показать насколько точные оценки мы даём, оценить фактическую емкость команды к планированию следующего спринта.
Автор
Теги
Новости
Дадим скидку до 15%, если вы перейдете в TeamStorm из других систем управления совместной работой и проведем бесплатный пилот. Поможем перенести данные в TeamStorm, настроим систему под ваши процессы.
02.05.2024
Рассказываем, как сотрудничество TeamStorm и DBI позволит объединить технологические решения и опыт обеих компаний для предоставления клиентам более интегрированных и эффективных сервисов.
22.04.2024
Рассказываем о том, что TeamStorm получил статус резидента инновационного центра Сколково. Это значительное достижение для компании, которое открывает доступ к новым возможностям и ресурсам для развития и инноваций.
01.04.2024
Рассказываем, каким образом TeamStorm может быть эффективным инструментом управления проектами для компаний, столкнувшихся с недоступностью Asana.
26.03.2024
Обсуждаем основные особенности и преимущества TeamStorm в контексте его использования в критических сферах, а также его роль в обеспечении надежности и защищенности IT-инфраструктуры.
06.03.2024
В статье описываем суть партнерства TeamStorm с Axoft, возможные выгоды для обеих компаний и их клиентов, а также планы на будущее сотрудничества.
15.02.2024
Рассказываем о важности и функционале управления ролями в проектном менеджменте с использованием платформы TeamStorm.
01.02.2024
Рассказываем о введении сроков перехода государственных компаний на программное обеспечение, разработанное в России. Обсуждаем причины и механизмы этого перехода, его ожидаемые последствия для государственного сектора и местной индустрии программного обеспечения.
24.11.2023
Гибкие подходы в разработке ПО подразумевают специфический рабочий процесс: в предыдущем материале мы рассказывали, как происходит управление апстримом и даунстримом. А
20.10.2023
Рассказываем, чем занимаются проджект-менеджеры и как система управления совместной работой TeamStorm помогает таким специалистам руководить проектом, объединять команду и доводить
17.08.2023
ДОМ.РФ продолжает пилотирование TeamStorm и ряда других российских систем для управления проектами в рамках импортозамещения зарубежной Jira. Внедрение TeamStorm в
Нажимая кнопку “Запросить демо”, я соглашаюсь на обработку моих персональных данных
Мы не спамим! Прочтите нашу политику конфиденциальности, чтобы узнать больше.
Вы успешно подписались на нашу рассылку!