Шаги и этапы методологии Agile: полное объяснение [2022]
Опубликовано: 2021-01-04Предположим, Google не обновлял свои приложения регулярно. Что делать, если ваша любимая мобильная игра не получала обновлений? Что, если бы вам пришлось ждать месяцы или даже годы, чтобы получить новую версию приложения?
Это было бы довольно раздражающим и разочаровывающим. Однако благодаря Agile-методологии разработки программного обеспечения компании выпускают регулярные обновления, устраняют ошибки в своих приложениях и радуют вас, пользователей.
Вы можете задаться вопросом: «Что такое гибкая методология?». Мы объясним это подробно в этом руководстве. Итак, приступим.
Оглавление
Что такое гибкая методология — объяснение
Как следует из названия, гибкая методология фокусируется на частом выпуске продуктов и адаптации к изменениям. Согласно Оксфордскому словарю, термин «ловкость» относится к способности двигаться быстро или стремительно. Методология Agile стала довольно популярной в последние несколько лет из-за ее эффективности и ориентированности на результат.
Это философия управления проектами, которая фокусируется на такой разработке программного обеспечения, которая опирается на обратную связь и постепенные изменения. То, как вы понимаете окружающую вас среду и с какими неопределенностями вы сталкиваетесь, — это неотъемлемые части этого подхода.
Agile-разработка фокусируется на команде, а не на продукте. Решения в этом подходе зависят от совместной работы вашей команды и кросс-функций. Agile-команда — это самоорганизующаяся команда.
Это не означает, что менеджеры не важны для гибкой разработки. Менеджеры несут ответственность за то, чтобы каждый член команды обладал необходимыми навыками. Они несут ответственность за создание благоприятных условий для участников, чтобы они могли добиться успеха в своей работе.
Читайте: Вопросы для интервью по Agile-методологии
История гибкой разработки
До того, как Agile-разработка стала популярной, самым популярным был метод Waterfall. Методология Waterfall была распространена до нескольких десятилетий. Но поколение разработчиков программного обеспечения в конце 90-х было недовольно этой методологией. Они хотели более гибкого подхода.
Подход Waterfall является жестким, а методология Agile — гибкой. В 2001 году 17 разработчиков программного обеспечения создали Манифест Agile. Они хотели разработать альтернативу тяжеловесным, управляемым документами процессам разработки программного обеспечения. Четыре фундаментальные ценности гибкой разработки заключаются в следующем:
- Вы должны отдавать предпочтение людям и их взаимодействиям, а не инструментам и процессам.
- Вы должны отдавать предпочтение рабочему программному обеспечению, а не подробной документации.
- Вы должны отдавать предпочтение сотрудничеству с клиентами над заключением контрактов.
- Вы должны отдавать предпочтение своей способности быстро реагировать на изменения, а не способности придерживаться плана.
Это не означает, что вы должны игнорировать документацию и сроки. Это означает, что вы должны больше сосредоточиться на итерации, прототипах, людях и совместной работе.
Гибкое мышление
По сути, Agile — это образ мышления. Создатели Agile Manifesto изложили 12 принципов Agile-разработки программного обеспечения, чтобы лучше объяснить его:
- Удовлетворение ваших клиентов за счет непрерывной и ранней доставки продуктов должно быть вашим главным приоритетом.
- Если требования вашего проекта изменятся даже на более поздних стадиях разработки, вы должны их приветствовать.
- Вы должны поставлять работающий продукт (программное обеспечение) часто, независимо от того, запускаете ли вы его через несколько недель или месяцев.
- Ежедневное сотрудничество между заинтересованными сторонами проекта и разработчиками является обязательным.
- Ваш проект должен строиться вокруг мотивированных людей. Вы должны предоставить им среду и поддержку, в которых они нуждаются, и вы должны доверять им, что они выполнят свою работу.
- Беседа лицом к лицу — это наиболее эффективный и действенный метод передачи информации вашей команде разработчиков и внутри нее.
- Работающий продукт (программное обеспечение) — критическая мера вашего прогресса.
- Вы должны способствовать устойчивому развитию. Ваша команда, заинтересованные стороны, пользователи и разработчики должны иметь возможность поддерживать постоянный поток без помех.
- Вы должны уделять постоянное внимание техническому совершенству, а хороший дизайн повышает маневренность.
- Сохранение процессов простыми, например, сокращение работы, которую вам нужно выполнить, жизненно важно.
- Самоорганизующиеся команды создают лучшие проекты, требования и архитектуры.
- Ваша команда должна подумать о том, чтобы стать более активной, а затем соответствующим образом скорректировать свое поведение.
Вы заметите, что основные принципы Agile-разработки больше всего сосредоточены на удовлетворенности пользователей. От частого выпуска работающего продукта до хорошего дизайна — все фундаментальные ценности этого подхода сосредоточены на том, чтобы пользователи были довольны.
Читайте: DevOps против Agile
И это правда. Ваши пользователи (или клиенты) не заботятся о вашей документации по программному обеспечению или о ваших будущих стратегиях. Они заботятся о том, как скоро они получат продукт, как быстро они получат исправления ошибок и какую ценность для них принесут продукты.
Различия между Agile и Waterfall
Итак, вы знаете, что до появления Agile-разработки модель Waterfall была самой популярной. Модель Waterfall утратила свою популярность, но это не значит, что она устарела. Многие команды до сих пор используют этот метод. Между этими двумя подходами есть много различий, которые делают их отличными друг от друга.
- Гибкая модель фокусируется на итеративном и поэтапном подходе к разработке программного обеспечения, тогда как в модели Waterfall разработка программного обеспечения происходит последовательно от начала до конца.
- Вам придется разбить agile-проект на отдельные модели. Но вам не нужно будет делать это в подходе Waterfall.
- Благодаря гибкому подходу ваши клиенты получают ранний и частый доступ к вашему рабочему продукту. Они могут предоставить вам соответствующую обратную связь и позволить вам изменить свой план будущей работы. С другой стороны, ваши клиенты получат доступ к продукту только после его завершения, если вы будете следовать подходу Waterfall.
- Гибкая модель неструктурирована, тогда как модель Waterfall структурирована, поэтому многие считают ее более безопасной.
- Гибкая разработка отлично подходит для небольших проектов, поскольку вы можете быстро их завершить. Метод водопада отлично подходит для крупных проектов, потому что вы можете сделать более точные оценки и соответствующим образом завершить план.
- В Agile-разработке меньше планирования по сравнению с Waterfall-разработкой.
- Вы выполняете процесс разработки итерациями по несколько недель, если придерживаетесь гибкого подхода. С другой стороны, при использовании каскадного подхода вы будете выполнять процесс разработки поэтапно, а этап больше, чем итерация.
- При гибком подходе вы можете исправлять ошибки в середине процесса, поскольку вы часто получаете обратную связь. Используя водопадный подход, вы будете тестировать конечный продукт в конце и никогда раньше. Если вы обнаружите ошибку в конечном продукте, вам придется перезапустить проект с самого начала.
- Документация имеет меньший приоритет в гибкой разработке по сравнению с разработкой Waterfall. На самом деле, в последнем случае вы можете использовать документацию и для обучения своего персонала.
- Как только итерация заканчивается в гибкой разработке, вы отправляете поставляемые функции напрямую своим клиентам. Клиенты могут использовать эти функции сразу после их получения. В водопадном подходе вы отправляете все функции вашего продукта вместе, когда заканчиваете проект после фазы.
- В гибком подходе тестировщики и разработчики сотрудничают, а в подходе Waterfall — нет.
- В Agile вы бы выполняли принятие пользователями в конце каждого спринта. В методе Waterfall вы должны выполнить принятие пользователем в конце вашего проекта.
- Гибкая разработка требует от разработчиков тесного и регулярного общения для планирования и анализа. В разработке Waterfall разработчики не принимают участия в процессе планирования и занимаются только этапом кодирования.
Шаги Agile-методологии
Гибкие методологии бывают разных видов. Мы кратко обсудим наиболее известные из них. Вы можете ссылаться на методологию как на определенный набор соглашений, которым хочет следовать ваша команда. У разных команд могут быть разные методологии. Гибкие методологии — это те, которые следуют основным ценностям и принципам гибкой разработки, которые мы обсуждали ранее. Существуют следующие методологии Agile:
- Скрам
- Канбан
- DSDM (метод динамической разработки программного обеспечения)
- Кристаллические методологии
- FDD (Разработка, управляемая функциями)
- XP (экстремальное программирование)
Давайте обсудим основные из них ниже:
Методология 1: SCRUM
SCRUM — это структура, направленная на расширение возможностей команд для совместной работы. Это эвристика. Основное внимание уделяется адаптации к факторам, которые колеблются, и непрерывному обучению. Он понимает, что команда не обязательно знает все в начале задачи. Scrum основан на стратегиях команд регби.
Он фокусируется на улучшении сотрудничества в команде, разделяя ее на более мелкие, как это делает команда по регби. Видите ли, в команде по регби есть разные группы игроков, у которых есть определенные обязанности. В Scrum ваша команда также делится на более мелкие группы.
В Scrum есть три основных артефакта: инкремент, бэклог спринта и бэклог продукта. Давайте кратко обсудим каждый из них, чтобы лучше понять Scrum:
Резерв продукта
Бэклог продукта относится к основному списку задач, которые должна выполнить ваша команда. Ответственность за ведение этого списка возлагается на менеджера по продукту или владельца продукта. Это список дел группы, так как он содержит требования, исправления, улучшения и функции, которые являются входными данными для следующего артефакта — невыполненной работы спринта.
Бэклог спринта
Этот артефакт содержит список исправлений ошибок и элементов, выбранных вашими командами разработчиков для определенного цикла спринта. Тем не менее, бэклог спринта довольно гибкий, и у вас есть возможность изменить его во время спринта, если это необходимо.
Увеличение
Другое название приращения — цель спринта. Это относится к конечному продукту, который вы получаете от спринта. Цель спринта — это конечный результат вашей команды разработчиков. И вы можете сказать, что достигли этой цели, только когда завершили весь процесс.
Предположим, вашей команде нужно опубликовать приложение в Play Store. В этом случае вы можете сказать, что достигли цели спринта, когда нажмете кнопку публикации.
Как мы упоминали ранее, Scrum делит вашу команду на более мелкие сегменты. Первым сегментом будет Scrum Master, который отвечает за завершение настройки команды и управление собраниями спринта. Второй — это Владелец Продукта, который должен создавать бэклог продукта и следить за доставкой в конце каждой итерации.
Последней является Скрам-команда, которая работает по спринтерскому циклу.
Методология 2: Канбан
Канбан фокусируется на разработке программного обеспечения в рамках одного длительного цикла. Он сильно отличается от SCRUM, гибкого метода, который мы обсуждали ранее. В процессах Канбан вы должны использовать карточки, которые проходят через весь процесс. Канбан является инкрементным, но не итеративным. Поскольку у проекта Канбан нет итераций, у него нет конкретных точек начала и окончания.
Его проекты имеют ограничения «Работа в процессе». Они помогают вашей команде сосредоточиться на небольшом сегменте задачи за раз. Вы бы добавили новые функции в цикл только после того, как завершили предыдущую. Канбан представляет различные этапы процесса создания через несколько этапов жизненного цикла разработки программного обеспечения. Вы представляете функции с помощью карт Канбан и управляете их потоком таким образом, чтобы количество введенных функций было таким же, как количество выполненных функций.
Методология 3: Разработка, управляемая функциями (FDD)
Feature Driven Development фокусируется на создании и проектировании функций. В FDD ваша команда будет работать короткими этапами, которые очень специфичны и сосредоточены на работе над элементом. Проверка дизайна, просмотр домена, проверка кода и продвижение сборки — вот некоторые примеры того же. Проще говоря, FDD фокусируется на разработке конкретных функций.
Вам придется работать над владением компонентами, моделированием объектов предметной области, регулярными сборками, проверками и специализированными группами. Вы должны поддерживать надлежащую видимость результатов и текущего прогресса проекта.
Методология 4: Бережливое развитие
Методология итеративной разработки Agile соответствует принципам бережливой разработки программного обеспечения. Бережливое производство направлено на сокращение объема работы в процессе для управления потоком. Это помогает увеличить скорость доставки. Бережливые команды функционируют как системы «точно вовремя». Это означает, что им приходится ждать до последнего необходимого момента для принятия решений.
Бережливое производство фокусируется на удалении отходов. А согласно принципам бережливого производства все, за что заказчик не будет платить, — пустая трата. Он также фокусируется на автоматизации процессов, которые являются повторяемыми и очень подвержены человеческим ошибкам.
Получите курс по разработке программного обеспечения в лучших университетах мира. Участвуйте в программах Executive PG, Advanced Certificate Programs или Master Programs, чтобы ускорить свою карьеру.
Последние мысли
Гибкая методология — обширная тема. Вы видите, насколько это сложно. Его влияние на современное общество видно повсюду.
В целом практики/методы Agile помогают создавать среды, в которых требования постоянно развиваются и меняются. Благодаря дисциплинированному подходу к управлению проектами методология Agile продвигает и продвигает поставку высококачественного программного обеспечения, соответствующего потребностям клиентов. Узнайте больше об Agile-разработке программного обеспечения, ознакомьтесь с программой upGrad Executive PG в курсе Full Stack Software Development.
