Каковы ваши чувства по функциональным характеристикам? И дизайн программного обеспечения?

Ответ 1

Я не буду запускать какой-либо независимый проект, пока у меня не появится спецификация дизайна и функциональная спецификация, написанная и не подписанная. Там слишком много места для мошеннических клиентов для никеля и копейки до смерти, если у вас его нет. Функциональная спецификация позволяет вам оставаться на целевой/сфокусированной и дает вам естественный контрольный список для работы.

Если нет функциональной спецификации, вы получите все, что "что, если" начнет ползать, и разработчики думают - вы знаете, это было бы полезно, и мне понадобится час. Уверенный час, чтобы закодировать прототип и заставить его работать в основном - плюс день для разработки всех тестов и проверки всех случаев тестирования, а затем еще пару дней, чтобы сгладить все ошибки, а затем время, чтобы написать документацию. Там слишком много места для того, что кажется тривиальным дополнением к вставке, когда нет спецификации. Вы, несомненно, слышали о позорной "ползучести". Там также слишком много места для клиентов, чтобы сказать "это не то, что я хотел...", когда вы его доставляете и пытаетесь вырваться из-за вас.

Если у вас есть спецификация дизайна и функциональная спецификация, написанная впереди разработки, и вы и клиент подписали это, чтобы понять не только основные детали, но и все нюансы используемого языка - это одно и то же то же самое - только тогда начнется реальная работа.

Есть пара анекдотов, там первое верно, а другое - распространенное заблуждение:

• Разработка программного обеспечения составляет всего 15% от кода, остальное - управление ресурсами/людьми.
• Требуется 20% времени для завершения первых 80% проекта, а оставшиеся 80% времени для завершения последних 20%.

Заблуждение состоит в том, что рабочий прототип составляет 80% пути - не обманывайте себя, это не так. Поэтому клиенту легко сказать "что так долго, я думал, что вы почти закончили!" и затем придираться к тому, что они слишком много платят за то, что должно было закончить несколько месяцев назад. Некоторые из методологий дизайна там действительно хорошо поддаются этому популярному заблуждению. Методология проектирования водопада является одной из них, если она не используется правильно.

Мое мнение - убедитесь, что ваше понимание одно и то же, оба подписываются. Установите контрольные точки и заранее сообщите клиенту, что прототипы находятся далеко от завершения проекта и с самого начала задают ожидания относительно того, каковы эти этапы и когда клиент может ожидать их доставки.

Для менеджеров проектов команд разработчиков документация и ожидания - это все. Вы не можете жить без него, это единственная форма обращения, которую вы имеете против "Это не то, что я сказал", или "Это не то, что я имел в виду", и эрго "Я не плачу вам".

Я узнал из многих ошибок, сделанных гораздо более квалифицированными разработчиками, чем я, и увидел, что с ними было. Двумя наиболее важными документами для вашего проекта являются спецификация дизайна и функциональная спецификация. Не уходите из дома без них или он может (или, скорее всего, будет) вернуться и укусить вас в попку.

Добавление re: Истории пользователей:

Дополнительная заметка об истории пользователей - это то, что они великолепны для того, чем они являются. Они должны быть включены в вашу функциональную спецификацию, но не должны быть вашей функциональной спецификацией.

Пользовательская история описывает только одну задачу. Он очень легкий и не содержит чрезмерных деталей. Как следует из общих рекомендаций, он должен соответствовать карте 3x5... если вы, как руководитель проекта, передали мне карточку 3x5 и сказали мне написать часть программного обеспечения на основе того, что я прочитал, без сомнения, это будет передано пользователь в конце, и они сказали менеджеру проекта, что они не хотели.

В функциональной спецификации вам нужен гораздо больший уровень детализации. Он не должен ограничиваться базовыми рабочими процессами. Функциональная спецификация представляет собой целую кучу рассказов пользователей, а также заметки о интерпретации этих историй пользователей, улучшения, которые могут быть сделаны для них, общие задачи, которые можно объединить для повышения эффективности. Список продолжается.

Итак, истории пользователей - хорошее начало, но они не являются заменой функциональной спецификации, они являются точками маркера в функциональной спецификации.

Ответ 2

