Что такого хорошего в Agile? Учебник по гибкой методологии
Agile Определить как Agile Management Systems, которые существовали некоторое время, но в последнее время приобрели популярность. Фактически, Agile Management постоянно входит в число главных трендов управления проектами почти каждого блога по управлению ИТ-проектами каждый год.
Применение Agile в ИТ-проектах не вызывает сомнений, поскольку оно находит применение не только в проектах по разработке программного обеспечения для ИТ, но также в разработке продуктов и инновациях.
Так что же такого хорошего в Agile? Спросите сотрудников, которые перешли из традиционной системы в Agile, и они могут оплакивать постоянные встречи и «встречи о встречах».
Оказывается, в Agile гораздо больше, чем просто встречи и обратная связь. Он нацелен на расширение прав и возможностей команд и устранение последовательных способов разработки проектов, чтобы обеспечить большую гибкость и инновации. Хотя это означает встречи и результаты чаще, чем с традиционными системами, это также означает, что существует меньший шанс повторений и изменений позже. в проектном цикле.
Это рекламируется как панацея от общих проблем, которые мешают проектам, связанным с ИТ. Что именно и чем оно лучше традиционных систем?
Потребность в гибкой методологии - практика управления
Любой, кто работал над гибкой методологией в проектах по разработке программного обеспечения, будет иметь представление о некоторых обычных проблемах, возникающих в ходе проекта: изменение масштаба, сроки, которые кажутся невозможными, и чрезмерно загруженные ресурсы.
Традиционные гибкие методологии в управлении проектами имели много недостатков, из-за которых они не справлялись с постоянно меняющейся бизнес-средой, особенно в разработке программного обеспечения, и, к сожалению, вышеперечисленные ситуации были слишком распространены. Это не означает, что традиционные методы нигде не применяются . Они по-прежнему являются лучшим выбором для проектов, в которых идея полностью сформирована с самого начала.
Практика Agile Management стала потребностью часа, потому что они удовлетворяли следующие потребности продукта, запущенного в динамичной среде:
- Потребность в скорости, чтобы вывести продукт на рынок
- Потребность в гибкости, чтобы учесть множество изменений в спецификациях
- Недостатки в сценарии «разделения труда»
- Дилемма заказчика
- Необходимость снижения стоимости
Потребность в скорости для выхода продукта на рынок:
Мы живем в быстро меняющейся среде, где гибкость и скорость являются ключом к успеху.
Технология является одним из наиболее быстро меняющихся секторов в отрасли. Каждую минуту появляется новая идея, продукт или инновация. На этом фоне традиционный подход к управлению проектами не дает результатов. Последовательный проект обязательно зависит от этапов гибкой методологии, которые выполняются удовлетворительно по порядку. Сроки в традиционно управляемых проектах всегда являются яблоком раздора.
Организации и команды, которые не являются динамичными, проиграют гонку тем, кто трансформируется в соответствии с меняющейся средой.
Потребность в гибкости, чтобы учесть многочисленные изменения в спецификациях:
Ожидания и требования клиентов часто меняются в процессе разработки продукта. До того, как Agile Management Systems стали массовыми, проекты в сфере ИТ часто терпели неудачу, потому что традиционная система управления проектами была построена так, чтобы «пахать». Если были какие-либо изменения, клиенты часто чувствовали, что их кошельки или тайм-ауты чувствуются. Традиционная модель управления проектами, адаптированная из других отраслей, просто не работала для такой динамичной отрасли, как ИТ.
Разделение труда:
В традиционной модели существуют отдельные этапы, начиная с анализа системных требований и заканчивая выпуском и обслуживанием продукта. Это приводит к разделению труда и маркировке участников как «дизайнеров», «программистов» или «тестировщиков». Но на самом деле сегодняшние ресурсы чрезвычайно функциональны, и такое четкое разграничение ролей невозможно в большинстве проектов.
Дилемма заказчика:
В нестабильных проектах очень часто клиенты не совсем уверены, каким должен быть их конечный продукт со всеми техническими характеристиками. Функциональные возможности и требования часто меняются по мере выполнения работы. Традиционные модели, такие как модель «Водопад», подчеркивают ясность в отношении конечного продукта, а отклонения в планах создают огромную нагрузку на систему. Это подводит нас к последнему фактору, который привел к развитию гибких систем.
Необходимость снижения стоимости:
Традиционно изменения в требованиях в любое время после начала проекта не поощрялись. Скорее, затраты на любой дополнительный компонент были высокими, а иногда и непомерно высокими. Поэтому было необходимо включить все возможные сценарии на самой стадии планирования. Это означало, что были рассмотрены все сценарии и предложено решение. Но так как почти невозможно точно знать, какую часть продукта предпочитает пользователь, команды часто разрабатывали «раздутые версии» продукта. В нем содержались все возможные сценарии, из которых обычный пользователь использовал бы не более 20%. Это привело к ненужным затратам и развитию.
Излишне говорить, что это означало, что все проекты были глобальными в своем планировании.
И когда появился совершенно новый незапланированный сценарий, все равно были дополнительные расходы, несмотря на все планирование.
Группа людей встретилась в феврале 2001 года, чтобы обсудить именно это: необходимость гибкой и гибкой модели разработки программного обеспечения, которая помогла бы разработать продукты, которые действительно работали бы для клиента и разработчика. Результатом стал «Agile Manifesto», который был преимуществом гибкой методологии разработки программного обеспечения, то есть набора из четырех принципов, которые просты и наглядны. Были также разработаны двенадцать «гибких принципов», объясняющих, как Agile-системы будут фактически работать в среде проекта.
Благодаря этой работе мы пришли к оценке:
- Индивидуумы и взаимодействия над процессами и инструментами
- Рабочее программное обеспечение над исчерпывающей документацией
- Сотрудничество с клиентом в рамках переговоров по контракту
- Реагирование на изменения после плана
То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.
12 проворных принципов
12 Agile Принципов - это набор руководящих принципов, лежащих в основе Agile Manifesto, которые поддерживают проектные группы в реализации Agile Projects. Они есть:
- Нашим главным приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.
- Приветствуя меняющиеся требования, даже на поздней стадии разработки. Agile методология процессов использует изменения для конкурентного преимущества клиента.
- Поставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
- Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
- Создавайте проекты вокруг мотивированных людей. Дайте им среду и поддержку, в которой они нуждаются, и доверьте им выполнение работы.
- Самый эффективный и эффективный метод передачи информации в команду разработчиков - это личный разговор.
- Рабочее программное обеспечение является основной мерой прогресса.
- Гибкие методологические процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
- Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
- Простота - искусство максимизировать количество не выполненной работы - очень важно.
- Лучшие архитектурные решения, требования и проекты возникают из самоорганизующихся команд.
- Через равные промежутки времени команда размышляет о том, как стать более эффективным, затем настраивает и корректирует свое поведение соответствующим образом.
Пример проекта, требующего гибкого управления
Представьте себе стартап, который разрабатывает мобильное приложение для клиента. Замораживание всего проекта приложения до начала разработки может иметь катастрофические последствия. Также есть ограниченное время для проведения исследования рынка, составления подробного плана, выбора вариантов, которые они хотят предложить, а затем для разработки продукта. Помимо огромных затрат, связанных с этим подходом, они рискуют, что какая-то другая компания может разработать приложение раньше, чем они.
Гибкая методология в управлении проектами помогает преодолеть эти проблемы. В рамках этой системы приложение разрабатывается поэтапно, с ежедневным взаимодействием с клиентом, и определяются конечные результаты или этапы проекта, скажем, каждую неделю.
Несколько команд могут также работать над одним и тем же приложением, поэтому время разработки значительно сокращается.
Функциональные возможности уточняются с каждой встречей, и конечный продукт отражает конечную потребность. Они шаг за шагом изучают, что работает для клиента, и импровизируют предложения, пока не получат желаемый продукт.
В традиционном подходе к управлению проектами перед выпуском продукта нужно подумать обо всех изменениях. Это приведет к несоблюдению сроков, увеличению рабочей нагрузки и росту инфляции. Более того, к моменту выпуска продукт мог полностью утратить свою актуальность.
Как именно работает Agile Management?
Хотя Agile Management в основном называют концепцией ИТ, его использование не ограничивается отраслью ИТ. Например, сеть магазинов одежды Zara использовала принципы Agile Management для преобразования своего бизнеса.
Используя гибкие принципы, Zara производила продукцию небольшими партиями, а не концентрировалась на большом производстве до нового сезона. Этот метод позволил компании избежать затрат, связанных с большими запасами и непредсказуемыми скидками.
Вот некоторые из ключевых аспектов Agile Project Management:
- Agile Project Management использует гибкий подход.
Agile Management приветствует дополнения и изменения в процессе разработки продукта, а не соответствует его оригинальным спецификациям.
- Гибкие проекты обычно делятся на отдельные части работы, при этом команды участвуют в разработке одной или нескольких из этих «частей» работы.
Так, например, можно иметь, например, четыре команды, работающие одновременно над различными частями проекта, так что сроки проекта сокращаются. Команды ежедневно координируют между собой и с клиентом результаты.
- Ежедневные встречи о прогрессе или препятствиях в проекте с постоянной обратной связью.
После получения отзывов клиентов изменения вносятся, и команды переходят к следующему фрагменту. Этот процесс продолжает предоставлять продукт, который более динамичен и лучше соответствует потребностям клиента.
- Члены команды более вовлечены, чем нисходящий подход.
В жизненном цикле разработки программного обеспечения члены команды участвуют на всех этапах: требования, проектирование, разработка и гибкая методология тестирования. Поскольку существует регулярный обзор эффективности задач, члены команды соответствующим образом корректируют поведение и процедуры.
- Профиль менеджера проекта в Agile проекте изменится с традиционной роли.
Он / она больше не тратит много времени на планирование или мониторинг ресурсов, но теперь проводит больше времени в сотрудничестве с командами и следит за тем, чтобы общая картина всегда была видна. Это непростой переход, и менеджеры, переходящие на гибкие системы, должны быстро адаптироваться, чтобы проект был успешным.
Несколько слов о Scrum:
Scrum - одна из самых популярных платформ для реализации гибкой методологии. Что такое гибкая методология? Это предшествует Agile, и было впервые предложено в 1986 году, и внедрено в автомобильной и полиграфической промышленности.
Гибкая методология с scrum не является синонимом; Существуют и другие фреймворки, которые можно использовать для реализации Agile, но Scrum является одним из самых эффективных и, вероятно, самых популярных. Что такое схватка? Как правило, Scrum имеет только три роли: владелец продукта, команда и мастер Scrum. Мастер методологии Scrum не является менеджером проекта. Обязанности традиционной роли менеджера проекта распределены между тремя ролями управления проектом Scrum. Проект состоит из серии итераций фиксированной длины, называемых спринтами. Успех каждого гибкого методологического спринта вызывает ощущение ощутимого прогресса и постоянного вдохновения. Цель каждой итерации - создать рабочий продукт, который может быть продемонстрирован заинтересованным сторонам. Agrum методология Scrum Master работает с владельцем продукта и командой, чтобы облегчить достижение целей путем устранения препятствий. Команда разработчиков гибкой методологии является межфункциональной и включает в себя тестировщиков, дизайнеров и оперативных инженеров, а также разработчиков.
Традиционное управление проектами: водопад
Одна из самых известных традиционных систем управления проектами - Водопад. Он часто использовался с 1970-х годов. В ИТ-проектах есть несколько хорошо известных и широко применяемых методик водопадов. К ним относятся PRINCE2, который был создан правительством Великобритании для государственного сектора.
Как следует из названия, это последовательный рабочий процесс. Конечный продукт фиксируется в начале проекта. Затем различные этапы рабочего процесса выполняются последовательно (инициация концепции, анализ, проектирование, конструирование, тестирование, внедрение и сопровождение). После завершения предыдущего шага разработчики переходят к следующему шагу. План проекта должен быть надежным; Как только этап в последовательности завершен, разработчики не могут вернуться к тому же самому, не начав заново. Это статический подход к гибкой методологии в управлении проектами. Здесь нет места для изменений или ошибок, и план проекта гибкой методологии должен тщательно соблюдаться.
Можно провести аналогию между управлением водопадом и рисованием шедевра. Образ финального шедевра уже в голове художника, и он неуклонно работает над этим. Если по какой-либо причине конечный продукт отличается от того, что он визуализировал, он не может легко его изменить.
Проворный или Водопад?
- Что такое Agile? Agile больше подходит для небольших групп, работающих над инкрементными и эволюционными проектами, тогда как Waterfall подходит для больших схем или проектов развития. Управление водопадом может лучше подходить для таких отраслей, как строительная отрасль. Agile используется в более динамичных проектах, таких как ИТ-индустрия.
- Гибкие системы требуют высококвалифицированных членов команды, которые могут обрабатывать все этапы проекта. Это требует кардинального изменения роли менеджера проекта. Процесс водопада структурирован более традиционным способом, является линейным, и, возможно, его легче понять не-разработчикам и новичкам в разработке программного обеспечения.
- Многие организации считают методологию Waterfall более удобной, поскольку она лучше документирована. Agile известен тем, что не подчеркивает обширную документацию. Это больше зависит от людей, что может быть неудобно в организациях, где уровень отсева высок.
- Небольшие прямые проекты могут не требовать гибкой методологической основы, и последовательная модель Waterfall может работать так же хорошо.
Куда все это идет?
По данным опроса, проведенного HP в мае 2015 года, методология гибкой разработки составляет более двух третей всех ИТ-проектов в США.
Но Agile не всегда «идеальное» решение. Это не универсальное решение, и в результате многие организации (24% согласно опросу HP) в настоящее время приняли гибридный подход.
Гибрид Agile и Waterfall методов может использовать преимущества обоих. Этот гибридный подход может работать для сложных проектов с внешними клиентами и большими командами. Этот подход был описан Эриком Бергманном и Энди Гамильтоном. Это компромисс между двумя методами, позволяющий программным группам работать «гибко», в то время как команды разработчиков оборудования и менеджеры по продуктам используют традиционный метод.
Марк Фромсон, цифровой консультант, указывает на другой способ работы гибрида:
Разбивка проекта на водопадоподобные фазы, позволяющие заключать контракты с фиксированной ставкой и определять объем работ в рамках более мелкой фазы, но при этом поддерживать проект в целом.
Независимо от того, какую форму примут будущие команды, ясно, что Agile-методология разработки должна остаться. Это позволило добиться гибкости, времени и затрат, а также самого важного из всех факторов: дать чувство удовлетворения и мотивирующую атмосферу людям, которые работают над этими проектами.
Источник:
Для Agile Manifesto и 12 Agile Принципов - www.agilemanifesto.org
Связанные курсы: -
Agile Project Management - Изучите гибкие методологии