VSTS 2010.

Средства гибкого планирования в Visual Studio Team System 2010

Аджои Кришнамурти (Ajoy Krishnamoorthy)

Эта статья основана на предварительной версии Visual Studio Team System (VSTS) 2010. Любые приведенные в ней сведения могут быть изменены.

Cодержание

Долгосрочное планирование
Планирование выпусков и итераций
Рабочие книги Excel VSTS 2010
Книга учета остающейся работы по продукту
Планирование возможностей
Книга учета остающейся работы по итерации
Отчеты

«Гибкое планирование» - оксюморон? Я надеюсь, что читатели так не думают, но при не недавнем тематическом опросе группы специалистов, имевшем место в Лос-Анджелесе, одна женщина из присутствующих гостей указала, что ее организация перешла от гибкого планирования к более формальным практикам. На уточняющие вопросы она ответила, что ее группа более не могла вносить поправки в код, основываясь на устных запросах от руководителя и немедленно развертывать их в производственной среде. Теперь ей приходилось следовать формальной процедуре. Для нее это означало отход от гибкости.

Однако ее понимания гибкой разработки неверно, и я рад, что ее организация установила формальную процедуру внесения изменений. Суть гибкости не в движении вслепую или в прыткости ради экономии времени. На самом деле, это дисциплинированный подход к планированию, учитывающий полученные на практике данные.

Visual Studio Team System (VSTS) 2010 включает в себя новые компоненты и возможности для помощи гибким группам разработчиков в планировании. В этой статье я представлю новые книги учета остающейся работы по продуктам и итерациям, а также набор новых отчетов, которые помогут гибким группам планировать выпуски и итерации продуктов и управлять ими.

Долгосрочное планирование

Проблема отсутствия долгосрочного плана, обладающего точностью, широко распространена и часто считается важнейшим барьером к принятию. Вышедший в 2008 году Опрос по состоянию гибкой разработки указал отсутствие усовершенствованных методов планирования как основную проблему в плане принятия гибких практик в организациях опрашиваемых. Я подозреваю, что для многих отсутствие долгосрочного, точного планирования, эквивалентно полному отсутствию планирования. Гибкие группы выбирают многоуровневое планирование с корректировками направления в ходе выполнения каскадоподобного плана и правильно делают.

Стив Макконнелл (Steve McConnell), рассказывая о своем Конусе неопределенности оценки программного обеспечения, полагает, что оценки, сделанные на ранней стадии проекта могут быть неверны на 400% и более, как правило в сторону завышения: «На ранней стадии проекта конкретные детали по природе программы, которую предстоит создать, детали конкретных требований, детали решения, проектного плана, подбора кадров и других переменных проекта неясны. Изменяемость этих факторов ведет к изменяемости в оценках проекта.»

Само собой, это не означает, что руководство примет стратегию: «Мы не знаем, когда проект будет завершен и на что он тогда будет похож». Это означает изменение подхода к планированию выпусков группами и объеме работы, завершаемой в выпусках.

Рис. 1. Книга учета остающейся работы по продукту и итерации

Планирование выпусков и итераций

В гибких группах, планирование выполняется на двух отдельных уровнях: планирование выпусков и планирования итераций. Планирование выпусков – это высокоуровневая деятельность по планированию, помогающая гибким группам рассматривать широкие наборы компонентов или заметок пользователей. Элементы в книге учета остающейся работы затем получают ранги стека, оцениваются и распределяются между набором итераций. Отметьте, что точность оценок на этом этапе примерно та же, что и при разделении футболок на размеры (маленькие, средние, большие). Задачей на данный момент является получение примерного порядка затрат на различные элементы запланированной работы, а не точных чисел. Это также помогает клиенту выделить требованиям ранги в стеке, держа в уме примерный размер.

В Scrum этот набор заметок пользователей содержится в списке, именуемом книгой учета оставшейся работы по продукту (см. рис. 1). Объем работы, которую нужно выполнить в каждой итерации, в большой степени зависит от скорости работы группы. То, что определяет выпуск, в большой степени зависит от момента, когда выполняется приемлемый набор требований клиентов. Например, если получение первого набора функций занимает четыре итерации, то первый выпуск будет назначен после четвертой итерации.

