Автоматизация управления проектами на основе гибких методологий

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа

Автоматизация управления проектами на основе гибких методологий

по направлению подготовки 38.04.05 «Бизнес-информатика»

Асеева Елена Геннадиевна

Москва 2020

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

ГЛАВА 3. ОПТИМИЗАЦИЯ ПРОЦЕССА ВНЕДРЕНИЯ CRM-СИСТЕМЫ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ ГИБКИХ МЕТОДОЛОГИЙ

3.1 Описание ИТ-проекта внедрения CRM-системы

3.2 Применение разработанной методологии для проекта внедрения CRM-системы

3.3 Результат применения разработанной методологии проектного управления

ЗАКЛЮЧЕНИЕ

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

ПРИЛОЖЕНИЯ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

На основе гибких методологий сформировать подход к управлению ИТ-проектами для консалтинговой компании.

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

Структура работы.

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

В главе 2 приведено описание объекта исследования - российской консалтинговой компании, определена методика управления проектами, подобранная под специфику компании и ее проектов. Определены инструменты управления проектами, которые будут наиболее эффективными для управления проектами в рассматриваемой компании.

Глава 3 посвящена описанию применения разработанного подхода на примере проекта внедрения 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 описано десять областей знаний, которыми должен обладать менеджер проекта:

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

пути поиска компромисса в случае возникновения конфликта;

эффективное распределение проектных ресурсов;

связи с другими областями знаний;

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

сроки: процессы, обеспечивающие завершение работ проекта в указанные сроки:

оценка трудозатрат;

планирование ресурсов.

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

оценка стоимости работ;

планирование бюджета.

качество: процессы, обеспечивающие соответствие задач проекта потребностям заинтересованных лиц;

человеческие ресурсы: процессы управления проектной командой;

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

риски: процессы идентификации и анализа рисков, а также определения методов реагирования на них;

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

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

В ходе доработки РМВОК (последняя актуальная версия руководства - шестая) его состав изменялся: изменения вносились в описание набора подходов, областей знаний и процессов. Вышедшая в 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 «Система менеджмента проектной деятельности. Основные положения»: устанавливает основные положения для систем менеджмента проектной деятельности в организациях.

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

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.

Рисунок 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).

Рисунок 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):

разработка и внедрение;

рост;

зрелость;

упадок.

Рисунок 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 Описание объекта исследования

Рассматриваемая ИТ-компания специализируется на внедрении информационных систем класса CRM, ERP и BI, а также систем электронного документооборота (СЭД). Компания является сертифицированным партнером Microsoft, SAP и Битрикс24. Компания предоставляет клиенту комплексное внедрение информационных систем, включающее в себя весь спектр работ: от консультации до внедрения и сопровождения системы, а также может выступать в качестве генерального подрядчика на проекте и координировать работу других компаний более узкого профиля. Компания предлагает свои решения на рынке ИТ-услуг уже более 20 лет и на текущий момент реализовано более 200 проектов для клиентов в ключевых отраслях:

финансы;

недвижимость;

торговля и логистика;

телекоммуникации;

страхование.

Организационная структура компании, представленная на рисунке 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 года - инкрементный.

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

определяется руководитель проекта - сотрудник отдела консалтинга с грейдом «Ведущий специалист» или «Менеджер»;

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

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

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

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

Анализ:

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

аналитики разрабатывают проектную документацию (Частное техническое задание (ЧТЗ) и Техническое задание на разработку архитектуры системы), руководитель проекта после проверки согласовывает ЧТЗ с заказчиком;

после согласования проектной документации заказчиком осуществляется переход к следующему этапу.

Дизайн:

дизайнеры (внешние сотрудники) разрабатывают макеты экранных форм системы;

после согласования макетов заказчиком осуществляется переход к следующему этапу.

Разработка:

руководитель проекта определяет приоритет задач и распределяет их между аналитиками;

аналитики ставят задачи разработчиком и контролируют их выполнения;

специалисты по тестированию выполняют ручную проверку функционала;

после завершения всех работ из ЧТЗ осуществляется переход к следующему этапу.

Тестирование:

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

руководителем проекта совместно с заказчиком осуществляется оценка системы: если система удовлетворяет требованиям, осуществляется переход к этапу «Поставки» (внедрения системы в промышленную эксплуатацию);

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

...