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

Question

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

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

Answer 1

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

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

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

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

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

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

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

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

;-)

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

Не беспокойтесь о разовых хаках и небольших утилитах.

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Ах да, и я согласен с Киевели:«Перейти сразу к коду» почти никогда не является хорошей идеей.

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

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

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

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

Answer 11

Важно не писать их: В функциональной спецификации нет ничего функционального