Как использовать метод управления проектами Scrum, работая с IBM Rational Team Concert и платформой Jazz

Согласно научному сотруднику IBM Грэйди Бучу (Grady Booch), IBM Rational Team Concert и платформа IBM Rational Jazz предназначены для формирования "максимально гладкой поверхности для разработки за счет устранения или автоматизации выполнения многих повседневных задач разработчиков". Одной из многих точек повышенного трения, которую удалось устранить с помощью Rational Team Concert и его шаблона Scrum Process, является интеграция agile-планирования и отслеживания в процесс разработки. Раньше при использовании популярных инструментов agile-планирования пользователю приходилось непрерывно переключаться между этими инструментами и средой IDE для определения работы, которую следует произвести, завершить и сдать. За счет интеграции этих и других операций Rational Team Concert и Jazz обеспечивает большую прозрачность, расширяет возможности для сотрудничества и трассируемости, предоставляет больше информации по процессу в рамках единой платформы, что позволяет улучшить производительность разработки и оптимизировать процесс поставки ПО.

Термин "scrum" произошел из игры в регби и является сокращением для "scrummage" или "scrimmage" (драка за мяч) . В контексте разработки ПО Scrum является таким методом управления проектом в процессе гибкой разработки, который позволяет удерживать фокус на предоставлении заинтересованным лицам максимальной бизнес-ценности за минимально возможное время. Процесс Scrum гарантирует, что наиболее ценная остающаяся функциональность будет реализована на следующей итерации, с особым акцентом на том, что работа всегда будет завершена к моменту формирования поставляемого результата. Работа структурирована по двух - или четырехнедельным итерациям, при этом работающее ПО поставляется в конце каждого интервала.

Для изучения того, как использовать шаблон Scrum Process при работе с Rational Team Concert, давайте настроим проект и выполним для него первую итерацию. Данные для примера проекта взяты из расширенного примера, приведенного в книге Майка Кона (Mike Cohn) под названием "Оценка и планирование в agile-разработке" (издательство Prentice Hall, 2005), в которой описана группа Scrum в Bomb Shelter Studios, работающая над новой компьютерной игрой под названием Havannah. Данные для этого примера приведены в прилагаемом документе "Данные для примера Rational Team Concert Scrum" (см. в конце статьи).

В данной статье предполагается, что вы зарегистрированы в jazz.net, загрузили и установили программное обеспечение в соответствии с приведенными там инструкциями. Вам нужно дойти до момента, когда ваш клиент Rational Team Concert сможет подключиться к вашему репозиторию Jazz . После краткого введения в процесс Scrum мы приступим к созданию основанного на Scrum проекта в Rational Team Concert.

У вас нет кода? Загрузите ознакомительную версию продукта Rational Team Concert Standard Edition.

Обзор процесса Scrum

Инфраструктура Scrum содержит следующие взаимосвязанные аспекты:

• Роли
  • Владелец продукта
  • Scrum-мастер
  • Сотрудник группы
• Формальности (собрания или совещания)
  • Планирование спринта
  • Обзор спринта
  • Ретроспектива спринта
  • Ежедневный Scrum
• Артефакты
  • Журнал незавершенных работ по продукту
  • Журнал незавершенных работ по спринту
  • Диаграмма "Burndown"
  • Список препятствий

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

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

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

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

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

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

Во время Ежедневного Scrum-собрания группа отвечает на три вопроса:

• Что я делал вчера?
• Что я буду делать сегодня?
• Что может помешать моей работе?

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

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

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

Когда элементы из Журнала незавершенных работ по продукту выбираются для выполнения, они становятся частью Журнала незавершенных работ по спринту. Журнал незавершенных работ по спринту содержит определенные задачи, ассоциированные с функциональностью из Журнала незавершенных работ по продукту. Во время выполнения спринта статус элементов работ в Журнале незавершенных работ по спринту обновляется ежедневно. Этот обновленный статус дает возможность генерировать диаграмму Burndown для спринта. Диаграмма Burndown (Остаток) графически показывает объем остающихся работ по проекту. Обычно на этой диаграмме также изображают "идеальную" линию, служащую индикатором гладкого выполнения работы от старта до финиша спринта.

Если имеются препятствия или помехи на пути движения, Scrum-мастер может вести в качестве дополнительного артефакта Scrum Список препятствий (илиСписок помех) . Все артефакты Scrum должны сохраняться там, где они будут легко доступны для всех сотрудников группы.

Шаблон Scrum-процесса в Jazz поддерживает все основные роли, формальности и артефакты Scrum. Rational Team Concert предоставляет простой доступ как к этим функциям, так и ко многим другим, как через пользовательский интерфейс полнофункционального клиента Eclipse™, так и через Web-интерфейс пользователя.

