Luokat: Kaikki - изменения - команда - интерактивность - гибкость

jonka Максим Номоконов 1 vuosi sitten

222

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

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

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

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

Гибкая методология - Agile

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

Методы Agile
Dynamic systems development method

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

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

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

  1. цикл функциональной модели — создание аналитической документации и прототипов.
  2. цикл проектирования и конструирования — приведение системы в рабочее состояние.
  3. цикл реализации — развертывание системы.


Crystal methodologists

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

Crystal-проекты должны соответствовать 3 основным показателям:

  1. быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
  2. совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
  3. «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.


Lean software development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

В набор входят следующие 7 принципов:

  1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
  2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
  3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
  4. быстрая доставка — по сути основа итеративной модели.
  5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
  6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
  7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.


Feature driven development

Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО».

Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

   Feature Driven Development состоит из таких цикличных этапов:

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


Extreme programming

Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого – справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.

   Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

  1. кодирование — согласно единым в команде стандартам оформления;
  2. тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;
  3. планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
  4. слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.


Kanban

   Kanban ― это метод улучшения процессов разработки и часть agile-философии.

  Цель Kanban  ― получать готовый качественный продукт вовремя.

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

Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и видит, на каком этапе находится задача.

  Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел.

  У каждого проекта есть план процесса работ. Сначала план анализируется и доска разделяется на столбцы, которые отражают этапы.

  Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком.

  Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски.

  C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект

  На доске отражаются все процессы. Команда их анализирует и устраняет слабые места. В Kanban это называется управлением потоком



Недостатки Kanban

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

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

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

Преимущества Kanban

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

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

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

Scrum

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

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

Недостатки Scrum

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

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

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

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

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

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

Преимущества Scrum

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

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

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

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

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

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

Sprint burndown chart

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

Sprint goal

Цель спринта

Sprint backlog

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

Product backlog

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

Шаги по использованию методики

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

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

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

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

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

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

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

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

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

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

Поиск Scrum-мастера

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

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

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

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

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

Недостатки методологии Agile
Повышенные требования к квалификации и опыту команды

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

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

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

Стимулирование постоянных изменений проекта

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

Философский характер методологии Agile

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

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

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

Во главе угла стоит рабочий продукт как основной показатель прогресса проекта

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

4 главные идеи Agile
Готовность к изменениям важнее следования первоначальному плану

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Каскадная/водопадная методология» - Waterfall

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

Недостатки методологии Waterfall
Стойкость к изменениям

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

Повышенный риск

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

Лишенный гибкости процесс

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

Инерционность

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

Преимущества методологии Waterfall
Оценка стоимости и сроков проекта

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

Стабильность задач

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

Удобная отчетность

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

Понятная и простая структура процесса разработки

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

Основные принципы Waterfall
Изменения могут быть внесены только после полного завершения всего процесса разработки
Заказчик не привлекается к непосредственному процессу разработки
Фиксированная стоимость продукта
Переход к новому этапу только после успешного завершения предыдущего
Жесткая последовательность этапов разработки
Основные этапы Waterfall
Техническая поддержка

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

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

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

Реализация

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

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

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

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

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

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

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

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