Categorieën: Alle - принципы - проектирование - аналитика - этапы

door чайнюк оксана 1 jaar geleden

134

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

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

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

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

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



Какую методологию выбрать?

Agile

Семейство методов
Kanban

рушит российский менталитет ТК РФ

человек в рамках рабочего дня может быть не загружен на 100%, то есть не все восемь часов cотрудник должен что-то делать.

большой уровень гибкости, можно уйти не туда

обеспечение качества

быстрое понимание узких мест системы

визуализация потока предоставления ценности

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

цель - получать готовый качественный продукт вовремя

FDD
DSDM
Crystal
RUP
Lean
Programming (XP)
Extreme
Scrum

недостатки

плохо подходит для больших команд

требует дополнительной роли scrum - мастера

если известны все требования к продукту - нецелесообразно

страх отпустить вожжи

требуется экспертиза в команде

преимущества

подходит для всего

легко маштабируется

легко адаптировать продукт к рынку

работающий улучшенный продукт после каждой итерации

самоорганизованные команды

основные элементы

Sprint Burndown Chart

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

Sprint Goal

цель спринта

Sprint Backlog

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

Product Backlog

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

ключевые шаги в технологии

проведение ретроспективы

проведение обзора рабочих частей продукта

организация ежедневных пятнадцатиминутных "мин-апов"

планирование спринтов

составление эклог продукта

поиск скрам-мастера

сбор команды проекта

выбор владельца продукта

факторы выбора
НЕ подходит компаниям, если

нужна документация по всем процессам

бюджет ограничен

продукт должен быть создан к конкретному сроку

компания не готова тратить доп ресурсы на налаживание коммуникаций

Agile подходит компаниям, если

продукт разрабатывается в сфере, подверженной постоянным изменениям

заказчик выступает в качестве партнера

нужно быстро получить рабочую версию

работает опытная команда

start -up

Недостатки
Сложность подсчета итоговой суммы работы
Философский характер методологии

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

Повышенные требования к квалификации и опыту команды
Стимулирование постоянных изменений проекта
Минимизация рисков, благодаря гибской системе внесения изменений
Во главе угла стоит рабочий продукт как основной показатель прогресса проекта
Высокая степень вовлеченности исполнителей, организаторов и заказчиков проекта
Короткие и понятные итерации
Манифест Agile
Готовность к изменениям важнее следования первоначальному плану

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

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

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

Работающий продукт важнее исчерпывающей документации

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

Люди и взаимодействие важнее процессов и инструментов

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

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

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

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд

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

Простота как искусство сократить до минимума лишнюю работу крайне необходима

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

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта

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

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

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

Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды

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

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

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

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

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

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

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

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

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

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценности

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

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

гибридная методология

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

Waterfall

Выбор методологии
НЕ подходит команиям, если

финансовые ресурсы не являются ключевым ограничением

компания не уверена в концепции

компания хочет создать инновационный продукт или крупный проект

Подходит компаниям, если

создание бизнеса на соблюдении строгой последовательности выполнения задач

нет ограниченности во времени

есть четкая концепция продукта

большая часть или вся работа над проектом проводится на аутсорсе

Недостатки
Повышенный риск
Инерционность
"Стойкость" к изменениям
Лишенный гибкости продукт
Преимущества
Стабильность задач
Понятная и проста] структура процесса разработки
Оценка стоимости и сроков проекта
Удобная отчетность
Основные принципы
изменения могут быть внесены только после завершения всего процесса разработки
заказчик не привлекается к непосредственному процессу разработки
фиксирование стоимости продукта
переход к новому этапу только после успешного завершения предыдущего
Жесткая последовательность этапов разработки
Манифест методологии
Следите, чтобы не было изменений
Чем подробнее ТЗ, тем лучше продукт
Нет ТЗ (технического задания)— нет продукта
Следуйте правилам
Основные этапы
Эксплуатация и техническая поддержка

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

Тестирование

На этом этапе проводят полноценное тестирование продукта, чтобы найти и исправить критические (и не очень) проблемы.

Разработка (реализация)

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

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

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

Аналитика (определение требований)

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