Модели управления разработкой ПО

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

Постараемся максимально кратко разобраться в этом вопросе, но при этом не упустив ничего важного.

Нужно знать, что существует три основных модели:

• Каскадная модель
• Метод набегающей волны
• Гибкие методологии

Давайте рассмотрим каждый из них.

Каскадная модель

Если вы читали нашу статью про жизненные циклы ПО, то вы уже в курсе, что существует каскадная модель ЖЦ, но каскадная модель управления разработкой может применяться еще и в инкрементальном подходе итерационной модели (подробнее — в статье про ЖЦ https://teletype.in/@hackinterview/slc_models)

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

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

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

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

1. Задачи известны наперёд, а значит, системный аналитик всегда знает, что будет делать завтра или через неделю.
2. Не придётся переключаться между разными типами задач — в любой момент времени работа однородна. Если проект находится на этапе анализа, системный аналитик занимается только анализом, если на этапе проектирования — только проектированием.
3. Есть чёткий план работы, и нужно стараться ему следовать. Умение придерживаться плана — один из критериев качества работы системного аналитика в каскадной модели.
4. Нагрузка распределяется неравномерно. При каскадной модели управления самые активные этапы для системного аналитика — анализ и проектирование. На следующих этапах его загруженность может снижаться.

Метод набегающей волны

Эта модель управления включает два плана: долгосрочный (общий план проекта) и краткосрочный (детальный план текущих и будущих работ). План проекта регулярно пересматривается и уточняется.

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

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

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

Особенности работы системного аналитика по методу набегающей волны:

1. Основные задачи известны наперёд, но их могут разбавлять другие задачи. Они иногда появляются спонтанно.
2. Работа не будет однородной. Часть функциональности приложения может быть ещё на этапе анализа, в то время как другая уже пойдёт в разработку. Тогда системному аналитику понадобится, например, метаться между сбором и анализом требований и ответами на вопросы разработчиков.
3. Есть чёткий план ближайших работ, и нужно стараться ему следовать.
4. Сравнительно равномерная загрузка на протяжении всего проекта — всегда есть чем заняться.
   

Гибкие методологии

В этой модели управления отсутствует долгосрочный план. Гибкие методологии применяют в итерационных моделях жизненного цикла ПО, особенно когда конечный результат неизвестен. Планирование основано на обновляемом списке задач, из которого выбирают приоритетные для текущей итерации. После выполнения задач планируется следующая итерация, обычно длительностью 2–3 недели.

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

Особенности работы системного аналитика в гибких методологиях:

1. Системный аналитик не знает, какой задачей будет заниматься через неделю, но может быть уверен в том, что это будет самая важная и нужная задача.
2. Разнородная работа. В рамках итерации придётся заниматься сразу анализом, проектированием, обработкой макетов дизайнеров, обсуждением деталей реализации с разработчиками и тестировщиками.
3. Равномерная загрузка на протяжении всего проекта — всегда есть чем заняться.