ИТ-архитектура. Практическое руководство от А до Я. Первое издание - стр. 33

•Определение требований

•Проектирование

•Конструирование («реализация» или «кодирование»)

•Интеграция

•Тестирование и отладка («верификация»)

•Инсталляция

•Поддержка

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

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

Слабые стороны классического проектного менеджмента – не толерантность к изменениям. Если в вашем проекте ресурсы и время не являются ключевыми ограничениями, а содержание проекта подвержено изменениям – возможно вам стоит присмотреться к другим системам управления проектами. Кроме этого, в реальных ИТ проектах довольно сложно на начальном этапе сформулировать детальные требования к конечному проекту.

AGILE – семейство процессов и методов разработки гибких методов управления и ведения проектов. Сам по себе Agile – скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют – фреймворк (frameworks). Примеры: Scrum, Kanban, Crystal, LeSS, SAFe, Nexus и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам. Гибкие методы предполагают изменения требований к продукту в течении всего времени проекта. Такое проектирование подразумевает совершенно иной подход к управлению проектами. Изначально методология разрабатывалась для проектов, которым требуются высокая гибкость и быстрая реализация. Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз – короткие циклы, называемые «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации. В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями: