Що ви думаєте про тест Джоеля? [зачинено]


51

Тест Джоеля добре відомий тест для визначення того, наскільки добре ваша команда. Що ви думаєте про моменти? Ви не погоджуєтесь ні з одним із них? Ви можете щось додати?

Відповіді:


41

Джефф Етвуд має Білль про права програміста .

З поста:

  1. Кожен програміст має два монітори
  2. Кожен програміст повинен мати швидкий ПК
  3. Кожен програміст має вибір миші та клавіатури
  4. Кожен програміст повинен мати зручне крісло
  5. Кожен програміст повинен мати швидке підключення до Інтернету
  6. Кожен програміст повинен мати тихі умови праці

Здається, є деякі елементи, які я хотів би побачити у списку Джоела. Зокрема в області апаратних засобів (подвійний монітор, швидкий ПК, миша / клавіатура, зручне крісло, швидке з'єднання).

Єдине, що не згадується - це зручний та регульований стіл .

Все це можна додати, змінивши:

Поточний № 9: Чи використовуєте ви найкращі інструменти, які можна придбати?

до

Удосконалено №9: Чи використовуєте ви найкращі інструменти та обладнання, які можна придбати за гроші?


Чи не ваш номер 6 ідентичний №8 у тесті Джоеля:
HerbN,

Це Джефф Етвуд №6, і так, це так.
губка

Схоже, тест Joel є більш специфічним для того, щоб допомогти програмістам розробити чисте програмне забезпечення, що не містить помилок, на відміну від умов праці, за винятком №8
Archmede

13

Цікаво, що пункт 8 тепер гласить:

8. Do programmers have quiet working conditions?

коли він читав (щось на кшталт)

8. Do programmers have their own office?

і останній абзац все ще починається:

Тепер давайте перенесемо їх в окремі кабінети зі стінами та дверима.

Я завжди підозріло ставився до цього тесту, оскільки у всіх місцях, де я працював - і як працівник, і як відвідувач, - єдині люди, які мають власні офіси, - це директори та вищі керівники.

Написання програмного забезпечення в реальному світі, як правило, є командною діяльністю, вам потрібно поговорити зі своїми товаришами по команді, щоб підстрибувати ідеї навколо тощо. Це важче зробити з людьми в окремих офісах, навіть із системами обміну миттєвими повідомленнями. Уміння намалювати речі та показати людям код та діаграми дуже допомагає. Це не означає, що розподілені команди не можуть працювати - вони, очевидно, можуть і робити, це просто інший набір проблем.

Що б я сказав, це те, що кожна команда повинна бути у власному кабінеті з 6-8 осіб (якщо припустити, що це розмір команди). Таким чином вони можуть взаємодіяти, не заважаючи іншим командам (якщо такі є) і продовжувати свою роботу, не турбуючи торгового колективу чи відвідувачів (в одному місці, де я працював, ви заходили через вхідні двері прямо в зону розвитку).

Якщо ви працюєте з іншими розробниками, але кожен працює над окремими проектами, то спільний офіс може бути корисним - але лише в тому випадку, якщо ви суворо ставитеся до засідань до зали засідань та дотримуєтесь інших термінів тощо.

Більшість інших є істинними істинами.


9
Проблема з відскакуванням ідей від товаришів по команді полягає в тому, що СКАЖИТИ їх усно - це величезна відволікання. Якщо вам потрібно зробити серйозну співпрацю, тоді працюйте в просторі співпраці. Але для питань "ей, як би ви це зробили", вам набагато краще з ІМ.
Метт Оленік

@Matt - Що стосується дрібниць, які ти маєш рацію, але офісних приміщень завжди мало - жодна компанія не хоче витрачати гроші на порожні офіси - саме тому допомагає наявність команд у власному просторі. Ви можете перетворити офіс у "простір для співпраці".
ChrisF

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

1
@ChrisF: можливо, в цьому проблема. Нас четверо, що сиділи в одній кімнаті, ледь не мають нічого спільного, програмуючи мудро. Це більше схоже на 4 людини, які працюють над 2 1/2 проектами, що сидять в одній кімнаті. А тепер додайте начальника, який абсолютно не проти проводити півгодини тривалої дискусії з іншим програмістом прямо біля вашого столу, незважаючи на те, що зал засідань знаходиться просто через передпокій . >. <
Baelnorn

1
@ChrisF - "Написання програмного забезпечення в реальному світі - це командна діяльність, вам потрібно поговорити зі своїми товаришами по команді, щоб підстрибувати ідеї навколо тощо. Це набагато складніше з людьми в окремих офісах". - Отже, як працюють команди-розробники по різних місцях? Я тісно співпрацював з людьми з США чи Бразилії чи Індії - IM та Adobe Connect - а також спільно розміщувався, від невеликих до дуже великих розподілених команд. Ваше - дуже руйнівне середовище. Робота в командах може бути виконана ефективно, але те, що ви прописуєте, - це що завгодно, але (ваша ідея правильна від водоспаду 70-х)
luis.espinal

10

Мені це подобається, але якби я використовував його для оцінки компанії, я б не однаково зважував усі предмети. Неможливо контролювати джерела - це набагато більша проблема, то не купувати найкращі інструменти, які можна придбати.


9

Єдиний вимикач для мене - це:

 8. Do programmers have quiet working conditions?

Цікавим є те, що питання, швидше за все, не вдасться оприлюднити роботу Stack Overflow.

Деякі питання важко відмовити, особливо якщо в компанії є більше одного програміста:

 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?

20
Думаю, ви здивуєтеся, скільки компаній не можуть скласти збірку за один крок і не мають бази даних про помилки. Ви, напевно, маєте рацію щодо контролю над джерелами, але я заперечую, що багато компаній використовують його просто для резервного копіювання свого коду і навіть не дряпають поверхню переваг контролю джерел.
Роб Соберс

1
Коли я почав свою роботу, у нас була система управління джерелами, але збірки були зроблені на машині одного хлопця, і лише він знав усі кроки, а помилок відслідковували на папері. Зараз це все "виправлено", але я б ніколи не сприймав ці речі як належне.
HappyCat

6

Треба сказати, що це хороша «базова лінія», але з будь-яким вимірювальним інструментом є інші фактори. Наприклад, жодна компанія, над якою я працював, не робила Daily Builds (я знаю, я знаю), але деякі з них були дуже хорошими.

У мене особисто є кілька інших пунктів, які я б додав до списку.

  1. Чи підтримуєте ви освіту розробників, відвідуючи конференції, купуючи книги чи щось подібне?
  2. Чи є у вас простий, задокументований процес для прийняття нових інструментів, якщо це необхідно для виконання завдань
  3. Чи надаєте розробникам обладнання та середовище, яке дозволить їм бути продуктивними.

Більше всього, ці речі "мене розчарували" від попередніх роботодавців, і тепер вони швидко запитують питання, які я задаю про кожну можливість.


1
У списку вже немає 3?
Casebash

Так, в тій чи іншій формі це так. Але я перелічу свій дещо інакше, тому я залишив його там.
продавці Мітчела

5

Я згоден з більшістю пунктів Джоеля. Я не дуже впевнений у "тестуванні на корисність передпокою". Тестування на працездатність, звичайно, але насправді схопити когось із передпокою і змусити їх перевірити вашу програму, хоча це не їхня робота? Це здається чудовим способом відзначити людей.


1
Безумовно, це культурна річ - якщо вона не є надмірно руйнівною і якщо вона є частиною способу функціонування бізнесу, то вона не повинна "галочувати людей" - особливо не, якщо метою бізнесу є розробка додатків.
Мерф

1
Можливо, справа в тому, що вона повинна бути частиною роботи інших людей?
JeffO

7
По суті, тест на корисність передпокою полягає в тому, що він повинен бути тим, хто не використовує програму регулярно. Після того, як ви побудували його та / або витратили години на його використання (як-от спеціалізований тестер), ваш погляд на додаток буде
зіпсований

5

Тест Джоеля не перевіряє, наскільки хороша команда. Він перевіряє, наскільки добре ваша команда дотримується тесту Джоеля.

Ось кращий тест на те, наскільки хороша ваша команда. Я називаю це тестом GrandmasterB. У нього одне питання.

1) Чи корисне програмне забезпечення, яке ви пишете?

