Комментарии 12
НЛО прилетело и опубликовало эту надпись здесь
ок. Убрал.
+1
НЛО прилетело и опубликовало эту надпись здесь
Статья просто о жизни и взаимоотношениях разработчиков с заказчиками в контексте одной конкретной проблемы — конфигурабельности.
+1
НЛО прилетело и опубликовало эту надпись здесь
А я много новых слов узнал. Спасибо.
0
Довольно распространенный сценарий. Я обычно прибегаю к тактике «бодание заказчика», когда вижу задачу, которая способна заметно усилить связи между подсистемами проекта — на мой взгляд, это одна из самых больших бед, существующих в коде, т.к. от нее чрезвычайно трудно избавляться, а избавляться часто приходится именно в процессе рефакторинга. Расчет простой — если заказчику фича нужна как воздух, он меня порвет и фича будет. Если же он и сам не уверен, зачем ему это нужно — я уберегу проект от излишнего внутреннего усложнения.
+1
Читаешь как школьное сочинение. Единственное — сюжет взрослый.
Прочитал, но не понравилось. Не моё.
Прочитал, но не понравилось. Не моё.
+2
Работа по scrum вообще не подразумевает отдачу микроменеджмента заказчику. Это лишь средство повышения прозрачности процесса разработки ПО между разработчиками и заказчиком. По сути дела все sprint необходимы в первую очередь заказчику и по этому ему должны быть пронятны все задачи в scrum. К примеру писать сделать загрузчик классов через relfection туда писать не надо. Оно ничего не даст заказчику. Он должен видеть там вещи вида «создание заявки», «отслеживание заявки», «поиск заявки» и т.п. Ну а про конфигурябельность я вам могу предложить посмотреть в сторону DI фреймворков реализующих данную концепцию под C# имеется.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфигурябельность