Гибкие методологии разработки по: Kanban/Agile/Scrum/Lean — гибкие методологии разработки — Карина Горбунова на vc.ru

Что такое Agile? Основные принципы и методы методологии гибкой разработки

Agile

В чем суть подхода и зачем он нужен бизнесу

Дарья Литвинова

15 мар. 2023 г. • 5 min read

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

Что такое Agile

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

Agile (от англ. «гибкий») — семейство методологий для улучшения производимого продукта. Философию Agile характеризуют гибкость, скорость и прозрачность рабочих процессов.

Как правило, для Agile-команды характерна работа небольшими порциями — итерациями на 2-3 недели. Внутри каждой итерации собрано несколько задач для реализации продукта:

• анализ,
• проектирование,
• работа,
• тестирование,
• запуск продукта.

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

Как появился Agile-метод

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

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

• Сложно реагировать на изменения рынка, ведь заранее предугадать проблемы невозможно, а менять план нельзя.
• Проект может растянуться. Из-за зависимости каждого этапа друг от друга в этом случае семеро одного ждут.
• Легко опоздать. Например, к концу проекта можно узнать, что продукт не решает проблему клиента или вообще не работает. А тестирование — самый последний этап каскадного метода разработки программного обеспечения.

Разработчики просто устали от излишней строгости и поняли, что создавать инновационные технологии по старым методологиям просто нельзя. В качестве альтернативы в 2001 и появилась Agile-концепция. В американском штате Юта 17 разработчиков со всего света собрались и подписали манифест об основных принципах Agile.

Ценности и принципы Agile

Манифест о гибких методологиях разработки находится в открытом доступе. На странице вы не найдете упоминания каких-либо программ или сайтов для работы. Но на сайте отображены именно основные принципы Agile-методологии. Возможно некоторые из них покажутся вам очевидными, но поверьте — в начале бюрократических 2000-х Agile-модель стала практически инновационной.

Всего принципов 12:

1. Главная задача продукта — удовлетворить клиента.
2. Изменять процесс разработки в ходе работы — хорошо.
3. Рабочее ПО нужно доставлять клиенту часто, в рамках 2-16 недель.
4. Руководители и разработчики трудятся вместе на протяжении всего процесса.
5. Над проектом работают заинтересованные, мотивированные сотрудники с комфортными условиями для работы.
6. Лучший способ передать информацию — личная встреча.
7. Главный показатель успешности проекта — работающий продукт, а не трудозатраты и другие показатели.
8. Гибкие методологии разработки помогают постоянному развитию, поддержанию рабочего темпа как на спринтерской, так и на марафонской дистанции.
9. Нужно уделять внимание технической стороне и качественному дизайну продукта.
10. Важно сокращать до минимума лишнюю работу и не усложнять.
11. Самые лучшие команды — самоорганизованные.
12. Сотрудники должны регулярно оценивать проделанную работу и улучшать, корректировать ее для большей эффективности.

Agile-разработка: плюсы и минусы

Начнем с плюсов:

➕ Гибкость и открытость к любым изменениям. Команда может оперативно вносить изменения в проект, дорабатывать продукт по комментариям заказчика и реагировать на изменения рынка.

➕ Небольшие риски потерпеть неудачу. В каждом цикле работы присутствует тестирование, аналитика и общение с заказчиком. Так можно быстрее выявить проблему и исправить ее, не перебирая этап за этапом, как в каскадном подходе.

➕ Устойчивость к срыву дедлайнов. В аджайл-подходе выставляются гибкие сроки с запасом на задержки и изменения.

➕ Вовлеченность команды. Тесное общение с руководством, коллегами и самоорганизация помогают работать эффективнее и чувствовать свое влияние на проект.

➕ Минимум рутинной работы. Разработчикам не нужно тратить огромное время на аналитику, планирование и заполнение отчетов. Главное — работа над продуктом.

Из минусов:

➖ Проект непредсказуем. В конце ожидания могут совсем не совпасть с реальностью. Возможно, это станет минусом для заказчиков с четким ТЗ.

➖ Потребность в тесном взаимодействии. Команде нужно постоянно общаться с заказчиком, чтобы отслеживать промежуточные результаты и вовремя обновлять продукт.

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

➖ Непростое внедрение системы Agile. Если компания уже работает по другой методологии, перестроиться на Agile-подход будет сложно. Скорее всего потребуется специалист, который хорошо разбирается в гибких методологиях. А на это нужно заложить и время, и бюджет.

Где используют гибкие методологии разработки

Если говорить о сферах бизнеса, то изначально Agile применялся разработчиками для создания нового программного обеспечения, интерфейсов и игр.

На сегодняшний день Agile — стандарт для большинства современных проектов. Сейчас его могут использовать абсолютно все: от гигантов IT-индустрии, как Google и Microsoft, до небольших стартапов.

В каком случае применять Agile

Вам стоит попробовать Agile, если:

1. Команда теряется в потоке задач: не понимает, как распределять задачи, кто за что отвечает и на каком этапе работы они находится.
2. Вы ограничены по времени. К примеру, вам нужно выпустить новый более востребованный и полезный пользователям продукт раньше, чем конкуренты. С помощью Agile можно минимизировать время на реализацию продукта и исправление ошибок, появляющихся в ходе работы.
3. Результат проекта неизвестен заранее: например, вы что‑то изобретаете или запускаете инновационный стартап. Agile позволит проложить оптимальный путь к работоспособному продукту, несмотря на меняющуюся в процессе работы цель.

Вам не нужно использовать Agile, если:

1. Нужен четкий и неизменный результат проекта строго по ТЗ. Например, если вы работаете в сфере с жесткими регулятивными нормами или заранее известными требованиями к проекту.
2. Проект предполагает многократное повторение полученного результата. Методология Agile не очень хорошо подходит для повторного воспроизведения. Переводя на жизненные примеры, если вам нужно построить 5 одинаковых домов, то с Agile вы получите 5 уникальных домов, каждый из которых будет отвечать на запросы разных клиентов.
3. Agile-проект требует постоянного контактирования с заинтересованными лицами. У заказчиков может просто не быть времени, возможности или желания использовать Agile-менеджмент.

Методы управления проектами по Agile

В семейство Agile входит несколько разных методов управления проектов — фреймворков. В СНГ наибольшей популярностью пользуются два — Scrum и Kanban.

• Kanban — это метод управления рабочим процессом, основанный на визуализации цели, задач и прогресса. В основе инструмента — канбан-доска.
• Scrum — метод деления работы на итерации (временные отрезки) для достижения цели. Цель — получить функциональный результат.

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

Как внедрить Agile в проект

Самое главное — это разделять философию Agile. Попробуйте начать с «пилотной группы» и рассказать о подходе небольшой команде. Крайне важно, чтобы сотрудники добровольно согласились использовать новый метод в работе. После дайте коллегам время. Если в течение 6-8 месяцев всё хорошо — можно постепенно масштабировать Agile во всей компании. О том, как подготовить сотрудников к переменам мы рассказали здесь.

Чтобы проекты выполнялись в срок и без ошибок, нужны и специальные инструменты управления: планировщики задач, календари, командные доски. Одним из таких сервисов и является Kaiten — визуальная система управления рабочими процессами.

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

Kaiten — гибкий инструмент для управляемых и прогнозируемых процессов с Agile-блоком в коробке

Попробовать бесплатно

Гибкая методология разработки / wiki ТопЭксперт

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

Экстремальное программирование

Одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Основные приёмы XP

• Короткий цикл обратной связи (Fine-scale feedback)
  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game)
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming)
• Непрерывный, а не пакетный процесс
  • Непрерывная интеграция (Continuous integration)
  • Рефакторинг (Design improvement, Refactoring)
  • Частые небольшие релизы (Small releases)
• Понимание, разделяемое всеми
  • Простота (Simple design)
  • Метафора системы (System metaphor)
  • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
  • Стандарт кодирования (Coding standard or Coding conventions)
• Социальная защищённость программиста (Programmer welfare):
  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

DSDM

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) — это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений[источник не указан 635 дней].

Принципы

Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