Планирование итераций гораздо более подробно и происходит перед началом каждой итерации. Высокоуровневые заметки пользователей из книги учета оставшейся работы рассматриваются и, должным образом, разбиваются на более мелкие. На этом этапе группа готова разбивать заметки пользователей на более мелкие истории и определять задачи, необходимые для выполнения запросов заметки пользователя. Эти заметки пользователей и связанные с ними задачи затем оцениваются в часах. На этом этапе группа может понять масштаб итерации.

Microsoft Office Excel – это средство, которое часто можно найти в инструментарии группы, вместе с учетными карточками и наклеиваемыми заметками. VSTS 2010 представляет две новые книги Excel, помогающие гибким группам управлять учетом остающейся работы по продуктами и итерациям. Но прежде чем погружаться в их изучение, давайте бросим быстрый взгляд на шаблон гибкого процесса из VSTS 2010.

Шаблон процесса в VSTS включает в себя типы рабочих элементов, запросы, отчеты и текстовое руководство. Ключевыми сущностями здесь являются рабочие элементы. Рабочие элементы могут быть заметкой пользователя, задачей, ошибкой и так далее. Чтобы приступить к работе, создайте проект группы в Team Foundation Server (TFS) и выберите шаблон процесса VSTS для гибкой разработки (VSTS Process for Agile Software Development v1.0) в мастере нового совместного проекта. Этот шаблон включает в себя следующие типы рабочих элементов:

• Задача
• Заметка пользователя
• Ошибка
• Проблемы
• Тестовый пример

Можно создать свой собственный тип рабочего элемента или настроить определенный рабочий элемент самостоятельно. Познакомьтесь ближе с индивидуализацией рабочих элементов в статье Брайана Рэнделла (Brian Randell) за декабрь 2008 года по использованию и индивидуализации шаблонов процессов TFS, «Team System: Ускорение работы над совместными проектами с помощью рабочих шаблонов».

Теперь давайте углубимся в рабочие книги Excel и взглянем на то, как эти рабочие элементы проходят через процесс разработки и помогают в планировании движения ценности и управления им.

Рабочие книги Excel VSTS 2010

В документе, озаглавленном «Средства для гибкости», Кент Бек (Kent Beck)говорит об изобилии переходов в гибких группах и необходимости для средств учитывать эти переходы. Интеграция рабочих книг планирования на основе Excel с отслеживанием рабочих элементов TFS помогает в минимизации издержек на переходы. Она устраняет или оптимизирует многие повседневные действия, от синхронизации книг учета остающейся работы по продуктам и итерациям, до автоматической записи обновления состояния заметки пользователя или рабочего элемента задачи в последних и создания ассортимента отчетов.

Предлагаемый ниже процесс гибкая группа может использовать для управления книгой учета остающейся работы по продукту и итерации с помощью VSTS 2010:

• Создайте новый совместный проект, используя шаблон гибкого проекта VSTS 2010.
• Создайте книгу учета остающейся работы по продукту, добавив заметку пользователя к листу книги учета остающейся работы по продукту или добавив рабочие элементы изнутри Visual Studio.
• Начните выделять элементы, основываясь на их ранге стека в книге учета остающейся работы по продукту для итерации. По умолчанию создаются итерации 0, 1 и 2. Можно создавать дополнительные итерации, используя параметры совместного проекта.
• Установите запросы для извлечения заметок пользователей, задач и других элементов из определенных итераций и сопоставления их с соответствующими листами книг учета остающейся работы по итерациям.

Интеграция между этими листами и TFS достигается с помощью запросов. Рис. 2 показывает конфигурацию для листа книги учета остающейся работы по продукту. В ленте Excel, на вкладке Team («Группа») в группе Work Items («Рабочие элементы»), щелкните Configure List («Настроить список»). Это открывает диалог настройки свойств списка. В этом диалоге можно выбрать запрос TFS и результат этого запроса будет тем, что можно увидеть в электронной таблице.

Рис. 2. Запрос в электронной таблице Excel

Запросы создаются в проекте рабочей группы. По умолчанию, при настройке проекта рабочей группы создается папка, именуемая Work Items\Team Queries\Workbook Queries. В этой папке можно найти запросы по умолчанию для книг учета остающейся работы по итерациям и продукту.

Чтобы лучше представить себе, как действуют эти книги, давайте взглянем на образец приложения DinnerNow, входящий в October 2008 VSTS 2010 и CTP-версию .NET Framework 4.0. (Последнюю загружаемую CTP-версию можно найти в центре разработчиков Team Suite). Книги учета остающейся работы как по итерациям, так и по продукту, можно найти в папке \DinnerNow\Documents\Shared Documents в Team Explorer.

