Agile Team Foundation Server

Как заставить Agile работать на вас в TFS 2010

Крис Адамс

Продукты и технологии:
Team Foundation Server 2010, Visual Studio Scrum 1.0, Microsoft Solutions Framework for Agile Software Development версии 5.0
В статье рассматриваются:

• внедрение MSF Agile;
• извлечение бизнес-ценности из пользовательских историй;
• планирование итераций в MSF Agile;
• средства отслеживания Product Planning и Iteration Backlog;
• настройки, специфичные для групповой разработки;
• интеграция TFS с Windows SharePoint Services;
• SharePoint и проекты TFS 2010;
• ретроспективы Agile;
• переход на Scrum 1.0;
• использование рабочей книги итераций (iteration workbook);
• назначение работы членам группы.

Крис Адамс (Chris Adams) — менеджер групповых программ Microsoft, руководитель группы разработки, которая создает ПО на основе средств менеджмента Microsoft на предприятиях. До этого в течение семи лет занимался IIS (blogs.iis.net/chrisad) в качестве менеджера программ в таких областях, как развертывание, удобство поддержки, UI и базовая архитектура. Активно пишет в блоге blogs.technet.com/chrad, где основное внимание уделяет Windows, System Center и Visual Studio. С ним можно связаться по адресу chrad@microsoft.com.**
Выражаю благодарность за рецензирование статьи экспертам Аарону Бьёрку (AaronBjork) и Джону Соча-Лейалоху (JohnSocha-Leialoha).**

Это история пути одной из групп к Agile с использованием Team Foundation Server (TFS) 2010.

В Agile Manifesto есть несколько ключевых моментов, крайне важных для понимания того, как Agile-группы должны совместно работать. В том числе оценивается роль индивидуальных участников (и их взаимодействие между собой) в работе с различными процессами и инструментами. Эти оценки (в числе других) используются группами как одна из причин для перехода к Agile-разработке (гибкой разработке). За прошедшие десять или около того лет со времени появления этого манифеста были разработаны разнообразные виды Agile. Я буду больше говорить о нескольких вариантах в TFS 2010, которые дают возможность использовать один из двух шаблонов Agile-процессов, и о том, как наша группа в Microsoft использует их.

После реорганизации, проведенной в Microsoft несколько лет назад, главной целью нашей группы разработки ПО стала задача обеспечить применение нами того инструментария, который можете использовать и вы, наши клиенты. Тем самым мы отказались от использования внутреннего инструментария, годами существовавшего в Microsoft. Наша группа разработки, входящая в подразделение Management & Security Division (MSD), занимается в основном созданием ПО, которое позволяет Microsoft предоставлять сервисы всему спектру клиентов: пользователям, администраторам и инженерам ИТ, а также операторам онлайновых сервисов. Если в двух словах, то наша группа, по большому счету, ничем не отличается от вашей: мы создаем ПО, расширяющее или улучшающее бизнес-процессы, на которые полагаются клиенты.

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

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

Что сработало для нас, может сработать и для вас

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

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

Мы хотели вести разработку в стиле Agile, но не знали, как этого добиться.

Внедрение MSF Agile версии 5.0

Мы перешли на TFS 2010 на ранних этапах его бета-тестирования и решили создать один из наших проектов с использованием Microsoft Solutions Framework Agile версии 5.0 (далее MSF Agile для краткости). Мы искали шаблон процесса, который помог бы нам добиться основных целей: обеспечить эффективное планирование процесса создания продукта, ритмичное продвижение разработки, и, что самое важное, улучшить взаимодействие между разработчиками, тестерами и менеджерами программ (program managers, PM). Жизненный цикл, предоставляемый в MSF Agile (рис. 1), казался идеально подходящим для того, что мы искали.

Рис. 1. Процесс MSF Agile

В MSF Agile имеется несколько типов рабочих элементов (work item types, WIT), помогающих работать в стиле Agile. Мы начали с изучения каждого WIT (табл. 1), чтобы понять, как эффективно пользоваться ими.

Табл. 1. Определения типов рабочих элементов в MSF Agile

Тип рабочего элемента

Описание

User Story (пользовательская история)

Описывает действия, которые пользователь сможет выполнять с продуктом

Task (задача)

Отслеживает работу, которую нужно выполнить

Bug (ошибка)

Описывает расхождение между требуемым и текущим поведением, а также позволяет отслеживать работу, которую нужно выполнить для устранения дефекта и подтверждения исправления