Настройка примера проекта

Прежде чем приступить к изучению того, как Rational Team Concert и шаблон Scrum-процесса в Jazz поддерживают Scrum-группы, нам следует поработать над базовой настройкой проекта. Приведенные снимки экрана были сделаны для версии Beta 3 Rational Team Concert и Jazz и предварительной версии шаблона Scrum-процесса, поэтому они должны быть очень похожи на выпущенный продукт.

Создание области проекта

1. 1. Убедитесь в том, что ваш сервер Jazz запущен, клиент Rational Team Concert открыт и вы выполнили регистрацию для подключения к репозиторию.
2. Для создания новой области проекта щелкните правой кнопкой мыши по вашему подключению Repository Connection в представлении Team Artifacts (рисунок 1) и затем выберите New > Project Area.

Рисунок 1. Создание новой области проекта Jazz

Новый мастер области проектов имеет две панели (рисунок 2).

3. На первой панели введите имя нового проекта (в этом примере Havannah) и щелкните Next ("Далее").
4. Из доступных шаблонов процессов выберите шаблон Scrum и щелкните Finish ("Готово"). (В выпущенном продукте имя шаблона Scrum-процесса не имеет суффикса "(Early Draft)".)

Рисунок 2. Шаги мастера создания области проекта

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

Рисунок 3. Теперь проект Havannah отображается во всех областях групп Team Area.

В левом столбце в представлении Team Artifacts вы можете видеть новую область проекта с папками Builds (Сборки), Reports (Отчеты), Streams (управление версиями), Work Items (элементы работ), и Plans (Планы). Последние и являются той областью, работа с которой обсуждается в этой статье. В редакторе области проектов имеется область для ввода описания проекта. В нижнем правом углу вы можете увидеть раздел для добавления приложений. Этот раздел предназначен для поддержки шаблона процесса Scrum и не является подходящим местом для размещения ваших приложений к проекту.

Добавьте сотрудников и укажите их роли

Как создатель области проекта вы изначально обладаете правами администратора (Admin). Тем не менее большинство полномочий по модификации структуры проекта в рамках шаблона процесса Scrum принадлежат Scrum-мастеру или владельцу продукта. Поэтому одним из первоочередных действий должно быть добавление сотрудников в проект и указание их ролей (по меньшей мере для Scrum-мастера и для владельца продукта). Как правило, членство в области проекта предназначено для сотрудников с полномочиями управления. Другие сотрудники позже будут добавлены в область группы.

1. Щелкните по стрелке слева от Members для развертывания этой панели (рис. 4).

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

2. Нажмите кнопку Create (Создать) (рисунок 4) для запуска мастера New Member (новый сотрудник).

Рисунок 4. Представление Members (Сотрудники)

3. Выделите Create… (Создать) (рисунок 5) и затем щелкните Next ("Далее").

Рисунок 5. Создание нового пользователя

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

Рисунок 6. Представление информации пользователя

5. Нажмите кнопку Next ("Далее").
6. Выберите группы безопасности Jazz, подходящие для пользователя (см. рисунок 7).
   • Пользователи Jazz обладают принятыми по умолчанию полномочиями в области проекта. Это обычно позволяет им создавать и добавлять элементы работ, просматривать отчеты и использовать другие функции, определенные параметрами защиты проекта.
   • Администраторы Jazz могут работать с различными настройками, относящимися к серверу Jazz и к проекту, например, такими как создание дополнительных областей проекта.

Рисунок 7. Представление Repository Groups (группы репозитория)

7. Нажмите кнопку Next ("Далее").
8. Выберите для пользователя подходящий тип лицензии (рисунок 8).
   • Лицензия Developer (разработчик) подходит для сотрудников группы, занимающихся разработкой кода и выполнением сборок.
   • лицензии Build и ClearCase Connector, например, обычно присваиваются только административным пользователям.
   • Лицензии Contributor (сотрудник) подходят всем другим пользователям.

Рисунок 8. Варианты лицензий клиентского доступа

9. Нажмите кнопку Finish ("Готово").
10. 10. Теперь, когда в области Members имеется сотрудник, кнопка Process Roles (роли процесса) (видимая, но ранее неактивная) становится доступной, когда вы выберете Sasha из списка Members (сотрудники).
11. Щелкните по кнопке Process Roles (рис. 9), выберите роль Scrum-мастера, добавьте ее к списку Assigned Roles (присвоенные роли) и щелкните Finish ("Готово").

Рисунок 9. Выбор и добавление ролей

12. Добавьте Frank в качестве Product Owner (владелец продукта).

На рисунке 10 показан законченный список сотрудников для примера проекта, а также Scrum-мастер на случай будущего расхождения привилегий.