Я работаю в основном с моделью Waterfall и исключительно с функциональными характеристиками. Когда я работаю самостоятельно (где я могу настроить свою модель и программу любым способом, я хочу), я начинаю с написания функциональных спецификаций, а затем их реализации. Это дает мне гораздо лучшее представление о размере и объеме работы, помогает оценить время и помогает мне ничего не пропустить.

Кроме того, этот документ можно передать:

• Пользователи, чтобы они могли четко определить свои требования.
• Разработчики для создания функциональности
• Тестеры, чтобы убедиться, что они тестируют правильную вещь.
• Архитекторы, чтобы они могли анализировать требования

Использование функциональных требований для пользовательских историй является вопросом предпочтения и объемом проекта. Если у вас небольшая пользовательская база, вы можете уйти с рассказами пользователей (в которых описываются различные последовательности событий, которые может выполнять пользователь), но для больших проектов вы должны использовать функциональные требования, поскольку они имеют более подробную информацию и приводят к меньшему количеству недопонимание. Подумайте о них как о средствах коммуникации со всеми людьми, участвующими в проекте.

Ответ 3

Честно говоря, функциональные спецификации уже должны быть частью вашей методологии Big-M (Waterfall). Ваша функциональная спецификация - это ЧТО вы собираетесь строить; не обязательно, как вы собираетесь его строить (это будет ваш подробный дизайн/спецификация и следующий шаг в водопаде).

Если вы еще не написали, остановите свое действие и напишите. Вы просто теряете время, если вы это сделаете иначе. Вы можете запустить здесь с статьей Джоэля.

Ответ 4

Мне потребовалось более 10 лет, чтобы заставить его биться в голове, чтобы написать функциональную спецификацию, прежде чем делать какой-либо код. Теперь я напишу один для чего-нибудь, что займет больше одного дня, чтобы написать. Уровень детализации и уровень допущений должны быть настолько важны, насколько это необходимо для четкого определения того, что нужно делать, и сообщать об этом другим (или напоминать себе), что-то помимо этого является отходами.

Другие предпочитают User Stories... и это тоже хорошо, если вы планируете какое-то планирование.

Ответ 5

Другой способ добиться этого - использовать истории пользователей

Ответ 6

Я нахожу хорошо написанные функциональные спецификации очень полезными. Хорошо организованная функциональная спецификация также может помочь организовать ваши тесты (сопоставление многих-ко-многим от индивидуальных требований к тестовым случаям).

<p style="tongue: in-cheek"> Они также полезны для указания пальцев в крупных организациях (требования были неточными! Реализация не соответствовала требованию! QA не проверила это требование надлежащим образом!) </p>

Ответ 7

Я поставлю ссылку Codeslave на Безфункциональная функциональная спецификация. хорошая серия статей по спецификациям. См. Также fooobar.com/questions/141137/... для обсуждения того, какой контент следует вводить в функциональные спецификации.

Я выполнил несколько крупных проектов, в том числе один с несколькими хитами человеко-лет общего усилия. По мере того как команда проекта становится больше, число неформальных каналов связи растет с квадратичной верхней границей. Без спецификации этот неофициальный механизм коммуникации является единственным способом передачи информации. Со спецификацией каналы связи подходят к концентраторам и спицам, что делает рост более похожим на линейную функцию размера команды проекта.

Спецификация - действительно единственный масштабируемый способ заставить команду "петь с того же листа гимнов". Должен быть некоторый обзор и переговоры о спецификации, но в конечном итоге кто-то должен взять на себя ответственность за это, чтобы проект не стал бесплатным для всех.

Ответ 8

Я думаю, что это прекрасная идея, и ее следует попробовать.

Ответ 9

Несколько комментариев по некоторым из ответов здесь...

Прежде всего, я считаю, что хороший спецификационный документ важен для любого умеренно сложного требования (и, безусловно, для очень сложных). Но убедитесь, что это хорошая спецификация, т.е. Не просто указать очевидное (как уже упоминалось выше), но и не оставлять без внимания те части, которые могут показаться вам тривиальными (или даже разработчиками), поскольку у вас может быть больше знаний этой части системы, чем некоторые другие, участвующие (например, тестеры или документаторы), которые оценят иначе "отсутствующие бит".

И если ваша спецификация хороша, она будет прочитана - по моему опыту (и я написал и прочитал множество спецификаций за последние годы), это плохие спецификации, которые сбрасываются, и хорошие, которые следуют.