Книга учета остающейся работы по продукту

Книга учета остающейся работы по продукту играет роль списка запросов и требований, которые клиенты предъявляют к приложению. Я встречал такие термины, как «эпопеи» или «темы», используемые рабочими группами для обозначения наборов высокоуровневых требований. Сведение этого набора требований в список, расстановка их по приоритетам и оценка их на высоком уровне помогает ответить на два важных вопроса этой стадии планирования:

1. 1. Каковы требования к приложению?
2. 2. Сколько оно будет стоить? Очевидно, что ответы на них основаны на оценках. Я видел группы, использующие точки состояния, примерные размеры или часы для выполнения оценок на этом этапе.

Отвечая на эти вопросы, группы могут получить хорошее представление о том, как может выглядеть выпуск или следующие несколько выпусков и на какие сроки можно их планировать. Обычно существуют бюджетные или временные ограничения, такие как предстоящая рекламная кампания, юридическое требование или сезонная активность. Это помогает планировать масштаб выпуска, поскольку им можно управлять основываясь на ограничении.

Если выпуск нацелен на определенную дату, масштаб работы диктуется тем, какие запросы удовлетворять в итерациях, в пределах срока выпуска. Например, если планирование началось в декабре, а дата выпуска установлена на июнь, то, по сути, следует ждать выполнения четырех-пяти итераций (предполагая одномесячные итерации) для завершения работы.

В случае, если твердой даты нет, расписание выпуска будет зависеть от того, когда можно выполнить минимальный набор требований. Например, если минимальный набор требуемых функций можно завершить за три итерации, то первый выпуск можно назначить после трех итераций. Если следующий набор функций можно завершить за пять или шесть итераций, то можно установить запуск выпуска 2 после этих пяти или шести итераций.

Рис. 3 показывает лист учета остающейся работы по продукту для проекта DinnerNow. На нем можно увидеть учет остающихся заметок пользователей. Несколько их этих заметок пользователей уже были выделены определенной итерации и некоторые из них уже были завершены в итерации 0 и итерации 1. Очевидно, что при начале нового проекта, начинать приходится с пустой рабочей книги, начиная создавать в ней эти высокоуровневые истории пользователей.

Рис. 3. Лист учета остающейся работы по продукту

Столбцы на этих электронных таблицах – это поля в рабочем элементе, которые, в свою очередь, сохраняются в хранилище данных TFS. Интеграция между Excel и TFS добавляет ленту Team («Группа») в Excel (см. рис. 4) в которой имеются элементы меню для публикации элементов в книге учета остающейся работы в TFS, ее обновления с помощью обновленных рабочих элементов в TFS и другого.

Рис. 4. Вкладка Team в ленте Excel

Каждая строка учета остающейся работы по продукту сохраняется как рабочий элемент внутри TFS, что показано на рис. 5. С помощью этого типа интеграции члены рабочей группы, использующие Visual Studio, могут обновлять заметку пользователя и другие рабочие элементы внутри самой Visual Studio. Обновление состояния заметки пользователя, оценки или остающейся работы теперь можно проделать без переключения между различными средствами.

Рис. 5. Рабочий элемент в TFS

Планирование возможностей

В качестве части планирования выпуска гибкие группы проведут немало времени, работая над листом – добавляя к нему новые заметки пользователей, оценивая их и, что более важно, расставляя по степени приоритетности. Но не менее важно отслеживать и состояние выпуска. Книга учета остающейся работы по продукту включает лист для планирования ресурсов. Этот лист помогает получить быстрое представление о самих итерациях, основываясь на оценках заметок пользователей и итерации, в которую назначается их работа.

Планирование возможностей является важным действием при планировании выпусков. Оно помогает в понимании того, какие компоненты могут быть завершены в различны итерациях. Ключевой точкой данных в этом расчете является скорость. Скорость – это объем работы, выполняемой группой за итерацию. Если имеются данные от предыдущих итераций, то начать ее оценку лучше с них.

Рис. 6. Использование предыдущих итераций для вычисления скорости

Обычно это именуется «прогнозом, основанным на вчерашней погоде». На практике электронная таблица планирования возможностей может извлечь данные истории из хранилища данных TFS, если оно доступно. Как можно увидеть на рис. 6, я могу выбрать итерацию 1 в качестве итерации, от которой следует получать исторические данные и ввести данные для даты начала, даты окончания и числа членов рабочей группы. В данном случае я получу скорость в 816 часов, а это значит, что группа смогла выполнить 816 часов работы в итерации 1. Если таких данных нет, группы могут начать с примерной оценки и использовать первую итерацию для планирования последующих.