Примечание:
Scrum-мастер не обязательно должен быть сотрудником группы.

Рисунок 10. Законченный список сотрудников группы

13. Для сохранения изменений нажмите Save в верхнем правом углу редактора области проекта Havannah.

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

14. Так как пользователи являются вымышленными, закройте это диалоговое окно.

Измените принятое по умолчанию имя категории

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

1. 1. Измените принятое по умолчанию имя категории для элементов работ в Product Backlog (Журнале незавершенных работ по продукту) (рисунок 11) для согласования с тем, как Scrum управляет функциональностью, которая добавляется в продукт. (Следует отметить, что этот шаг не является необходимым для выпущенного продукта.)

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

Рисунок 11. Изменение имени категории в Журнале незавершенных работ по продукту.

2. Среди вкладок в нижней части окна редактора области проекта выберите Work Item Categories, затем выберите первую категорию (пока только эту) под именем проекта и измените ее, выбрав Edit ("Редактировать") внизу выпадающего меню.
3. Измените имя на Product Backlog (Журнал незавершенных работ по продукту), нажмите OK и сохраните изменения в области проекта.

Добавление сотрудников и их ролей в область группы

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

1. Щелкните по вкладке Team Organization (Организация группы) на левой панели (рисунок 12). Если вкладка не открывается, используйте путь меню Window > Show View > Team Organization для ее открытия.
2. Дважды щелкните мышью по папке Havannah Team (которая была автоматически создана при создании области проекта) для открытия редактора области группы.
3. В панели редактора щелкните Add ("Добавить") для запуска мастера, который позволит выбрать сотрудников области проекта для добавления в эту группу.

Рисунок 12. Панель редактора для Havannah Team

4. Добавьте Sasha в качестве Team Member (сотрудник группы) и Scrum-мастера:
   1. Наберите s (буква S) в текстовом поле имени пользователя для поиска подходящих имен (рисунок 13). Sasha появится в списке Matching Users (Соответствующие пользователи).
   2. Нажмите Select ("Выбрать") для его перемещения в список Selected Users (Выбранные пользователи).
   3. Нажмите кнопку Next ("Далее") для присвоения ему ролей Scrum-мастер и Team Owner.
   4. Нажмите кнопку Finish ("Готово").

Рисунок 13. Добавление сотрудников в группу

5. Пока в системе нет других пользователей. Используя кнопку Create (Создать), добавьте других сотрудников в качестве сотрудников группы, как вы это делали раньше для Frank и Sasha.

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

Рисунок 14. Обновленный список сотрудников

6. Затем откройте раздел Administrators и добавьте Sasha в качестве администратора Области проекта. Позже, при необходимости, администратор области проекта может удалить вас из администраторов.

Организация итераций ("спринтов")

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

Выпадающее меню в Repository Connection (подключение к репозиторию) (показано на рис. 15) содержит пункты для выполнения выхода и регистрации.

Рисунок 15. Выход и регистрация в качестве другого пользователя

1. Используя то же самое выпадающее меню, что и для выхода, войдите как Sasha (по умолчанию пароль совпадает с идентификатором пользователя, поэтому этот пароль будет тоже Sasha, пока его не изменят). Так как область проекта является узлом верхнего уровня, вам следует использовать выпадающее меню этого уровня (рисунок 16) и выбрать Open (двойной щелчок приведет только к его развертыванию или свертыванию).

Рисунок 16. Открытие области проекта

Когда редактор области проекта снова откроется, вы увидите созданные по умолчанию "заглушки" итераций, установленные шаблоном процесса при создании области проекта (рис. 17).

2. Выделите Release 1.0 в Process Iterations (Итерации процесса) и щелкните Edit Properties (Изменить свойства).

Рисунок 17. Изменение свойств релиза ПО

3. Этот идентификатор должен быть уникальным, при этом вы можете изменить его для соответствия вашему продукту.
4. Установите начальную и конечную даты для релиза (см. Примечание), убедитесь, что установлен флажок "A release is scheduled for this iteration" (На эту итерацию намечен релиз) и щелкните OK.
5. Аналогично можно редактировать свойства для существующих итераций

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

Маленькие синие треугольники на значке Release 1.0 и на значке Sprint 1 указывают, что это текущий релиз и текущая итерация.

6. Для добавления итерации щелкните Create Iteration (Создать итерацию) для добавления новой итерации или выберите существующую итерацию и щелкните Duplicate (Дублировать) (рисунок 18). Для сохранения согласованности идентификаторов и названий на дисплее вы можете использовать дублирование.
7. В этом примере создайте третью итерацию для продукта: щелкните Sprint 2 и затем выберите Duplicate (Дублировать).

