Что такое методология Agile?

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

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

Что такое Agile?

Это практика итеративной разработки продукта в короткие циклы, называемые спринтами. Agile основывается на основных принципах:

·        Использует частые релизы, чтобы ускорить изучение того, что работает, а что нет, путем создания программного обеспечения и получения отзывов от клиентов на ранней стадии и часто.

·        Гибкие планы изменений постоянно отражают новую информацию. Команды готовят программное обеспечение каждые 2-4 недели.

·        Использует эмпирический подход для создания правильного продукта, а не для следования плану.

·        Agile больше озабочен адаптивностью и реагированием на изменения, чем поиском "единственного наилучшего способа" что-то сделать.

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

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

Традиционно крупные компании со сложными продуктами (например, Microsoft и их операционная система или Nasa и космическая ракета) не могли запускать свое программное обеспечение по частям, иначе весь продукт не работал бы должным образом. Эти компании должны были поставлять продукты прогнозируемым образом, тщательно планируя все варианты.

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

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

Плюсы Agile

·        Agile может быстро создать рабочий прототип, чтобы сразу же показать отзывы клиентов;

·        Клиенты могут вносить свой вклад на протяжении всего проекта разработки;

·        Поскольку спринты длятся 1-4 недели, проекты могут предоставлять новые функции быстро и часто, а также с высокой степенью предсказуемости;

·        В отличие от Waterfall, который сложнее изменить после составления спецификаций, Agile позволяет команде всегда оптимизировать или переориентировать бэклог продукта;

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

Минусы Agile

·        Если оценки для определенных функций неточны, команде придется добавлять спринты или добавлять функции в последующие спринты, что повлияет на общий срок;

·        Большая ответственность ложится на scrum мастера, который постоянно управляет бэклогом продукта, чтобы убедиться, что спринты завершены вовремя;

·        Более крупным командам может быть сложнее использовать Agile;

Популярные гибкие методологии

1. Scrum

Scrum - это популярная методология, используемая многими стартапами, которую можно разбить на 4 основных компонента:

·        Планирование спринта

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

·        Спринт

У каждого могут быть разные периоды времени спринта, хотя общий цикл спринта составляет 2 недели (выпуск продукта / новое обновление отправляется пользователям в реальном времени в конце цикла спринта). В реальном спринте членам команды будут назначены задачи на спринт для работы, и все, что не будет завершено вовремя для выпуска, будет считаться "пропущенным" и получит повторный приоритет для будущего спринта или, возможно, с пониженным приоритетом.

·        Stand-up встречи

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

·    Ретроспектива — это, как правило, собрание, которое происходит в конце вашего цикла спринта, на котором вы анализируете, что произошло во время последнего спринта. Ваша команда может обсудить пункты повестки дня, например, что прошло хорошо, что не прошло хорошо, что можно улучшить, а также любые вопросы / опасения по поводу всего процесса. PM может быть тем, кто берет на себя инициативу задавать эти вопросы, собирать отзывы и выяснять, как улучшить процесс спринта. 

2. Kanban

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

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

В Kanban обычно есть доска с 3 столбцами: "Сделать", "Выполняется" и "Сделано". Столбец "Сделать" будет представлять собой список невыполненных работ по продукту с приоритетом, в котором члены команды могут выбирать элементы из верхней части списка для работы. После завершения работы с тикетом член команды просто выбирает следующий тикет для работы из верхней части списка. Также могут быть определенные ограничения, применяемые командой, например, иметь только определенное количество элементов в каждом столбце в данный момент времени.

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

3. Экстремальное программирование (XP)

Экстремальное программирование — это методология, направленная на создание программного обеспечения чрезвычайно высокого качества, которое может развиваться и меняться по мере появления новых идей. Agile и Agile-подобные методологии — это просто современные итерации XP, которая была создана в конце 90-х.

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

4. Адаптивная разработка программного обеспечения (ASD)

Адаптивная разработка программного обеспечения (ASD) — это методология, которая была популяризирована Microsoft еще в 90-х годах, которая в основном объединяет Agile и Waterfall в один процесс.

В гибриде гибкого водопада, таком как ASD, все еще существуют спринты, в которых принципы Agile применяются к продолжительности цикла выпуска. Гибкое планирование все еще происходит в начале, чтобы убедиться, что соблюдаются как Agile, так и Waterfall принципы. После гибкого планирования команда разработчиков выполняет каскадные методологии для внедрения. В конце спринта (Agile) будет поставлен этапный продукт (Waterfall). Специалисты этой области говорят, что сочетание Agile с Waterfall приводит к получению конечного продукта, который можно отправлять быстрее без ущерба для качества. Специалисты по Agile также говорят, что Agile может помочь уменьшить количество отходов, возникающих в каскадных методологиях, потому что эти методологии основаны на оценках, которые не всегда могут быть точными.

5. Динамический метод разработки программного обеспечения (DSDM)

Динамический метод разработки программного обеспечения (DSDM) является аналогом гибкой модели водопада. DSDM — это метод, в котором Agile управление проектами и Agile программирование используются вместе в одной общей методологии.

DSDM обычно состоит из планирования по Agile, программирования по Agile, разработки по Agile и Agile поддержки (для управления проектами).

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

6. Разработка, основанная на функциях (FDD)

Разработка, основанная на функциях (FDD), является ближайшим родственником Agile, который существует за пределами Agile. FDD и Agile — это не одно и то же, но Agile заимствует из нее многое. Специалисты по Agile говорят, что Agile — это расширение FDD, а не замена.

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

7. Разработка, ориентированная на поведение (BDD)

Поведенческая разработка (BDD) - двоюродный брат Agile. Управление проектами и программирование являются гибкими благодаря BDD. Agile разработка — это гибкость благодаря BDD. Agile поддержка гобкая благодаря BDD. Специалисты говорят, что Agile не является Agile без гибкого управления проектами или гибкого программирования в ИТ, и, следовательно, Agile не может существовать без BDD.

Как выбрать правильную гибкую методологию для вас?

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

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

Материал был отобран, переведен и отредактирован командой ProductCamp. Источник