Сколько дизайна происходит на вашем этапе реализации?

Question

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

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

Я понимаю, что это недостаток модели водопада, но если есть кто -то, кто может дать некоторые конструктивные советы: где можно рисовать линию? Какими должны быть ожидания в области проектирования и сборки и какими недостатками дизайна или ошибок/ошибок не следует терпеть на этапе сборки?

Answer 1

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

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

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

Answer 2

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

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

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

Таким образом, реализация начнет раскрывать вещи забытые или пропущенные, а также другие детали реализации, которые могли бы показаться простыми, но оказываются не так. (Возможно, услуги, которые, как вы думали, вы можете получить из какой-то библиотеки или вашей ОС, оказываются не так, как ожидалось ... и вам нужно сделать копание или написать много нового кода в качестве рабочего, Shim или патч.)

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

---

Немного более интересный комментарий об этом можно найти в более старой книге: «Отказаться от американского программиста» Эда Юдона.

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