Насколько актуален тест Джоэла? [закрыто]

17

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

Никлас
источник
2
Тест Джоэла направлен на процессы разработки программного обеспечения и найма разработчиков. Каким образом вы лицензируете свое программное обеспечение или вы публикуете или не публикуете свой источник, связанный с этим?
Марьян Венема
Спасибо Марьян за вопрос. Я думал, что с момента создания теста Джоэла Open Source стал тенденцией, и если кто-то очень негативно относится к Open Source, то, вероятно, я хотел бы знать, как команда выступает против открытого исходного кода, если это так. Я согласен, что вопросы авторского права могут выходить за рамки, но программист не может работать с командой, которая считает, что открытый исходный код - это возможность просматривать исходный код, а также вопрос 13: «Есть ли у вас система резервного копирования?» и 14 "У вас есть более надежная защита, чем у MD5?" где ответы должны быть да.
Никлас
1
Хорошо, это имеет смысл. Усилия с открытым исходным кодом должны быть не только «потреблены», но и должны быть внесены, хотя и не обязательно с помощью кода (подумайте о денежной поддержке). Системы резервного копирования важны, но не ограничиваются разработкой, поэтому я бы не стал добавлять их в тест Джоэла. Но если бы я взял интервью у бизнеса, который ничего не делал с резервными копиями, я бы побежал к двери. Безопасность я бы тоже не добавил. Для безопасности, разработанной программным обеспечением, это может не беспокоить (собственные приложения), и поэтому оно не поддается ответу «да / нет», плюс безопасность не должна зависеть от разработки.
Марьян Венема
Спасибо, что поделились знаниями со мной. Это правда, что резервное копирование важно, но не зависит от разработки.
Никлас
Многие хорошие вопросы генерируют определенную степень мнения, основанного на опыте экспертов, но ответы на этот вопрос, как правило, будут почти полностью основаны на мнениях, а не на фактах, ссылках или конкретных знаниях.
комнат

Ответы:

23

Я думаю, что тест Джоэла актуален - он так же актуален, как и большинство других программных продуктов, которые «вне времени».

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

Как вы знаете, куда вы хотите пойти?

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

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

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

[Из этого правила есть только одно исключение: иногда конкретная деталь или метод реализации являются обязательными или обязательными, и в этом случае их необходимо ввести. Например, если программное обеспечение должно быть написано на PHP, а это не подлежит обсуждению, тогда оно входит в спецификация Там должно быть очень мало случаев этого.]

Я мог бы добавить: отсутствие отслеживания ошибок является актом равного безумия. Это просто самый непрофессиональный и глупый способ действовать и приведет к сильной боли и страданиям.

quickly_now
источник
Спасибо за очень быстрый и ценный ответ. Другим случаем безумия, которое дошло до меня, было утверждение, что все должно иметь одинаковый приоритет. Такое чувство, что выполнение противоположных этих сумасшедших правил приведет к успеху.
Никлас
4
«все имеет равный приоритет» - также известно как «все является № 1». Честно говоря, это полная чушь. Все должно быть приоритетным, жестоко, с точки зрения ВРЕДА ДЛЯ БИЗНЕСА. Тогда вы работаете на # 1. Если по какой-то причине вас остановили на # 1, вы работаете на # 2. И так далее. Если у вас есть люди, которые по какой-то причине не могут работать на # 1, и в итоге они работают на # 9 - это нормально, если есть веская причина. («Я чувствовал, что это и его cooooooool» не является хорошей причиной). Также можно изменить приоритеты. Делать это чаще, чем еженедельно - тоже безумие.
quick_now
Спасибо за мудрость. Я полностью согласен, что все должно быть приоритетом. Мой партнер также заявил, что у нас не должно быть проблем и проблем нет. Но я чувствую, что документирование проблем является правильным, и даже лидер рынка продолжает отслеживать проблемы. Опять же, выполнение противоположного правила сработает ...
Никлас
@ 909Niklas Вы, вероятно, должны искать другого партнера, чтобы ваша будущая жизнь была более комфортной ...
Марсель
+1 только для: при написании спецификации говорите только то, что должен делать продукт, а не как это нужно делать.
Марсель
5

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

Документы со спецификациями, по крайней мере, большие предварительные документы о спецификациях теперь не нужны, поскольку у нас есть пользовательские истории и процессы разработки Agile Этот вопрос следует изменить на «Соответствует ли уровень документации разрабатываемым решениям?» Небольшие, более узкие пользовательские истории, которые публикуются каждые две недели, в большинстве случаев гораздо полезнее, чем большой предварительный документ, в котором подробно описывается продукт. Однако, если вы строите следующий марсоход, вам может потребоваться подробный предварительный проектный документ. Если бы вы спросили, есть ли у компании спецификации дизайна, я бы не удивился, услышав ответ: «Не совсем, мы вместо этого используем гибкие процессы и пользовательские истории».

Во-вторых, вопрос «ежедневных сборок» должен измениться на вопрос о непрерывной интеграции. Если вы не создаете программное обеспечение, на создание которого уйдут часы (чего не будет делать 99,99% мест), следует задать вопрос, использует ли компания непрерывную интеграцию.

Большая часть теста Джоэла действительно не датирована вообще. Это все еще хороший способ получить представление о рабочей среде.

Стивен
источник