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