аспирант
Москва, г. Москва и Московская область, Россия
ГРНТИ 06.81 Экономика и организация предприятия. Управление предприятием
ГРНТИ 06.01 Общие вопросы экономических наук
ГРНТИ 06.39 Наука управления экономикой
ГРНТИ 06.52 Экономическое развитие и рост. Прогнозир-ние и планирование экономики. Экономич. циклы и кризисы
ОКСО 38.03.02 Менеджмент
ОКСО 38.04.02 Менеджмент
ББК 65 Экономика. Экономические науки
ББК 6539 Экономика информатики
ТБК 7717 Экономика предприятия (фирмы)
ТБК 7748 Экономика информационных технологий
Адаптация и внедрение гибких методологий разработки в инновационный IT-проект – продолжительный и поэтапный проект, требующей тщательной подготовки и координации. Грамотно выбранный состав компонент данных методологий, а также набор ключевых метрик проекта будут являться определяющими факторами успешности внедрения. В статье рассматриваются преимущества фреймворков Scrum и Kanban для инновационных IT-проектов и предоставляемые ими метрики проекта в целом и каждой задачи в отдельности. Сделан вывод о необходимости грамотного выбора целевых метрик проекта и состава компонент гибких методологий перед началом процесса внедрения.
управление проектом, гибкие методологии, Scrum, Kanban, метрики проекта, agile
Разработка инновационного IT-проекта начинается после прохождения прединвестиционной фазы проекта. Таким образом уже сформированы некоторые первичные ожидания и требования инвесторов проекта, установлены сроки и стоимость реализации. Часто для успешной продажи проекта инвестором от команды проекта требуется предоставление верхнеуровнего плана работ, технической спецификации проекта и демонстрация прототипов [1]. Таким образом работа над проектом начинается с использования традиционной каскадной модели по запланированному графику, что может приводить к следующим проблемам [2]:
- Процесс реализации не прозрачен для инвесторов и владельцев проекта
- Большие сроки перед показом первых действующих прототипов
- Невозможность быстрой реакции на изменения требований
- Высокий уровень риска, связанный с наличием неисследованных узких мест проекта ввиду его инновационной природы.
Внедрение гибких методологий в процесс разработки
Для осуществления контроля над процессом внедрения необходимо измерять ряд целевых метрик проекта и проектных задач. Правильное внедрение компонент гибких методологий должно приводить к улучшению показателей выбранных метрик, при этом от выбора набора ключевых метрик будет зависеть эффективность внедрения методологий. Рассмотрим составные части методологий Scrum и Kanban, необходимые для эффективной работы команды в условиях высокой неопределенности и список целевых метрик проекта согласно данным методологиям:
Таблица 1. Преимущества методологий Scrum и Kanban
|
Kanban [8] |
Scrum [9] |
|
Визуализация процессов разработки |
Итерационная разработки |
|
Поиск и устранение потерь |
Развитие команды проекта |
|
Метрики по каждой задаче |
Ежедневные митинги |
|
Контроль WIP |
Регулярные демонстрации результатов работ |
|
|
Ретроспективный анализ итераций |
Итерационная разработка. Итерационная разработка и Kanban может выглядеть более рискованной ввиду недетерминированности конечного результата работ, однако позволяет интегрировать регулярные исследования в процесс разработки. Таким образом обеспечивается соблюдение принципов Customer development и JIT [10] возможность принимать стратегические проектные решения в начале каждого спринта на основе вновь полученных данных.
Команда инновационного проекта. Инновационная деятельность предполагает тесное сотрудничество высококлассных специалистов – участников проекта. В условиях, когда деятельность отдельно взятых сотрудников не является строго регламентированной должностными инструкциями и ее характер может изменяться на протяжении работы над проектом, развитие у команды навыков взаимодействия и коллективного принятия решений становится особенно важным.
Методология Scrum и XP предполагает ряд мероприятий, позволяющих команде лучше взаимодействовать друг с другом и улучшать процесс совместной работы [5, c. 18–22]. Среди них:
- Проведение ретроспективы итераций. Ретроспективный анализ каждой итерации позволяет выявлять проблемные места командного взаимодействия и выносить их на обсуждение с целью последующего устранения.
- Совместное планирование. Участие команды в процессе планирования позволяет участникам лучше разбираться в продукте и бизнес-приоритетах проекта, так же позволяет участникам команды лучше представлять себе, чем заняты другие члены команды.
Контроль процесса разработки
Одним из главных преимуществ гибких методологий является прозрачность процесса разработки. Методология Kanban предполагает наличие специально доски, позволяющей визуализировать весь процесс и отображающей все задачи, сгруппированные по статусам. Scrum предполагает проведение ежедневных митингов команды с целью синхронизации работ между участниками проекта и демонстрации продукта в конце каждой итерации с целью синхронизации ожиданий стейкхолдеров и инвесторов проекта с командой разработки.
Метрики задач
Процесс итерационной работы подразумевает проведение большого числа активностей, при этом методология Scrum подразумевает измерение лишь общих бизнес-метрик (ROI), и отдельной метрики Velocity [7, c. 975–8887], что приводит к потере информации и сглаживанию внутриитерационных проблем. Однако Velocity – не может служить единственной метрикой процесса итерационной разработки [11]. У метрик scrum можно выделить две проблемы:
- Возможность снимать метрики появляется только 1 раз за спринт в конце итерации.
- Метрики итерации не позволяют выявить возникающие внутри итерации проблемы, т.к. метрики суммируют все положительные и отрицательные результаты.
Методология Kanban, напротив, предполагает измерение метрик, описывающих каждую задачу в отдельности [4, c. 115–116][6]:
- Cycle time – время разработки задачи с момента начала первых работ по ней и до момента релиза
- WIP – количество задач в статусе «Work in progress»
- Lead time – время существования задачи с момента создания до релиза. Включает в себя Cycle time и Wasted time.
- Wasted time – время, которое задача провела в различных очередях в статусе ожидания, а не непосредственно в работе.
- Effectiveness – процент времени, который тратится непосредственно на работу с задачей, а не на ожидание в очередях.
- Throughput – количество задач, которые способна реализовать команда за единицу времени.
В некоторых командах так же используется ретроспективный анализ burndown – диаграммы с целью выявления шаблонов работы команды и их последующего улучшения [3, c. 145–159].
Заключение
Процесс разработки инновационного IT-проекта не детерминирован и во-многом зависит от специфики разрабатываемого продукта. Тем не менее такие проекты испытывают те же традиционные для сферы IT проблемы, что и коммерческая разработка, следовательно, для инновационных проектов все так же целесообразно внедрение различных компонент гибких методологий. При этом успех внедрения agile будет напрямую зависеть от выбранных целевых метрик проекта. Процесс перехода к гибким методологиям несет некоторые риски сам по себе, ввиду чего рекомендуется сразу разрабатывать проект согласно принципам agile, однако если изначально сформированная команда этих принципов не придерживалась, переход так же осуществим. При этом выбор компонент гибких методологий следует осуществлять индивидуально под каждый проект.
1. Палей Т.Ф. Инновационный менеджмент. : Фолиантъ, 2011. 162 с.
2. Степанова И.П. Инновационный менеджмент. Курс лекций. Саратов: Саратов- ский социально-экономический институт (филиал) ФГБОУ ВПО «РЭУ им. Г.В. Плеханова», 2014. 124 с.
3. Allwood J. A bird’s eye view of pragmatics // Physics (College. Park. Md). 2016. Vol. 3. № 20. p. 145-159.
4. Bowden R. CIM-Principles of Computer Integrated Manufacturing. // Prod. Plan. Control. 1994. Vol. 5. № 1. p. 115-116.
5. Cervone H.F. Understanding agile project management methods using Scrum // OCLC Syst. Serv. Int. Digit. Libr. Perspect. 2011. Vol. 27. № 1. p. 18-22.
6. Edwards J. EnterpriseOne Kanban Management 9.0 Implementation Guide. , 2015.
7. Ifra, Bajwa J.K. Metrics of Scrum Methodology // Int. J. Comput. Appl. 2016. Vol. 149. № 2. p. 975-8887.
8. Shingo S. A Study of the Toyota Production System from an Industrial Engineering Viewpoint // Manuf. Eng. 1990.
9. Sutherland J. Scrum Handbook. : Scrum Foundation, 2010.
10. Tregubov A., Lane J.A. Simulation of Kanban-based scheduling for SoS.
11. Your Scrum team’s velocity and how to misuse it. [website]. URL: http://thescrumblog.blogspot.com/2011/12/your-scrum-teams-velocity-and-how-to.html.
