a Максим Номоконов 1 éve
196
Még több ilyen
Agile-проектирование лучше подходит для проектов, требующих интенсивного взаимодействия в реальном времени и реализуемых высокомотивированными командами, не нуждающимися в дополнительном контроле. Методология agile отличается высокой интерактивностью, дает возможность быстро подстраиваться под проект. Одно из главных ее преимуществ в том, что можно быстро выявлять спорные моменты и вносить необходимые изменения на ранней стадии разработки, не дожидаясь завершения тестирования. Agile-проектирование обеспечивает применение повторяющихся процессов, снижение рисков, оперативную обратную связь, быструю оборачиваемость и уменьшение сложности.
Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.
DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.
Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.
Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.
Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО».
Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого – справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.
Kanban ― это метод улучшения процессов разработки и часть agile-философии.
Kanban начинается с визуализации, чтобы процессы были на виду у команды. Для этого используют специальную доску и набор карточек или стикеров.
Доска ― это обязательный элемент для гибкой методологии. Она есть в Scrum, есть и в Kanban. Каждый член команды получает к ней доступ в любое время и видит, на каком этапе находится задача.
Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел.
У каждого проекта есть план процесса работ. Сначала план анализируется и доска разделяется на столбцы, которые отражают этапы.
Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком.
Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски.
C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект
На доске отражаются все процессы. Команда их анализирует и устраняет слабые места. В Kanban это называется управлением потоком
Недостатки Kanban
Рушит российский менталитет ТК РФ
Человек в рамках рабочего дня может быть не загружен на 100%
Большой уровень гибкости, можно уйти не туда
Преимущества Kanban
Обеспечение качества
Быстрое понимание узких мест системы
Визуализация потока предоставления ценности
Своему термину «Scrum» (дословно- "схватка") обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.
Scrum помогает попасть в «поток» — состояние наивысшей концентрации, когда вы делаете то, что нужно, не затрачивая на это усилий, не заставляя себя и не подгоняя.
Недостатки Scrum
Плохо подходит для больших команд
(больше 10 человек)
Требует дополнительной роли Scrum-мастера
Если известны все требования к продукту - нецелесообразно
Страх отпустить вожжи
Требуется экспертиза в команде
Преимущества Scrum
Подходит для всего
Легко масштабируется
Легко адаптировать продукт к рынку
Самоорганизованные команды
Работающий улучшенный продукт после каждой итерации
Основные элементы
Sprint burndown chart
Диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды по проекту
Sprint goal
Цель спринта
Sprint backlog
Список требований, который нужно выполнить в ближайший спринт
Product backlog
Список требований по проекту
Шаги по использованию методики
Проведение ретроспективы
Обсуждение проблемы и поиск решений после каждого спринта. Полученный план изменений внедряется на следующем спринте
Проведение обзора рабочих частей продукта
Вовлечение в просмотр и обсуждение стейкхолдеров
Организация ежедневных пятиминутных "мит-апов"
По 3 вопроса каждому члену команды: что делал вчера, что будешь делать сегодня, какие возникли проблемы
Планирование спринтов
Отрезки времени на выполнение определенного ряда задач
Составление бэклог продукта
На Agile доске расставляются приоритеты по каждому требованию к продукту
Поиск Scrum-мастера
Он следит за ходом проекта, помогает скрам-команде бороться с трудностями
Сбор команды проекта
До 10 человек с необходимыми для создания работоспособного продукта навыками
Выбор владельца продукта
Он знает о цели проекта и ожидаемом результате
Команда должна анализировать эффективность собственной работы, искать способы ее улучшения, быть мотивированной и самоорганизованной
Стимулирование изменений и усовершенствование готового продукта приводят к плавающему значению стоимости продукта
Гибкость разработки продукта может привести к тому, что он никогда не придет к финальной версии.
Команда не может механически применить инструменты "гибкой" разработки, необходимо принять ключевые принципы системы
Циклы разработки длятся от 2 недель до 4 месяцев, по окончанию которых заказчик получает готовую версию продукта
Можно рассматривать и как "+", и как "-".
Эта ценность прежде всего характеризует Agile-управление проектами. Agile-команды чутко реагируют на изменения и успешно адаптируются к новым условиям и вызовам.
Agile-команды любят сотрудничество — включая регулярные обновления и обратную связь о том, как продвигается проект, от клиентов и заинтересованных сторон. Чего Agile-команды не любят, так это долгих согласований объемных контрактов.
Agile-команды не очень любят бумажную работу. Для управления данными, отчетами и обновлениями статуса они предпочитают использовать гибкие программные решения, а не традиционную документацию.
То, что общение и межличностные отношения важнее, чем строгие процессы — краеугольный камень Agile-управления проектами. Agile рекомендует персонализированный подход к управлению проектами, когда команды ориентируются на постоянное общение, а не на жестко распланированный выпуск обновлений.
Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться большего.
Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микроменеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микроменеджмента.
Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.
Agile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.
Смысл принципа, который называет работающий продукт основным показателем прогресса, в том, что главная цель команды всегда остается одна — предоставить клиенту как можно более высококачественный результат. Когда клиент доволен, это и есть главный показатель успеха проекта.
Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.
Agile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.
Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.
Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.
В этом их преимущество перед традиционными командами, которым обычно не так легко управлять изменениями.
Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.
Методология водопада включает в себя статические этапы (анализ требований, проектирование, тестирование, реализацию и техническую поддержку), которые выполняются в определенном порядке. Она позволяет усиливать контроль на каждом из этапов, но, если границы проекта меняются уже в процессе его реализации, она не может обеспечить необходимую гибкость.
Невозможность производить изменения в процессе разработки
Проверка качества готового продукта происходит без возможности изменить отдельные элементы
Качество проекта будет ухудшаться при недостатке денежных/ временных ресурсов
На первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат практически невозможно
Стоимость и сроки выполнения проекта могут быть просчитаны заранее
Задачи ясны с самого начала и остаются неизменными
Можно легко отследить ресурсы
Это снижает порог вхождения для команд
Проект передают заказчику и следят заранее определённое время, чтобы всё работало.
Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки.
На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ (техническому заданию).
Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.
Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать.
Agile и Waterfall — две абсолютно разные методологии разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов Agile будет идеальной для IT-компаний, стартапов, проектов в инновационных сферах Waterfall не сдаёт позиции в строительных проектах или проектах, где ключевым ограничителем является срок реализации проекта, а не финансы
Несмотря на то что многие команды отдают предпочтение либо методологии водопада, либо agile-проектированию, преимущества обоих подходов привели к появлению гибридной методологии, когда этапы планирования и определения требований выполняются согласно методологии водопада, а этапы проектирования, разработки, внедрения и оценки соответствуют гибкому подходу