Рисунок 18. Дублирование итерации

8. Удалите текст "Copy_of_" и измените соответствующие разделы в названии новой итерации.
9. Скорректируйте даты и щелкните OK.
10. Сохраните изменения в области продуктов.

Создание записи в Журнале незавершенных работ по продукту

Product Backlog (Журнал незавершенных работ по продукту) является одним из наиболее важных артефактов в методе Scrum.

1. Для его создания в нашем примере перейдите к представлению Team Artifacts (Артефакты группы) (рисунок 19) и добавьте план итераций к релизу, выбрав Release 1.0 > New > Iteration Plan.

Совет:
Вам может понадобиться открыть один или несколько узлов дерева для просмотра итерации Release 1.0. Дополнительные планы релиза и спринтов (при их наличии) находятся ниже линии разработки (в данном случае Main Development (Основная разработка)), но для упрощения доступа текущий релиз и спринт отображаются на уровне Plans (Планы).

Рисунок 19. Создание журнала незавершенных работ по продукту

2. В открывшемся мастере New Iteration Plan (Новый план итераций) введите Product Backlog (Журнал незавершенных работ по продукту) для имени и щелкните Finish ("Готово").

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

• На странице Overview (см. вкладку внизу окна) вы можете ввести информацию о вашем продукте, используя форматирование в стиле wiki. Она будет отображаться как часть Web-страницы вашего проекта в пользовательском Web-интерфейсе.
• Область Attachments внизу представления редактора служит удобным местом для добавления любых требований или другой общей документации, имеющей отношение к данному релизу: эти документы становятся легко доступными для всех сотрудников группы.

Рисунок 20. Изменение плана итераций

 4.    Используйте опцию выпадающего меню Group by (Сгруппировать по) на панели с правой стороны (рисунок 21) для переключения на представление Folders (Папки), если это представление еще не выбрано. С этим представлением проще всего работать, если требуется добавить много новых историй .

Рисунок 21. Переключение на представление Folder

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

5. Щелкните правой кнопкой мыши по папке Top Items, выберите Add Work Item (Добавить элемент работы) (рисунок 22) и затем щелкните Story для добавления первого элемента.

Рисунок 22. Добавление элементов Журнала незавершенных работ по продукту в виде историй

В папку добавляется новый элемент и открывается соответствующая текстовая область для ввода Story Summary (краткого описания истории) (рисунок 23).

Рисунок 23. Ввод краткого описания истории

Так можно легко вводить новые истории.

6. 6. Используйте выпадающее меню для добавления дополнительных историй (также можно нажать Ctrl+Enter для перехода в контекст элемента работ, затем стрелку вниз для перехода к первому элементу - Story (истории) и затем клавишу Enter).
7. Нажмите кнопку Save в верхнем правом углу вкладки Iteration Plan (план итераций) для сохранения вашей работы.

После добавления историй следующим шагом для владельца продукта будет расстановка приоритетов историй. На текущий момент доступна лишь шкала приоритетов от 1 до 10. Система запоминает пользовательское упорядочение, выполненное с помощью перетаскивания мышью (или с использованием сочетаний клавиш Alt+стрелка вверх или вниз). Поэтому, если вы таким образом расположите истории с некоторыми приоритетами, то каждый раз, когда вы выбираете User defined order (Порядок, определенный пользователем) из выпадающего меню Group by (Сгруппировать по), вы увидите их именно в этом порядке. Вы можете легко присвоить приоритеты, используя выпадающее меню, встроенное в элементы списка, как показано на рисунке 24.

Рисунок 24. Расстановка приоритетов историй

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

8. Дважды щелкните по истории для открытия ее редактора (в этом примере в истории говорится: "В качестве игрока я могу играть против слабого алгоритма, способного распознавать кольца", как показано на рисунке 25).

Рисунок 25. Редактирование истории

9. Перейдите на вкладку Acceptance Test (приемочное тестирование) и добавьте истории туда.

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

Рисунок 26. Предварительный просмотр историй
 

Stories (истории) и Story Points (баллы историй)

Планирование итерации

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

Создайте план итераций в Журнале незавершенных работ по спринту

1. 1. Сначала создайте план итераций в Журнале незавершенных работ по спринту.
   1. A. Аналогично приведенным ранее инструкциям по созданию плана итераций Журнала незавершенных работ по продукту, щелкните правой кнопкой мыши по Sprint 1 (1.0) в узле Plans представления Team Artifacts (Артефакты группы) и выберите New (Создать), затем Iteration Plan (План итераций).
   2. В мастере введите Sprint Backlog (Журнал незавершенных работ по спринту) в качестве имени.
   3. В открытом окне Product Backlog выберите нужные истории, щелкните правой клавишей мыши и выберите Plan For, затем Sprint 1.0.

