Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.
Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организации процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам или данная статья – на выбор.
План захвата темы:
• Описание требований (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:
Обратите внимание, что мне также удалось оставить в неприкосновенности запланированный ранее однодневный загородный тимбилдинг.
В этот день у нас в заливе запланированы гонки на распашных четверках. Говорят, командную работу хорошо развивает…
Автор: ayakovlev
