Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Управление информационными ресурсами»

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объектом исследования является консалтинговая компания, реализующая ИТ-проекты для внешних заказчиков.

Предметом исследования является проект внедрения CRM-системы.

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

В процессе работы необходимо решить следующие задачи:

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ПРЕДПОСЫЛКИ ИССЛЕДОВАНИЯ

1.1. Понятие проектного управления

Управление проектом (Project Management) – это применение знаний, методов и технологий при планировании и выполнении проекта для реализации ожиданий и требований участников проекта. Проект является объектом управления и представляет собой ограниченный по времени, бюджету, трудовым и материальным ресурсам комплекс задач и работ, ориентированный на достижение четко сформулированных целей. Проект – временное предприятие, направленное на создание уникального продукта, услуги или результата. (PMBoK 6, 2017).

В любой организации одновременно выполняется большое количество проектов, которые могут различаться по масштабу, типу и сложности выполнения. Таким образом, управление ресурсами – обязательная составляющая процессов любой компании. В течение многолетней практики проектного управления было сформировано большое количество стандартов управления ресурсами, а также требований к компетенциям менеджера и участников проектной команды. На сегодняшний день в мире используется большое количество нормативных документов, стандартов и рекомендаций, которые позволяют упорядочить и формализовать проектную деятельность. К наиболее крупным международным профессиональным ассоциациям относятся Американский институт управления ресурсами (Project Management Institute, PMI) и Международная организация по стандартизации (International Organization for Standardization, ISO).

Управление ресурсами окончательно сформировалось в качестве отдельной области знаний еще в 1950-х годах. Все началось с появления двух математических метода управления расписанием проектов — метод критического пути СРМ и метод оценки и анализа программ PERT. Несколькими годами позднее (1959) комитетом Андерсона (NASA) был предложен системный подход к управлению проектом по стадиям его жизненного цикла. В 1966 г. появляется система GERT (Graphical Evaluation and Review), Technique), использующая новую генерацию сетевых моделей. В 1981 г. в PMI) началась подготовка документа, содержащего методологические основы управления ресурсами, — «A Guide to the Project Management Body of Knowledge» (PMBОK Guide) или «Руководство к своду знаний по управлению ресурсами», который является актуальным на сегодняшний день и представляет собой руководство для менеджера проектов. В данном документе:

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

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

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

ценность для бизнеса,
срочность,
сложность,
число участников.

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

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

В ходе доработки РМВОК (последняя актуальная версия руководства - шестая) его состав изменялся: изменения вносились в описание набора подходов, областей знаний и процессов. Вышедшая в 2017 году шестая версия РМВОК Guide была дополнена отдельным руководством с описанием гибких методологий – Agile Practice Guide, выпущенным совместно институтом PMI и Agile Alliance. Руководство Agile Practice Guide содержит описание всех основных методов и практик гибкого и включает в себя следующие разделы.

Введение в Agile.
Выбор жизненного цикла.
Реализация Agile. Создание среды Agile.
Реализация Agile. Поставка в среде Agile.
Организационные соображения для гибкости проекта.
Призыв к действию.

В практическом руководстве Agile Practice Guide подробно описано, как применять agile-подходы на проектах в различных предметных областях и использовать на практике современные инструменты, методы и фреймворки (Agile Practice Guide, 2017).

Не меньшей популярностью пользуются стандарты международной организации по стандартизации ISO – крупнейшей неправительственной организациии по разработке стандартов. Стандарты ISO, широко известные по всему миру, включают в себя общую терминологию и описание базовых принципов управления ресурсами и используются компаниями, которые реализуют проекты с зарубежными клиентами и партнерами. На сегодняшний день наиболее популярным международным стандартом ISO в области проектного управления является ISO 21500:2012 «Руководство по менеджменту проектов», который входит в новую серию стандартов «Руководство по управлению ресурсами» (Guidance on project management) и является базовым нормативным документом, регламентирующим проектное управление на международном уровне (Зиядуллаев, Фридлянов, 2017).

Развитием стандартов проектного управления в России занимается автономная некоммерческая организация «Центр оценки и развития проектного управления» (АНО «ЦОРПУ»). В ЦОРПУ постоянно проводятся исследования, направленные на расширение набора государственных стандартов (ГОСТов), на данный момент широкое применение в стране получили перечисленные ниже стандарты (АНО «ЦОРПУ», 2020).

ГОСТ Р 54869 – 2011 «Проектный менеджмент. Требования к управлению проектом»: устанавливает требования к управлению проекта от его старта до завершения.
ГОСТ Р 54871 – 2011 «Проектный менеджмент. Требования к управлению программой»: устанавливает требования к управлению программой на этапах ее формирования и реализации.
ГОСТ Р 54870 – 2011 «Проектный менеджмент. Требования к управлению портфелем проектов»: устанавливает требования к управлению портфелем проектов на этапах его формирования и реализации.
ГОСТ Р 58305 - 2018 «Система менеджмента проектной деятельности. Проектный офис»: устанавливает цели, задачи, типы и функции проектных офисов.
ГОСТ Р 58184 - 2018 «Система менеджмента проектной деятельности. Основные положения»: устанавливает основные положения для систем менеджмента проектной деятельности в организациях.

1.2. Понятие гибких методологий управления ресурсами

Переход к управлению ресурсами с использованием гибких методологий (Agile) является основным трендом в проектном управлении уже на протяжении нескольких лет. Agile – семейство гибких подходов (методологий) к разработке программного обеспечения (Rusbase, 2018). Изначально Agile появился в IT сфере, но позже распространился и в другие сферы, например, машинное обучение и искусственный интеллект. Методики Agile ориентированы на постоянно изменяющиеся условия внешней и внутренней среды, требования заказчиков и потребности конечных пользователей. Согласно этим методологиям, проект необходимо разбивать на отдельные краткосрочные итерации длительностью не более 1 месяца, в конце каждой итерации необходимо получать новую работающую версию продукта, которую можно продемонстрировать заказчику и получить обратную связь. После анализа обратной связи могут быть внесены необходимые правки в продукт. Цель Agile – разработать наиболее эффективный и полезный для бизнеса продукт.

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

В 2001 году группой энтузиастов, применяющих гибкие методики программирования, была выпущена декларация разработчиков ПО – agile-манифест разработки программного обеспечения, который включает в себя 4 ключевых ценности любой гибкой методологии:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

Манифест содержит важное дополнение к списку ценностей: «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева» (Agile-манифест, 2001). Это значит, что не стоит пренебрегать такими аспектами, как проектная документация, процессы и инструменты, но основной фокус в гибких методологиях находится не на них.

Согласно гибким методологиям, проекты по разработке ПО состоят из семи «измерений» (Аппело, 2011).