В электронной таблице планирования возможностей можно указать диапазон данных для итераций, число членов группы и любые перерывы в ходе итерации, такие как праздники. Эти данные, в сочетании с оценками заметки пользователя и скоростью, создают таблицу, дающую представление о том, как выглядит рабочая нагрузка итерации. Если видно, что предполагаемая работа выходит за пределы ожидаемых возможностей, то желательно переместить заметки пользователей между итерациями, чтобы добиться приемлемого размещения.

В моем случае в итерации 2 не запланировано никакой работы. Я могу добавить несколько находящихся в списке остающейся работы заметок пользователей к итерации 2. Теперь диаграмма возможностей выглядит подобно показанной на рис. 7. Это хорошая ситуация – ожидаемая работа не превысила возможностей.

Рис. 7. Диаграмма возможностей с выделенной работой для итерации 2

Электронную таблицу остающейся работы по продукту также можно использовать для получения картины общего состояния различных заметок пользователей, после того, как проект запущен. Но гораздо больше информации можно получить от отчетов, таких как отчета по остающейся работе, отчета по ее соотношению со скоростью и степени выполнения заметок пользователей. Эти отчеты включаются в шаблон гибкого проекта, и их можно будет найти в совместном проекте из папки отчетов. Я рассмотрю отчеты ниже в данной статье.

Книга учета остающейся работы по итерации

Итерация – это ключевое действие для гибких рабочих групп. Гибкие группы, практикующие Scrum, знакомы с этим по термину «спринт». Продолжительность итерации обычно варьируется. Группы, использующие eXtreme Programming следуют одно- или двухнедельным операциям, тогда как группы, использующие Scrum, обычно следуют четырехнедельному спринту.

Планирование итераций помогает определить охват определенной итерации. В ходе встречи по планированию итерации группы обычно анализируют истории пользователей, выделенные для определенной итерации, собирают подробные требования, добавляют связанные задачи и оценивают, сколько времени должно уйти на выполнение каждой задачи. На этой встрече владельцы продукта, вместе с остальной частью группы, определяют приоритетность заметок пользователей, основываясь на следующих факторах: зависимостях, оценке цены, подробных требованиях и возможных свидетельствах того, что определенная заметка не так важна, как считалось в ходе планирования выпуска.

Давайте начнем с рассмотрения остающейся работы по итерации в проекте группы DinnerNow. В папке общих документов совместного проекта имеются папки, именуемые Iteration 0, 1 и 2. Внутри каждой из этих папок можно найти запись остающейся работы по итерации. Каждая из электронных таблиц остающейся работы по итерации соединена с определенным запросов, выводящим лишь заметки пользователей и задачи этой определенной итерации.

В случае добавления других типов рабочих элементов, таких как функции, темы или эпопеи, они будут добавлены к этому запросу, чтобы втянуть эти дополнительные рабочие элементы в список. Совместный проект DinnerNow уже включает в себя несколько задач, добавляемых как дочерние элементы к заметкам пользователей в итерации 2. Но, как правило, в ходе встречи по планированию итерации, группы будут добавлять задачи и модифицировать их, чтобы получить хороший план итерации для итерации 2. Рис. 8 показывает запись оставшейся работы по итерации.

Рис. 8. Оставшаяся работа по итерации с дочерними задачами

TFS теперь поддерживает иерархические дочерние элементы и это позволяет создавать деревья родительских/дочерних элементов. В данном случае следующие новые задачи добавляются как дочерние задачи к пользовательской заметке «пользователи должны иметь возможность использовать DinnerNow со своих мобильных телефонов»:

• Определение того, какие части интерфейса пользователя использовать для телефона
• Использование архитектуры стека карты для интерфейса пользователя
• Определение наиболее популярных телефонов
• Уменьшение числа нажатий клавиш, необходимого для размещения заказа

На этом этапе группа готова приступить к выделению задач. Сколько работы берет на себя каждый член группы, зависит от таких факторов, как возможность члена группы работать над данной итерацией, его опыт в данной области и то, сколько времени он был членом группы.

Книга учета остающейся работы по итерации имеет дополнительные таблицы, чтобы помогать в других аспектах планирования и исполнения. Электронная таблица планирования возможностей подобна имеющейся в книге учета остающейся работы по продукту. Эту электронную таблицу можно использовать, чтобы оценить возможности группы.