В отношении рассказов пользователей (или иногда также называемых прецедентами): Я думаю, что это важно, чтобы получить представление о сценарии, но они обычно не могут заменить детали (например, макеты экрана, как, где и если функция настраивается, модель данных, проблемы с миграцией и т.д.), поэтому вам, возможно, понадобятся как более сложные требования.

Ответ 10

По моему опыту, функциональные спецификации имеют тонкую грань между недостаточно выражением и слишком многого.

Если они не говорят достаточно, то они оставляют области открытыми для недоразумений.

Если они говорят слишком много, они не оставляют достаточно "комнаты для маневра", чтобы улучшить решение.

И они должны всегда открывать процесс пересмотра.

Ответ 11

Это зависит от функциональной спецификации. У меня были функциональные спецификации, где писатель знал систему внутри и снаружи, и написал спецификацию как таковую, и у меня были другие авторы, которые пишут ее только с тем, что они ожидали увидеть как пользователь.

С первым, это проще, потому что я точно знаю, что мне нужно написать, и где мне нужно его написать, но он ограничивает, насколько легко я могу реорганизовать существующий код, поскольку в оценках учтена только эта функция, а не рефакторинг существующий код, который он затрагивает.

С последним у меня есть свобода для рефакторинга (пока конечная функциональность такая же), но если это система, с которой я незнаком, оценка времени сложнее сделать.

В целом, я люблю функциональные спецификации - мне также нравится напоминать людям, что они написаны на бумаге, которая изгибается и, как таковая, должна быть гибкой.

Ответ 12

Одним из интересных заметок для спецификаций func или пользовательских историй, которые, как я видел, выступает, является сначала написать руководство пользователя для программного обеспечения.

Даже если это только условно (т.е. если вы не собираетесь отправлять какое-либо руководство, которое вы, вероятно, не должны, так как никто его не прочитает), это может быть полезным и достаточно легким способом достичь общего понимания того, что программное обеспечение будет делать и выглядеть. И это заставляет вас делать дизайн спереди.

Ответ 13

Если вы называете их функциональными спецификациями, бизнес-требованиями или историями пользователей, все они очень полезны для процесса разработки.

Проблема с ними возникает, когда они вырезаны из камня и используются как устройство, чтобы обвинять себя, когда система полностью не соответствует реальным потребностям пользователя. Я предпочитаю использовать функционалы или требования в качестве отправной точки для итеративного процесса, а не как библию точно, как система будет выглядеть, когда она будет завершена. Вещи меняются, и у пользователей обычно нет понимания того, чего они хотят, пока у них не будет что-то (возможно, опытного прототипа) в их руках, с которым они могут работать, вместо того, чтобы концептуализировать на листе бумаги, как он будет функционировать в реальном мире, Наиболее успешными проектами, которые я реализовал, были те, в которых команда разработчиков и пользователи были тесно связаны друг с другом, и смогли быстро обменивать изменения, а не удерживать людей на том, что они хотели на листе бумаги шесть месяцев назад.

Конечно, этот процесс не сработает, если вы столкнулись с ситуацией с фиксированной ставкой, как указывал один из ранних ответов.

Ответ 14

Я обнаружил, что даже если вы пишете функциональные спецификации, многие детали иногда теряются на том, кого вы пытаетесь решить. Теперь, если функциональная спецификация написана вместе с каким-то макетом пользовательского интерфейса, это имеет огромное значение. Макеты UI не только показывают пользователю то, что вы предполагаете, но и заставляете пользователей запоминать то, что они не продумали в первую очередь.

Ответ 15

Я видел и писал много спецификаций, некоторые были очень хороши, большинство из них не было. Главное, что все они имели вместе, - это то, что они никогда не соблюдались. У них у всех была паутина на 3-й день кодирования.

Напишите спецификацию, если хотите, лучшее время для нее - в конце проекта. Это будет бесполезно для разработчиков, но это будет, по крайней мере, точное представление о том, что было сделано (я знаю - не совсем спецификация). Но не ожидайте, что спецификация получит код, написанный для вас. Это настоящая работа. Если вы не знаете, что написать, поговорите с вашими заинтересованными сторонами и пользователями и получите хорошие истории пользователей, а затем продолжите с ним.