Что вы думаете о тесте Джоэл? [закрыто]

51

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

joel-test

— Casebash
источник

41

У Джеффа Этвуда есть Билль о правах программиста .

Из поста:

У каждого программиста должно быть два монитора

У каждого программиста должен быть быстрый ПК

Каждый программист должен иметь свой выбор мыши и клавиатуры

У каждого программиста должно быть удобное кресло

Каждый программист должен иметь быстрое подключение к интернету

У каждого программиста должны быть спокойные условия труда

Кажется, в этом есть некоторые пункты, которые я хотел бы видеть в списке Джоэла. Конкретно в области аппаратного обеспечения (двойной монитор, быстрый ПК, мышь / клавиатура, удобное кресло, быстрое соединение).

Единственное, что не упомянуто, - это удобный и регулируемый стол .

Все это можно добавить, изменив:

Текущий # 9: Вы используете лучшие инструменты, которые можно купить за деньги?

в

Улучшено # 9: Используете ли вы лучшие инструменты и оборудование, которые можно купить за деньги?

— Spong
источник

Разве ваш # 6 не идентичен # 8 в тесте Джоэла:

— HerbN

Это # 6 Джеффа Этвуда, и да, это так.

— Спонг

Похоже, что Joel Test более конкретно помогает программистам разрабатывать чистое, не содержащее ошибок программное обеспечение, а не рабочие условия, кроме # 8

— Archmede

13

Интересно, что пункт 8 теперь гласит:

8. Do programmers have quiet working conditions?

когда раньше читал (что-то вроде)

8. Do programmers have their own office?

и последний абзац все еще начинается:

Теперь давайте перенесем их в отдельные кабинеты со стенами и дверями.

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

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

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

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

Большинство других являются самоочевидными истинами.

— ChrisF
источник

9

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

— Мэтт Оленик

@ Matt - По мелочам вы правы, но офисных площадей всегда мало - ни одна компания не хочет тратить деньги на пустые офисы - вот почему помогает команда в своем собственном пространстве. Вы можете превратить офис в «пространство сотрудничества».

— ChrisF

2

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

— Baelnorn

1

@ChrisF: возможно, это проблема. Четверо из нас, сидящих в одной комнате, едва ли имеют какое-либо отношение друг к другу, мудро программируя. Это больше похоже на то, что 4 человека работают над 2 1/2 проектами, сидя в одной комнате. А теперь добавьте босса, который совершенно не против провести получасовые дискуссии с другим программистом рядом с вашим столом, несмотря на то, что комната собраний находится прямо через коридор . >. <

— Baelnorn

1

@ChrisF - «Написание программного обеспечения в реальном мире - это командная деятельность, вам нужно поговорить с товарищами по команде, чтобы обмениваться идеями и т. Д., И это намного сложнее с людьми в отдельных офисах». - Итак, как работают команды разработчиков в разных местах? Я работал в тесном контакте с людьми из США, Бразилии или Индии - IM и Adobe Connect, - а также с разными местами, от небольших до очень больших распределенных команд. Ваша очень разрушительная среда. Работа в командах может быть выполнена эффективно, но то, что вы прописываете, совсем не то, что (ваша идея

— верна,

10

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

— JeffO
источник

9

Единственный нарушитель соглашения для меня:

 8. Do programmers have quiet working conditions?

Интересно, что этот вопрос, скорее всего, потерпит неудачу из-за публикации сообщений о переполнении стека.

Некоторые из вопросов трудно подвести, особенно если в компании работает более одного программиста:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

Большинство других меня не волнует. Я имею в виду, честно

12. Do you do hallway usability testing?

Есть один, чтобы обнаружить лжецов:

 5. Do you fix bugs before writing new code?

— Том Хотин - Tackline
источник

20

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

— Роб Соберс

1

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

— HappyCat

6

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

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

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

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

— Митчел Селлерс
источник

1

3 уже нет в списке?

— Casebash

Да, в той или иной форме это так. Но я перечисляю свои немного по-другому, поэтому я оставил это там.

— Митчел Селлерс

5

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

— Тим Гудман
источник

1

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

— Murph

1

Может быть, дело в том, что это должно быть частью работы других людей?

— Джефф

7

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

— GSto

5

Joel Test не проверяет, насколько хороша команда. Он проверяет, насколько хорошо ваша команда придерживается теста Джоэл.

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

1) Хорошее ли программное обеспечение, которое вы пишете?

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

По сути, вы можете выполнить каждый шаг теста Джоэла, и при этом получить код и продукты, которые никогда не доставляются. Например, управление исходным кодом магическим образом не делает человека лучшим программистом; это облегчает управление кодом. А наличие последней версии Visual Studio не означает, что ваше приложение будет работать лучше, чем если бы оно было написано с Visual Studio 2005 .

— GrandmasterB
источник

14

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

— Мэтт Оленик

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

— GrandmasterB

2

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

— Мэтт Оленик

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

— Бернард Ди

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

— Финни МакФингер

5

Хотя я думаю, что это имеет смысл в общем смысле, я обнаружил, что список довольно сосредоточен на конкретном программном обеспечении, которое делает Fog Creek Software ( shrinkwrap ). Это не удивительно, поскольку он также говорит об этом в другом посте, Five Worlds . И есть много событий за пределами этого мира.

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

— Khelben
источник

Согласовано. После того, как вы отойдете от приложений «вершины стека», многие современные идеи кажутся ... немного неуместными.

— Пол Натан

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

— Бернард Ди

6

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

— Питер Мортенсен