В чем ключевое различие между адаптивной моделью жизненного цикла и итеративной/инкрементной моделью?

TL;DR

Вы перепутали некоторые понятия.

Как написал Станислав; есть два подхода .

Предиктивный и адаптивный

В Adaptive вы можете найти как инкрементальные, так и итеративные, которые отличаются друг от друга.

Однако весьма вероятно , что инкрементальные модели встречаются и в прогнозных моделях.

Как это работает?

Инкременты — это предварительно определенные пакеты функций, основанные на предыдущем инкременте. Они спланированы и являются частью более крупной архитектуры.

Мы добавим VISA, затем Mastercard, затем PayPal, затем...

В конечном итоге они делают что-то большее.

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

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

Мы позволим пользователям использовать один тип оплаты, а затем спросим пользователей, какие типы платежей отсутствуют, и проанализируем это в соответствии с исследованиями рынка...

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

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

Широкая разбивка

Инкрементный

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

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

Так.

Инкрементальный подход в программной инженерии такой же. Вы строите раздел за разделом, или компонент за компонентом, или функцию за функцией, пока ваше видение (в основном определенное в начале) не будет завершено.

Итеративный

Адаптивная модель, использующая итеративный подход, рассматривает препятствие и думает,

как мы могли пройти через это?

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

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

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

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

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

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

Другие соображения

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

Исторические рассуждения

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

В 60–80-х годах производственные среды были очень дорогими, и вход в производство стоял в очереди. В свою очередь, это означало, что тестирование было дорогим, а также стояло в очереди.

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

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

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

Штраф за ошибку в современной разработке программного обеспечения намного ниже, поэтому мы можем позволить себе свободу создавать вещи быстро и позволять отзывам пользователей определять, что мы будем делать дальше. Исправляем ли мы A, или улучшаем B, или добавляем C, или делаем D более производительным и т. д.

Тем не менее, все еще есть организации, которые борются с этим (по разным причинам), и Agile Manifesto был попыткой поощрения большей способности быстро реагировать на обратную связь .

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

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

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

Дополнение к самому ценному игроку

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

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

Привет , кажется, вы противопоставляете подходы к моделям.

Есть предиктивные и адаптивные подходы.

Predictive, например, Waterfall и Adaptive, похожи на Agile.

Таким образом, подходы Adaptive SDLC сочетают в себе инкрементную и итеративную разработку.

Здесь вы можете найти больше информации.