Люди: ценность составляют не таланты отдельных людей, а создание кросс-функциональной команды, суммарные компетенции участников которой позволяют качественно реализовать проект.
Функциональность: постоянное взаимодействие с заказчиком позволяет постоянно поддерживать функциональные требования в актуальном виде;
Качество: контроль качества выполнения задач проводится на всех этапах разработки.
Инструменты: повторяющиеся рутинные операции должны быть автоматизированы, чтобы участники команды не тратили на них время.
Время: длина итерации и частота релизов определяется участниками команды совместно с заказчиком.
Ценность: ценность ПО для клиента определяется наиболее быстрой и качественной реализацией новой функциональности. Функциональность должна быть реализована как можно скорее после того, как была выявлена потребность в ней.
Процесс: основные процессы в гибких методологиях – это планирование, ежедневное личное общение участников команды и контроль выполнения задач проекта.

1.3. Обзор существующих гибких методологий

Первая гибкая методология управления ИТ-ресурсами появилась в начале 1990-х. Называлась эта методология «Быстрая разработка приложений» (Rapid Application Development, RAD) и заключалась в сочетании стандартных формализованных подходов методики Waterfall (актуализация технической документации, четкое планирование последовательных стадий проекта) с практикой создания прототипов, версионностью выпускаемого продукта и более тесного общения с заказчиком (Аппело, 2011). Позднее появились и другие гибкие методологии, такие как:

эволюционное управление разработкой (Evo) (1988): проект разделен на этапы реализации – эволюции, каждая из которых планируется на основании результатов предыдущей эволюции (Habr, 2015);
Scrum (1995) – фреймворк процесса разработки с участием одной команды; проект реализовывается итерационно, по итогу каждой итерации должна быть представлена новая работоспособная версия продукта (Rusbase, 2017);
методы разработки динамических систем (DSDM) (1995): заказчик является частью команды и непрерывно участвует в процессе анализа и согласования требований (Аппело, 2011);
методы Crystal (1997) – семейство методологий, предусматривающих выбор средств обеспечения строгости методологии в зависимости от размера и критичности проекта (Agile Practice Guide, 2017). Основная цель методики – «Кристально чистое» выполнение задач проекта, которое достигается с помощью непрерывной рефлексии по поводу состояния проекта, что в свою очередь позволяет выбрать наиболее правильные и эффективные способы реализации (Winfox, 2014);
экстремальное программирование (XP) (1999) – методология разработки программного обеспечения, основанная на частом повторении циклов разработки (Agile Practice Guide, 2017). В методологии активно применяются такие практики, как парное программирование, разработка через тестирование (разработчик сначала пишет тесты, а потом код программы), свободный доступ всех разработчиков к коду своих коллег, непрерывная доработка кода (Skillbox, 2018);
адаптивная разработка ПО (ASD) (2000): основу методологии составляют три нелинейные фазы: обдумывание, сотрудничество и обучение; они относятся к каждому периоду разработки, который завершается выпуском релиза. Отклонения от плана не считаются ошибками, а наоборот, они ведут к новым, более верным решениям (Интуит, 2004).

Agile-методологии с каждым годом применяют все больше компаний по всему миру. Компания ScrumTrek проводит ежегодное исследование State of Agile среди организаций по всему миру с целью определения зрелости Agile-практик в компаниях. В 2019 году в исследовании принимали участие респонденты по всему миру: 46% респондентов из компаний, штат сотрудников которых превышает 5000 человек; 18% - из компаний со штатом сотрудников численностью 1000-5000, и 36% - менее 1000 человек (13th annual State of Agile report, 2019). Из респондентов, которые являются сотрудниками компаний, специализирующихся на разработке программного обеспечения, 27% респондентов из компаний, со штатом сотрудников численностью менее 100 человек; 33% - из компаний, в которых от 100 до 1000 сотрудников и 40% из компаний, штат которых превышает 1000 человек (рисунок 1).

По данным ежегодного исследования State of Agile, на сегодняшний день agile-методологии используют 97% респондентов: в 22% из них agile-методологии используются только всеми командами компании; в 26% более чем половиной команд и в 48% компаний менее половины команд применяют agile-практики в своей работе.

Рисунок 1. Распределение респондентов по размеру штата сотрудников организаций

Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Наиболее популярным фреймворком является Scrum – его используют 54% респондентов. 32% компаний используют комбинированные методики, состоящие из нескольких различных методологий:

8% респондентов используют гибрид Scrum и Kanban (Srcumban);
10% респондентов используют гибрид Scrum и XP (Extreme Programming);
14% респондентов используют гибрид из нескольких гибких методологий.

В чистом виде методологиями Kanban, Lean и XP пользуются всего 5%, 2% и 1% респондентов, соответственно (рисунок 2).

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

Источник: Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Наиболее популярными практиками, применяемыми на сегодняшний день в рамках методологий Agile, являются:

ежедневный standup (daily standup) (86%);
планирование итерации (sprint planning) (80%);
ретроспективы (retrospectives) и обзоры (review) итерации (80%)
использование коротких итераций (67%);
оценка задач (planning poker/team estimation) (61%);
kanban (61%);
планирование релиза (release planning) (57%);
назначение владельца продукта (product owner) (57%);
единая команда разработки, включающая специалистов по аналитике, разработке и тестированию (54%);
частые релизы (50%);
расположение команды в едином пространстве (45%);
построение дорожной карты продукта (product roadmapping) (50%).

Диаграмма распределения голосов респондентов относительно используемых agile-практик и инструментов представлена на рисунке 3.

Рисунок 3. Распределение голосов респондентов относительно используемых agile-практик

Источник: Источник: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

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

Scrum-команда включает в себя 3 базовых роли: Product owner, Scrum master и Development team (Команда разработки).

Product owner (PO, владелец продукта) – связующее звено между заказчиком и командой разработки. PO владеет бэклогом продукта (Product Backlog) (перечнем пользовательских историй, которые необходимо выполнить в рамках проекта) и несет ответственность за максимизацию ценности продукта.
Scrum master (SM) – помогает команде максимизировать эффективность работы путем обучения, мотивации и устранения препятствий; отвечает за соблюдение командой скрам-правил.
Команда разработки (Development team, DT) является кроссфункциональной и включает в себя специалистов, которые участвуют в процессе разработки, например, аналитиков, разработчиков, тестировщиков и дизайнеров. Команда должна обладать всеми необходимыми навыками для разработки продукта, за качество продукта отвечает вся команда, а не отдельные ее участники (Rusbase, 2017).

Рабочий процесс в Scrum состоит из следующих событий:

Sprint (спринт, итерация);
Sprint Planning (Планирование спринта);
Daily Scrum (Ежедневный стендап);
Sprint Review (Анализ спринта);
Sprint Retrospective (Ретроспектива спринта).

И артефактов:

Product Backlog (Бэклог продукта);
Sprint Backlog (Бэклог спринта);
Increment (Инкременты).