Рисунок 27. Создание плана итерации

Истории будут перемещены на вкладку Sprint Backlog. Первоначально истории будут показаны с маленькими стрелками на левом краю, что указывает на то, что они ожидают перемещения.

2. Нажмите кнопку Save для завершения перемещения.
3. Щелкните по вкладке Sprint Backlog для перемещения на передний план.

Добавление задач

Теперь добавьте задачи к историям.

1. Сначала создайте ярлык для упрощения этой операции: щелкните правой кнопкой мыши по первой истории для добавления элемента работы (аналогично тому, как вы добавляли истории), но при этом выберите из выпадающего списка опцию Set Default (установить по умолчанию) (рисунок 28).

Рисунок 28. Добавление задач

Отобразится диалоговое окно, похожее на приведенное на рисунке 29, поэтому, когда вы нажмете на Ctrl+Enter, будет автоматически добавлен элемент принятого по умолчанию типа. Позже вы можете использовать это диалоговое окно для удаления или повторного присваивания принятого по умолчанию типа элемента работы.

Рисунок 29. Установка принятого по умолчанию типа элемента работы

Теперь щелкните OK.

2. Чтобы начать ввод задач, выберите первую историю и нажмите Ctrl+Enter.

Задача будет создана под выбранной историей. При этом обратите внимание, что она располагается с тем же уровнем отступа, что и история (рисунок 30).

3. Так как эта задача "принадлежит" истории, однократно нажмите Tab для ее перемещения под историю.

Примечание.
Rational Team Concert отметит эту задачу как пока еще не имеющую требуемого поля Summary, но это предупреждение будет снято после добавления этого поля. Если вы не хотите получать это предупреждение, то сначала введите Summary.

Рисунок 30. Выделение задачи отступом

Задачи, добавляемые к этой истории, будут автоматически рассматриваться как дочерние истории (подыстории).

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

4. Продолжайте добавление задач для этой и для других историй.

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

Добавление оценок времени выполнения

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

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

1. В представлении Team Artifacts (артефакты группы) откройте узел My Team Areas (Области моей группы) и затем откройте Havannah Team .
2. Дважды щелкните по имени Rose для открытия подробной информации по этому пользователю (рисунок 31).

Рисунок 31. Корректировка рабочей загрузки группы

Rose имеет возможность работы в группе лишь 75% своего времени.

3. Щелкните расположенную внизу вкладку Work Environment (Рабочая среда) и затем по разделу Work Assignment (Присвоение работ), далее щелкните по строке Havannah Team и по кнопке Change (Изменить) (рисунок 32).

Рисунок 32. Изменение уровня присваивания

4. Уменьшите присваивание до 75%.
5. Нажмите кнопку OK.

Это скорректирует количество часов, имеющихся у Rose для присваивания работ. Обратите внимание, что вскоре у нее выходной день.

6. Переключитесь на вкладку Scheduled Absences (Запланированные отсутствия), щелкните New (Создать) на правой стороне списка и введите дату для выходного дня (рисунок 33).
7. Нажмите кнопку OK и Save для обновления подробных данных по Rose.

Рисунок 33. Добавление отсутствий

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

8. Вернитесь к вкладке Журнал незавершенных работ по спринту (откройте узел Plans и при необходимости дважды щелкните по Sprint Backlog).
9. Когда группа примет решение по оценкам времени выполнения, эти интервалы легко можно указать с использованием выпадающего меню, которое отображается при щелчке по маленькому значку часов, как показано на рисунке 34. (Вместо этого вы можете дважды щелкнуть по каждой задаче и открыть ее, но описанная выше процедура проще). Если вашу оценку времени выполнения нельзя установить с помощью выпадающего меню, выберите More (Больше), после чего отобразится небольшое окно ввода, в котором вы сможете ввести вашу оценку. Введите оценки времени выполнения в виде дней или часов, например: 10 ч или 2 д.

Рисунок 34. Ввод оценки времени выполнения

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

Совет:
Обычно сотрудники группы Scrum сами регистрируются для выполнения задач, и присвоения можно выполнять в этот момент. Так как различным сотрудникам группы может понадобиться различное количество времени для завершения задачи, то весьма затруднительно выполнить оценку времени без присвоения задачи. При этом имеется похожее выпадающее меню, в котором перечисляются сотрудники группы Havannah (рисунок 35).

Рисунок 35. Присвоение пользователей задачам

По мере расстановки задач можно отслеживать рабочую нагрузку на группу. Самый простой способ состоит в том, чтобы вывести представление организации группы (рисунок 36), которое будет обновляться по мере выполнения оценок. Это представление можно держать открытым при работе с представлением Sprint Backlog.