Issue (проблема)

Отслеживает препятствие, мешающее прогрессу

Test Case (тестовый сценарий)

Описывает набор этапов, подлежащих тестированию, и ожидаемые результаты

Shared Steps (общие этапы)

Определяет повторно используемый набор тестовых этапов и результатов

Хотел бы отметить важный момент. Хотя мы изучили каждый WIT, поначалу мы использовали не все из них. Вместо этого большую часть внимания мы уделили пользовательским историям, задачам и ошибкам. И лишь спустя почти год мы приступили к внедрению некоторых других WIT, в частности тестовых сценариев. На данный момент наша группа все еще не использует WIT «проблема», но это не значит, что так должно быть в вашем случае. Как и многие группы, осваивающие Agile, мы использовали только то, что понравилось, а остальное отбрасывали. Тем самым я хочу подчеркнуть, что не все используют Agile-разработку ПО в полном объеме и что TFS 2010 обеспечивает необходимую гибкость через шаблон MSF Agile.

Извлечение бизнес-ценности из пользовательских историй

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

Через некоторое время мы поняли, что в хорошей пользовательской истории должно быть три ключевых элемента. Во-первых, должен быть заголовок, очень кратко отражающий суть истории. Используя короткие заголовки, легче рассортировать пользовательские истории в порядке важности. Во-вторых, должно присутствовать описание в форме «В качестве <тип пользователя> я хочу <некая цель>, потому что <некая причина>», что создает контекст для данной пользовательской истории. То есть почему то-то и то-то добавляет ценность и для кого. Это ценность для клиента! В-третьих, существуют критерии приемлемости (acceptance criteria), значимость которых мы оценили лишь впоследствии, когда переключились на шаблон процесса Scrum 1.0 (далее Scrum 1.0 для краткости) в Microsoft Visual Studio. Критерии приемлемости дают группе четкое понимание того, что мы планируем поставлять в конечном счете.

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

Группы вроде нашей часто самостоятельно решают, что для них важно. Это противоречит Agile Manifesto, в котором подчеркивается, что все вращается вокруг клиента. Чтобы перебросить мостик через этот расселину, мы используем поле ранжирования (stack-rank field) в WIT «пользовательская история» для определения порядка выполнения работ. Это поле используется в собеседованиях с нашими клиентами и партнерами, чтобы гарантировать соответствие приоритетов обеих сторон. С помощью простого TFS-запроса заинтересованные лица и клиенты могут просматривать упорядоченный список работ, необходимых для реализации потребностей клиента (этот список также публикуется на нашей информационной панели, о которой я расскажу позже).

Планирование итераций в MSF Agile

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

Работа в Agile-группах делится на итерации фиксированной длительности. Но насколько продолжительной должна быть итерация? После дискуссий мы выбрали четырехнедельные итерации, так как не считали, что сумеем создавать законченное ПО в сроки, меньшие четырех недель. Через несколько итераций мы обнаружили, что сделать всю работу, запланированную на одну итерацию, весьма трудно, и попробовали перейти на шестинедельные итерации. Однако это сделало слишком долгим цикл обратной связи с клиентами, и нам пришлось вернуться к четырехнедельным итерациям. Спустя примерно 10 месяцев мы перешли на двухнедельные итерации (спринты), что позволило нам быстрее взаимодействовать с клиентами.

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

С целью распределения ресурсов наша группа обычно тратила весьма значительное время на «проектирование» функций и последующий расчет стоимости их создания. В MSF Agile мы перешли на подсчет пунктов каждой истории и поля Original Estimate, в которое записывали оценку по необходимой работе. Для оценки мы применяли покерное планирование (planning poker) в процессе планировании спринтов (итераций) (подробнее о покерном планировании см. на сайте planningpoker.com). Прогресс в достижении поставленных целей на данной итерации мы отслеживали ежедневно, требуя от членов группы обновлять свои поля Completed Work и Remaining Work (табл. 2).

Табл. 2. Управление плановыми оценками в MSF Agile

Поле в MSF Agile

Описание

Original Estimate (исходная оценка)

Начальное значение для оставшейся работы; задается один раз в момент начала работ

Remaining Work (оставшаяся работа)

Оценка времени оставшейся работы (в часах), которое потребуется на выполнение задачи

Completed Work (выполненная работа)

