Материал: Sb97307

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

(Agile).

4. ИСПОЛЬЗОВАНИЕ ТЕХНИК ГИБКОЙ РАЗРАБОТКИ AGILE.

УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ

Как уже говорилось во введении, расширением PMBoK для проектов по разработке программного обеспечения (SWX) устанавливается, что подход к формированию жизненного цикла проекта по разработке ПО может варьиро-

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

жать, следует научиться ими управлять.

Сегодня основным инструментом для работы с изменениями при разра-

ботке программного обеспечения является гибкая разработка (Agile). Принципы Agile изложены в «Agile-манифесте для разработки программ-

ного обеспечения» (http://agilemanifesto.org/) и сводятся к следующему:

1) разработка ведется короткими циклами (итерациями) продолжитель-

ностью 1–4 недели;

2)в конце каждой итерации заказчик получает приложение (или его часть), которое можно использовать;

3)команда разработки сотрудничает с заказчиком в ходе всего проекта;

4)изменения в проекте приветствуются и быстро включаются в планы. В рамках Agile применяются различные техники гибкой разработки –

XP, Kanban, Lean Software Development и др. Одной из техник является

SCRUM, на примере которого будет рассмотрена работа с инструментом гибкой разработки. Более подробно положения и практические рекомендации

кприменению SCRUM можно найти в [4].

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

Владелец продукта (Product Owner) – роль в SCRUM, лицо, отвечающее за разрабатываемый продукт, например уполномоченное лицо заказчика.

16

Скрам-мастер (Scrum Master) – роль в SCRUM, человек, организующий процессы, обычно также является исполнителем в команде.

Команда (Team) – группа исполнителей, самоорганизующаяся и само-

управляемая.

История (User Story) – описание требования к программному продукту с точки зрения пользователя, форма описания требования в SCRUM.

Задачи (Tasks) – задачи, которые необходимо решить для реализации функции программного продукта, получаются при декомпозиции User Story.

Спринт (Sprint) – итерация в SCRUM.

Бэклог (Backlog) – форма документирования требований, принятая в SCRUM; бэклог продукта (Product Backlog) – список желаемых историй в рамках продукта с указанием приоритета их реализации; бэклог спринта (Sprint Backlog) – список желаемых историй в рамках спринта с указанием приоритета их реализации.

Стори-пойнт (Story Point) – единица измерения трудоемкости, например человеко-день.

График сгорания (Sprint Burndown Chart) – график суммы оценок остав-

шейся работы в стори-пойнтах в зависимости от времени, демонстрирует прогресс команды по ходу итерации и называется диаграммой сгорания.

Скрам (Scrum) – ежедневное совещание команды.

Бэклог продукта составляется в начале проекта, но постоянно пересмат-

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

варительно оценивается трудоемкость в единицах «стори-пойнт». Из бэклога продукта выбираются истории для включения их в бэклог спринта при пла-

нировании итерации (рис. 4.1).

Итерации в SCRUM организованы следующим образом: в начале каждо-

го спринта проводится его планирование, создается бэклог спринта (документ, фиксирующий объем работ на спринт), и спринт поступает в работу.

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

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

17

Рис. 4.1

реализована («как продемонстрировать»). Для каждой истории и задачи оценивается ее трудоемкость в «стори-пойнтах».

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

SCRUM характеризует самоорганизацию команды. Скрам-мастер не назначает задачи, распределение задач происходит в результате совмест-

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

сти служат знания и навыки конкретных людей.

В SCRUM предусмотрены собрания команды: планирование – собра-

ние на котором формируются и обсуждаются бэклоги; ежедневное статусное совещание – скрам; демонстрация результата итерации и ретро-

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

18

ID-задачи

Описание

Как продемонстрировать

 

 

 

IDK-

Проектирование

Документ, описывающий основное окно

TASK-

интерфейса закладки

закладки со списком результатов осмотра,

0022

со списком результатов

интерфейс для работы с подробной

 

осмотра

информацией о результатах осмотра включая

 

 

графические изображения и интерфейс для

 

 

работы с актом осмотра

IDK-

Доработка БД и модели

Скрипты, сформированные по рабочей БД,

TASK-

ERWin для реализации

и модели в ERWin идентичны

0023

возможности хранения

 

 

результатов осмотра

 

IDK-

Разработка интерфейса

Пользователь переходит на закладку работы

TASK-

закладки для работы

с результатами осмотра, выбирает из списка

0024

с результатами осмотра

запись; открывается окно просмотра текстовой

 

и формы просмотра

информации о записи

 

результатов

 

IDK-

Доработка формы

Пользователь переходит на закладку работы

TASK-

работы с результатами

с результатами осмотра, выбирает из списка

0025

осмотра с целью

запись; открывается окно просмотра текстовой

 

добавления возможности

информации о записи, пользователь

 

просмотра графических

просматривает приложенные к результатам

 

изображений

графические изображения

Еще одним элементом подхода SCRUM является график сгорания. С его помощью наглядно демонстрируется прогресс в выполнении задач проекта,

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

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

ская зависимость в идеале должна приближаться к плановой.

Итак, прослеживается явная аналогия между процессами управления проектом по PMBoK и процессами в подходе SCRUM. Процессам группы инициации можно сопоставить формирование концепции продукта, форми-

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

19

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

носится к группе процессов мониторинга и управления. И, наконец, ретроспектива – совещание, которое проводится по итогам каждого спринта; ана-

логом в PMBoK ему служит процесс обновления базы знаний о проектах –

«lessons learned».

5. О ЧЕМ ЕЩЕ НАДО БЫЛО РАССКАЗАТЬ

До сих пор явно не рассматривались результаты применения процессов из областей знаний управления коммуникациями, закупками, качеством и человеческими ресурсами. Тем не менее, процессы управления качеством час-

тично рассмотрены в разд. 2, а управление коммуникациями и человеческими ресурсами являются важной частью в подходе Agile, что, как сказано в разд. 4, не противоречит PMBoK, который тоже предполагает как можно более раннее и полное вовлечение команды во все процессы управления проектом. Управление закупками представляет несколько обособленную область знаний, поскольку в отличие от остальных областей применяется не для всех проектов.

В заключение необходимо также сказать, что PMBoK не есть догма и, хотя практически все описанные в нем процессы в том или ином виде сопут-

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

6. КЕЙСЫ ДЛЯ РАБОТЫ В КОМАНДЕ

АИС «Отель». Необходимо автоматизировать финансовую деятельность отеля. Отель предоставляет номера клиентам. Информацией о характеристиках каждого номера обладает руководство отеля. При поселении клиента в свободный номер фиксируется дата поселения. При выезде из гостиницы фиксируется факт освобождения номера.

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

АИС «Оптово-розничная торговля». Необходимо автоматизировать финансовую деятельность оптово-розничной компании. Компания торгует товарами. Информацией о характеристиках товаров обладает руководство

20