Среди многих команд занимающихся разработкой все большую популярность приобретает подход Scrum. Действительно, лаконичную, в 20 страниц текста методологию, легко понять и после некоторой практики начать использовать. Вот почему Microsoft выпустил дополнительный шаблон Scrum, который позволяет использовать эту методологию вместе с Team Foundation Server.
Те, кто уже использует TFS в работе, знают, что для организации работы команды можно использовать два шаблона процесса — MSF Agile и MSF CMMI. Технологически эти шаблоны представляют собой набор файлов, которые описывают рабочие элементы процесса, документы, отчеты, настройки безопасности и так далее. Более того, TFS позволяет настраивать эти шаблоны, дополняя их какими-то свойствами, которые специфичны именно для этой команды. Такие модификации удобно делать, используя Visual Studio Power Tools. На рынке представлено несколько дополнительных шаблонов процессов разработанных силами сообщества и коммерческими компаниями.
Этот шаблон был разработан специалистами Microsoft при непосредственном участии экспертов из Scrum.Org. Как и стандартные MSF Agile и MSF CMMI он в первую очередь состоит из набора рабочих элементов которые призваны организовать работу команды:
Productuct Backlog Item (PBI): Отслеживание требований к всему программному продукту.
Bug: Найденная в процессе разработки ошибка. Следует отметить что Product Backlog Item и Bug это практически равноценные элементы списка требований в контексте оценок затрат и планирования. Отсюда и практически идентичный набор полей. Небольшое замечание. В отличие от MSF Agile и MSF CMMI Шаблонов, TFS не создает Bug на основании ошибочной сборки (build).
Task: Задача. Этот элемент позволяет внести требуемый уровень детализации для Product Backlog Item. Естественно и сами задачи могут быть раздроблены на подзадачи.
Sprint: В этом рабочем элементе фиксируются даты спринта, цели и ретроспектива. Выделение Sprint в отдельный рабочий элемент отличает шаблон Scrum от шаблонов MSF Agile и MSF CMMI. В них спринт обозначается только с помощью механизма иерархий итераций, но к сожалению с помощью него не возможно обозначить даты начала и окончания спринта.
Impediment: Проблемы, риски и все то что может влиять на работу команды но не связано напрямую с свойствами разрабатываемого продукта.
Test Case: Описание теста для PBI. Обычно тесты напрямую привязываются к конкретному PBI. Этот рабочий элемент (как в прочем и Shared Steps) не определен напрямую в Scrum но он необходим для корректной работы инфраструктуры TFS.
Shared Steps: Разделяемые между несколькими Test Case шаги проверок.
Собственно сам процесс работы хорошо описан в руководстве по Scrum и ниже приведен очень краткий пример шагов:
1) Формируется команда проекта, и подготавливаются минимально необходимые документы (Vision, Scope)
2) Формируется первичный список PBI и там где возможно назначаются приоритеты. Этот этап аналитики, как правило, не долгий.
3) На основании первичного списка PBI проводится первая оценка (Поле Effort) с помощью Planning Poker. Не следует забывать что это абстрактные единицы, хотя можно планировать и в часах.
a. Те PBI которые не понятны (оценка уровня бесконечность или очень высокие стоимости) отправляются на дополнительную аналитику.
4) Формируется первый спринт на основе приоритетов и значимости PBI из полного набора Product Backlog, и которые уже понятно как реализовать.
5) PBI которые попали в Sprint детализуются разработчиками до уровня задач (Task) там где это необходимо. Тут можно вводить время. У Task есть поле Remaining Work.
a. После двух-трех Sprint уже можно ожидать однозначности в стоимостях и уточнить горизонт планирования.
6) Производится проверка PBI в состоянии Commited на основании заданных Test Case.
7) Неизбежно возникающие ошибки следует фиксировать с помощью Bug которые тоже попадают в Product Backlog.
8) Выполненные PBI закрываются с статусом Done
9) Планируется следующий Sprint, процесс повторяется с п.п. 5.
Манипуляции с списками PBI/Bugs/Task в рамках Product Backlog и Sprint осуществляются с помощью стандартных запросов которые уже определены в шаблоне для Sprint 1.
Соответственно после окончания первого спринта следует не забыть изменить запрос «Sprint Backlog» на текущее значение спринта:
Состояния рабочих элементов Scrum
В шаблонах MSF Agile и MSF CMMI используется уже устоявшийся в TFS подход ARC (Active->Resolved->Closed) который не совсем соответствует терминам Scrum.
Напомню, что более детально с Workflow всех рабочих элементов можно ознакомиться как на сайте MSDN, так и с помощью Team Foundation Server Web Acces и Process Editor.
Для примера приведу скриншот из редактора Wokflow для рабочего элемента Bug (он наиболее сложный) процесса Scrum:
Отчеты Scrum
Естественно, практически все поля, которые определены в рабочих элементах Scrum, попадают в системы аналитики Team Foundation Server и позволяют построить несколько важных отчетов, которые в последствии дают возможность понимать, как идут дела на проекте.
Sprint/Release Burndown – два отчета которые дают возможность оценить объемы оставшейся работы по проекту и спринту.
Release Burndown: От спринта к спринту общий объем задач, оценённый в единицах Effort должен уменьшаться. Косвенно через этот график так же можно оценить производительность команды.
Sprint Burndown: Каждый день команда закрывает некоторое количество PBI в рамках спринта.
Отчет Velocity: Усилия которые были затрачены на каждом спринте. Этот отчет перекликается с Release Burndown. Так же на графике представлена средняя цифра (35) производительности команды в рамках спринта. В идеале (и неизменной команде) чем больше было спринтов тем точнее эта цифра, и тем точнее можно предсказать дату окончания проекта.
Build Success Over Time, Build Summary отчеты: показывают состояние сборок проекта в разрезе платформ и пройденных тестов. Позволяют понимать прогресс, масштаб изменений и оценивать качество продукта.
Отчеты по тестам призваны дать оценку общему состоянию качества продукта, а так же решить организационные вопросы связанные с самими тестами. Исходя из информации представленной в этих отчетах можно понять сколько тестов от даты к дате проходят с корректным результатом, сколько с ошибочным, сколько вообще пока не запускалось и сколько тестов заблокировано.
Организовать работу с тестами позволяет отчет Test Case Readiness показывающий сколько тестов уже готово к исполнению и сколько еще пока находится на стадии детализации. В идеале этот отчет должен нарисовать такую картинку:
Шаблон процесса Scrum один из самых простых шаблонов процессов для Team Foundation Server, который тем не менее позволяет решить основные вопросы по организации командной работы. Более того, лаконичность Scrum позволяет быстро внедрить этот подход в новые или существующие команды и получить видимый результат за достаточно короткий промежуток времени. Который, хочется верить, будет заключаться в разработке более качественного программного обеспечения и точном планировании.
Шаблоны процессов
Те, кто уже использует TFS в работе, знают, что для организации работы команды можно использовать два шаблона процесса — MSF Agile и MSF CMMI. Технологически эти шаблоны представляют собой набор файлов, которые описывают рабочие элементы процесса, документы, отчеты, настройки безопасности и так далее. Более того, TFS позволяет настраивать эти шаблоны, дополняя их какими-то свойствами, которые специфичны именно для этой команды. Такие модификации удобно делать, используя Visual Studio Power Tools. На рынке представлено несколько дополнительных шаблонов процессов разработанных силами сообщества и коммерческими компаниями.
Шаблон процесса Scrum
Этот шаблон был разработан специалистами Microsoft при непосредственном участии экспертов из Scrum.Org. Как и стандартные MSF Agile и MSF CMMI он в первую очередь состоит из набора рабочих элементов которые призваны организовать работу команды:
Productuct Backlog Item (PBI): Отслеживание требований к всему программному продукту.
Bug: Найденная в процессе разработки ошибка. Следует отметить что Product Backlog Item и Bug это практически равноценные элементы списка требований в контексте оценок затрат и планирования. Отсюда и практически идентичный набор полей. Небольшое замечание. В отличие от MSF Agile и MSF CMMI Шаблонов, TFS не создает Bug на основании ошибочной сборки (build).
Task: Задача. Этот элемент позволяет внести требуемый уровень детализации для Product Backlog Item. Естественно и сами задачи могут быть раздроблены на подзадачи.
Sprint: В этом рабочем элементе фиксируются даты спринта, цели и ретроспектива. Выделение Sprint в отдельный рабочий элемент отличает шаблон Scrum от шаблонов MSF Agile и MSF CMMI. В них спринт обозначается только с помощью механизма иерархий итераций, но к сожалению с помощью него не возможно обозначить даты начала и окончания спринта.
Impediment: Проблемы, риски и все то что может влиять на работу команды но не связано напрямую с свойствами разрабатываемого продукта.
Test Case: Описание теста для PBI. Обычно тесты напрямую привязываются к конкретному PBI. Этот рабочий элемент (как в прочем и Shared Steps) не определен напрямую в Scrum но он необходим для корректной работы инфраструктуры TFS.
Shared Steps: Разделяемые между несколькими Test Case шаги проверок.
Организация работы
Собственно сам процесс работы хорошо описан в руководстве по Scrum и ниже приведен очень краткий пример шагов:
1) Формируется команда проекта, и подготавливаются минимально необходимые документы (Vision, Scope)
2) Формируется первичный список PBI и там где возможно назначаются приоритеты. Этот этап аналитики, как правило, не долгий.
3) На основании первичного списка PBI проводится первая оценка (Поле Effort) с помощью Planning Poker. Не следует забывать что это абстрактные единицы, хотя можно планировать и в часах.
a. Те PBI которые не понятны (оценка уровня бесконечность или очень высокие стоимости) отправляются на дополнительную аналитику.
4) Формируется первый спринт на основе приоритетов и значимости PBI из полного набора Product Backlog, и которые уже понятно как реализовать.
5) PBI которые попали в Sprint детализуются разработчиками до уровня задач (Task) там где это необходимо. Тут можно вводить время. У Task есть поле Remaining Work.
a. После двух-трех Sprint уже можно ожидать однозначности в стоимостях и уточнить горизонт планирования.
6) Производится проверка PBI в состоянии Commited на основании заданных Test Case.
7) Неизбежно возникающие ошибки следует фиксировать с помощью Bug которые тоже попадают в Product Backlog.
8) Выполненные PBI закрываются с статусом Done
9) Планируется следующий Sprint, процесс повторяется с п.п. 5.
Манипуляции с списками PBI/Bugs/Task в рамках Product Backlog и Sprint осуществляются с помощью стандартных запросов которые уже определены в шаблоне для Sprint 1.
Соответственно после окончания первого спринта следует не забыть изменить запрос «Sprint Backlog» на текущее значение спринта:
Состояния рабочих элементов Scrum
В шаблонах MSF Agile и MSF CMMI используется уже устоявшийся в TFS подход ARC (Active->Resolved->Closed) который не совсем соответствует терминам Scrum.
- В этом шаблоне используются другие наименования состояний:
- PBI,Bug: New->Approved->Commited->Done
- Task: To Do->In Progress->Done
- Impediment: Open->Closed
Напомню, что более детально с Workflow всех рабочих элементов можно ознакомиться как на сайте MSDN, так и с помощью Team Foundation Server Web Acces и Process Editor.
Для примера приведу скриншот из редактора Wokflow для рабочего элемента Bug (он наиболее сложный) процесса Scrum:
Отчеты Scrum
Естественно, практически все поля, которые определены в рабочих элементах Scrum, попадают в системы аналитики Team Foundation Server и позволяют построить несколько важных отчетов, которые в последствии дают возможность понимать, как идут дела на проекте.
Sprint/Release Burndown – два отчета которые дают возможность оценить объемы оставшейся работы по проекту и спринту.
Release Burndown: От спринта к спринту общий объем задач, оценённый в единицах Effort должен уменьшаться. Косвенно через этот график так же можно оценить производительность команды.
Sprint Burndown: Каждый день команда закрывает некоторое количество PBI в рамках спринта.
Отчет Velocity: Усилия которые были затрачены на каждом спринте. Этот отчет перекликается с Release Burndown. Так же на графике представлена средняя цифра (35) производительности команды в рамках спринта. В идеале (и неизменной команде) чем больше было спринтов тем точнее эта цифра, и тем точнее можно предсказать дату окончания проекта.
Build Success Over Time, Build Summary отчеты: показывают состояние сборок проекта в разрезе платформ и пройденных тестов. Позволяют понимать прогресс, масштаб изменений и оценивать качество продукта.
Отчеты по тестам призваны дать оценку общему состоянию качества продукта, а так же решить организационные вопросы связанные с самими тестами. Исходя из информации представленной в этих отчетах можно понять сколько тестов от даты к дате проходят с корректным результатом, сколько с ошибочным, сколько вообще пока не запускалось и сколько тестов заблокировано.
Организовать работу с тестами позволяет отчет Test Case Readiness показывающий сколько тестов уже готово к исполнению и сколько еще пока находится на стадии детализации. В идеале этот отчет должен нарисовать такую картинку:
Заключение
Шаблон процесса Scrum один из самых простых шаблонов процессов для Team Foundation Server, который тем не менее позволяет решить основные вопросы по организации командной работы. Более того, лаконичность Scrum позволяет быстро внедрить этот подход в новые или существующие команды и получить видимый результат за достаточно короткий промежуток времени. Который, хочется верить, будет заключаться в разработке более качественного программного обеспечения и точном планировании.