• Вовлечение пользователя — это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
• Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
• Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше — это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
• Главный критерий — как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
• Разработка — итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
• Любые изменения во время разработки — обратимы.
• Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
• Тестирование интегрировано в жизненный цикл разработки.
• Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

Scrum

Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

FDD

Feature driven development (FDD, функционально-ориентированная разработка) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.

Что такое гибкая разработка программного обеспечения (гибкие методологии)?

Качество программного обеспечения

К

• Кейт Браш
• Валери Сильверторн

Что такое гибкая разработка программного обеспечения?

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

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

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

Четыре ценности Agile

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

Четыре основные ценности, изложенные в Agile Manifesto, следующие:

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

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

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

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

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

12 принципов Agile

Манифест Agile также содержит 12 основных принципов процесса разработки. Они следующие:

1. Удовлетворение потребностей клиентов за счет раннего и непрерывного выполнения ценной работы.
2. Разбейте большую работу на более мелкие задачи, которые можно выполнить быстро.
3. Признайте, что лучшая работа получается у самоорганизованных команд.
4. Обеспечьте мотивированных людей средой и поддержкой, в которых они нуждаются, и доверьте им выполнение работы.
5. Создание процессов, способствующих устойчивым усилиям.
6. Поддерживайте постоянный темп выполнения работы.
7. Приветствуйте изменение требований даже на поздних стадиях проекта.
8. Ежедневно собирайте команду проекта и владельцев бизнеса на протяжении всего проекта.
9. Попросите команду через регулярные промежутки времени подумать о том, как стать более эффективными, а затем соответствующим образом настроить и скорректировать поведение.
10. Измеряйте прогресс по объему выполненной работы.
11. Постоянно стремитесь к совершенству.
12. Смена снаряжения для конкурентного преимущества.

Принципы и ценности гибкой разработки

Цикл разработки программного обеспечения Agile

Цикл гибкой разработки программного обеспечения можно разбить на следующие шесть шагов:

• концепция
• начало
• итерация/конструкция
• выпуск
• производство
• выход на пенсию

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

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

Визуализация цикла разработки программного обеспечения Agile

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

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

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

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

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

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

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

Типы методологий Agile

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

• Скрам
• Бережливая разработка программного обеспечения
• Экстремальное программирование
• Кристалл
• Канбан
• Метод разработки динамических систем
• Разработка, ориентированная на функции

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

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

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

• Повышение уровня обучения
• Расширение возможностей команды
• Воспитание честности
• Удаление отходов
• Понимание всего
• Принимать решения как можно позже
• Доставка товара как можно быстрее

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

Метод экстремального программирования (XP) — это дисциплинированный подход, ориентированный на скорость и непрерывную доставку. Это способствует более активному участию клиентов, быстрой обратной связи, непрерывному планированию и тестированию, а также тесной командной работе. Программное обеспечение доставляется с частыми интервалами — обычно раз в одну-три недели. Цель состоит в том, чтобы улучшить качество программного обеспечения и скорость отклика при столкновении с изменяющимися требованиями клиентов.

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

Crystal  — это наиболее легкая и адаптируемая методология. Он фокусируется на людях и взаимодействиях, которые происходят во время работы над Agile-проектом, а также на бизнес-критичности и приоритете разрабатываемой системы. Метод «Кристалл» основан на осознании того, что каждый проект обладает уникальными характеристиками, которые требуют слегка адаптированного набора политик, практик и процессов. В результате он состоит из набора моделей процессов Agile, таких как Crystal Orange, Crystal Clear и Crystal Yellow. Каждая модель имеет свои уникальные характеристики, которые определяются различными факторами, включая приоритеты проекта, размер команды и критичность системы.

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

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

Канбан использует три основных принципа: визуализировать рабочий процесс; ограничить объем незавершенной работы; и улучшить рабочий процесс. Как и Scrum, метод Kanban призван помочь командам более эффективно работать друг с другом. Он поощряет постоянное сотрудничество и пытается определить наилучший возможный рабочий процесс, чтобы создать среду с активным и постоянным обучением и совершенствованием.

Метод разработки динамических систем (DSDM) является ответом на потребность в общей отраслевой структуре для быстрой доставки программного обеспечения. DSDM основан на восьми ключевых принципах; несоблюдение любого из принципов создает риск для успешного завершения проекта. Восемь принципов таковы:

