Это статья о том, как с помощью TrackStudio можно вести разработку ПО по методологии Scrum. TrackStudio — это универсальная система управления задачами и Scrum — это один из примеров использования. Вам понадобится экземпляр TrackStudio (90-дневная пробная версия) и конфигурация. После скачивания нужно устанавить TrackStudio и накатить по инструкции конфигурацию.
В соответствие с методологией Scrum, в системе определены три роли: Product Owner (Заказчик), Scrum Master (Мастер) и Team (Команда).
Задача Product Owner’а или Заказчика — регистрировать в системе истории и определять их важность для продукта. Заказчик взаимодействует с командой (Team) для наиболее полного понимания командой целей Заказчика, и Заказчиком — возможностей команды. Результатом этого взаимодействия должны стать четко сформулированные и ранжированные по важности истории, которые Заказчик и команда понимают одинаково.
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
В системе определены проекты, истории, спринты и задачи. Проектами ведает Заказчик. Он же пишет истории. Спринты создает Мастер, он же заполняет их историями. Задачи могут создавать участники команды внутри спринтов и внутри историй.
Заказчик создает истории, максимально полно и четко описывая их. При этом обязательно заполняются поля «Как продемонстрировать» и «Важность». В поле «Важность» должно быть любое целое число, чем оно больше, тем выше важность.
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Система подсказывает, какие задачи уже оценены этим участником, а какие еще нет.
В отличие от традиционной методологии Scrum, Заказчик не определяет трудоемкость реализации истории, но видит оценки трудоемкости и может участвовать в их обсуждении.
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации. Исходя из сроков и производительности команды Мастер указывает бюджет спринта. При этом он ориентируется на показатель «Можно запланировать» таблицы «Планирование» в спринте. Бюджет спринта должен быть меньше, чем эта оценка.
После того, как все или почти все участники оценили истории, Мастер начинает заполнять спринт, перенося в него наиболее важные для Заказчика задачи. Бюджет историй на этом этапе не утвержден, это все еще предмет обсуждения. Перенеся истории в спринт, Мастер видит первую оценку бюджета спринта и сравнивает ее с заданной. На этом этапе уже можно представить какие истории войдут в спринт, а какие — нет.
Затем Мастер начинает распределять истории по исполнителям и утверждать бюджеты задач.
При этом он может руководствоваться как оценками участников команды, выбирая в качестве ответственного того, кто указал меньшее время, так и таблицей загруженности команды. Бюджет при этом Мастер может указать, исходя из своих оценок.
Иногда пользователь, входящий в команду, работает не только над проектом этого Заказчика, но и над другими проектами. Кроме того, в некоторых командах разные пользователи работают разное количество времени (не все сидят на работе с 9 до 18). Чтобы учитывать это, для каждого пользователя есть дополнительное поле «Степень занятости». В нем указывается количество рабочих часов для пользователя в неделю. Тех рабочих часов, когда работают, а не присутствуют на работе — это важно для планирования спринтов.
После распределения задач спринта может оказаться, что на ком-то из участников «висит» больше задач, чем он сможет выполнить. В таком случае нужно либо пересмотреть бюджеты историй этого участника, либо переназначить часть задач на другого участника, либо провести декомпозицию самых крупных задач и распределить их по команде.
Так же, разумеется, может оказаться, что «бюджет вечеринки» при планировании превышен. В таком случае следует либо увеличить бюджет спринта (если позволяет запас по времени), либо изменить оценки части историй, либо убрать из спринта часть наименее значимых историй.
По окончанию планирования спринта Мастер запускает спринт в работу и команда может приступать к своим задачам.
Мастер может следить за ходом выполнения спринта и своевременно реагировать на отставание от плана. Если на историю было потрачено времени больше планируемого, это время будет отмечено красным цветом. Когда участник команды выполнит все свои задачи, Мастер может переназначить на него задачи других участников, которые отстают от графика.
После того, как все истории в спринте будут реализованы, Мастер сможет закрыть спринт и вместе с командой приступить к демонстрации результатов Заказчику.
В соответствие с методологией Scrum, в системе определены три роли: Product Owner (Заказчик), Scrum Master (Мастер) и Team (Команда).
Product Owner
Задача Product Owner’а или Заказчика — регистрировать в системе истории и определять их важность для продукта. Заказчик взаимодействует с командой (Team) для наиболее полного понимания командой целей Заказчика, и Заказчиком — возможностей команды. Результатом этого взаимодействия должны стать четко сформулированные и ранжированные по важности истории, которые Заказчик и команда понимают одинаково.
Scrum Master
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Team
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Backlog
В системе определены проекты, истории, спринты и задачи. Проектами ведает Заказчик. Он же пишет истории. Спринты создает Мастер, он же заполняет их историями. Задачи могут создавать участники команды внутри спринтов и внутри историй.
Как это работает
Заполнение product backlog
Заказчик создает истории, максимально полно и четко описывая их. При этом обязательно заполняются поля «Как продемонстрировать» и «Важность». В поле «Важность» должно быть любое целое число, чем оно больше, тем выше важность.
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Система подсказывает, какие задачи уже оценены этим участником, а какие еще нет.
В отличие от традиционной методологии Scrum, Заказчик не определяет трудоемкость реализации истории, но видит оценки трудоемкости и может участвовать в их обсуждении.
Планирование
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации. Исходя из сроков и производительности команды Мастер указывает бюджет спринта. При этом он ориентируется на показатель «Можно запланировать» таблицы «Планирование» в спринте. Бюджет спринта должен быть меньше, чем эта оценка.
После того, как все или почти все участники оценили истории, Мастер начинает заполнять спринт, перенося в него наиболее важные для Заказчика задачи. Бюджет историй на этом этапе не утвержден, это все еще предмет обсуждения. Перенеся истории в спринт, Мастер видит первую оценку бюджета спринта и сравнивает ее с заданной. На этом этапе уже можно представить какие истории войдут в спринт, а какие — нет.
Затем Мастер начинает распределять истории по исполнителям и утверждать бюджеты задач.
При этом он может руководствоваться как оценками участников команды, выбирая в качестве ответственного того, кто указал меньшее время, так и таблицей загруженности команды. Бюджет при этом Мастер может указать, исходя из своих оценок.
Степень занятости
Иногда пользователь, входящий в команду, работает не только над проектом этого Заказчика, но и над другими проектами. Кроме того, в некоторых командах разные пользователи работают разное количество времени (не все сидят на работе с 9 до 18). Чтобы учитывать это, для каждого пользователя есть дополнительное поле «Степень занятости». В нем указывается количество рабочих часов для пользователя в неделю. Тех рабочих часов, когда работают, а не присутствуют на работе — это важно для планирования спринтов.
После распределения задач спринта может оказаться, что на ком-то из участников «висит» больше задач, чем он сможет выполнить. В таком случае нужно либо пересмотреть бюджеты историй этого участника, либо переназначить часть задач на другого участника, либо провести декомпозицию самых крупных задач и распределить их по команде.
Так же, разумеется, может оказаться, что «бюджет вечеринки» при планировании превышен. В таком случае следует либо увеличить бюджет спринта (если позволяет запас по времени), либо изменить оценки части историй, либо убрать из спринта часть наименее значимых историй.
Запуск
По окончанию планирования спринта Мастер запускает спринт в работу и команда может приступать к своим задачам.
Мастер может следить за ходом выполнения спринта и своевременно реагировать на отставание от плана. Если на историю было потрачено времени больше планируемого, это время будет отмечено красным цветом. Когда участник команды выполнит все свои задачи, Мастер может переназначить на него задачи других участников, которые отстают от графика.
После того, как все истории в спринте будут реализованы, Мастер сможет закрыть спринт и вместе с командой приступить к демонстрации результатов Заказчику.
