Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
S>Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Это как посмотреть. На TDD тоже можно посмотреть так, что оно будет про управление требованиями. Я не хочу здесь возражать, но у гибких ребят написано что это
Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process
http://agilemodeling.com/essays/fdd.htm
S>Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
S>Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.
Я понимаю, о чем речь. Но в FDD есть целые этапы Build Features List & Plan by Feature, которые, по всей видимости, должны подразумевать процесс выбора фич более рациональный, чем то, что происходит в Спортлото.
S>Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N 2 2N способами, порождая примерно такое же количество сценариев.
S>А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
S>Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
S>Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.
Тут уже речь немного о другом. Это не про разработку, а про терки между менеджментом и клиентом, в которых ориентация процесса вторична (фичи/сценарии, либо что-то еще). И тут мне сложно выбрать сторону, т.к. с одной стороны клиент может передавливать с хотелками, мешая реализовать основные сценарии, а с другой — менеджмент может прикрывать процессом свою палочную (по кол-ву фич/сценариев) мотивацию.
Эффективный процесс — все равно будет чем-то из области разумных компромиссов. А то, выразим ли мы необходимый сценарий в виде десятка невнятных фич, или наоборот, представим ли десяток нужных фич одним невнятным сценарием ради формального соблюдения процесса — это уже не сильно интересно со стороны разработки.
