Moskva, Moscow, Russian Federation
GRNTI 06.81 Экономика и организация предприятия. Управление предприятием
GRNTI 06.01 Общие вопросы экономических наук
GRNTI 06.39 Наука управления экономикой
GRNTI 06.52 Экономическое развитие и рост. Прогнозир-ние и планирование экономики. Экономич. циклы и кризисы
OKSO 38.03.02 Менеджмент
OKSO 38.04.02 Менеджмент
BBK 65 Экономика. Экономические науки
BBK 6539 Экономика информатики
TBK 7717 Экономика предприятия (фирмы)
TBK 7748 Экономика информационных технологий
Adaptation and implementation of flexible development methodologies in an innovative IT-project is a long and phased project that requires careful preparation and coordination. A well-chosen composition of the component of these methodologies, as well as a set of key metrics of the project will be the determining factors for the success of the implementation. The article discusses the advantages of Scrum and Kanban frameworks for innovative IT projects and the metrics they provide for the project as a whole and each task separately. The conclusion about the necessity of a proper choice of the target project metrics and composition component of the agile methodologies before beginning the implementation process.
project management, agile methodologies, Scrum, Kanban, project metrics, 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. Paley T.F. Innovacionnyy menedzhment. : Foliant', 2011. 162 s.
2. Stepanova I.P. Innovacionnyy menedzhment. Kurs lekciy. Saratov: Saratov- skiĭ social'no-ekonomicheskiĭ institut (filial) FGBOU VPO «REU im. G.V. Plehanova», 2014. 124 s.
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.