Время работы (в часах), потраченное на выполнение задачи

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

Средства отслеживания Product Planning и Iteration Backlog в MSF Agile

Используя рабочие книги Product Planning и Iteration Backlog в MSF Agile (рис. 2), мы улучшили свои возможности в оценке сроков работ, которые мы могли бы успешно выполнить.

Рис. 2. Шаблоны рабочих книг для планирования разработки в MSF Agile

Нас не обескуражили неудачи на первых итерациях — мы же только начинали. При планировании итераций пользовательские истории сопоставлялись с определенными итерациями с помощью рабочих книг Product Planning. Для экономии времени мы пытались подготавливать итерации до начала планирования спринта. (Подробнее о формировании итераций см. по ссылке bit.ly/lakyZA.) Когда мы больше узнали о средней скорости выполнения работ нашей группой (сколько пунктов истории было выполнено на предыдущих итерациях), мы стали лучше распределять истории между итерациями с некоторой долей уверенности, что сумеем закончить работы к определенной дате.

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

Рабочая книга открывается с вкладкой Iteration Backlog, где показываются ваши пользовательские истории и любые последующие задачи, связанные с этими историями. Эта вкладка связана с запросом к дереву TFS (TFS tree query), что позволяет просматривать каждую пользовательскую историю и все относящиеся к ней задачи как дочерние элементы в привычном древовидном представлении (подробнее о типах запросов к дереву TFS см. по ссылке bit.ly/l0tv1K). Вам нужно будет обновлять этот запрос для каждого спринта, чтобы на первой вкладке показывались все элементы, назначенные на данный момент итерации. Вы можете манипулировать данными на этой вкладке и заново публиковать их на TFS-сервере, не выходя из Excel; именно так мы и создавали задачи, относящиеся к пользовательской истории, при планировании спринта (подробнее см. по ссылке bit.ly/lmPN4k).

Вторая вкладка, Area & Iteration, позволяет задать даты начала и окончания работ в данной итерации (Start Date и End Date), а также путь к этой итерации (Iteration), как показано на рис. 3.

Рис. 3. Даты начала и окончания работ в рабочей книге Iteration Backlog в MSF Agile

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

Третья вкладка, Interruptions, позволяет вести учет нерабочих дней, например отпусков или выходных, когда члены группы не могут участвовать в проекте. Однако на этой вкладке указывать нерабочие дни можно только для членов группы, которым в данный момент закреплены рабочие элементы в итерации. Таким образом, прежде чем открывать эту вкладку, распределите работы и закрепите их за членами группы (на первой вкладке, Iteration Backlog) — иначе в раскрывающемся списке членов группы будет пусто.

Очень ценной для нас оказалась четвертая вкладка, Capacity. На этой вкладке выводится информация о перегруженности (over capacity) и недогруженности (under capacity) для каждого члена группы. Эти данные вычисляются на основе объема оставшейся работы и количества дней в итерации, а также учитывается информация на вкладке Interruptions.

Вкладка Capacity существенно упрощает балансировку нагрузки, позволяя перераспределять задачи между членами группы. До внедрения Agile нам не хватало как раз этого — возможности переназначать задачи в первые дни, а не по прошествии длительного времени, когда делать это слишком поздно.

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

Рис. 4. Планирование загруженности группы в MSF Agile

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

Полное руководство по использованию этой рабочей книги и другие детали опубликованы в моем блоге (bit.ly/fZpzWx).

Настройки, специфичные для групповой разработки

Программное обеспечение не всегда создается только одной группой. На практике несколько групп работает совместно. Проблема с разработкой, в которой участвует несколько групп, заключается в наличии разных «групповых» процессов. Некоторые группы придерживаются методологии по принципу водопада, тогда как другие используют Scrum. Уникальность каждой группы зачастую создает проблемы, и наша группа тоже работала не в вакууме. Напротив, один из наших первых проектов на основе MSF Agile потребовал взаимодействия между двумя группами, использующими разные длительности итераций и разные стили, хотя обе применяли Agile. И вот здесь нашей группе помогла гибкость TFS 2010: он позволяет настраивать любой WIT (и даже создавать совершенно новые WIT). Новый WIT нам не требовался, но понадобилось настроить один из существующих.