Рисунок 36. Представление Team Organization (Организация группы)

Обратите внимание, что у Rose есть лишь 54 доступных рабочих часа, что вызвано ее ограниченной вовлеченностью в рабочий процесс и отпуском. Распределение задач выполняется до тех пор, пока у сотрудников группы не останется доступного рабочего времени. Для успешного решения задач группой Scrum помните о том, что необходимо оставлять некоторое незанятое время в рабочей загрузке каждого сотрудника на случай ошибок в оценке рабочего времени и для компенсации перерывов в работе.

Примечание.
Если представление Team Load пусто или выводится строка "Not Connected" (нет подключения), то вам следует сконфигурировать представление: щелкните по направленному вниз белому прямоугольнику на правой стороне представления Team Load, затем воспользуйтесь выпадающим меню (рисунок 37) и выберите Configure (Конфигурировать).

Рисунок 37. Конфигурирование представления Team Load (загрузка группы)

11. На следующей странице выберите Project Area (должно отобразиться название проекта Havannah) и выберите Team Area (Havannah Team).
12. Дважды нажмите кнопку OK и рабочая загрузка для сотрудников группы должна стать видимой, как это показано на рисунке 38.

Рисунок 38. Добавление сотрудников группы в представление Load

Выполнение работы

Для сотрудников группы наиболее простым способом отслеживания своей работы является использование представления My Work ("Моя работа"), которое по умолчанию открывается на левой панели. Если вы используете это представление в первый раз, его нужно сконфигурировать. Допустим, что вы зарегистрированы в системе как Prasad: три приведенных ниже экранных снимка (рисунки 39, 40 и 41) иллюстрируют шаги, требуемые для заполнения этого представления.

1. В первой области, показанной на рисунке 39, щелкните по ссылке для выбора Project Area (Область проекта) с целью конфигурирования этого представления. Это диалоговое окно показывает все доступные области проектов.
2. Выделите Havannah и щелкните OK.
3. Так как Prasad использует это представление в первый раз, вся работа находится в его Inbox. Следуйте инструкциям и щелкните по ссылке для принятия работы.

После этого работа перемещается на панель Current Work (текущая работа).

Рисунок 39. Конфигурирование представления MyWork

Обратите внимание, что текущая рабочая панель (рисунок 40) указывает, что работа "Imprecisely Planned" (неточно запланирована), но тем не менее она запланирована в часах и присвоена некоторому сотруднику.

Рисунок 40. Приемка присвоенной работы

4. В пределах этого представления вы можете использовать указатель вашей мыши для перетаскивания элементов (или использовать Alt + курсор вверх или вниз) для установки порядка выполнения элементов работ (которые Jazz будет помнить).

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

На рисунке 41 показаны два других способа просмотра присвоенной работы:

• В папке Work Items откройте папки Shared Queries и Predefined и дважды щелкните по запросу Open assigned to me (Открыть присвоенные мне). При этом будет открыто представление запроса, показанное на рис. 41.
• Также в представлении Sprint Backlog вы можете внести изменения в расположенном на правой панели выпадающем меню Group By, указав Group by Owner (Группировать по владельцу). Это отобразит истории, с которыми ассоциирован каждый пользователь: при развертывании истории будет отображено, какие задачи пользователя связаны с этой историей.

Рисунок 41. Два представления назначенных мне присваиваний

Работу с элементом можно начать через выпадающее меню из представлений Query или My Work. Вы можете также открыть задачу для изменения ее состояния (см. рис. 42).

Рисунок 42. Работа с задачей

Отслеживание и регистрация степени выполнения

Сотрудники группы должны начать работу над задачами, решать их и регистрировать затраченное на них время. Учитывая, что в методе Scrum ценится завершенная работа, а не начатая, предпочтительно начинать и заканчивать элемент работ, и лишь затем переходить к следующему элементу. Это позволяет сотрудникам быстрее завершать истории и раньше перемещать их в состояние "Ready for Sprint Review" (Готовность для обзора спринта). Чтобы помочь сотрудникам отслеживать свои истории и успешность оценки задач, следует вводить данные Time Spent (Затраченное время) для задач, ежедневно решаемых сотрудниками (см. рис. 43). Time Spent - это простое текстовое поле; таким образом, если над задачей работают несколько дней, каждый сотрудник должен ежедневно обновлять поле Time Spent, включая в него предыдущее значение плюс затраченное дополнительное время.

Рисунок 43. Регистрация затраченного времени

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

Также степень выполнения истории необходимо отслеживать при начале работы над ней. Часто бывает, что определенного сотрудника, ответственного за всю историю в целом, нет, поэтому после завершения задач в рамках истории Scrum-мастер может присвоить истории атрибут "Готовность для обзора спринта" для ежедневно проводимого собрания Scrum (см. рис. 44). Этот статус истории отображается в инструментальной панели Project Area (Область проекта).

