Sb97307

1.Проект разработки «Автоматизированной системы заказа товаров»

1.1.Разработка постановки задачи

1.1.1.Проведение аналитического обследования

1.1.2.Разработка функциональных требований

1.1.3.Разработка требований к базовому ПО

1.1.4.Постановка задачи утверждена

1.2.Поставка и установка базового ПО

1.2.1.Разработка спецификаций на базовое ПО

1.2.2.Закупка базового ПО

1.2.3.Развертывание и настройка базового ПО

1.2.4.Базовое ПО установлено у заказчика

1.3.Установка и конфигурирование рабочей среды

1.4.Проектирование и разработка ПО

1.4.1.Авторизация и аутентификация пользователей

1.4.2.Разработка подсистемы заказа

1.4.2.1.Просмотр каталога продуктов

1.4.2.2.Поиск продуктов по каталогу

1.4.2.3.Подсистема заказа передана в тестовую эксплуатацию

1.4.3. Разработка подсистемы сопровождения каталога. Подготовка и сопровождение каталога продукции

1.4.4.Тестирование ПО

1.4.5.Документирование прикладного ПО

1.5.Обучение пользователей

1.5.1.Подготовка учебных курсов

1.5.2.Обучение сотрудников отдела продаж

1.5.3.Обучение администраторов АС

1.6.Ввод в опытную эксплуатацию

1.6.1.Развертывание и настройка прикладного ПО

1.6.2.Проведение приемо-сдаточных испытаний

1.6.3.Акт передачи системы в опытную эксплуатацию утвержден

1.7.Сопровождение системы в период опытной эксплуатации

Рис. 2.1

Описание содержания проекта, ИСР и словарь ИСР называют базовым планом по содержанию, он определяет один из компонентов тройственного ограничения.

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

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

11

которого могут потребоваться изменения – исправления ошибок. После ис-

правления ошибок и повторного контроля качества проверенные результаты представляются заказчику. Заказчик осуществляет формальную приемку или требует провести доработку.

3. РАЗРАБОТКА РАСПИСАНИЯ ПРОЕКТА, ОПРЕДЕЛЕНИЕ

СТОИМОСТИ ПРОЕКТА И УПРАВЛЕНИЕ РИСКАМИ

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

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

раций, определение последовательности операций, оценка ресурсов и длительности для операций, составление расписания. Один процесс, контроль расписания, находится в группе процессов мониторинга и контроля.

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

Итак, пакеты работ из ИСР разбиты на операции, такие, что их может выполнить один человек не более чем за неделю, определена их последовательность и длительность; теперь пора составлять расписание.

Одна из техник составления расписания это – метод критического пути. Строится сетевая диаграмма, которая является направленным графом с узлами – операциями проекта. Дуги определяют последовательность выполнения операций. Есть и другие виды сетевых диаграмм, но здесь они рассматриваться не будут. Например, на рис. 3.1 представлена сетевая диаграмма проекта, в котором предусмотрены операции с длительностью A= 6, B = 12, С = 5, D = 7, E = 7, H = 5 и G = 8. Длительность операций S и F равна нулю.

13

ются «контрольные счета» (Control Account Estimates), которые представляют собой оценку стоимости для элементов ИСР верхнего уровня, сумма которых дает оценку стоимости проекта. Бюджет получается добавлением к оценке стоимости проекта резервов на непредвиденные расходы и накладные расхо-

ды организации.

Вернемся теперь к сетевой диаграмме. Что делать, если сроки, которые были рассчитаны, не устраивают заказчика и требуется их изменение? Не-

обходимо применить одну из техник сокращения сроков проекта. Могут быть выбраны, например, следующие техники: быстрый проход (Fast Track),

сжатие (Crash), сокращение содержания (Reduce Scope).

Быстрый проход – это параллельное выполнение нескольких операций.

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

торых операций из сетевого графика проекта. В таблице приведены послед-

ствия применения каждой техники.

Таким образом, нет идеальной техники сокращения сроков проекта. Необходимо проводить анализ влияния действий по сокращению расписа-

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

де от соблюдения сроков разработки.

Предварительные планы по содержанию, срокам и стоимости сформи-

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

Команда проекта уже определила высокоуровневые риски, когда зани-

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

14

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

ходится в группе процессов мониторинга и контроля.

Для программных проектов характерны следующие риски (в соответст-

вии с [2]):

1)дефицит специалистов;

2)нереалистичные сроки и бюджет;

3)реализация несоответствующей функциональности;

4)разработка неправильного пользовательского интерфейса;

5)«золотая сервировка», ненужная оптимизация и оттачивание деталей;

6)непрекращающийся и неуправляемый поток изменений;

7)нехватка информации о внешних компонентах, определяющих окру-

жение системы или вовлеченных в интеграцию; 8) недостатки в работах, выполняемых внешними по отношению к про-

екту ресурсами;

9)недостаточная производительность получаемой системы;

10)«разрыв» в квалификации специалистов разных областей знаний.

В [3] приводится несколько иной список наиболее важных источников рисков любого проекта разработки ПО:

1)изъяны календарного планирования;

2)текучесть кадров;

3)раздувание требований;

4)нарушение спецификаций;

5)низкая производительность.

Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причин, условий, последствий и ущерба.

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

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

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

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

15

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

(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

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

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

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

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

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

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

19

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

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

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

«lessons learned».

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

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

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

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

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

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

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

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

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

20