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

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

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

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

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

Это очень неоднозначно ...

Я могу сказать две вещи:

1. Есть много очень одаренных технических людей, чья карьера останавливается, потому что они ждут идеальных требований. Или они играют: «Извините, не могу этого сделать, не было требований». На самом деле требования к написанию очень сложны. Точность, требуемая для хороших требований, непохожа на то, что большинство деловых людей когда-либо создавали. Между технологиями и бизнесом существует мост, и люди, которые заставляют других пройти 100% пути к их удовлетворению, обычно проигрывают.

2. Есть программисты, которые изучают домены так же хорошо или лучше, чем их клиенты. Эти люди на вес золота, даже если они не на 100% лучшие разработчики. Я видел, как программисты предвосхищают количественные маркетинговые потребности лучших бренд-менеджеров страны. Они не были лучшими в кодировании всех решений, но они были героями, потому что они могли пересечь мост.

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

Требования - это шаги в пути, видение - это направление

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

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

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

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

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

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

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

Тем не менее, компании-разработчики программного обеспечения все время поставляют программное обеспечение, несмотря на эти недостатки в процессе. Спецификация никогда не будет идеальной. Спецификация также НЕТРАЛЬНАЯ и устаревшая. Спецификация к прототипу похожа на логарифмическую таблицу для отдельного графика - спецификация - это, по сути, скучная брошюра, предназначенная для печати, тогда как вместо этого вы можете взаимодействовать с инструментом / графиком. Проверьте http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html для вдохновения.

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

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

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

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

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

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

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

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

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

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

Невозможно написать программу без требований. Даже у «Hello World» есть требование: производить продукцию. Итак, я думаю, что вы спрашиваете об официальных требованиях, в виде большого стека чего-то подобного UML. Что касается тех, я встречал 2 типа людей:

1) Люди, которым нужны формальные требования. Им нужно точно сказать, что делать, и, в лучшем случае, как это сделать. Им нравятся такие предложения, как «Процедура A с аргументом B» , и они ненавидят их: программа должна сделать работу нашего отдела более эффективной . Обычно это корпоративные животные.

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

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

Вы НЕ можете разрабатывать операционное программное обеспечение, не зная Требований; но вы можете получить очень хороший удар по разработке того, что ваш опыт говорит вам, что требования, вероятно,быть. Гибкая разработка использует комбинацию «интуитивных» методов, включая правило 80:20 и «обнаружение» требований путем прототипирования. Другими словами, опытная команда разработчиков делает правильное предположение о том, что нужно, и создает прототип программного обеспечения. Правило 80:20 говорит, что они будут правильными на 80%. Заинтересованные стороны проекта затем рассматривают материальный прототип. Их отзывы начинают заполнять пробел в 20% в нашем понимании требований. Таким образом, Agile, по сути, не занимается написанием программного обеспечения без каких-либо требований, а скорее использует ваш предыдущий опыт, чтобы сказать: «Вы хотите что-то подобное?» Что, в 80% случаев, позволит вам опередить и подтвердить то, что действительно необходимо, быстрее, чем пройти через традиционные процессы требований.

Кто сказал, что Agile пишет код при отсутствии требований? Я знаю, что Манифест был истолкован некоторыми так ... но это не делает его правильным.