1. Сотрудничество
2. Своевременная доставка
3. Продемонстрированный контроль
4. Непрерывная четкая связь
5. Постоянное внимание к потребностям бизнеса
6. Итеративная разработка
7. Создание в приращениях от твердых основ
8. Отказ от компромисса качества

В DSDM доработка встроена в процесс, и все изменения должны быть обратимыми. Системные требования имеют приоритет в соответствии с Правилами MoSCoW, которые ранжируют приоритет следующим образом:

• М — должен быть
• S — должно быть
• C — мог бы, но не критично
• W — сейчас не будет, но может быть позже

В DSDM важно, чтобы не каждое требование считалось критическим. Каждая итерация должна включать менее важные элементы, которые можно удалить, чтобы не повлиять на требования с более высоким приоритетом.

Наконец, разработка на основе функций (FDD) сочетает в себе лучшие практики разработки программного обеспечения, такие как разработка по функциям, владение кодом и моделирование объектов предметной области, для создания согласованного, управляемого моделями процесса с короткими итерациями. FFD начинается с определения общей формы модели, которая, в свою очередь, создает список функций. Затем метод переходит к итерациям, которые длятся две недели и фокусируются на планировании по функциям, проектировании по функциям и построении по функциям. Если создание функции занимает более двух недель, ее следует разбить на более мелкие функции. Основное преимущество FDD заключается в том, что его можно масштабировать — даже для больших команд, — поскольку в нем используется концепция «первоначально достаточно дизайна» или JEDI.

Преимущества и недостатки Agile

За прошедшие годы многие подходы Agile и Waterfall сравнивали друг с другом.

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

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

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

С другой стороны, многие скажут, что самым большим недостатком Agile является тот факт, что многие организации модифицировали его — некоторые сказали бы, разбавили. Это явление настолько широко распространено, что практикующие «Agile по-моему» известны как «ScrumButs», например: «Мы используем Scrum в нашей организации, но…».

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

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

Примечание редактора: Эта статья была написана Кейт Браш и Валери Сильверторн в 2019 году. Редакторы TechTarget переработали ее в 2022 году, чтобы сделать ее более удобной для читателей.

Последнее обновление: ноябрь 2022 г.

Продолжить чтение об Agile-разработке программного обеспечения

• Часто задаваемые вопросы по Agile: начало работы с основами Agile

• Быть Agile и работать Agile: в чем разница?

• Agile и DevOps: в чем разница?

• Узнайте о распространенных типах Agile-команд

• Гибкость в масштабе

Углубитесь в методологии Agile, DevOps и разработки программного обеспечения

• Гибкое управление проектами (APM)

  Автор: Александр Гиллис

• Дисциплинированная гибкая поставка (DAD)

  Автор: Бен Луткевич

• Тщательно взвесьте эти плюсы и минусы DevOps

  Автор: Стивен Бигелоу

• повторяющийся

  Автор: Рахул Авати

Облачные вычисления

• Преимущества и ограничения Google Cloud Recommender

  Расходы на облако могут выйти из-под контроля, но такие службы, как Google Cloud Recommender, предоставляют информацию для оптимизации ваших рабочих нагрузок. Но…

• Zadara выбирает нового генерального директора, поскольку основатель переходит на роль технического директора

  Йорам Новик, второй генеральный директор облачного стартапа Zadara, привносит в эту должность многолетний опыт руководства ИТ и рассказывает о …

• Как работает маршрутизация на основе задержки в Amazon Route 53

  Если вы рассматриваете Amazon Route 53 как способ уменьшить задержку, вот как работает этот сервис.

Архитектура приложения

• Краткий обзор языка программирования Carbon

  Carbon — это экспериментальный язык программирования, созданный на базе C++, но с новым взглядом на безопасность памяти,…

• Прочная связь между законом Конвея и микросервисами

  Хотя закону Конвея уже несколько десятков лет, некоторые утверждают, что спешка индустрии по внедрению микросервисов заставляет его принимать . ..

• Как выжить, когда царит развитие Waterfall

  Несмотря ни на что, методология Waterfall поддерживает бесчисленное количество команд разработчиков программного обеспечения. …