Электронная таблица балансировки нагрузок полезна как в ходе планирования, так и в ходе самой итерации. Гибкие группы продолжают свое планирование по ходу итерации, чтобы выполнять коррекции по мере того, как становится доступна новая информация об определенных заметках пользователей, на задачах обнаруживаются технические зависимости или члены группы становятся недоступными. Эти случаи требуют обновления распределения задач и здесь-то в дело вступает электронная таблица балансировки нагрузки.

Другой интересной электронной таблицей является таблица, предоставляемая для отслеживания скорости. Те, кто знаком с крикетом, могут узнать такие термины, как текущее число пробежек и требуемое число пробежек. Это два показателя, используемых для определения того, насколько успешно играет команда. Как правило, если требуемое число пробежек выше текущего, бьющей команде необходимо увеличить усилия, чтобы не проиграть матч. С другой стороны, если текущее число пробежек выше требуемого, то дела бьющей команды идут хорошо.

Прежде чем знакомые с крикетом читатели начнут меня дополнять, позвольте мне отметить, что такие показатели, как число сбитых калиток и остающихся серий бросков также важны для полного осознания состояния. Это верно и в гибком проекте. Таблица отслеживания скорости дает быстрое представление о текущей скорости работы команды и скорости, требуемой для завершения заметок пользователей в итерации. Как и в случае крикета, другие параметры, вроде остающихся дней, важны для получения полной картины того, на каком этапе находится работа над итерацией. Например, группа может урезать масштаб, если их текущая скорость не совпадает с требуемой. Опять же, ключевым элементом является прозрачность всего этого и скоординированное выполнение необходимых поправок группой.

Отчеты

Само собой, чтобы начать управлять проектами с помощью VSTS 2010, не нужно быть любителем крикета. Чтобы отслеживать ход проекта, включая темп и остающуюся работу, можно использовать отчеты.

Рис. 9 показывает отчет по соотношению остающейся работы с выполненной для итерации 1. Этот отчет показывает число остающихся и завершенных часов и темп продвижения. Как можно увидеть из числа остающихся часов в диаграмме, группа не выполнила всех задач, выделенных данной итерации.

Рис. 9. Диаграмма соотношения остающейся работы с выполненной

Состояние также показывают линии тенденций. Как можно увидеть в диаграмме, собственно линия тенденции указывает, что работа не будет завершена во время в темпе этой группы во время итерации 1. В ходе итерации группа может наблюдать соотношение оставшейся работы с выполненной и вносить необходимые корректировки курса, также позволяя клиентам знать, что план выпуска может измениться.

Отчет оставшейся работы также довольно полезен. Как можно увидеть на рис. 10, группа устойчиво продвигалась к завершению работы. То, что в ходе этой итерации к учитываемой остающейся работе ничего не добавилось, – хороший знак. Темпы продвижения снизились в конце итерации, что привело к незавершенности ряда задач.

Рис. 10. Остающаяся работа

Как читатели увидели, средства гибкого планирования и электронные таблицы для VSTS 2010 предоставляют рабочим группам интерфейс Excel и интегрированное хранилище данных, записывающее добывающее данные от планирования выпусков до планирования итераций и от исполнения тестов до качества сборки. Это предоставляет отличное средство, как для менеджеров, планирующих гибкие проекты и управляющих ими, так и для разработчиков с тестерами в группе – они могут работать вместе, оценивать продвижение работы, вносить изменения по мере необходимости и управлять всем проектом. Эта интеграция устраняет многие из выполняемых вручную и монотонных действий, которые гибкие группы предпринимают для сбора данных и создания отчетов.

Для достаточно отличающегося от других, более математического подхода к предварительному планированию, взгляните на статью доктора Джеймса Маккефри (James McCaffrey) в рубрике «Тестовый прогон» из данного номера.

Аджои Кришнамурти (Ajoy Krishnamoorthy) – ведущий планировщик продуктов в группе шаблонов и практик корпорации Майкрософт. До этого Аджои был старшим менеджером по продуктам для Microsoft Visual Studio Team System. На этой должности Аджои отвечал за управление продуктами, стратегию и маркетинг. У него имеется свыше десяти лет опыта консультаций в различных ролях, включая роли разработчика, архитектора и технического руководителя проекта. Ознакомиться с его блогом можно по адресу blogs.msdn.com/ajoyk.