Разработка по Scrum осуществляется итерационно: по окончании итерации (спринта) должна быть реализована новая версия работающего продукта. Длительность Спринта не должна превышать 4 недели (обычно используется длительность 2 недели). Перед началом Спринта производится Планирование спринта (Sprint Planning), на котором из Бэклога продукта (Product Backlog) отбираются пользовательские истории для Бэклога спринта (Sprint Backlog), который представляет собой перечень пользовательских историй, которые необходимо реализовать в рамках Спринта, а также определяются требования к инкременту (Increment) продукта (Definition of Done, DoD), далее Бэклог спринта разбивается на отдельные задачи (Tasks). Каждый день проводится Ежедневный стендап (Daily Scrum), цель которого отследить прогресс в работе во время Спринта.

По окончании Спринта проводятся две встречи:

Анализ спринта (Sprint Review) – демонстрация версии продукта (Increment) PO и заказчику (и другим заинтересованных лицам) с целью получения обратной связи;
Ретроспектива спринта (Sprint Retrospective) – обсуждение проблем, возникших в рабочем процессе.

Схема процесса разработки по фреймворку Scrum представлена на рисунке 4.

Картинки по запросу "scrum diagram"

Рисунок 4. Процесс Scrum

Источник: https://medium.com/@jw207427/how-scrum-help-turn-around-our-development-process-dac6ff7c700

Для оценки задач в Scrum используются Story Points – оценка, которая выставляется элементу бэклога (пользовательской истории, User Story) на основании количества усилий, которые необходимо приложить для ее решения (Cohn, 2016). При оценке учитываются:

сложность истории;
объем работ;
уровень рисков и неопределенности при выполнении работ.

При оценке в Story Points элементу бэклога присваивается некоторое количественное значение, которое показывает относительную сложность реализации между пользовательскими историями. Например, история со значением 1 Story Point должна быть вдвое меньше истории со значением Story Points = 2. Важно, чтобы оценка в Story Points учитывала все работы, которые потребуются для доведения элемента бэклога до состояния готовности (от анализа истории до завершения тестирования).

Для оценки историй может быть использован метод, который называется Planning Poker (Покер планирования). Суть метода заключается в оценке историй участниками команды с использованием карт. Алгоритм оценки следующий:

всей команде раздаются карты с числами из шкалы оценки;
выбирается история и обсуждаются требования к ней;
после завершения обсуждения по команде модератора каждому из участников необходимо выбрать карту с числом, соответствующим оценке истории, и положить ее «рубашкой» вверх;
по команде модератора участники переворачивают карты: если оценки участников близки по значению, оценка согласуется и модератор присваивает ее истории. В противном случае, участники забирают карты обратно и продолжают обсуждение задачи (Habr, 2020).

Фреймворк Kanban. Kanban – гибкий подход к разработке ПО, который обеспечивает прозрачность рабочих процессов и позволяет улучшить процесс разработки. Фреймворк Kanban основывается на принципах системы бережливого производства (Lean), которое предполагает повышение качества продукта при сокращении расходов за счет максимального вовлечения в процесс каждого сотрудника (Agile Practice Guide, 2017).

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

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

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

Kanban предназначен для последовательного процесса, в котором для продвижения работ по этапам процесса используется принцип pull system – при завершении одной работы на этапе команда может взять следующую работу из предыдущего этапа. Ценность несет только завершенная работа, поэтому в методе Kanban цель команды заключается в коллективном завершении всех работ с соблюдением лимитов на объемы незавершенных работ на этапах. Основные принципы и свойства метода представлены на рисунке 5.

Рисунок 5. Принципы и свойства метода Kanban

Источник: Agile Practice Guide, 2017

Для визуализации процесса разработки в гибких методологиях используются доски (Task Board). Доска в agile-методологиях может быть:

виртуальной (специализированное ПО);
физической (пробковая доска или флипчарт).

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

TO DO (необходимо сделать);
IN PROGRESS (в работе);
DONE (сделано).

Задачи представляют собой карточки, которые перемещаются между столбцами в зависимости от их статуса: когда команда берет задачу в работу, задача перемещается в столбец IN PROGRESS. После того, как команда завершила работу над задачей, она перемещает соответствующую задачу в столбец DONE (рисунок 6). Чтобы контролировать нагрузку команды, можно устанавливать лимиты на количество задач на каждом из этапов.

Рисунок 6. Kanban-доска

Источник: https://www.patboard.com/shop/full-scrum-kanban-board-kit-nanocups-for-glass/

В Srcum-доске, помимо перечисленных выше столбцов, должен присутствовать столбец, включающий в себя задачи бэклога (BACKLOG). При необходимости, на доске могут быть добавлены дополнительные столбцы, например: бэклог текущего спринта – SPRINT и тестирование – TESTING/VERIFY (рисунок 7).

Картинки по запросу "kanban board"

Рисунок 7. Scrum-доска

Источник: https://www.patboard.com/shop/full-scrum-kanban-board-kit-nanocups-for-glass/

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

Для визуализации прогресса выполнения работ в гибких методологиях используются диаграммы:

Burndown Chart (диаграмма сгорания);
Burnup Chart (диаграмма сгорания наоборот).

Диаграмма Burndown Chart показывает на временной шкале, сколько Story Points осталось выполнить до завершения спринта и сколько Story Points уже выполнено: по оси X указывается время, по оси Y – количество невыполненных задач в Story Points (Scrum Time, 2020). Цель команды – выполнить («сжечь») все Story Points до конца Спринта.

На графике присутствуют две кривые:

идеальная (планируемая) кривая: строится на предположении, что задачи выполняются с постоянной скоростью в N Story Points в день;
фактическая кривая: визуализирует реально выполненное количество Story Points за каждый день (рисунок 8).

Рисунок 8. Burndown Chart

Источник: https://www.projectmanagement.com/blog-post/40731/Burndown-vs-Burnup-Chart

Диаграмма Burnup Chart показывает на временной шкале, сколько Story Points уже выполнено: по оси X указывается время, по оси Y – количество выполненных задач в Story Points.

На графике присутствуют две кривые:

идеальная (планируемая) кривая: строится на предположении, что задачи выполняются с постоянной скоростью в N Story Points в день;
фактическая кривая: визуализирует реально выполненное количество Story Points за каждый день (рисунок 9).

Рисунок 9. Burnup Chart

Источник: https://www.projectmanagement.com/blog-post/40731/Burndown-vs-Burnup-Chart

Верхняя граница отмечается кривой Scope («Все задачи»), фактическая кривая достигает кривой Scope в тот момент, когда все задачи спринта выполнены.

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

