Сочетания проектных методологий в разработке ПО

Дисклеймер

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

Методологий много, т.к. это выгодно авторам

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

Кроме того, внедрение новых, актуальных фреймворков является своеобразной модой среди топ-менеджмента российских компаний, и каждая новая методика прокатывается волной по корпоративному миру – сначала стартапы, потом бизнес покрупнее, затем большие корпорации и, наконец, гос.структуры. И нередко речь идет только о внедрении названий, без каких-либо изменений принципов работы.

По практике реальных проектов, основных методологий – две

При этом, исходя из реального опыта на проектах можно сказать, что в качестве основных используются два подхода. Можно использовать разные термины, но условно назовем их Классический (Waterfall во всех проявлениях) и Гибкий (все итеративные методы). Главное отличие их, в общем случае, кроется в понимании конечного результата. В проектах, где он формализован и неизменен, используется классический подход. В этом случае обычно есть артефакт, фиксирующий и описывающий, каким этот результат должен быть (техническое задание, требования к функционалу, тех. проект и прочее). Во всех остальных случаях – когда итог проекта сложно формализовать, логичнее использовать Гибкие методики. В таких проектах часто ориентирами служат метрики, клиентские пути, коммерческие показатели.

Waterfall – для B2G. Agile – для продукта

Условно можно считать, что из двух основных подходов первый больше подходит для проектов заказной разработки, для которых обычно устраивают тендеры и нанимают подрядчиков. Он ценен для выполнения конкретной задачи – автоматизации определенного процесса (или нескольких), рефакторинга легаси-систем, систематизации наборов данных. А второй гармонично смотрится в проектах продуктовой разработки, чаще реализуемых с помощью внутренней команды. Зачастую в таких проектах может не быть задач, а есть только направления, ориентиры в которых стоит двигаться в поисках коммерческого результата. Только не стоит считать гибкие методологии способом автоматизации хаоса. Эта задача лежит за пределами мира разработки и не решается ни одной из методологий