Статьи

Автор: Аджой Кришнамурти

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

Содержание

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

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

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

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

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

Отсутствие четкого долгосрочного плана является общей проблемой и основной причиной отказа от перехода к Agile. Опрос по состоянию гибкой разработки (Agile Development Survey), проведенный в 2008 году, показал, что отсутствие перспективного планирования является вопросом номер один при переходе к Agile в организациях респондентов. Я подозреваю, что многие понимают отсутствие четкого долгосрочного планирования как абсолютное отсутствие планирования, но Agile подразумевает не что иное, как многоуровневое планирование с коррекцией курса по схеме «водопада».

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

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

Рис. 1 Перечень работ по продукту и в итерации

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

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

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

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

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

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

• Task (Задача)
• User Story (Пользовательская история)
• Bug (Дефект)
• Issues (Проблемы)
• Test Case (Сценарий тестирования)

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

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

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

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

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

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

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

Рис. 2 Запрос в рабочей книгеExcel

Запросы создаются в групповом проекте. При создании группового проекта по умолчанию создается папка WorkItems\TeamQueries\WorkbookQueries. В ней располагаются стандартные запросы к рабочим книгам перечня работ по продукту и перечня работ итераций.

Чтобы лучше понять принцип функционирования рабочих книг, рассмотрим пример приложения Dinner Now, которое включено в VSTS 2010 и .NETFramework 4.0 CTP, вышедшие в октябре 2008 года. (Последнюю версию CTP можно найти в Team Suite Developer Center.) Рабочие книги перечней работ по продукту итерации располагаются в папке \DinnerNow\Documents\SharedDocuments в Team Explorer.

Рабочая книга перечня работ по продукту

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

1. Какие требования предъявляются к приложению?
2. Сколько это будет стоить? Безусловно, цифра здесь будет лишь оценочной. Я знаю, что на этом этапе для оценки часто используют различные подходы (баллы, размеры футболок или необходимое количество часов работы).

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

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

Если есть некоторый запас гибкости по конечной дате, планирование выпускаемой версии будет опираться на минимальный набор требований, которые можно реализовать. Например, если такой минимальный набор необходимых функций может быть выполнен за три итерации, выпуск Версии 1 может быть назначен через три итерации. Если следующий набор функций может быть реализован за пять или шесть итераций, выпуск Версии 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 часов, т.е. в Итерации 1 группа смогла выполнить 816 часов работ. При планировании будущих итераций группы могут начинать с оценки и использовать данные о скорости в первой итерации.

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

В рассматриваемом случае в Итерации 2 не планировались никакие работы. Добавим несколько оставшихся пользовательских историй в перечень работ для Итерации 2 и получаем диаграмму нагрузки, как показана на рис. 7.В данном случае все просто замечательно – предполагаемая работа не превышает нагрузки.

Рис. 7 Диаграмма нагрузки и работа, назначенная для выполнения в Итерации 2

Рабочая книга перечня работ по продукту также может использоваться для получения общей картины состояний пользовательских историй в ходе проекта, но отчеты, такие как Burn down and Velocity (Выполнение и скорость), Remaining Work (Невыполненная работа) и Stories Progress (Динамика обработки историй), намного более информативны. Они включены в шаблон Agile и находятся в папке Report (Отчет) группового проекта. Отчеты будут рассмотрены в этой главе чуть позже.

Рабочая книга перечня работ итерации

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

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

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

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

Рис. 8 Перечень работ итерации с дочерними задачами

В настоящее время TFS поддерживает иерархическую структуру рабочих элементов, что позволяет создавать деревья родительских/дочерних элементов. В данном случае, в пользовательскую историю «Users should be able to use DinnerNow from their cell phones» (Пользователи должны иметь возможность использовать DinnerNow с мобильных телефонов) добавляются следующие новые дочерние задачи:

• Identify which parts of the UI to use for the phone (Определить части пользовательского интерфейса, используемые для телефона)
• Use a card stack architecture for the UI (Использовать специальную архитектуру для организации пользовательского интерфейса)
• Identify most popular phones (Определить наиболее популярные марки телефонов)
• Reduce number of keystrokes needed to place an order (Сократить число нажатий клавиш для размещения заказа)

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

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

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

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

Отчеты

Для отслеживания выполнения работ по проекту можно использовать отчеты, такие как диаграмма выполнения работ и диаграмманевыполненных работ.

На рис. 9 представлен отчет о выполнении работ для Итерации 1. На этой диаграмме показаны количество отработанных часов, количество оставшихся рабочих часов и темп выполнения. Как видно из количества оставшихся рабочих часов, группа не выполнила все задачи, запланированные для данной итерации.

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

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

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

Рис. 10 Невыполненная работа

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

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

Аджой Кришнамурти (AjoyKrishnamoorthy) – ведущий специалист по планированию продуктов группы patterns&practices Microsoft. До этого Аджой занимал пост ведущего руководителя продукта в Microsoft Visual Studio Team System и отвечал за управление, стратегию и маркетинг платформы для разработки ПО. Имеет более чем10-летний опыт работы в области консалтинга, занимал различные должности, включая разработчика, архитектора и руководителя технического проекта. Его блог можно найти по адресу blogs.msdn.com/ajoyk.

Источник: http://msdn.microsoft.com/en-us/magazine/dd347827.aspx

Переведено с разрешения правообладателей, все права защищены.