Сообщение Re[2]: feature driven development от 13.01.2022 9:06
Изменено 17.02.2022 11:58 Sinclair
Re[2]: feature driven development
Здравствуйте, samius, Вы писали:
S>Здравствуйте, snaphold, Вы писали:
S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
S>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.
Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N 2 2N способами, порождая примерно такое же количество сценариев.
А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.
S>Здравствуйте, snaphold, Вы писали:
S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
S>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.
Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N 2 2N способами, порождая примерно такое же количество сценариев.
А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.
Re[2]: feature driven development
Здравствуйте, samius, Вы писали:
S>Здравствуйте, snaphold, Вы писали:
S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
S>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.
Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N2 до 2N способами, порождая примерно такое же количество сценариев.
А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.
S>Здравствуйте, snaphold, Вы писали:
S>>Не понимаю термин фича тут.
S>>Если к примеру есть в системе функция создания пользователя, но надо сделать функцию массового создания пользователей, немного изменив логику,
S>>то делается паралелльный код и используются только классы сущности по работе с базой?
S>>Или же где есть возможность переиспользования методов то надо переиспользовать?
S>Feature — это про то, что именно является драйвером изменений в разработке, что именно определяет дизайн системы, либо его изменения. Так domain driven (design) ставит во главу углза предметно-ориентированность, т.е. объекты домена и отношения между ними (фичи не рулят, они вторичны), data driven (design) ориентируется на данные и отношения между ними.
S>А FDD говорит, что именно фичи будут рулить процессом разработки, т.е. все будет подчинено им.
Насколько я знаю, Feature-driven — это не столько про разработку, сколько про управление требованиями. И противопоставляется он scenario-based design.
Фича обычно трактуется как некоторый отдельный фрагмент функциональности, типа "система должна давать пользователю вносить наличные деньги на счёт".
Сценарии были изобретены для того, чтобы избежать появления вороха фич, которые сами по себе пользы не приносят. Типа "скачать шаблон заявки" отдаёт заявку в PDF, а "загрузить заявку" принимает документ в RTF. И вроде каждая фича сделана и протестирована успешно, а заполнить заявку по шаблону не получается.
Оборотной стороной дизайна по сценариям является негибкость системы: если в feature-based разработке конкретные сценарии достигаются комбинированием фич, и проектирование ведёт вменяемый архитектор (или команда архитекторов), то N фич комбинируются от N2 до 2N способами, порождая примерно такое же количество сценариев.
А если разработка ведётся исключительно по сценариям, то сценариев будет ровно столько, сколько задокументировано, ни больше ни меньше.
Если сказано "пользователь находит заявку по номеру заявки" — всё, не ждите поиска по контрагенту или позициям в заявке.
Попытка потребовать что-то типа "давайте сделаем поиск по произвольной части документа, в стиле гугл" тут же упирается в возражение "это не сценарий; в нашем процессе разработки есть только сценарии. Выньте да положьте нам сценарий, в котором пользователю нужен поиск по произвольной части документа". И продакт менеджмент либо сдаётся, либо вынужден изобретать 100500 сценариев вида "пользователь хочет найти заявку, в которой он заказывал позицию X", "пользователь хочет найти заявку, в которой он заказывал у контрагента Y" и так далее. И всё ещё нет гарантии, что инженеры не сделают 100500 кнопок "поиск по позиции", "поиск по контрагенту", и т.д., с разными формами.