Методологии проектного управления

Agile и Waterfall — две абсолютно разные методологии разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов Agile будет идеальной для IT-компаний, стартапов, проектов в инновационных сферах Waterfall не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы   Несмотря на то что многие команды отдают предпочтение либо методологии водопада, либо agile-проектированию, преимущества обоих подходов привели к появлению гибридной методологии, когда этапы планирования и определения требований выполняются согласно методологии водопада, а этапы проектирования, разработки, внедрения и оценки соответствуют гибкому подходу 

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

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

Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.

На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ (техническому заданию).

Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки.

Проект передают заказчику и следят заранее определённое время, чтобы всё работало.

Это снижает порог вхождения для команд

Можно легко отследить ресурсы

Задачи ясны с самого начала и остаются неизменными

Стоимость и сроки выполнения проекта могут быть просчитаны заранее

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

Качество проекта будет ухудшаться при недостатке денежных/ временных ресурсов

Проверка качества готового продукта происходит без возможности изменить отдельные элементы

Невозможность производить изменения в процессе разработки

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

Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.

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

Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.

Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.

Agile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.

Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.

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

Agile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.

Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.

Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микроменеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микроменеджмента.

Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться большего.

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

Agile-команды не очень любят бумажную работу. Для управления данными, отчетами и обновлениями статуса они предпочитают использовать гибкие программные решения, а не традиционную документацию.

Agile-команды любят сотрудничество — включая регулярные обновления и обратную связь о том, как продвигается проект, от клиентов и заинтересованных сторон. Чего Agile-команды не любят, так это долгих согласований объемных контрактов.

Эта ценность прежде всего характеризует Agile-управление проектами. Agile-команды чутко реагируют на изменения и успешно адаптируются к новым условиям и вызовам.

Можно рассматривать и как "+", и как "-".

Циклы разработки длятся от 2 недель до 4 месяцев, по окончанию которых заказчик получает готовую версию продукта

Команда не может механически применить инструменты "гибкой" разработки, необходимо принять ключевые принципы системы

Гибкость разработки продукта может привести к тому, что он никогда не придет к финальной версии.

Стимулирование изменений и усовершенствование готового продукта приводят к плавающему значению стоимости продукта

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

 Своему термину «Scrum» (дословно- "схватка") обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.Scrum помогает попасть в «поток» — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя. 

Он знает о цели проекта и ожидаемом результате

До 10 человек с необходимыми для создания работоспособного продукта навыками

Он следит за ходом проекта, помогает скрам-команде бороться с трудностями

На Agile доске расставляются приоритеты по каждому требованию к продукту

Отрезки времени на выполнение определенного ряда задач

По 3 вопроса каждому члену команды: что делал вчера, что будешь делать сегодня, какие возникли проблемы

Вовлечение в просмотр и обсуждение стейкхолдеров

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

Список требований по проекту

Список требований, который нужно выполнить в ближайший спринт

Цель спринта

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

(больше 10 человек)

   Kanban ― это метод улучшения процессов разработки и часть agile-философии.  Цель Kanban  ― получать готовый качественный продукт вовремя.   Kanban начинается с визуализации, чтобы процессы были на виду у команды. Для этого используют специальную доску и набор карточек или стикеров.Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и видит, на каком этапе находится задача.  Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел.  У каждого проекта есть план процесса работ. Сначала план анализируется и доска разделяется на столбцы, которые отражают этапы.  Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком.  Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски.  C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект  На доске отражаются все процессы. Команда их анализирует и устраняет слабые места. В Kanban это называется управлением потоком

Человек в рамках рабочего дня может быть не загружен на 100%

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

Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО».Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:больше внимания предварительному моделированиюповышенная (по сравнению с Agile) важность построения отчётности и графиковнацелено на корпоративную разработку.   Feature Driven Development состоит из таких цикличных этапов:Создание общей модели — видение проекта на основе предварительных данных.Разработка списка свойств — аналог product backlog в методике скрам.Планирование по свойствам — оценка сложности свойств каждым членом команды.По каждому свойству — технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.В набор входят следующие 7 принципов:избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.быстрая доставка — по сути основа итеративной модели.усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.Crystal-проекты должны соответствовать 3 основным показателям:быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.«осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.Особая роль отводится участия конечного потребителя (пользователя) в процессе разработки. Помимо этого принципа, к базовым относятся:частые выпуски рабочих версий продуктаавтономность разработчиков в плане принятия решенийтестирование на протяжении всего рабочего цикла.DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.В начале команда изучает реальность разработки приложения и область применения. Дальше работа делится на три взаимосвязанных цикла:цикл функциональной модели — создание аналитической документации и прототипов.цикл проектирования и конструирования — приведение системы в рабочее состояние.цикл реализации — развертывание системы.