Мы разрабатывали новое решение User-Driven Installation (bit.ly/kjySZk) в тандеме с группой Microsoft Deployment Toolkit (MDT). Оно позволяет конечным пользователям изменять свои системы Windows 7 на настольных компьютерах или лэптопах. Группа MDT применяла Scrum (используя закрытый инструментарий, доступный только внутри Microsoft), а наша группа — TFS 2010. Помимо этого, группы интенсивно взаимодействовали с особым акцентом на ошибках, поскольку наша группа создавала новые функции и исправляла ошибки, тогда как тестированием полностью занималась другая группа.

Группы совместно проработали несколько итераций только для того, чтобы увидеть, что на первых итерациях не удается добиться заявленного выхода (например, готового ПО). Наша скорость работы была низкой. До совместной работы с партнером наша группа уже использовала Agile в течение нескольких месяцев и заканчивала каждую итерацию со всей выполненной работой. Тогда почему же мы вдруг перестали выпускать все, что планировали?

Ирония в том, что мы не включали оценки работы над ошибками при планировании спринтов. Таким образом, зачастую мы принимали в работу новые функции вместе со всеми ошибками, которые партнерская группа просила нас устранить. Поскольку в WIT «ошибка» не было полей учета времени, таких как Remaining Work и Completed Work, это влекло за собой необъективную оценку, и мы даже не подозревали о дополнительной работе, которая не завершалась.

Средства настройки в TFS 2010 позволили довольно легко модифицировать этот WIT под наши потребности. Мы включили в WIT «ошибка» поля времени, добавив их к форме Bug, и тогда смогли отслеживать как ошибки, так и задачи. Подробнее о том, как добавить собственное поле в WIT, см. в моем блоге (bit.ly/gb1BOb).

Интеграция TFS с Windows SharePoint Services

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

В TFS 2010 есть готовые средства интеграции для использования новой или существующей службы Windows SharePoint Services (WSS). Создание проекта MSF Agile включает (при необходимости) создание сайта SharePoint, содержащего настраиваемую информационную панель (dashboard). Чтобы улучшить взаимодействие внутри группы и с клиентами, мы, в том числе, использовали информационные панели, встроенные в TFS. Самое ценное в информационной панели и интеграции с SharePoint — гибкость. Например, информационная панель, предлагаемая в стандартном проекте TFS, не дает всей нужной нам информации. Мы хотели большего.

Информационные панели уйти от ежедневного обмена по электронной почте отчетами, такими как Burndown, Velocity или Bug Counts, и вместо этого предоставить нашему менеджменту и партнерам доступ к сайту SharePoint, где они могли наблюдать за ходом работ почти в реальном времени.

Как и в любой организации, разные люди хотели наблюдать за разными показателями. Мы настроили нашу информационную панель так, чтобы включать в нее дополнительные отчеты, которые по умолчанию на ней не показываются. Например, наша группа управления встречается с нами ежемесячно для проверки выполненных работ и обсуждения нашего продвижения в жизненном цикле Agile-проектов. В ходе одной из таких встреч наш руководитель попросил показывать ему пользовательские истории, над которыми мы работаем, достигнутый прогресс, а также пользовательские истории в журнале невыполненных работ, которые на данный момент не включены в спринт. Чтобы узнать больше о том, как мы смогли адаптировать информационную панель под требования этого руководителя, см. статью в моем блоге по ссылке bit.ly/jJ6XUp.

Раскройте мощь SharePoint и проектов TFS 2010

Если у вас уже есть корпоративная версия Microsoft Office SharePoint Server (MOSS), вы можете перейти на новый уровень функциональности, используя проекты MSF Agile, связанные с MOSS. Как уже упоминалось, TFS 2010 поставляется с WSS, но в WSS нет некоторых средств корпоративного уровня.

Мы хотели использовать некоторые из отчетов Excel, поставляемых с MSF Agile. Эти отчеты, как показано на рис. 5, открывают массу возможностей, например можно использовать Excel Web Services (EWS) для хостинга отчетов и их данных в веб-фрагментах в информационных панелях наших проектов.

Рис. 5. Отчеты Excel вMSF Agile

Эта функциональность недоступна, если в вашей группе нет сервера (или серверов) SharePoint 2007 или 2010 в редакции Enterprise.

TFS 2010, обнаружив наличие сервера SharePoint Enterprise при создании проекта MSF Agile, создает информационную панель, которая включает отчеты как EWS, так и SQL Server Reporting Services (SSRS). Такая гибкость дает много возможностей, в том числе возможность использования таких отчетов, как Code Churn и Bugs by Assignment, наряду с отчетами, предоставляемыми в MSF Agile, например Burndown и Burn Rate.

Основной проблемой, с которой столкнулась наша группа, поддерживая информационную панель SharePoint, заключалась в управлении, а именно: на кого следует возложить задачу обновления отчетов в информационной панели. Например, когда наша группа использовала двухнедельные итерации, даты начала и окончания работ в Burndown нужно было обновлять через каждые две недели, а иначе данные в информационной панели теряли актуальность. Мы поддерживали информационную панель в течение нескольких месяцев, но со временем стали искать способы либо автоматизировать создание этих отчетов, либо упростить отслеживание итераций. Это было незадолго до выпуска Scrum 1.0 (его можно скачать по ссылке bit.ly/fdojaD).

Agile: ретроспективы бесценны

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

TFS в MSF Agile позволяет отслеживать ретроспективы через шаблон невыполненных работ на итерации (iteration backlog template), предоставляемый на сайте SharePoint вашего проекта. Эта рабочая книга дает возможность отслеживать скорость выполнения работ, что сделано отлично и что можно было бы улучшить (рис. 6).

Рис. 6. Шаблон ретроспектив итерации в MSF Agile

Как группа мы гордимся, что уделяли внимание не только совершенствованию в этой области, но и постоянно подвергали переоценке все то, что мы делали. Хотя многому мы учились при ретроспективном анализе, мы также оптимизировали наши Agile-процессы по мере развития технологий. В нашем случае это произошло, когда Microsoft выпустила для TFS новый шаблон процесса, Scrum 1.0.

Переход на Scrum 1.0

Хотя наша группа не стремилась работать строго в стиле Scrum, во многих отношениях была похожа на Scrum-группу. Еще до внедрения MSF Agile мы использовали такие термины, как Product Backlog Items (PBIs), а затем прошли переход на пользовательские истории.

Для оценки нового шаблона процесса Scrum 1.0 мы, как и раньше, выбрали один из наших коротких проектов. Во многом по аналогии с тем, что мы делали при внедрении MSF Agile, мы потратили некоторое время на изучение WIT, доступных в шаблоне Scrum 1.0. Как показано в табл. 3, терминология слегка отличается, но многие концепции схожи.

Табл. 3. Определения типов рабочих элементов в Scrum 1.0

Тип рабочего элемента	Описание
Product Backlog Item (элемент списка невыполненных работ по продукту)	Отслеживает действие, которое пользователь сможет выполнить с помощью продукта
Task (задача)	Отслеживает работу, которую нужно выполнить
Bug (ошибка)	Описывает расхождение между требуемым и текущим поведением, а также позволяет отслеживать работу, которую нужно выполнить для устранения дефекта и подтверждения исправления
Impediment (препятствие)	Отслеживает препятствие, мешающее прогрессу
Test Case (тестовый сценарий)	Данные на серверной стороне для набора этапов, подлежащих тестированию
Shared Steps (общие этапы)	Данные на серверной стороне для повторно используемого набора тестовых этапов
Sprint (спринт)	Спринт, в ходе которого выполняется работа, взятая из списка невыполненных работ по продукту, с точными датами начала и окончания

Самое большое изменение, которое бросилось нам в глаза при переходе на Scrum 1.0, заключалось в наличии WIT под названием Sprint. Он позволяет группам Scrum 1.0 определять конкретные даты начала и окончания спринтов, отслеживать задачи спринта и хранить пометки из ретроспектив в TFS 2010. Как уже упоминалось, MSF Agile предлагал схожую функциональность в рабочей книге Iteration Backlog и шаблон Microsoft Word для ретроспектив. Возможность рассматривать спринты, их цели и ретроспективы как рабочий элемент, которому впоследствии назначается работа, была для нас очень притягательна. Это стало основной причиной нашего перехода с MSF Agile на Scrum 1.0.

Менеджеры программ в нашей группе, отвечающие за управление информационными панелями, отчетами и другими артефактами итераций, обнаружили, что она часто тратят много времени на обновление отчетов, чтобы эти отчеты отражали актуальное состояние дел для нашей группы и партнеров. С другой стороны, в Scrum 1.0 есть WIT с именем Sprint, где назначаются даты для спринта. Burndown-отчет, в котором используется информация из рабочих элементов Sprint для отображения корректного диапазона дат, представлен на рис. 7.

