Смешанный Agile – Waterfall подход при внедрении бизнес приложений (aka Agile-like)

[rustysm]

Как вы управляете техническим долгом?)

[sleepdger]

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

[UnclShura]

Но это и есть Waterfall! У него тоже итерации и все дела. Все отличие WF от аджайла в сроках и порядке (обязательности) фаз.

[uzverkms]

А Waterfall-то мифический (с)

[sleepdger]

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

[SergeyTitkov]

Waterfall, а что он существует в природе?
Ссылочку можно на описание :)
Эту можно не предлагать: ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D0%BA%D0%B0%D0%B4%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C
Нет там ничего :)

[sleepdger]

На проектах внедрения ERP систем к сожалению существует :) Я лично участвовал в проектах, где команда консультантов совмество с бизнес-пользователями сначала описывали AS-IS, TO-BE, детальные требования по этим процессам. И потом когда этот документ был готов, подрядчик начал разработку и настройку. А после завершения всей разработки и настройки, были 3 фазы бизнес-тестирования. Это в моем понимании и есть стандартный WF. Я описываю WF подход следующими принципами:
1. Не начинаем разработку, пока не подписан с бизнесом документ дизайна (не на отдельную функциональность, а по всем процессам)
2. Не начинаем тестирование, пока не настроены все бизнес-процессы, описанные в документе дизайна.
При этом на принципе#1 обычно настаивает подрядчик, который делает работу, т.к. до начала работы заказчик просит сказать сколько это будет стоить и когда будет сделано.
А на принципе#2 настаивает в свою очередь заказчик, чья команда потратила большое количество времени на этапе дизайна, и хочет вернуться к своим операционным задачам и чтобы их перестали отвлекать на проект.

[DNT_DT]

А ещё давайте представим что мы не внедряем ERP а мигрируем с одной ERP в другую сохраняя все идентификаторы и не перенося баги и недостатки прошлой ERP. Тогда становится больше As is /To be, и от аджайла остаются названия команд и daily stand up

[SergeyTitkov]

И чем это отличается от обычного проектного подхода?

Я поэтому и говорю, что WF — это миф. Обычно WF — обзывают именно проектный подход с выделенными этапами, которые идут последовательно.

[sleepdger]

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

[SergeyTitkov]

А что из треугольника проектоного треугольника у вас не фиксировано?

[sleepdger]

Scope. Но частично, а не полностью, т.к. не чистый Agile подход, а смешанный. Scope гибкий, но в рамках, которые накладываются платформой и темплейтом (SAP)

[SergeyTitkov]

То бишь можно резать?

[sleepdger]

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

[sleepdger]

<>

[vydacha]

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

[sleepdger]

угу. из-за того, что количество комуникации и онсайт присутствия увеличивается, у нас трэвел бюджет составил примерно 10% от всей стоимости проекта

[syseng]

Обозначены некоторые существенные проблемы.

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

[sleepdger]

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

[ValeryGL]

Это не то же самое, что Time-Material, т.к. мы фиксируем длительность и общий объем работ. При этом мы остаемся гибкими в изменении/добавлении бизнес-требований, если длительность проекта и команда не увеличивается.

Извините, но я не вижу отличия от T&M. Вы фиксируете "длительность проекта и объем работ". Другими словами, заказчик получает на 22 недели 40 человек в распоряжение. Какие из самых приоритетных требований успеют реализовать - то и реализуем. Какие изменения согласуем и успеем за эти 22 недели - те и сделаем. На мой взгляд, это T&M, в котором предоплачен пакет в 880 человеко-недель.

Не вижу ничего плохого в этом, просто не пойму, что тут нового. Похоже на ORACLE AIM for BF, где на уровне договора ограничены три итерации обработки болванки перехода от прототипа к готовой системе; все важное и все изменения требований или нужно уложить в эти три спринта, или это было не важное.