В общем, кажется, что подход Make it work, make it right, make it fast должен хорошо сработать в качестве метода программирования. Есть ощущение, что применять этот принцип можно на любом уровне работы над функциональностью, начиная с эпика и заканчивая отдельным методом в коде.
Make it work - функциональные требования
Как понять, что функциональность реализована?
- Уровень пользовательской истории
- Приемочные автоматизированные тесты или зафиксированные тестовые сценарии.
- Этот этап может использоваться для дальнейшего разделения истории на более мелкие (например, выделить реализацию с заглушками, а интеграцию перенести на второй этап - make it right). Но это необязательно.
- Уровень приложения
- Интеграционные тесты, использующие заглушки всех внешних по отношению к приложению сервисов и источников данных
- Уровень компонентов / классов
- Классические юнит-тесты
В целом, следует стремиться к Shameless Green-коду, то есть, удовлетворить все функциональные требования не обращая внимания на качество кода. Главное, чтобы вся реализованная функциональность была покрыта автоматическими тестами, что обеспечит безопасный рефакторинг на следующем этапе.
Методика работы
Поскольку вся функциональность в legacy-системах в идеале должна разрабатываться как новая (то есть, отдельно от существующего кода, в существующем коде добавляются лишь точки вызова новой функциональности), то можно для этих целей использовать TDD. На самом низком уровне компонентов и классов должно отлично сработать.