Управление проектами в IT: лучшие методологии и практики
Когда компания разработчик начинает создание ПО, одной из первых задач после определения характеристик проекта и основных инструментов разработки является выбор эффективной методологии управления проектами. Методология – это стратегический подход к администрированию и распределению ресурсов, использование систем практик к организации работы команд вовлеченных в проект. На практике используют одну либо композицию нескольких методологий, которые давно доказали свою эффективность. Рассмотрим распространенные типы управления проектами и определим целесообразность их применения в определенных условиях разработки.
Как правило, за менеджмент проектов отвечает project manager и technical lead (тем лед). Поэтому одним из важных этапов выбора методологии разработки является первая оценка потребностей заказчика, оценки конкурентных решений, план технологических внедрений, масштаб программного продукта и т.д. Чаще эту оценку проводят менеджер и технический специалист, согласовав все детали — они определяют какой подход управления проектом будет рациональным при полученных условиях.
Менеджер учитывает количество специалистов в команде, их профессиональную направленность и этап, на котором каждый специалист будет задействован. Менеджер должен учитывать форс-мажорные обстоятельства или резкое масштабирование проекта, которое влечет за собой привлечение новых специалистов. Задача менеджера — обеспечить каждого нового специалиста, который присоединяется к команде, информацией о проекте. Правильно выбранные концепции управления проектами упрощают процесс интеграции. Использование досок задач, сохранение итераций, классифицированная техническая документация — смягчают процесс ознакомления с проектом и в целом оптимизируют процесс.
Предлагаем рассмотреть 14 моделей управления, которые используются разработчиками для создания эффективных программных решений. Методы отличаются по структуре и организации. На первый взгляд, некоторые из них могут быть очень похожи, но иметь различия, которые определяют критические аспекты влияния на результативность выбранной методологии.
Водопад или каскадная модель – одна из старейших методологий разработки с четкими этапами и правилами. Эта модель характеризуется линейностью действий. Команда не может передать процесс разработки на следующий этап до завершения текущего. Такой подход считается устаревшим и часто критикуемым. Каскадная модель закладывает тестирование на последнем этапе, таким образом могут оказаться проблемы, допущенные из-за ошибок на этапах дизайна или даже анализа. Собственно изменения вносить крайне сложно. Однако она все еще не покидает списки и топы. Это связано именно с его дисциплинированным процессом управления и ведением документации, и иногда используется для создания крупных инженерных проектов и систем. При разработке ПО или мобильных приложений IT компании выбирают другие типы управления проектами.
Эта методология наиболее популярна среди разработчиков и имеет несколько подтипов. Ее главные столбы: гибкость, коммуникация и эффективность. Методология основана на постоянных итерациях к моменту релиза приложения на рынок. К примеру, команда анализирует и обсуждает идеи, создает дизайн и вносит информацию в документации, производит разработку и создает первую версию продукта (демо), затем проект отдают на тестирование и анализируют полученный результат (т.е. итерация завершилась). Чтобы этот процесс не становился циклическим и нескончаемым, Agile характерно разделять проект на недельные сроки. Например, одна итерация не может проводиться более 2 недель.
Методология Agile вовлекает в процесс заказчика для получения обратной связи. Команда может удовлетворить потребности в изменениях, наполнять проект инновационными идеями и экспериментировать, когда проект это позволяет. В отличие от каскадной модели, гибкая модель позволяет быстро и эффективно исправлять недостатки ПО. Однако иногда это может подвинуть сроки реализации. Задача менеджера следить за тем, чтобы сроки выпуска продукта на рынок оставались постоянными, или вовремя согласовать подобные изменения с заказчиком.
Система управления проектами руководствуется такими же принципами, как и Agile, но предлагает еще более короткие итерации, которые называют спринтами. Методология подходит для инновационных и стартап проектов незначительного размера, а от команды требует постоянной коммуникации, поскольку спринт может держать всего неделю. Подходы Kanban и Scrumban используются командами предпочитающими Agile, и в первую очередь незначительно отличаются организационными и визуальными аспектами.
Lean или рациональная разработка сосредоточена на устранении потерь и на оптимизации процессов. Ее цель при высокой эффективности уменьшить потребление ресурсов и распределить их нагрузку. Соответственно, с большими проектами этот подход управления работает плохо.
Extrime programming – используют для гибких проектов со сжатыми сроками. Методология учитывает все этапы программирования, распределенные на несколько месяцев до полной реализации. Качество кода и тестирование прежде всего. Иногда в таких условиях страдает дизайн. К сожалению, эта методология не подходит для визуально сложных проектов, а сжатые сроки разработки требуют команду высококвалифицированных экспертов. Кроме того, заказчик должен поддерживать постоянную связь с командой. Методология XP гибкая, поэтому дает волю для поиска и интеграции свежих решений. CPM и CCPM являются прекрасной альтернативой этому методу, потому что более четки своими требованиями.
Rapid application development – итеративная методология разработки ПО, которая также направлена на быструю разработку и прототипирование. В сравнении с предыдущим подходом, RAD уделяет больше внимания дизайну и ориентируется на потребности конечного пользователя. Эта модель управления позволяет осуществлять быстрые циклы разработки, что приводит к более быстрому выводу приложений на рынок. Однако эффективность модели в значительной степени зависит от наличия инструментов и фреймворков быстрой разработки, а также опытных разработчиков.
Feature driven development также разновидность гибкого подхода, которая сосредоточена на предоставлении небольших функций или функциональных блоков. Несмотря на свою природу, этот подход меньше всего привлекает заказчика к процессам. Но команда усердно ведет документацию по каждому функциональному этапу.
Методология DSDM или Dynamic systems development – это еще одна проектная методология, созданная на принципах RAD, однако акцентируется на управлении рисками. При такой методологии команда определяет срок, качество и стоимость как фиксированные параметры и не изменяет их. Приоритеты устанавливаются по системе 1) Must have; 2) Should have; 3) Could have; 4) Won’t have (currently). Таким образом, команда разлагает потребности проекта и требования заказчика на категории при необходимости интеграции. Методология обеспечивает своевременную доставку благодаря строгому соблюдению сроков. Проект может адаптироваться и продолжать свою работу даже при наличии ограничений.
Как понятно из названия, эта методология сконцентрирована на принципах создания прототипа, когда проект мало известно, а определенные сроки и требования просто отсутствуют. Заказчик может увидеть будущий вид продукта, а команда может быстро обнаружить проблемы и внести правки.
Современные методы управления проектами очень разнообразны и адаптированы под потребности команд, особенности проектов и технологические инструменты.
Подведем итоги. Каждая описанная выше методология используется на современном IT рынке, что уже доказывает их эффективность. Однако риск выбрать методологию, не соответствующую приоритетам проекта и типа команде — все еще существует. Мы предлагаем простой алгоритм выбора наиболее эффективной методологии проектного менеджмента под ваши потребности.
| Модель | Тип проектов | Проблематика | Требования к команде |
|---|---|---|---|
| Waterfall | Устойчивые проекты, четкие требования и ясно определенные задачи. | Отсутствует гибкость к масштабированию и изменениям | Для каждого этапа есть квалифицированный специалист, полностью преданный своему этапу |
| Agile | Гибкие, инновационные и динамические проекты | Может не работать на больших проектах, когда привлечена очень большая команда. Однако если коммуникация налажена, эта проблема незначительна. | Команды с высоким уровнем отлаженной коммуникации. |
| Scrum | Гибкие, инновационные и динамические проекты | Сложные проекты в высоко регулируемых отраслях с жесткими сроками реализации. | Команды до 10 человек с возможностью поддерживать частую коммуникацию. |
| Lean | Малые и средние проекты нацелены на эффективность и сокращение затрат | Большие проекты с обширной документацией | Небольшие команды и налаженная связь заказчиком |
| XP | Малые, иногда средние объекты ориентированы на пользователя. Проекты, в которых клиент не представляет конечного продукта. | Проекты в высоко регулируемых отраслях с жесткими сроками реализации. | Малые и средние команды с высоким уровнем креативности и широкими техническими навыками. |
| RAD | Малые и средние проекты, которые должны выйти на рынок за короткий срок | Отсутствие четких требований, неизменная потребность в утверждении от заказчика. Не подходит под проекты в высоко регулируемых отраслях с жесткими сроками реализации. | Команда должна уметь работать в сжатых условиях и полностью отдана проекту. |
| Prince2 | Корпоративные проекты масштабных размеров, продуктовые и маркетинговые проекты. | Не подходит под малые проекты и критически малые команды. | Средние и большие команды |
| Kanban | Гибкие, инновационные и динамические проекты малых и средних размеров. | Проекты в высоко регулируемых отраслях с жесткими сроками реализации. | Удаленные команды разных размеров |
| FDD | Большие и гибкие проекты. | Не подходит под малые проекты и критично малые команды. Иногда менее эффективен при больших проектах при четких требованиях | Средние команды |
| DSDM | Средние и крупные проекты с короткими сроками разработки, но с гибкими требованиями. | Сложная методология управления и при наличии четких требований и результата лучше отдать предпочтение другим моделям. | Команда должна уметь работать в сжатых условиях и общаться с разработчиком. |
| Прототипна модель | Создание прототипов, отсутствие четкого видения продукта | Высоко регулируемые проекты и объекты с четкими требованиями | Опыт создания прототипов |
| CPM, CCPM | Подходит для детерминированных, хорошо спланированных проектов и ограниченных ресурсов. | Не подходит для проектов с высокой неопределенностью (стартап) | CPM – малые и средние команды; CCPM – средние и большие команды. Главная цель минимизировать многозадачность |
Компания PNN Soft занимается кастомной разработкой уже более 20 лет. За этот срок мы реализовали стартап-проекты, собственные авторские продукты, крупномасштабные ПО и системы для высоко регулируемых отраслей, ERP системы для банкинга/финансов, а также множество интересных решений для ритейла и электронного обучения. Наши команды активно изучают современные технологические тренды и готовы быстро адаптироваться к изменениям, против управления разработкой проекта мы предпочитаем Agile, Scrum, RAD и FDD. Чтобы заказать кастомную разработку вашего программного