На практике в чистом виде достаточно часто используется только фреймворк Scrum – согласно ежегодному отчету State of Agile (13th annual State of Agile report, 2019) им пользуются 54% респондентов. Методологиями Kanban и XP пользуются всего 5% и 1% соответственно (рисунок 2). По данным отчета, 35% опрошенных компаний используют в работе гибридные методики, включающие в себя отдельные практики из разных методологий, которые могут комбинироваться в процессе работы. Проектная команда может брать из различных методик наиболее необходимые практики для реализации конкретного проекта. Например, Scrum и Kanban могут использоваться одновременно: роли на проекте и итерации разработки определяются по фреймворку Scrum, а статусы задач в рамках итерации отслеживаются на Kanban-доске. Наиболее уместно использование Kanban-доски в случае, если команда разработки достаточно большая (5 и более человек) – без нее участникам проектной команды будет сложно следить за изменением статусов задач, а менеджерам – контролировать их выполнение.

1.4. Жизненные циклы ИТ-проектов

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

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

Определенная последовательность фаз, которая продолжается от начала до окончания проекта, называется жизненным циклом проекта (ГОСТ Р ИСО 21500-2014). При этом жизненные циклы проектов существуют независимо от жизненного цикла продукта, на реализацию которого направлен проект. Жизненный цикл продукта представляет собой набор фаз, которые проходит продукт от концепции до изъятия из обращения. Основные фазы жизненного цикла продукта (рисунок 10):

разработка и внедрение;
рост;
зрелость;
упадок.

Рис. 40

Рисунок 10. Жизненный цикл продукта

Источник: http://textb.net/96/40.html

Жизненный цикл продукта отражает, что нужно сделать для разработки и внедрения, эксплуатации, поддержки и утилизации продукта, в то время как жизненный цикл проекта определяет, как организовать работы и управлять ими (Интуит, 2013) Фаза проекта представляет собой совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Свойства каждой фазы могут быть уникальными и измеримыми, границами фаз являются точки принятия решений (вехи). (Руководство PMBOK, 2017). Точки принятия решения принято называть «Воротами фазы» (gate): для принятия решения о переходе на следующую фазу осуществляется анализ фактического прогресса проекта относительно данных проектной документации. По результатам анализа может быть принято одно из следующих решений относительно проекта (Projectimo, 2020):

переход на следующую фазу;
переход на следующую фазу с изменениями;
продолжение работ на текущей фазе;
повтор текущей фазы или её отдельных элементов;
завершение работ по проекту.

Жизненный цикл ИТ-проекта разделяют на следующие этапы:

анализ (разработка требований);
проектирование;
реализация (разработка);
тестирование;
ввод в действие (ввод в эксплуатацию).

Выделяют четыре типа жизненных циклов проектов и ИТ-проектов в частности (Agile Practice Guide, 2017).

Предиктивный жизненный цикл (каскадная модель, Waterfall Model) предполагает осуществление основной части планирования до начала работ с его последовательным исполнением за один подход. Каждый последующий шаг в рамках модели начинается только после полного завершения предыдущего шага. В результате завершения шага формируется промежуточная версия продукта, которая не может быть изменена на дальнейших этапах (QAEVOLUTION, 2016).
Итеративный жизненный цикл (спиральная модель) позволяет получать обратную связь по проекту с целью использования ее для доработки и уточнения требований по незавершенным работам. На каждой итерации осуществляется уточнение требований, определяется качество реализованных работ и происходит планирование работ следующей итерации.
Инкрементный жизненный цикл (инкрементная модель) представляет собой подход, при котором заказчик может сразу использовать в работе конечные поставляемые результаты. Модель подразумевает разработку продукта с линейной последовательностью стадий, но в несколько инкрементов (версий) и предполагает поэтапное улучшение продукта в течение жизненного цикла. Каждый инкремент должен добавлять продукту новую функциональность (QAEVOLUTION, 2016).
Жизненный цикл agile объединяет инкрементный и итеративный подход и подразумевает постоянное уточнение элементов работы и частые поставки (релизы).

Сравнение обобщенных характеристик предиктивного, итеративного, инкрементного и agile типов жизненных циклов представлено в таблице 1.

Таблица 1. Характеристики типов жизненных циклов ИТ-проектов

Подход	Требования	Операции	Поставка	Цель
Предиктивный	Фиксированные	Выполняются однократно за весь проект	Разовая поставка	Управление стоимостью
Итеративный	Динамичные	Повторяются до полного уточнения	Разовая поставка	Правильность решения
Инкрементный	Динамичные	Производятся однократно для каждого инкремента	Несколько поставок меньшего размера	Скорость
Agile	Динамичные	Повторяются до полного уточнения	Частые поставки частями маленького размера	Ценность для заказчика за счет частых поставок и обратной связи

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

Таблица 2. Преимущества и недостатки моделей жизненных циклов ИТ-проектов

Подход	Преимущества	Недостатки	Область применения модели
Предиктивный	Стабильность требований в течение всего жизненного цикла разработки Определенность и понятность шагов модели Простота применения модели Логическая последовательность выполнения работ позволяет планировать сроки и соответствующие ресурсы	Невозможность динамического изменения требований в течение всего жизненного цикла разработки Отсутствие гибкости в управлении проектом Непригодность промежуточного продукта для использования Недостаточное участие пользователя в создании системы Несвоевременное обнаружение проблем (возврат к предыдущим шагам для исправления приводит к нарушению сроков и увеличению затрат)	Разработка проектов с чёткими, неизменяемыми требованиями Разработка проекта по аналогии с другим проектом, уже реализованным ранее Разработка проекта, направленного на выпуск новой версии уже существующего продукта Разработка проекта, связанного с переносом существующего продукта на новую платформу
Итеративный	Возможность гибкого проектирования Возможность исправления ошибок и обнаружения слабых мест на каждой итерации Активное участие пользователей в процессе разработки и планирования Обратная связь от пользователей на каждом из этапов	Сложная структура модели для участников проекта Для проекта с низкой степенью риска модель может оказаться дорогостоящей Риск получения версии, не соответствующей потребностям бизнеса Сложно однозначно определить критерии перехода на следующий этап	Разработка проектов, использующих новые технологии Разработка нового вида продуктов Разработка проектов с большой величиной неопределенности Разработка долгосрочных проектов
Инкрементный	Релевантная обратная связь от пользователей в отношении готовых версий продукта Клиент получает реальные преимущества от системы до завершения разработки Пользователи быстрее осваивают новую систему	Структура системы чувствительна к изменениям, которые не были определены заранее: для реализации концептуально новых требований необходим дорогостоящий рефакторинг Согласование результатов разработки с пользователями происходит только при завершении этапа Трата ресурсов на разработку документации на каждое минимальное изменение версии продукта	Разработка проектов с требованиями, которые могут изменяться незначительно Разработка проекта по аналогии с другим проектом, уже реализованным ранее, но требующим кастомизации Разработка проекта, направленного на выпуск новой версии уже существующего продукта
Agile	Клиент получает минимально ценный продукт в кратчайший срок, наглядно наблюдает прогресс разработки Получение обратной связи на раннем этапе разработки Получение релевантной обратной связи по от пользователя по итогу каждой итерации Гибкое управление проектом, динамическое формирование требований Возможность выпустить продукт раньше запланированного срока	Сложная структура модели для участников проекта Для проекта с низкой степенью риска модель может оказаться дорогостоящей Срок завершения проекта может затянуться из-за постоянно поступающих новых требований к продукту	Разработка проектов, использующих новые технологии Разработка нового вида продуктов Разработка проектов с большой величиной неопределенности и рисков Разработка долгосрочных проектов развития системы

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

