it-swarm-eu.dev

Co si myslíte o testu Joel?

Joelův test je dobře známý test pro určení, jak dobrý je váš tým. Co si myslíte o bodech? Nesouhlasíte s některým z nich? Je něco, co byste přidali?

52
Casebash

Jeff Atwood má Programová listina práv .

Z příspěvku:

  1. Každý programátor musí mít dva monitory
  2. Každý programátor musí mít rychlý počítač
  3. Každý programátor musí mít na výběr myš a klávesnici
  4. Každý programátor musí mít pohodlnou židli
  5. Každý programátor musí mít rychlé připojení k internetu
  6. Každý programátor musí mít klidné pracovní podmínky

Zdá se, že to má některé položky, které bych rád viděl na Joelově seznamu. Konkrétně v oblasti hardware (duální monitor, rychlé PC, myš/klávesnice, pohodlné křeslo, rychlé připojení).

Jediná věc, která nebyla zmíněna, je mít pohodlný a nastavitelný stůl .

To vše lze přidat změnou:

Aktuální # 9: Používáte nejlepší nástroje, které mohou peníze koupit?

na

Vylepšené # 9: Používáte nejlepší nástroje a vybavení peníze, které můžete koupit?

41
spong

Je zajímavé, že bod 8 nyní zní:

8. Do programmers have quiet working conditions?

když to čítalo (něco jako)

8. Do programmers have their own office?

a poslední odstavec stále začíná:

Nyní je přesuneme do samostatných kanceláří se stěnami a dveřmi.

Na tento test jsem vždycky podezíral, protože na všech místech, kde jsem pracoval - jako zaměstnanec i návštěvník - jediní lidé s vlastní kanceláří jsou ředitelé a vedoucí pracovníci.

Psaní softwaru v reálném světě je obvykle týmovou aktivitou, je třeba mluvit se svými spoluhráči, aby odrazili nápady kolem atd., A to je těžší dělat s lidmi v samostatných kancelářích i se systémy okamžitých zpráv. Být schopen čerpat věci a ukazovat lidem kód a diagramy hodně pomáhá. Tím nechci říci, že distribuované týmy nemohou fungovat - samozřejmě to dokážou a dělají, to je jen jiná sada problémů.

Řekl bych, že každý tým musí být ve své kanceláři 6-8 lidí (za předpokladu, že je to velikost týmu). Tímto způsobem mohou interagovat, aniž by rušili ostatní týmy (pokud existují), a pokračovat ve své práci, aniž by byli rušeni prodejním týmem nebo návštěvníky (na jednom místě, kde jsem pracoval, jste prošli předními dveřmi přímo do vývojové oblasti).

Pokud pracujete s jinými vývojáři, ale každý pracuje na samostatných projektech, pak bude společná kancelář může užitečná - ale pouze pokud budete přísně dodržovat schůzky v zasedací místnosti a dodržovat termíny ostatních lidí atd. .

Většina ostatních jsou evidentní pravdy.

13
ChrisF

Líbí se mi to, ale kdybych to používal k hodnocení společnosti, nevyvážil bych všechny položky stejně. Nemít kontrolu zdroje je mnohem větší problém, než nekupovat nejlepší nástroje, které si peníze mohou koupit.

10
JeffO

Jediným obchodníkem, který má na starosti obchod, je:

 8. Do programmers have quiet working conditions?

Zajímavé je, že tato otázka s největší pravděpodobností selže při odesílání úloh Stack Overflow.

Některé z otázek je obtížné selhat, zejména pokud je ve společnosti více než jeden programátor:

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

Většině ostatních mě to opravdu nezajímá. Upřímně:

12. Do you do hallway usability testing?

Existuje jeden, který odhalí lháře:

 5. Do you fix bugs before writing new code?
9

Musím říci, že je to dobrý „základní“, ale s jakýmkoli měřicím nástrojem existují i ​​další faktory. Například žádná společnost, pro kterou jsem pracoval, nedělala Daily Builds (já vím, já vím), ale některé z nich byly velmi dobré.

Osobně mám několik dalších položek, které bych přidal do seznamu.

  1. Podporujete vzdělávání vývojářů účastí na konferencích, nákupem knih nebo něco takového?
  2. Máte jednoduchý a zdokumentovaný proces pro přijetí nových nástrojů, pokud je to nutné pro dokončení funkcí úlohy
  3. Poskytujete vývojářům vybavení a prostředí, které jim umožní být produktivní.

Více než cokoli jiného jsou to položky, které mě „nasraných“ od předchozích zaměstnavatelů, a dobře, jsou nyní zrychlené otázky, které se ptám na každou příležitost.

6
Mitchel Sellers

Joelův test netestuje, jak dobrý tým je. Testuje, jak dobře váš tým dodržuje test Joel.

Tady je lepší test toho, jak dobrý je váš tým. Říkám tomu test GrandmasterB. Má jednu otázku.

1) Je software, který píšete, dobrý?

Je pro mě irelevantní, zda testujete v chodbě nebo ne, nebo jaký máte zdrojový ovládací prvek, nebo jaký máte proces sestavování (pokud existuje, ne každý lanugage). Skutečnou mírou týmu je kvalita softwaru, který vytvářejí.

V zásadě byste mohli sledovat každý jednotlivý krok Joel Testu a nakonec skončit s blbým kódem a produkty, které se nikdy nedodávají. Například řízení zdroje nečiní magicky jednoho lepším kodérem; to usnadňuje správu kódu. A mít nejnovější verzi Visual Studio neznamená, že vaše aplikace bude fungovat lépe, než kdyby byla napsána s Visual Studio 2005 .

5
GrandmasterB

I když si myslím, že to dává smysl v obecném smyslu, našel jsem seznam docela soustředěný na konkrétní druh softwaru, který Fog Creek Software dělá ( shrinkwrap ). To není opravdu překvapivé, protože o tom také mluví na jiném příspěvku, Five Worlds. A mimo tento svět existuje spousta vývoje.

Existují určité podmínky, které opravdu nedávají velký smysl, pokud vyvíjíte například vestavěný software pro satelit nebo prodejní automat, jako jsou denní sestavení (3) nebo testování použitelnosti (12).

5
Khelben

Souhlasím s většinou Joeliných bodů. Nejsem si tak jistý „testováním použitelnosti chodby“. Testování použitelnosti, jistě, ale ve skutečnosti někoho chytíte z chodby a přiměje je otestovat váš program, i když to není jejich práce? Vypadá to jako skvělý způsob, jak odškrtnout lidi.

5
Tim Goodman