Для мене не має значення, чи ви "тестуєте передпокій" чи ні, або який у вас контроль над джерелами, або який у вас процес збирання (якщо такий є - не кожен прапор має їх). Справжньою мірою команди є якість створеного ними програмного забезпечення.

В основному, ви можете дотримуватися кожного кроку тесту Джоела, і все-таки закінчуєтесь лайним кодом та продуктами, які ніколи не поставляються. Наприклад, керування джерелами не магічно робить когось кращим; це полегшує управління кодом. А наявність останньої версії Visual Studio не означає, що ваша програма працюватиме краще, ніж якби вона була написана з Visual Studio 2005 .


14
Ви пропускаєте суть. Тест Джоеля не в тому, наскільки хороше програмне забезпечення, а в тому, наскільки ефективний виробничий процес. Команда, яка провалить тест Джоеля, все ж може зробити хороші продукти, але, швидше за все, це займе набагато більше часу, і робітники стануть нещасними. Також інструменти не стосуються лише програмного забезпечення. Це також означає апаратне забезпечення - від комп'ютера до робочого столу та клавіатури.
Метт Оленик

Я думаю, ти пропускаєш суть. Якщо команда закінчує проекти вчасно і виробляє якісне програмне забезпечення, вони, за визначенням, ефективні. І вони мають, за визначенням, ефективний процес.
GrandmasterB

2
Ви ніколи не згадували про доставку вчасно. Також я був би надзвичайно здивований, побачивши ефективну команду, яка провалила (повністю) тест Джоеля. Такі речі, як контроль версій, тестування та зручність використання, є критичними. Інші предмети також можуть бути досить великими перешкодами.
Метт Оленік

Це хороший момент, але головна слабкість - це його суб’єктивність. Кожна людина може мати різну думку щодо якості програмного забезпечення, залежно від свого досвіду, рівня кваліфікації та перспективи використання. Але мені подобається суть.
Бернард Ді

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

5

Хоча я вважаю, що це має сенс у загальному сенсі, я знайшов цей список досить орієнтований на певний тип програмного забезпечення, яке робить Fog Creek Software ( скорочується ). Це насправді не дивно, адже він також розповідає про це на іншій посаді, П’ять світів . І поза цим світом існує маса розробок.

Існують деякі умови, які насправді не мають великого сенсу, якщо ви розробляєте, наприклад, вбудоване програмне забезпечення для супутника або торгового автомата, наприклад, щоденні збірки (3) або тести на зручність використання (12).


Домовились. Коли ви віддаляєтесь від додатків "вершини стека", багато сучасних ідей здаються трохи ... неважливими.
Пол Натан

Я згоден. У корпоративних ІТ-магазинах є багато робочих місць для розробників ... звичайно, не настільки гламурно, як робити стиснуту обробку. Оскільки більшість цих компаній не займаються програмним забезпеченням, більшість із них зазвичай набирають близько 4 тестів на Джоелі.
Бернард Ді

6
Чому б вам не створити одиничні тести для вбудованого програмного забезпечення (і автоматично їх запускати система складання)?
Пітер Мортенсен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.