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

На практике в чистом виде достаточно часто используется только фреймворк 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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. стажер;
2. младший специалист;
3. специалист;
4. старший специалист;
5. ведущий специалист;
6. менеджер.

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

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

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

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

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