Разработка инновационного IT-проекта начинается после прохождения прединвестиционной фазы проекта. Таким образом уже сформированы некоторые первичные ожидания и требования инвесторов проекта, установлены сроки и стоимость реализации. Часто для успешной продажи проекта инвестором от команды проекта требуется предоставление верхнеуровнего плана работ, технической спецификации проекта и демонстрация прототипов [1]. Таким образом работа над проектом начинается с использования традиционной каскадной модели по запланированному графику, что может приводить к следующим проблемам [2]:Процесс реализации не прозрачен для инвесторов и владельцев проектаБольшие сроки перед показом первых действующих прототиповНевозможность быстрой реакции на изменения требованийВысокий уровень риска, связанный с наличием неисследованных узких мест проекта ввиду его инновационной природы. Внедрение гибких методологий в процесс разработкиДля осуществления контроля над процессом внедрения необходимо измерять ряд целевых метрик проекта и проектных задач. Правильное внедрение компонент гибких методологий должно приводить к улучшению показателей выбранных метрик, при этом от выбора набора ключевых метрик будет зависеть эффективность внедрения методологий. Рассмотрим составные части методологий Scrum и Kanban, необходимые для эффективной работы команды в условиях высокой неопределенности и список целевых метрик проекта согласно данным методологиям: Таблица 1. Преимущества методологий Scrum и KanbanKanban [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, однако если изначально сформированная команда этих принципов не придерживалась, переход так же осуществим. При этом выбор компонент гибких методологий следует осуществлять индивидуально под каждый проект.