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


17

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


2
Тест Джоэла направлен на процессы разработки программного обеспечения и найма разработчиков. Каким образом вы лицензируете свое программное обеспечение или вы публикуете или не публикуете свой источник, связанный с этим?
— Марьян Венема

Спасибо Марьян за вопрос. Я думал, что с момента создания теста Джоэла Open Source стал тенденцией, и если кто-то очень негативно относится к Open Source, то, вероятно, я хотел бы знать, как команда выступает против открытого исходного кода, если это так. Я согласен, что вопросы авторского права могут выходить за рамки, но программист не может работать с командой, которая считает, что открытый исходный код - это возможность просматривать исходный код, а также вопрос 13: «Есть ли у вас система резервного копирования?» и 14 "У вас есть более надежная защита, чем у MD5?" где ответы должны быть да.
— Никлас

1
Хорошо, это имеет смысл. Усилия с открытым исходным кодом должны быть не только «потреблены», но и должны быть внесены, хотя и не обязательно с помощью кода (подумайте о денежной поддержке). Системы резервного копирования важны, но не ограничиваются разработкой, поэтому я бы не стал добавлять их в тест Джоэла. Но если бы я взял интервью у бизнеса, который ничего не делал с резервными копиями, я бы побежал к двери. Безопасность я бы тоже не добавил. Для безопасности, разработанной программным обеспечением, это может не беспокоить (собственные приложения), и поэтому оно не поддается ответу «да / нет», плюс безопасность не должна зависеть от разработки.
— Марьян Венема

Спасибо, что поделились знаниями со мной. Это правда, что резервное копирование важно, но не зависит от разработки.
— Никлас

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

Ответы:


23

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

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

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

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

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

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

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

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


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

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

Спасибо за мудрость. Я полностью согласен, что все должно быть приоритетом. Мой партнер также заявил, что у нас не должно быть проблем и проблем нет. Но я чувствую, что документирование проблем является правильным, и даже лидер рынка продолжает отслеживать проблемы. Опять же, выполнение противоположного правила сработает ...
— Никлас

@ 909Niklas Вы, вероятно, должны искать другого партнера, чтобы ваша будущая жизнь была более комфортной ...
— Марсель

+1 только для: при написании спецификации говорите только то, что должен делать продукт, а не как это нужно делать.
— Марсель

5

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.