Конфигурябельность

А я много новых слов узнал. Спасибо.

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

Читаешь как школьное сочинение. Единственное — сюжет взрослый.
Прочитал, но не понравилось. Не моё.

Работа по scrum вообще не подразумевает отдачу микроменеджмента заказчику. Это лишь средство повышения прозрачности процесса разработки ПО между разработчиками и заказчиком. По сути дела все sprint необходимы в первую очередь заказчику и по этому ему должны быть пронятны все задачи в scrum. К примеру писать сделать загрузчик классов через relfection туда писать не надо. Оно ничего не даст заказчику. Он должен видеть там вещи вида «создание заявки», «отслеживание заявки», «поиск заявки» и т.п. Ну а про конфигурябельность я вам могу предложить посмотреть в сторону DI фреймворков реализующих данную концепцию под C# имеется.