ITОперации

• Сервисная сетка eBPF без Sidecarless вызвала споры

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

• Новости KubeCon + CloudNativeCon 2023

  Пытаетесь быть в курсе последних новостей с KubeCon + CloudNativeCon? Используйте это подробное руководство, чтобы оставаться в курсе последних событий…

• Настройте конвейер машинного обучения в этом руководстве по Kubeflow.

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

TheServerSide.com

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

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

• JavaScript против TypeScript: в чем разница?

  TypeScript и JavaScript — две дополняющие друг друга технологии, которые стимулируют разработку как интерфейсных, так и серверных приложений. Вот…

• Как применить принцип единой ответственности в Java

  Как модель единой ответственности работает в программе на Java? Здесь мы покажем вам, что означает этот принцип SOLID, и как …

ПоискAWS

• AWS Control Tower стремится упростить управление несколькими учетными записями

  Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Сервис автоматизирует…

• Разбираем модель ценообразования Amazon EKS

  В модели ценообразования Amazon EKS есть несколько важных переменных. Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу…

• Сравните EKS и самоуправляемый Kubernetes на AWS

  Пользователи AWS сталкиваются с выбором при развертывании Kubernetes: запускать его самостоятельно на EC2 или позволить Amazon выполнять тяжелую работу с помощью EKS. См…

404: Страница не найдена

Качество программного обеспечения

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

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

• Узнайте последние новости.
• Наша домашняя страница содержит последнюю информацию о качестве программного обеспечения.
• Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, «Качество программного обеспечения».
• Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Облачные вычисления

• Преимущества и ограничения Google Cloud Recommender

  Расходы на облако могут выйти из-под контроля, но такие службы, как Google Cloud Recommender, предоставляют информацию для оптимизации ваших рабочих нагрузок. Но…

• Zadara выбирает нового генерального директора, поскольку основатель переходит на роль технического директора

  Йорам Новик, второй генеральный директор облачного стартапа Zadara, привносит в эту должность многолетний опыт руководства ИТ и рассказывает о …

• Как работает маршрутизация на основе задержки в Amazon Route 53

  Если вы рассматриваете Amazon Route 53 как способ уменьшить задержку, вот как работает этот сервис.

Архитектура приложения

• Краткий обзор языка программирования Carbon

  Carbon — это экспериментальный язык программирования, созданный на базе C++, но с новым взглядом на безопасность памяти,…

• Прочная связь между законом Конвея и микросервисами

  Хотя закону Конвея уже несколько десятков лет, некоторые утверждают, что спешка индустрии по внедрению микросервисов заставляет его принимать …

• Как выжить, когда царит развитие Waterfall

  Несмотря ни на что, методология Waterfall поддерживает бесчисленное количество команд разработчиков программного обеспечения. …

ITОперации

• Сервисная сетка eBPF без Sidecarless вызвала споры

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

• Новости KubeCon + CloudNativeCon 2023

  Пытаетесь быть в курсе последних новостей с KubeCon + CloudNativeCon? Используйте это подробное руководство, чтобы оставаться в курсе последних событий…

• Настройте конвейер машинного обучения в этом руководстве по Kubeflow.

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

TheServerSide.com

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

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

• JavaScript против TypeScript: в чем разница?

  TypeScript и JavaScript — две дополняющие друг друга технологии, которые стимулируют разработку как интерфейсных, так и серверных приложений. Вот…

• Как применить принцип единой ответственности в Java

  Как модель единой ответственности работает в программе на Java? Здесь мы покажем вам, что означает этот принцип SOLID, и как …

ПоискAWS

• AWS Control Tower стремится упростить управление несколькими учетными записями

  Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Сервис автоматизирует…

• Разбираем модель ценообразования Amazon EKS

  В модели ценообразования Amazon EKS есть несколько важных переменных. Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу…

• Сравните EKS и самоуправляемый Kubernetes на AWS

  Пользователи AWS сталкиваются с выбором при развертывании Kubernetes: запускать его самостоятельно на EC2 или позволить Amazon выполнять тяжелую работу с помощью EKS.

  No related posts.