Насколько важно писать функциональные спецификации?

Question

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

Что ты думаешь, ты пишешь спецификации или просто начинаешь программировать и планируешь на ходу, и какая практика лучше?

Answer 1

Если вы едете из дома в ближайший продуктовый магазин, вам, вероятно, не нужна карта. Но ...

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

Если вы едете наугад, чтобы получить удовольствие от вождения, вам, вероятно, не нужна карта. Но ...

Если вы пытаетесь добраться куда-нибудь наиболее эффективным способом (минимизировать расстояние, минимизировать время, сделать три конкретных остановки по пути и т. Д.), Вы, вероятно, это сделаете.

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

Если вы едете в составе конвоя, и всем нужно, чтобы еда и ночлег останавливались вместе, и вам нужно приехать вместе, вы, вероятно, это делаете.

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

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

; -)

Answer 2

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

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

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

Я бы порекомендовал прочитать Быстрое развитие , если вы не уверены. Вы действительно сможете быстрее выполнить работу, если потратите больше времени на планирование и проектирование.

Answer 3

Прыжок "прямо к коду" для больших программных проектов почти наверняка приведет к провалу (как сразу же началось бы создание кирпича для построения моста).

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

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

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

Answer 4

Для одноразовых взломов и небольших утилит, не беспокойтесь.

Но если вы пишете серьезное, большое приложение, и у которого есть требовательные клиенты и вам нужно долго работать, это ОБЯЗАТЕЛЬНО. Прочитайте замечательные статьи Джоэла на эту тему - это хорошее начало.

Answer 5

Если вы работаете в среде XP (или аналогичной), вы будете использовать историй для руководства разработкой наряду с множеством тестов на пригодность для юнитов и прихожих (я выпил Kool- Помощь , наверное).

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

О, да, и я согласен с Кивели: «переход на правильный код» почти никогда не является хорошей идеей.

Answer 6

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

В действительности в больших проектах почти необходимо иметь дорожную карту того, как работает система и что она делает. Если хотите, назовите его функциональной спецификацией, но обычно у вас должно быть что-то, что может показать вам, почему шаг b следует за шагом a. Мы все думаем, что можем придумать это на лету (я тоже определенно виновен в этом), но на самом деле это вызывает у нас проблемы. Вспомните и спросите себя, сколько раз вы сталкивались с чем-то и говорили себе: «Парень, я бы хотел подумать об этом раньше?» Или кто-то еще увидит, что вы сделали, и показал, что вы могли бы сделать 3 шага, чтобы выполнить задачу, на которую вы взяли 10.

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

Answer 7

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

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

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

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

Answer 8

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

Answer 9

Мне нравится сначала разбирать любые нетривиальные задачи на бумаге, а не переходить к коду по ряду причин;

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

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

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

Answer 10

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

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

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

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