И руководство о том, как это сделать

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

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

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

Но так быть не должно, потому что так должно быть.

Текущее состояние Agile

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

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

Хотя в этих идеях нет ничего плохого, именно реализация часто является основной причиной реальной проблемы, лежащей в основе Agile. Процесс часто начинается разрозненно: каждая команда занимается своим делом, а затем объединяется для создания продукта. Здесь часто что-то идет не так, поскольку узкие места и разговоры теряются в море бюрократии и промежуточного управления. Проблема не в идеях, лежащих в основе Agile, а в реализации и том, как собираются команды.

Agile - это не просто гибкость

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

Затем есть те попытки гибкой разработки, которые требуют, чтобы разработчики начали кодировать, когда еще ничего не решено. Почему бы и нет? Если водопад является воплощением чрезмерного планирования и попыток микроменеджмента задач, тогда противоположный подход состоит в том, чтобы деконструировать процесс и просто позволить разработчикам кодировать.

Но программное обеспечение работает не так.

Создание надежного и функционального программного обеспечения сродни постройке дома. Вы не можете просто сказать своим строителям, чтобы они начали строить и кончили с этим. Разработчики - это не просто разработчики программного обеспечения. Они также ваши архитекторы и инженеры - две очень разные и дополнительные роли в разработке программного обеспечения. Несколько движущихся частей должны быть скоординированы и доставлены в определенной последовательности, чтобы гибко обеспечить наилучший результат.

Правильно

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

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

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

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

Важность осмысленного творчества в Agile

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

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

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

Заключительные слова

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

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

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

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

Спасибо за чтение. ❤

Афинья