Модель оценки применимости Agile-подходов для конкретного проекта, предложенная в Agile Practice Guide, представляет собой комплекс нескольких фильтров применимости и предполагает оценку организации и проекта по трем основным категориям:

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

Категории включают в себя вопросы, направленные на оценку следующих аспектов:

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

Критерии оценки характеристик культуры компании, команды и проекта представлены в таблице 3.

Таблица 3. Оценка оценки применимости Agile-модели на проекте

Категория	Вопрос	Описание	Критерий оценки
Культура	Поддержка подхода	Понимает ли руководство суть использования подхода agile для проекта?	1 - Да 5 - Частично 10 - Нет
	Доверие в команде	Имеют ли заинтересованные стороны уверенность в том, что команда в состоянии реализовать их видение?	1 - Да 5 - Вероятно 10 - Маловероятно
	Полномочия команды на принятие решений	Будет ли команда иметь самостоятельность в принятии своих собственных решений по вопросам выполнения работы?	1 - Да 5 - Вероятно 10 - Маловероятно
Команда	Размер команды	Какой размер будет иметь основная команда?	1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151-200 = 9, 201+ = 10
	Уровни опыта	Рассмотрение уровней опыта и навыков по ролям основной команды	1 - Да 5 - Частично 10 - Нет
	Доступ к заказчику	Будет ли у команды ежедневный доступ, по крайней мере, к одному представителю заказчика для уточнения возникающих вопросов?	1 - Да 5 - Частично 10 - Нет
Проект	Вероятность изменений	Каков процент требований, которые могут с определенной степенью вероятности измениться на протяжении месяца?	1 - 50% 5 - 25% 10 - 5%
	Критичность продукта или услуги	Каким может быть результат неуспеха?	1 - Время 2 - Несущественный деньги 5 - Существенные деньги 7 - Одна жизнь 10 - Много жизней
	Инкрементная поставка	Можно ли создавать и оценивать продукт или услугу по частям?	1 - Да 5 - Возможно/иногда 10 - Маловероятно

Анкету заполняют заинтересованные лица, каждому вопросу присваивается оценка от 1 до 10. Результаты ответов на вопросы изображаются на лепестковой диаграмме (рисунок 11).

Рисунок 11. Диаграмма применимости подхода agile

Источник: Agile Practice Guide, 2017

Интерпретируются результаты следующим образом:

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

ГЛАВА 2. ОБЗОР ИНСТРУМЕНТОВ, ИСПОЛЬЗУЕМЫХ ДЛЯ УПРАВЛЕНИЯ РЕСУРСАМИ

2.1. Описание объекта исследования

Организационная структура компании, представленная на рисунке 12, включает в себя:

четыре департамента по видам услуг: Департамент ERP-систем, Департамент CRM-систем, Департамент BI-систем, Департамент портальных решений;
функциональные департаменты: HR, маркетинг, финансы.

Рисунок 12. Организационная структура компании

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

стажер;
младший специалист;
специалист;
старший специалист;
ведущий специалист;
менеджер.

Штат сотрудников компании составляет 130 человек.

Департамент ERP-систем (Enterprise Resource Planning) – систем управления ресурсами предприятия состоит из 32 человек:

отдел консалтинга – 15 человек;
отдел разработки – 13 человек;
отдел тестирования – 4 человека.

Сотрудники департамента работают на проектах внедрения решений Microsoft Dynamics NAV и SAP Business One на предприятиях различных отраслей: дистрибуция, профессиональные услуги, прямые продажи, финансовый сектор.

Департамент CRM-систем (Customer Relationship Management) – систем управления взаимоотношениями с клиентами состоит из 35 человек:

отдел консалтинга – 15 человек;
отдел разработки – 17 человек;
отдел тестирования – 3 человека.

Решения разрабатываются на платформах Microsoft Dynamics CRM, Microsoft Dynamics 365 и Terrasoft. Решения позволяют обеспечить прозрачное и удобное взаимодействия продавца и покупателя, непрерывное обслуживание и персонализированный сервис; увеличивается скорость взаимодействия с клиентом и надежность сервиса.

Департамент BI-систем (Business Intelligence) состоит из 11 человек: отдел консалтинга – 6 человек и отдел разработки – 5 человек. Сотрудники департамента занимаются разработкой и внедрением решений на платформе Microsoft Power BI для визуализации и всестороннего анализа бизнес-данных для клиентов в банковской сфере и сфере страхования. BI-решения позволяют эффективно управлять бизнесом любого уровня сложности и обеспечивают точность принятия управленческих решений.

Департамент портальных решений состоит из 12 человек: отдел консалтинга – 7 человек и отдел разработки – 5 человек. Департамент предлагает клиентам в банковской сфере решения по автоматизации внутреннего документооборота на платформе Microsoft Dynamics 365 и Terrasoft Creatio. СЭД позволяют наладить взаимодействие между подразделениями и обеспечить эффективность обмена информацией.

На протяжении всей своей деятельности компания осуществляет разработку и внедрение информационных систем по каскадной (Waterfall) или инкрементной модели. Как правило, для проектов длительностью до 1 года используется предиктивный тип жизненного цикла проекта, а для проектов длительностью более 1 года – инкрементный.

Перед началом проекта внедрения информационной системы из сотрудников департамента формируется проектная команда. Процесс формирования команды осуществляется следующим образом:

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

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

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

Анализ:
1. руководитель проекта оценивает сроки и бюджет проекта и согласовывает оценку с заказчиком;
2. аналитики разрабатывают проектную документацию (Частное техническое задание (ЧТЗ) и Техническое задание на разработку архитектуры системы), руководитель проекта после проверки согласовывает ЧТЗ с заказчиком;
3. после согласования проектной документации заказчиком осуществляется переход к следующему этапу.
Дизайн:
1. дизайнеры (внешние сотрудники) разрабатывают макеты экранных форм системы;
2. после согласования макетов заказчиком осуществляется переход к следующему этапу.
Разработка:
1. руководитель проекта определяет приоритет задач и распределяет их между аналитиками;
2. аналитики ставят задачи разработчиком и контролируют их выполнения;
3. специалисты по тестированию выполняют ручную проверку функционала;
4. после завершения всех работ из ЧТЗ осуществляется переход к следующему этапу.
Тестирование:
1. руководитель проекта координирует тестирование системы заказчиком (в режиме опытно-промышленной эксплуатации на выбранной группе пользователей/филиалов) и собирает обратную связь;
2. руководителем проекта совместно с заказчиком осуществляется оценка системы: если система удовлетворяет требованиям, осуществляется переход к этапу «Поставки» (внедрения системы в промышленную эксплуатацию);
3. если система не соответствует требованиям, руководитель проекта совместно с аналитиками разрабатывает технические задания на дополнительную функциональность и оценивает сроки и бюджет;
4. после завершения разработки дополнительной функциональности, система заново проходит этап тестирования заказчиком.
Поставка:
1. аналитики разрабатывают пользовательскую документацию и проводят обучение конечных пользователей;
2. осуществляется запуск системы в промышленную эксплуатацию и последующее сопровождение.

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

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