Рисунок 44. Отметка готовности истории к обзору спринта

Одним из простых способов подготовки к ежедневному собранию Scrum служит использование запроса Recently Modified для идентификации задач, которые были обновлены за истекший день или около этого (рис. 45). Количество часов, определяющее понятие "недавно", можно задавать как аргумент запроса; по умолчанию принято значение в 12 часов.

Рисунок 45. Выполнение запроса Recently Modified (Недавно измененные)

Этот список быстро показывает, кто чем занят. Список помогает определить тех, кто в последнее время не сообщил о каком-либо прогрессе (обратите внимание, что имя Rose не появляется в списке).

Непрерывно обновляйте отчет Sprint Burndown

1. Доступ к отчету Sprint Burndown осуществляется при открывании узла Reports ("Отчеты") в представлении Team Artifacts (Артефакты группы) и последующего открывания папок Shared Reports (Общие отчеты) и Work Items (Элементы работы).
2. 2. Дважды щелкните по отчету Burndown. (Для того, чтобы отчет Burndown выглядел похоже на приведенный на рис. 46, необходимо несколько дней обновлять и регистрировать работы, выполняемые различными сотрудниками.)

Рисунок 46. Просмотр отчета Burndown

Совет:
Вы можете добавлять отчеты, такие как отчет Burndown, и запросы, такие как "Open Assigned to Me" (Открыть присвоенное мне) и "Recently Modified" (Недавно модифицированное) в вашу папку Favorites, щелкнув по ним правой клавишей мыши и выбрав Add to Favorites (Добавить в избранное) в качестве одного из пунктов выпадающего меню. Это значительно облегчит к ним доступ.

Как вычисляется значение burndown

Планирование собрания Iteration Retrospective (Ретроспектива итерации)

Важной частью процесса Scrum является собрание Sprint Review (Обзор спринта). Первой частью этого собрания является демонстрация для заинтересованных лиц. Rational Team Concert здесь можно не использовать, так как обсуждение фокусируется на показе работающего ПО, а не на списке задач. Тем не менее на обзорном собрании необходимо собрать отзывы и комментарии и разместить их либо на странице Iteration's Overview (Обзор итерации), либо как приложение к этой странице.

Следующей частью собрания Sprint Review является Iteration Retrospective (Ретроспектива итерации) (иногда называемая Reflection (Обсуждение)). Она дает группе возможность обсудить, что шло хорошо, что не слишком, и что планируется с этим делать. Шаблон процесса Scrum определяет тип элемента работы Retrospective (рис. 47), который помогает не забыть об обсуждении и отслеживать комментарии и планы сотрудников группы.

Рисунок 47. Просмотр типа элемента работы Retrospective

Снова и снова

Жизнь здоровой группы Scrum наполнена ритмом успеха. Что-то планировать, над чем-то работать, предоставить результат и повторить все снова. Когда наступает время для следующего спринта, создайте плана для Sprint 2, используя тот же подход, который применялся для создания плана итераций для Sprint 1, после чего начните перемещать в него элементы Product Backlog (Журнал незавершенных работ по продукту) для планирования.

Если история не получает своего завершения на текущем спринте, переместите ее в новый спринт (см. примечание):

1. Щелкнув по вкладке для Sprint 2 Backlog и перетащив ее в нижнюю часть экрана, вы можете сделать оба плана видимыми одновременно.
2. Затем перетащите Story из одного плана в другой.

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

Рисунок 48. Планирование следующей итерации

Важно:
Звездочка, находящаяся слева от Story, указывает на то, что изменения еще не сохранены. Серая стрелка, указывающая налево от выделенной серым фоном копии в окне Sprint 1, указывает, что для этого элемента запланированное перемещение не выполнено. При нажатии Save перемещение будет завершено.

Несмотря на то, что вы назначили даты для спринтов, Rational Team Concert автоматически не перейдет из текущего спринта к следующему только из-за того, что время ушло вперед. Вам следует вручную указать, какой спринт рассматривать в качестве текущего:

3. Откройте проект Havannah.
4. В разделе Process Description щелкните по Sprint 2 (текущему спринту) и затем по кнопке с маленьким голубым треугольником для перемещения обозначения текущего спринта на новый спринт.

Рисунок 49. Установка текущей итерации

Web-интерфейс Rational Team Concert

