Гибкая разработка программного обеспечения относится к методологиям разработки программного обеспечения, основанным на идее итеративной разработки, при которой требования и решения развиваются посредством сотрудничества между самоорганизующимися межфункциональными командами. Конечная ценность Agile-разработки заключается в том, что она позволяет командам создавать ценность быстрее, с более высоким качеством и предсказуемостью, а также с большей способностью реагировать на изменения. Scrum и Kanban — две наиболее широко используемые методологии Agile . Ниже приведены пять распространенных ошибок в гибкой методологии.
Что такое гибкий?
Гибкая разработка программного обеспечения относится к группе методологий разработки программного обеспечения, основанных на итеративной разработке, в которой требования и решения развиваются посредством сотрудничества между самоорганизующимися межфункциональными командами. Гибкие методы или гибкие процессы обычно способствуют дисциплинированному процессу управления проектами, который поощряет частые проверки и адаптации, философии лидерства, которая поощряет командную работу, самоорганизацию и подотчетность, набору лучших инженерных практик, направленных на быструю доставку высококачественного программного обеспечения, и бизнес-подход, который согласовывает развитие с потребностями клиентов и целями компании. Гибкая разработка относится к любому процессу разработки, соответствующему концепциям Манифеста Agile. Манифест был разработан группой из четырнадцати ведущих деятелей индустрии программного обеспечения и отражает их опыт определения того, какие подходы работают, а какие не работают в разработке программного обеспечения. Узнайте больше о Agile-манифесте. Знаете ли вы, что Agile можно применять к любым типам проектов? Узнайте о революционной Agile-инфраструктуре с FM2S.
Пять распространенных ошибок в гибкой методологии
По мере того, как Agile становится все более популярным, кажется, что количество заблуждений вокруг него увеличивается, а не уменьшается. Стремясь устранить некоторые распространенные ошибки, допускаемые при интеграции Agile в вашу повседневную рабочую практику, мы составили этот пост в надежде, что он даст вам пищу для размышлений. Вот некоторые из наиболее распространенных ошибок, с которыми я столкнулся как профессиональный тренер Scrum:
Ошибка 1: размышления о ежедневных схватках делают вас более гибкими
Точно так же, как посещение церкви один или два раза не делает вас религиозным, то, что вы проводите Scrum-совещания, не означает, что вы теперь гибки. Ежедневный Скрам — жизненно важная часть Скрама, но простое его соблюдение никому не поможет. Чтобы получить максимальную пользу от Daily Scrum, важно следовать основным принципам мероприятия, каким бы сложным оно ни казалось. Цель Daily Scrum — дать команде разработчиков возможность проанализировать и спланировать свой прогресс в достижении цели спринта. Это также форум, позволяющий вам выявлять потенциальные проблемы и быстро или поздно решать их. Он разработан так, чтобы быть кратким для решения проблем и обеспечения (как минимум) постоянного уровня общения и планирования со стороны команды разработчиков по ходу спринта. Его редко бывает достаточно самого по себе, и он предназначен для решения проблем, о которых команде разработчиков приходится тратить больше времени, обсуждая и решая вне ежедневного Scrum.
Ошибка 2: думать, что Scrum Master должен быть менеджером проекта
Давайте на мгновение рассмотрим роль Scrum-мастера. Именно с этой ролью, пожалуй, больше, чем с какой-либо другой, люди сталкиваются при внедрении Scrum в свою рабочую практику. Некоторые люди предполагают, что Scrum Master — это то же самое, что и менеджер проекта. Другие берут на себя ту же роль ведущего разработчика. В этом даже нет необходимости. Scrum Master — это, вероятно, роль, которую вы никогда раньше не видели. Это не означает, что менеджер проекта не может выполнять эту работу, но это определенно не является свершившимся фактом. Скрам-мастер — это тот, кто обучает и пом люксембург whatsapp номер телефона огает. Технически они не управляют командой. Scrum Master предоставляет рекомендации и советы команде и владельцу продукта, особенно по вопросам, связанным со структурой Scrum. Вы можете позволить своей команде решить, кто должен быть Скрам-мастером. Это не обязательно должен быть кто-то конкретный.
Ошибка №3: слишком большая Scrum-команда
В идеале Scrum-команда должна представлять собой небольшое специализированное подразделение, тесно работающее и самоорганизующееся. Чтобы это произошло, он не должен быть слишком большим или тяжелым. Джефф Безос (сооснователь Amazon.com) постулировал, что идеальная команда имеет размер двух пицц, то есть такое количество людей, которых можно накормить двумя пиццами. Вам решать уровень голода и, следовательно, размер пиццы.
Ошибка №4: получение неправильного бэклога продукта
Четвертая из пяти распространенных ошибок в гибкой методологии связана с бэклогом. Невыполненные работы по продукту бывают разных форм. Этап первоначального сбора требований закладывает основу для всего последующего. Сделайте это неправильно, и вы можете сорвать все свое развитие. Если вы используете пользовательские истории, лучше всего, чтобы их написал самый близкий к клиенту человек, которого вы сможете найти. Обычно это владелец продукта, но он может получить помощь, если задача будет выполнена. Как правило, ищите следующую информацию: Конкретный человек/должность, требующая новой функции/проблемы, которую необходимо решить, поскольку она приносит конкретную выгоду клиенту + критерии приемки (используются для подтверждения того, что элемент бэклога продукта выполнен и работаем по плану). Без какого-либо из этих критериев ваши пользовательские истории будут неполными, и вам следует тщательно подумать, прежде чем пытаться начать их техническую разработку.
Ошибка №5: Думать, что вам не нужно ничего документировать.
Да, в манифесте Agile говорится, что мы ценим завершенную функциональность выше подробной документации, НО это не то же самое, что предполагать, что вам не нужно ничего документировать. Если в эпоху до Agile вам, вероятно, приходилось документировать все, от требований и технических спецификаций до планов тестирования (все, что выходит за рамки внутренних измерений ног), то теперь вам нужно документировать только то, что действительно ценно. Это может включать, например, ваш исходный код и/или краткий документ о вашей архитектуре. Что бы вы ни решили документировать, помните принципы Agile и убедитесь, что это каким-то образом полезно для продукта. Если это не имеет ценности, скорее всего, вам не нужно это писать. Это была пятая из пяти распространенных ошибок в гибкой методологии. В заключение позвольте мне сказать следующее: не стесняйтесь отвергать любой из приведенных выше советов (и любые другие советы, которые вы получаете), если они не работают для вас, вашей команды, вашего клиента или вашей компании. Agile не является универсальным решением, поэтому не думайте, что вам нужно вмешиваться в те аспекты, которые вам не подходят. Не бойтесь время от времени выбрасывать книгу (вместо того, чтобы выбрасывать полотенце), если это необходимо. Одним из самых популярных направлений Agile является методология Scrum. Получите доступ к нашей платформе EAD и ознакомьтесь с нашим курсом Scrum Specialist .