Рис. 7. Пример отчета по Burndown-спринту в Scrum 1.0

Этот WIT оказался очень удобен для работы, которой мы занимались при планировании спринтов. Нам больше не было нужды настраивать отчеты для указания дат начала и окончания работ — теперь это делалось за нас, когда мы создавали рабочий элемент Sprint перед планированием спринта.

Напомню, что MSF Agile и Scrum 1.0 предлагают разные варианты Agile-группам. Выбор, конечно же, остается за вами. В табл. 4 показаны WIT из каждого шаблона процесса и их соответствие друг другу. И вновь я посоветовал бы любой группе, внедряющей Agile-разработку ПО с применением TFS 2010, первым делом глубоко изучить, как пользоваться каждым WIT.

Табл. 4. Сравнение типов рабочих элементов в MSF Agile и Scrum 1.0

MSF Agile	Scrum 1.0
User Story	Product Backlog Item
Task	Task
Bug	Bug
Issue	Impediment
Test Case	Test Case
Shared Steps	Shared Steps
—	Sprint

Чтобы узнать больше о различиях между этими шаблонами процесса, читайте статью в моем блоге по ссылке bit.ly/i5tF2G.

Использование рабочей книги итераций в проектах Scrum 1.0

По мере того, как наша группа создавала все больше проектов в TFS 2010, мы начали понимать, что нам не хватает рабочей книги итераций. Она значительно помогала нам в понимании любых перерывов в работе и, что важнее, загруженности группы на уровне спринтов. Поэтому мы адаптировали данную рабочую книгу так, чтобы она была совместимой со Scrum 1.0.

Мой коллега, Джон Соча-Лейалоха (John Socha-Leialoha), в своем блоге (blogs.msdn.com/jsocha) обрисовал, как модифицировать рабочую книгу Iteration Backlog, чтобы ее можно было использовать с шаблоном Scrum 1.0. В изначальном виде эта рабочая книга не годится отчасти потому, что использует данные, хранящиеся в полях, которые отсутствуют в Scrum. В статье Джон на примере нашей группы помогает другим научиться, как адаптировать эту рабочую книгу под проекты Scrum 1.0. В итоге наша группа сумела использовать рабочую книгу Iteration Backlog при планировании и на совещаниях для отслеживания загруженности участников группы. Один из недостатков, обнаруженных нами в Scrum 1.0, заключается в том, что по умолчанию при планировании индивидуальным членам группы не назначаются конкретные работы. Вместо этого работы ранжируются по степени важности и впоследствии извлекаются из списка предстоящих работ в соответствии с определенным порядком. Таким образом, для совместимости с рабочей книгой Iteration Backlog нам пришлось самим назначать все задачи индивидуальным участникам группы, чтобы потом наблюдать за их загруженностью.

Назначение работы членам группы

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

Наша группа сделала большой шаг вперед после перехода на шаблон Scrum 1.0, когда отказалась от назначения работ индивидуальным лицам и переключилась на назначение на основе области задач (discipline-based assignment). В первых проектах Scrum 1.0 мы обнаружили, что нам не удается добиться успеха из-за того, что мы назначали задачи индивидуальным членам группы вместо использования области. Мы обсудили это в группе и решили использовать поле Activity, переименовав его в Discipline в рабочем элементе (рис. 8).

Рис. 8. Назначение работы на основе области задач в Scrum 1.0

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

Заключение

Наш экскурс в Agile не полный; для совершенствования процессов есть много дополнительных возможностей. Распространенное заблуждение в отношении Agile состоит в том, что Agile-группам не хватает дисциплины. Это совершенно неправильно. Напротив, мы на своем опыте убедились, что в Agile-группах существует высокий уровень дисциплины. До перехода на Agile у нашей группы не было эффективного процесса и, увы, дисциплины. Именно с момента перехода на TFS 2010 и шаблон процесса MSF Agile началось наше «взросление» как группы.

Наш путь начался от использования шаблона процесса MSF Agile, а сейчас мы используем шаблон процесса Scrum 1.0, и у нас есть ощущение, что мы уже почти «там». Надеюсь, что наш путь вдохновит и вашу группу к переходу на TFS 2010 и один из этих шаблонов процесса.

Однако без TFS 2010 нам не удалось бы выйти на тот уровень, на которым мы находимся сегодня. В конце концов, это был рассказ о том, как группа успешно перешла на Agile с использованием TFS 2010.