Не каждый сотрудник группы имеет на своем компьютере или желает установить Eclipse-клиент. Многие из функций Rational Team Concert доступны через Web-интерфейс. Более того, некоторые функции, например, Project Area Dashboard, есть только в Web-интерфейсе. Инструментальные панели могут настраиваться самим пользователем, и они поставляются в немного различающихся конфигурациях в зависимости от установленного шаблона процесса. На рис. 50 показана инструментальная панель Scrum Dashboard для проекта Havannah (инструментальная панель для окончательной версии может быть другой.)

Рисунок 50. Scrum Dashboard

Интерфейс использует многие из функций Web 2.0, сходные с подсказкой для отчета по степени выполнения, появляющейся при наведении курсора на панель Sprint. Аналогичное всплывающее представление покажет по меньшей мере частичные результаты запроса, если вы наведете курсор на один из запросов в нижней части. Так как это инструментальная панель Scrum, вверху страницы посередине отображается список открытых препятствий и блокировок.

Чего не хватает? Конечно, burndown-графика для Scrum. (Если говорить о версии RC5, то там имеется вкладка Trends, на которой отображается график burndown, наряду с отчетом Story Points by Iteration, но в примере на рис. 51 также показано, как настраивать инструментальную панель). Этот важный артефакт и ценный индикатор прогресса в решении задач легко добавить на панель.

1. Щелкните стрелку, направленную вниз, рядом с пунктом General на вкладке в верхней части окна (рис. 51).
2. Выделите Add Viewlet. Панель Add Viewlet будет открыта в верхней части страницы (рис. 51).

Рисунок 51. Добавление окна графика

3. 3. Прокрутите список доступных viewlet-окон, откройте папки Trend Reports и Work items и выберите Burndown (рисунок 52). На панели справа отобразится описание выбранного окошка.

Рисунок 52. Добавление отчета Burndown

4. Щелкните Add Viewlet, и отчет Burndown будет добавлен на инструментальную панель (рис. 53).

Рисунок 53. Отчет Burndown на инструментальной панели

Теперь у вас есть два наиболее важных артефакта для вашей группы Scrum, и они находятся прямо наверху инструментальной панели. Изучая вкладку Reports, можно найти и другие интересные отчеты, которые стоило бы добавить, но отчета Burndown будет достаточно, чтобы постоянно контролировать работу над проектом. После того, как вы изучите способы использования Rational Team Concert и Jazz для поддержки других аспектов вашего проекта, вы можете добавить отчеты Build Health, Code Coverage и Test Failure на инструментальную панель. Сотрудники группы могут сделать эту страницу домашней страницей своего браузера.

Элементы Summary на инструментальной панели также включают ссылки на полную информацию. Щелчок по ссылке запроса Recently Modified, расположенной внизу экрана (рис. 54), приведет к переходу на вкладку Work Items и отобразит полные результаты этого запроса.

Рисунок 54. Просмотр результатов запроса Recently Modified

Этот отчет полезно просматривать перед ежедневным собранием Scrum; он может быть очень полезен тем, кто возвращается из отпуска или из командировки и хочет быстро войти в курс дела. Также обратите внимание, что рабочие элементы можно создавать из вкладки Work Items при помощи ссылки, приведенной наверху в левом столбце. Таким образом, любой сотрудник, у которого есть Web-доступ к вашей области проекта, может легко добавлять элементы Defects, User Stories и Enhancement Requests.

Сотрудники группы также могут из этого представления обновлять информацию о выполнении своих задач и добавлять комментарии к своим элементам работ. Щелчок по Work Item выведет информацию, имеющуюся для этого элемента (см. рисунок 55).

Рисунок 55. Просмотр Work Item

Вкладка Iteration Plans содержит различные представления, фокусирующиеся на историях и сотрудниках группы: Щелкните Iteration Plans > Sprint Backlog > Planned Items > Group By Owner.

В официальном релизе Rational Team Concert вы также можете отобразить панели Progress или панели Load для сотрудников группы (рис. 56).

Рисунок 56. Просмотр плана итераций

Продолжение работы

Хотя вы почерпнули из этой статьи много информации, возможности Rational Team Concert и в Jazz значительно больше, чем основанное на Scrum гибкое планирование. Более того, в этом продукте значительно больше средств для agile-планирования, чем было описано в этой статье. Например, подумайте об использовании контроля исходных текстов в Jazz и ядра сборки Jazz для придания дополнительного импульса вашему процессу непрерывной интеграции. Сотрудников группы, не являющихся разработчиками, можно познакомить с Web-интерфейсом для проверки элементов работ и статуса проекта. Вашим руководителям очень понравятся инструментальные Web-панели. Попробуйте использовать различные отчеты для оценки того, насколько они согласуются с методами, которыми ваша группа управляет своим процессом.

Когда вы войдете в курс дела, оглянитесь вокруг. Скорее всего, вас ждут новые и новые приятные сюрпризы.

Загрузка