MS Project используется руководителем проекта для решения задач:
- планирование стадий проекта с указанием сроков;
- планирование и оценка трудозатрат задач внутри стадии;
Jira используется для решения задач:
- постановка задач разработчикам;
- уточнение информации по задачам;
- контроль выполнения задач.

В Jira используются стандартные типы запросов (issue): задача (task) и ошибка (bug), а также базовый бизнес-процесс (рисунок 13):

Рисунок 12. Организационная структура компании

Источник: https://wiki.teamlead.ru/pages/viewpage.action?pageId=85229701

Вся проектная документация хранится в отдельной папке проекта в Microsoft SharePoint, доступ к папке есть только у проектной команды и руководителей.

2.2. Обоснование выбора методологии проектного управления

Последние несколько лет компания стала сталкиваться с проблемами при реализации проектов: при использовании привычной каскадной или инкрементной модели на фазе «Тестирование» от клиентов на разных проектах стало поступать большое количество требований на изменение текущей функциональности или разработку новой.

Новые требования вызваны разными причинами:

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

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

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

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

Таблица 4. Оценка применимости agile на проектах компании

Категория	Вопрос	Критерий оценки	Ответ
Культура	Поддержка подхода	1 - Да 5 - Частично 10 - Нет	4
	Доверие в команде	1 - Да 5 - Вероятно 10 - Маловероятно	3
	Полномочия команды на принятие решений	1 - Да 5 - Вероятно 10 - Маловероятно	7
Команда	Размер команды	1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151-200 = 9, 201+ = 10	2
	Уровни опыта	1 - Да 5 - Частично 10 - Нет	5
	Доступ к заказчику	1 - Да 5 - Частично 10 - Нет	2
Проект	Вероятность изменений	1 - 50% 5 - 25% 10 - 5%	5
	Критичность продукта или услуги	1 - Время 2 - Несущественный деньги 5 - Существенные деньги 7 - Одна жизнь 10 - Много жизней	5
	Инкрементная поставка	1 - Да 5 - Возможно/иногда 10 - Маловероятно	3

Рисунок 14. Диаграмма применимости подхода agile в компании (Agile Practice Guide, 2017)

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

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

Таким образом, необходимо, разработанная методология обладала следующими характеристиками:

требования к системе в целом и отдельно к MVP продукта (Minimum viable product, Минимально жизнеспособная версия продукта) формируются до начала разработки, но после каждой итерации могут быть изменены или дополнены;
разработка продукта осуществляется короткими (не более 1 месяца) итерациями;
по завершении каждой итерации заказчику для получения обратной связи предоставляется работоспособная версия продукта;
есть возможность пересматривать и изменять план следующих итераций;
в проекте есть задачи, которые не могут быть реализованы с использованием Agile-практик (например, задачи по реализации интеграции с внешними системами, у которых отсутствует тестовый стенд).

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

События:
1. Sprint (спринт, итерация): разработка будет проводиться короткими итерациями (длиной от 2 до 4 недель в зависимости от проекта);
2. Sprint Planning (Планирование спринта): планирование спринта будет осуществляться руководителем проекта совместно с заказчиком и ведущим разработчиков;
3. Daily Scrum (Ежедневный стендап): ежедневные встречи с команды с руководителем проекта со стороны заказчика для обсуждения статуса задач;
4. Sprint Review (Анализ спринта): демо инкремента для заказчика (проводится при необходимости);
Артефакты:
1. Product Backlog (Бэклог продукта): набор задач, который формируется на основе проектной документации;
2. Sprint Backlog (Бэклог спринта): набор задач, которые обеспечивают реализацию необходимой функциональности инкремента;
3. Increment (Инкременты): работоспособная версия продукта, которая предоставляется заказчику по итогу каждой итерации.

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

Таким образом, применение SCRUM в чистом виде невозможно в рассматриваемой компании, но большинство практик могут быть успешно использованы. Сравнение гибридной методологии для компании с фреймворком SCRUM представлено в таблице 5.

Этап подготовки и согласования технического задания на проект до начала фазы разработки остается аналогичным предиктивной модели.

Таблица 5. Сравнение разработанной гибридной методологии с фреймворком SCRUM

	SCRUM	Гибридная методология	Специфика объекта в гибридной методологии
События	Спринт	Итерация	Итерация не будет называться "Спринт" для удобства действующих заказчиков
	Планирование спринта	Планирование итерации	Планирование осуществляется не командой разработки, а руководителями проекта (со стороны команды и заказчика) и ведущим разработчиком команды
	Ежедневный стендап	Ежедневный стендап	На ежедневном стендапе присутствует руководитель проекта со стороны заказчика; стендапы допустимо проводить не каждый день
	Анализ спринта	Демо	Проведение демо реализованного функционала для заказчика (на постоянной основе, или по требованию заказчика)
	Ретроспектива спринта	-
Артефакты	Бэклог продукта	Бэклог проекта	Перечень задач разного уровня сложности, сформированный на основе проектной документации (согласованной до начала обработки)
	Бэклог спринта	Бэклог итерации	Перечень задач, которые должны быть завершены в рамках итерации
	Инкремент	Релиз	Релиз подразумевает установку новой версии продукта на стенд заказчика
Роли	Product owner	Руководитель проекта Руководитель проекта со стороны заказчика	За бэклог задач отвечают руководители проекта со стороны компании и заказчика
	Scrum master	-
	Команда разработки	Проектная команда	В проектную команду входят руководитель проекта, аналитики, разработчики и специалисты по тестированию
Единица спринта	Пользовательская история	Задача
Единица оценки	Story Point	Час

Для визуализации задач будет использоваться SCRUM-доска со следующим набором столбцов:

BACKLOG;
TO DO;
ANALYSIS;
IN PROGRESS;
TESTING;
DONE.

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

Таблица 6. Описание столбцов SCRUM-доски

Наименование	Описание	Лимит незавершенных задач	Переход
BACKLOG	Перечень задач, которые должны быть выполнены в течение итерации	-	в столбец TO DO
TO DO	Перечень задач на текущий день	-	в столбец BACKLOG или ANALYSIS
ANALYSIS	Задача в работе у аналитика	Равен количеству аналитиков в команде	в столбец IN PROGRESS, TO DO или BACKLOG
IN PROGRESS	Задача в работе у разработчика	Равен количеству разработчиков в команде	в столбец TESTING или ANALYSIS
TESTING	Задача в работе у тестировщика	Равен количеству тестировщиков в команде	в столбец IN PROGRESS, DONE или ANALYSIS
DONE	Задача выполнена	-	в столбец TO DO или BACKLOG

