Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.
Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организаци�� процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам, практическое занятие на русском MSDN или данная статья – на выбор.
План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей
Контекстом планирования и управления работами в 11-й версии является «Команда». Это приятное нововведение облегчает организацию работ нескольких команд над одним проектом. Таким образом, даже масштабные проекты могут быть реализованы по гибким методологиям, если применить подходы к масштабированию команд. Однако мы сейчас сосредоточимся на работе одной команды.
Для команды нужно обязательно определить:
• Список членов команды
• Набор подсистем, над которыми работает команда
• Итерации, к которым привязаны работы команды
Команда на своём сайте будет видеть только те элементы, которые относятся к её подсистемам и итерациям, поэтому если вдруг команда не видит задачу, проверьте, отнесена ли задача к одной из подсистем команды. Чтобы сократить статью, будем считать, что команда уже создана.
Итак, с главной страницы мы можем перейти в Product Backlog – список новых требований к продукту. Те, требования, которые уже реализованы и закрыты, уходят в раздел Past и не отображаются. Те, которые сейчас в работе — в разделе Current.
SCRUM предполагает ведение линейного списка требований, поэтому веб-интерфейс реализует именно такой подход. Впрочем, никто не мешает построить иерархические отношения между элементами backlog и работать с таким деревом в Visual Studio или через веб с помощью запросов.
В списке должны быть все требования – и функциональные и нефункциональные. Самый быстрый способ добавить новую запись – ввести заголовок и нажать кнопку Add. Запись сразу появится в списке, но мы не увидим никаких дополнительных параметров. Если нажать кнопку Add при пустой строке Title, то увидим полный диалог вв��да параметров:
Здесь нас сейчас интересует поле Effort — это то поле, куда вводится относительная оценка трудоёмкости реализации данного требования. Оценка вводится в условных единицах – Storypoints ( «в попугаях» — народн.), которые получаются при проведении командной оценки. В методологии SCRUM для этого используется Agile Poker, который вполне может быть темой для небольшой статьи. Инструментами для проведения такого оценивания являются: команда, закрытое помещение, стол, колода карт Agile Poker. В TFS этот процесс никак не поддержан инструментально, и это – правильно, иначе получится не Agile Poker, а бокс по переписке, ибо самое главное в нём – обсуждения команды между итерациями схождения оценки. Т.е. в поле Effort мы вводим уже одну цифру, полученную в результате планирования. Это не часы, не дни, не деньги, не строчки кода, не классы, это приблизительная относительная условность. Storypoints. Сепульки.
Однако, уже после первой успешной итерации мы имеем данные о том, сколько примерно Storypoints команда успевает реализовать за срок итерации — Velocity:
Показатель Velocity можно использовать в разных целях: для планирования объема работ на новую итерацию, для определения объема оплаты за работу, для измерений в процессе постоянного повышения эффективности работы команды. Один из вариантов нужно вычеркнуть обязательно.
Включив инструмент Forecast, мы можем посмотреть, как примерно наши требования по трудоёмкости поместятся в предстоящие итерации:
Элементы в этом списке можно перемещать мышкой вверх-вниз (менять Order), можно вводить другие оценки текущей Velocity, в поле Iteration мы можем указывать конкретную итерацию (Sprint):
Но прежде, чем указывать итерацию, мы должны утвердить требования. Требования (ещё их иногда называют «хотелками») собирают все, которые поступают от пользователей, бизнеса, администраторов, группы проектирования и т.д. Они попадают в состояние New. После этого, принимается решение о том, утверждается это требование (Approved) или отклоняется (Removed):
Отклонённые требования уходят из беклога, новые и утверждённые – остаются.
Перед стартом новой итерации команда на основе приоритетов, своей текущей производительности, пожеланий владельца продукта, выбирает требования для реализации (коммитится на их выполнение). Требования переводятся из состояния Approved в Commited и также исчезают из списка «хотелок» и попадают в Sprint Backlog – план конкретной итерации.
Для того, чтобы требование (и его задачи) появились на доске задач текущей итерации, у требования (задачи) должна быть указана эта итерация (см. выше).
На доске отображаются в виде стикеров задачи, над которыми работает сейчас команда для реализации выбранных требований.
Реализация каждого требования может заключаться в решении нескольких задач: написании бизнес-логики, создании интерфейсов в клиентах на каждую из платформ, описании тестов, создании справочной документации и т.д.
Нефункциональное требование, как и любое другое, требует учета и усилий по его реализации. Например, создания тестовой инфраструктуры и тестов производительности – для требований производительности и т.п.
Реализация требования может растянуться на несколько итераций, в то время как отдельную задачу рекомендуется не делать длинее 2-3-х дней.
Задачи можно создавать здесь же, на доске, тогда они автоматически привязываются к требованию, подсистеме и текущей итерации:
Тут же, в поле Remaining Work можно ввести оценку в человеко-часах. Таким образом, инструмент позволяет комбинировать относительные методы оценивания требований и почасовое планирование загрузки.
Новая задача появится в статусе To Do и оценка оставшейся работы добавится к суммарной оценке работ по требованию:
На доске мы можем выбрать исполнителей (или исполнитель может выбрать себе задачу), перетащить её мышкой в состояние In Progress, а по завершении – в Done.
Есть интересные возможности, связанные с удобным управлением задачами в Visual Studio. Это и список своих актив��ых задач в Team Explorer, и ассоциация их с изменениями в исходном коде и автоматически перевод в завершенное состояние при check-in, но статья и так слишком длинная.
Имея список работ, длительность итерации и оценки в часах по работам, мы можем посмотреть график динамики уменьшения оставшихся работ (график «сгорания работ»):
Теперь у нас есть всё, чтобы вернуться к планированию загрузки исполнителей.
Последний взгляд на доску работ, но уже сгруппированных по исполнителям:
Перейдем в Backlog, выберем текущий спринт и увидим те же задачи, но уже в виде дерева и с кратким анализом загрузки команды на диаграмме справа:
Мы видим общий объем работ всей команды (Team 52 of 54h).
Разбивку работ по категориям (Work By: Activity) – эту категоризацию мы не использовали, но есть возможность отнести каждую задачу к какой-либо категории:
И далее мы видим загруженность наших исполнителей. Красным цветом подсвечена перегруженность Brian Keller, которому только что была добавлена задача аудита.
Чтобы решить проблему, я иду к менеджеру Брайана и упрашиваю его, чтобы он на этой итерации работал на мой проект не 4 часа в день, как мы раньше договаривались, а 5. Информацию о доступности ресурсов я ввожу на закладке capacity:
Обратите внимание, что мне также удалось оставить в неприкосновенности запланированный ранее однодневный загородный тимбилдинг.
В этот день у нас в заливе запланированы гонки на распашных четверках. Говорят, командную работу хорошо развивает…
UPD: Оказывается, есть даже более подробная статья на MSDN. Но эта-то — моя! =)
Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организаци�� процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам, практическое занятие на русском MSDN или данная статья – на выбор.
План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей
Контекстом планирования и управления работами в 11-й версии является «Команда». Это приятное нововведение облегчает организацию работ нескольких команд над одним проектом. Таким образом, даже масштабные проекты могут быть реализованы по гибким методологиям, если применить подходы к масштабированию команд. Однако мы сейчас сосредоточимся на работе одной команды.
Для команды нужно обязательно определить:
• Список членов команды
• Набор подсистем, над которыми работает команда
• Итерации, к которым привязаны работы команды
Команда на своём сайте будет видеть только те элементы, которые относятся к её подсистемам и итерациям, поэтому если вдруг команда не видит задачу, проверьте, отнесена ли задача к одной из подсистем команды. Чтобы сократить статью, будем считать, что команда уже создана.
Описание требований
Итак, с главной страницы мы можем перейти в Product Backlog – список новых требований к продукту. Те, требования, которые уже реализованы и закрыты, уходят в раздел Past и не отображаются. Те, которые сейчас в работе — в разделе Current.
SCRUM предполагает ведение линейного списка требований, поэтому веб-интерфейс реализует именно такой подход. Впрочем, никто не мешает построить иерархические отношения между элементами backlog и работать с таким деревом в Visual Studio или через веб с помощью запросов.
В списке должны быть все требования – и функциональные и нефункциональные. Самый быстрый способ добавить новую запись – ввести заголовок и нажать кнопку Add. Запись сразу появится в списке, но мы не увидим никаких дополнительных параметров. Если нажать кнопку Add при пустой строке Title, то увидим полный диалог вв��да параметров:
Планирование итераций
Здесь нас сейчас интересует поле Effort — это то поле, куда вводится относительная оценка трудоёмкости реализации данного требования. Оценка вводится в условных единицах – Storypoints ( «в попугаях» — народн.), которые получаются при проведении командной оценки. В методологии SCRUM для этого используется Agile Poker, который вполне может быть темой для небольшой статьи. Инструментами для проведения такого оценивания являются: команда, закрытое помещение, стол, колода карт Agile Poker. В TFS этот процесс никак не поддержан инструментально, и это – правильно, иначе получится не Agile Poker, а бокс по переписке, ибо самое главное в нём – обсуждения команды между итерациями схождения оценки. Т.е. в поле Effort мы вводим уже одну цифру, полученную в результате планирования. Это не часы, не дни, не деньги, не строчки кода, не классы, это приблизительная относительная условность. Storypoints. Сепульки.
Однако, уже после первой успешной итерации мы имеем данные о том, сколько примерно Storypoints команда успевает реализовать за срок итерации — Velocity:
Показатель Velocity можно использовать в разных целях: для планирования объема работ на новую итерацию, для определения объема оплаты за работу, для измерений в процессе постоянного повышения эффективности работы команды. Один из вариантов нужно вычеркнуть обязательно.
Включив инструмент Forecast, мы можем посмотреть, как примерно наши требования по трудоёмкости поместятся в предстоящие итерации:
Элементы в этом списке можно перемещать мышкой вверх-вниз (менять Order), можно вводить другие оценки текущей Velocity, в поле Iteration мы можем указывать конкретную итерацию (Sprint):
Но прежде, чем указывать итерацию, мы должны утвердить требования. Требования (ещё их иногда называют «хотелками») собирают все, которые поступают от пользователей, бизнеса, администраторов, группы проектирования и т.д. Они попадают в состояние New. После этого, принимается решение о том, утверждается это требование (Approved) или отклоняется (Removed):
Отклонённые требования уходят из беклога, новые и утверждённые – остаются.
Перед стартом новой итерации команда на основе приоритетов, своей текущей производительности, пожеланий владельца продукта, выбирает требования для реализации (коммитится на их выполнение). Требования переводятся из состояния Approved в Commited и также исчезают из списка «хотелок» и попадают в Sprint Backlog – план конкретной итерации.
Планирование работ
Для того, чтобы требование (и его задачи) появились на доске задач текущей итерации, у требования (задачи) должна быть указана эта итерация (см. выше).
На доске отображаются в виде стикеров задачи, над которыми работает сейчас команда для реализации выбранных требований.
Реализация каждого требования может заключаться в решении нескольких задач: написании бизнес-логики, создании интерфейсов в клиентах на каждую из платформ, описании тестов, создании справочной документации и т.д.
Нефункциональное требование, как и любое другое, требует учета и усилий по его реализации. Например, создания тестовой инфраструктуры и тестов производительности – для требований производительности и т.п.
Реализация требования может растянуться на несколько итераций, в то время как отдельную задачу рекомендуется не делать длинее 2-3-х дней.
Задачи можно создавать здесь же, на доске, тогда они автоматически привязываются к требованию, подсистеме и текущей итерации:
Тут же, в поле Remaining Work можно ввести оценку в человеко-часах. Таким образом, инструмент позволяет комбинировать относительные методы оценивания требований и почасовое планирование загрузки.
Новая задача появится в статусе To Do и оценка оставшейся работы добавится к суммарной оценке работ по требованию:
На доске мы можем выбрать исполнителей (или исполнитель может выбрать себе задачу), перетащить её мышкой в состояние In Progress, а по завершении – в Done.
Есть интересные возможности, связанные с удобным управлением задачами в Visual Studio. Это и список своих актив��ых задач в Team Explorer, и ассоциация их с изменениями в исходном коде и автоматически перевод в завершенное состояние при check-in, но статья и так слишком длинная.
Имея список работ, длительность итерации и оценки в часах по работам, мы можем посмотреть график динамики уменьшения оставшихся работ (график «сгорания работ»):
Теперь у нас есть всё, чтобы вернуться к планированию загрузки исполнителей.
Загруженность исполнителей:
Последний взгляд на доску работ, но уже сгруппированных по исполнителям:
Перейдем в Backlog, выберем текущий спринт и увидим те же задачи, но уже в виде дерева и с кратким анализом загрузки команды на диаграмме справа:
Мы видим общий объем работ всей команды (Team 52 of 54h).
Разбивку работ по категориям (Work By: Activity) – эту категоризацию мы не использовали, но есть возможность отнести каждую задачу к какой-либо категории:
И далее мы видим загруженность наших исполнителей. Красным цветом подсвечена перегруженность Brian Keller, которому только что была добавлена задача аудита.
Чтобы решить проблему, я иду к менеджеру Брайана и упрашиваю его, чтобы он на этой итерации работал на мой проект не 4 часа в день, как мы раньше договаривались, а 5. Информацию о доступности ресурсов я ввожу на закладке capacity:
Обратите внимание, что мне также удалось оставить в неприкосновенности запланированный ранее однодневный загородный тимбилдинг.
В этот день у нас в заливе запланированы гонки на распашных четверках. Говорят, командную работу хорошо развивает…
UPD: Оказывается, есть даже более подробная статья на MSDN. Но эта-то — моя! =)