2.3. Обоснование выбора программного обеспечения для управления ресурсами

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

Ниже приведен обзор и сравнительный анализ современных инструментов для проектного управления, которые используются в российских и зарубежных компаниях:

Microsoft Project;
Jira Software;
Asana;
Slack;
Trello.

Microsoft Project

Microsoft Project – это программное обеспечение (ПО) для управления ресурсами от компании Microsoft. Инструмент предназначен для анализа сложности проекта, планирования задач и распределения ресурсов (Microsoft Office, 2019).

Microsoft Project позволяет контролировать следующие аспекты проекта:

этапы выполнения;
количество участников;
затраты;
используемые ресурсы;
затраченное время.

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

Рисунок 15. Диаграмма Гантт

Источник: https://professionali.ru/Soobschestva/upravlenie_proektami/upravlenie-proektami-diagramma-ganta-v/

Решаемые задачи.

Microsoft Project позволяет решать следующие задачи управления ресурсами:

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

Преимущества.

Microsoft Project имеет ряд преимуществ:

возможность интеграции с другими продуктами Microsoft Office;
возможность реализации модели с несколькими сценариями;
возможность создания интерактивных панелей мониторинга с использованием Power BI;
синхронизация с корпоративной почтой и мессенджерами;
может внедряться как полностью независимый инструмент, так и взаимодействовать с уже налаженной экосистемой классических или облачных решений от Microsoft;
высокий уровень защиты данных;
хранение данных в БД MS SQL Server;
интеграция с библиотекой проектной документации на базе SharePoint.

Заключение

В процессе работы автором были решены следующие задачи.

Был проведен обзор современных гибких методологий управления ресурсами, были подробно описаны фреймворки Scrum и Kanban.
На основе гибких методологий был сформирован гибридный подход к управлению ресурсами для консалтинговой компании: agile-подход на основе фреймворка SCRUM с использованием элементов предиктивной модели.
Был проведен обзор и сравнительный анализ современных инструментов управления ресурсами: были рассмотрены инструменты JIRA, MS Project, Asana, Slack, Trello.
Были определены преимущества и недостатки инструментов автоматизации управления ресурсами и подобран перечень инструментов для консалтинговой компании:
1. MS Project для подготовки план-графика проекта с учетом трудозатрат и бюджета, дорожной карты продукта и контроля отклонения фактического темпа реализации от планируемого;
2. Jira для постановки задач на разработку и тестирование, планирования релизов и контроля выполнения задач;
3. Confluence (в дополнении к Jira) для хранения проектной документации, инструкций и другой полезной информации для команды и заказчика;
4. Slack для обсуждения вопросов по проекту и задачам и обмена файлами;
5. Trello для создания Scrum-досок для распределения задач между аналитиками, а также создания сотрудниками индивидуальных Scrum-досок для отслеживания личных задач.
Были определены проблемы в управлении ИТ-ресурсами, реализуемыми для внешнего заказчика:
1. отсутствие постоянного взаимодействия с заказчиком с целью уточнения требований и получения обратной связи;
2. отсутствие частых поставок работоспособных версий продукта заказчику с целью получения обратной связи.
Был предложен перечень мероприятий, необходимых для перевода проекта на новую методологию проектного управления:
1. разбиение процесса разработки на итерации, по итогу каждой итерации заказчику будет представлена работоспособная версия продукта с новой функциональностью;
2. планирование регулярных встреч с заказчиком и командой;
3. настройка пространства в Jira (настройка новых типов запросов и их бизнес-процессов, меток, Scrum-доски);
4. использование новых инструментов: Confluence, Slack и Trello для работы над проектом.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Руководство к своду знаний по управлению ресурсами (Руководство PMBOK®). Шестое издание – Project Management Institute, Inc., 2017 – 1170 p.
Agile: Практическое руководство (Agile Practice Guide). Первое издание – Project Management Institute, Inc., 2017 – 337 с.
Стандарт PMBOK по управлению ресурсами [Электронный ресурс] / finswin.com, 2017-2020. – URL: https://finswin.com/projects/metody/PMBOK.html
Зиядуллаев Н., Фридлянов М. Современные стандарты проектного управления // Стандарты и качество. 2017. № 8 (962) г., с. 44-48. URL: http://www.ipr-ras.ru/articles/ziyadul17-06.pdf
Стандарты по проектному управлению [Электронный ресурс] / Центр оценки и развития проектного управления, 2020. – URL: https://www.isopm.ru/metodicheskie_osnovy/gosts/
ГОСТ Р 54869―2011. Проектный менеджмент. Требования к управлению проектом. – Москва, Федеральное агентство По техническому регулированию и метрологии, 2012. – 13 с.
ГОСТ Р 54869―2011. Проектный менеджмент. Требования к управлению программой. – Москва, Федеральное агентство По техническому регулированию и метрологии, 2012. – 15 с.
ГОСТ Р 54870―2011. Проектный менеджмент. Требования к управлению портфелем проектов. – Москва, Федеральное агентство По техническому регулированию и метрологии, 2012. – 12 с.
ГОСТ Р 58305-2018. Система менеджмента проектной деятельности. Проектный офис. – Москва, Федеральное агентство По техническому регулированию и метрологии, 2018. – 16 с.
ГОСТ Р 58184-2018 Система менеджмента проектной деятельности. Основные положения. – Москва, Федеральное агентство По техническому регулированию и метрологии, 2018. – 16 с.
Топ-7 методов управления ресурсами: Agile, Scrum, Kanban, PRINCE2 и другие [Электронный ресурс] / ООО «Проектные Сервисы», 2014-2018. – URL: https://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/
Agile, scrum, kanban: в чем разница и для чего использовать? [Электронный ресурс] / Rusbase, 2012-2019. – URL: https://rb.ru/story/agile-scrum-kanban/ (дата обращения: 12.04.2020).
Agile-манифест разработки программного обеспечения [Электронный ресурс] / Ward Cunningham, 2001. – URL: https://agilemanifesto.org/iso/ru/manifesto.html
13th annual State of Agile report / CollabNet VersionOne, 2019. – URL: https://stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508
Гибкая методология разработки “Scrum” [Электронный ресурс] / Habr, 2018 – URL: https://habr.com/post/247319/ (дата обращения: 15.05.2020).
Schwaber K, Sutherland J. The Scrum Guide™. The Definitive Guide to Scrum: The Rules of the Game. Ken Schwaber and Jeff Sutherland, 2017 – 19 p.
My Scrum Diagram [Электронный ресурс] / Jordan Job, 2015 – URL: https://jordanjob.me/blog/scrum-diagram/
What Are Story Points? (By Mike Cohn) // Mountain Goat Software, 1998-2020 – URL: https://www.mountaingoatsoftware.com/blog/what-are-story-points
Оценка задач в Story Points [Электронный ресурс] / Habr, 2018 – URL: https://habr.com/ru/post/489500/ (дата обращения: 15.05.2020).
Аппело, Ю. Agile-менеджмент. Лидерство и управление командами / Ю. Аппело. – Москва. : Альпина Паблишер, 2019. – 534 с
Сазерленд Д. Scrum. Революционный метод управления ресурсами командами / Д. Сазерленд. – Москва. Манн, Иванов и Фербер (МИФ), 2016. – 320 с.
Story Points [Электронный ресурс] / Scrum Time, 2020 – URL: https://ru.scrum-time.com/infobase/story-points.php (дата обращения: 15.05.2020).
Что такое Kanban? [Электронный ресурс] / Atlassian Agile Coach. – URL: https://ru.atlassian.com/agile/kanban (дата обращения: 15.04.2020).
Эволюционное управление разработкой — гарантированный путь к успеху [Электронный ресурс] / Habr, 2015 – URL: https://habr.com/ru/post/289266//
Crystal Clear – гибкая методология разработки приложений и сайтов [Электронный ресурс] / Winfox, 2014-2020. – URL: http://wnfx.ru/crystal-clear-gibkaya-metodologiya-razrabotki-prilozheniy-saytov/ (дата обращения: 15.04.2020).
Экстремальное программирование или управление: как не путаться в терминах [Электронный ресурс] / Skillbox – Онлайн-университет, 2020. – URL: https://skillbox.ru/media/management/ekstremalnoe_programmirovanie_ili_upravlenie/ (дата обращения: 15.04.2020).
Методология Kanban: доски, принципы и возможности управления [Электронный ресурс] / Skillbox – Онлайн-университет, 2020. – URL: https://skillbox.ru/media/management/vse_chto_nuzhno_znat_o_kanban/
Full scrum kanban board kit – nanocups for glass [Электронный ресурс] / PATboard – 2020. – URL: https://www.patboard.com/shop/full-scrum-kanban-board-kit-nanocups-for-glass/
Burndown vs Burnup Chart [Электронный ресурс] / ProjectManagement.com – 2020. – URL: https://www.projectmanagement.com/blog-post/40731/Burndown-vs-Burnup-Chart
How scrum help turn around our development process [Электронный ресурс] / Medium – 2019. – URL: https://medium.com/@jw207427/how-scrum-help-turn-around-our-development-process-dac6ff7c700
Жизненный цикл программного обеспечения [Электронный ресурс] / QA evolution, 2020. – URL: https://qaevolution.ru/zhiznennyj-cikl-programmnogo-obespecheniya/
Лекция 11: Модели жизненного цикла в некоторых реальных методологиях программирования. Курс: Основы менеджмента программных проектов [Электронный ресурс] / НОУ ИНТУИТ, 2003-2020. – URL: https://www.intuit.ru/studies/professional_retraining/941/courses/38/lecture/1136?page=2
Методология Kanban: доски, принципы и возможности управления [Электронный ресурс] / Skillbox – Онлайн-университет, 2020. – URL: https://skillbox.ru/media/management/vse_chto_nuzhno_znat_o_kanban/
Жизненный цикл товара [Электронный ресурс] / textb.net, 2020. – URL: http://textb.net/96/40.html
Жизненный цикл проектной задачи [Электронный ресурс] / Projectimo.ru, 2020. – URL: http://projectimo.ru/upravlenie-proektami/zhiznennyj-cikl-proekta.html
Лекция 1: Введение. Курс: Методические основы управления ИТ-ресурсами [Электронный ресурс] / НОУ ИНТУИТ, 2003-2020. – URL: https://www.intuit.ru/studies/courses/646/502/lecture/11389
Лекция 2: Инициация проекта. Курс: Методические основы управления ИТ-ресурсами [Электронный ресурс] / НОУ ИНТУИТ, 2003-2020. – URL: https://www.intuit.ru/studies/courses/646/502/lecture/11390
Базовый бизнес-процесс JIRA [Электронный ресурс] / Atlassian, 2020. – URL: https://wiki.teamlead.ru/pages/viewpage.action?pageId=85229701 (дата обращения: 10.05.2020).
Microsoft Project [Электронный ресурс] / Microsoft, 2020. – URL: https://products.office.com/ru-ru/project/project-management-software
Управление ресурсами. Диаграмма Ганта в разных инструментах [Электронный ресурс] / Профессионалы.ru, 2020. – URL: https://professionali.ru/Soobschestva/upravlenie_proektami/upravlenie-proektami-diagramma-ganta-v/ (дата обращения: 10.05.2020).
MS Project: что это и для кого подходит? [Электронный ресурс] / ООО «365 СОЛЮШНС» - Официальный партнер Майкрософт, 2020. – URL: https://365solutions.ru/ms-project-chto-ehto-i-dlya-kogo-podhodit/
Функциональные возможности MS Project [Электронный ресурс] / ООО «Олбест», 2000-2018. – URL: https://knowledge.allbest.ru/programming/2c0a65635a2bc69a5d43a88521316c36_0.html
Средства для разработки ПО. Jira Software [Электронный ресурс] / Atlassian, 2020. – URL: https://www.atlassian.com/ru/software/jira/features
Причины бросить Jira и перейти на BrainOffice [Электронный ресурс] / Proglib, 2020. – URL: https://proglib.io/p/brainoffice
Make more time for the work that matters most. Asana [Электронный ресурс] / Asana, 2020. – URL: https://asana.com/
Slack brings the team together, wherever you are. Slack [Электронный ресурс] / Slack, 2020. – URL: https://slack.com/intl/en-ru/?eu_nc=1
Мессенджер Slack — причины выбора, косяки при внедрении и особенности сервиса, облегчающие жизнь / Habr, 2015 – URL: https://habr.com/ru/post/433550/
Как пользоваться Slack? / Лекториум, 2020 – URL: https://www.lektorium.tv/howtouseslack
Slack: обзор мессенджера для продуктивной совместной работы / Интернет-агентство TexTerra, 2007-2020 – URL: https://texterra.ru/blog/slack-obzor-messendzhera-dlya-produktivnoy-sovmestnoy-raboty.html
Trello способствует более тесному сотрудничеству и увеличению эффективности работы [Электронный ресурс] / Trello, 2020. – URL: https://trello.com/ru
Что такое Trello и как им пользоваться [Электронный ресурс] / Нетология-групп, 2011-2020. – URL: https://netology.ru/blog/trello
Регрессионное тестирование или Regression Testing [Электронный ресурс] / ProTesting.ru , 2008-2020. – URL: http://www.protesting.ru/testing/types/regression.html