Co sądzisz o teście Joela? [Zamknięte]

51

Joel testu jest dobrze znanym testem dla określenia jak dobry zespół. Co sądzisz o punktach? Czy nie zgadzasz się z którymkolwiek z nich? Czy mógłbyś coś dodać?

Casebash
źródło

Odpowiedzi:

41

Jeff Atwood ma Kartę praw programisty .

Z postu:

  1. Każdy programista powinien mieć dwa monitory
  2. Każdy programista powinien mieć szybki komputer
  3. Każdy programista powinien mieć wybór myszy i klawiatury
  4. Każdy programista powinien mieć wygodne krzesło
  5. Każdy programista powinien mieć szybkie połączenie z Internetem
  6. Każdy programista powinien mieć ciche warunki pracy

Wygląda na to, że zawiera pewne elementy, które chciałbym zobaczyć na liście Joela. Szczególnie w dziedzinie sprzętu (podwójny monitor, szybki komputer, mysz / klawiatura, wygodne krzesło, szybkie połączenie).

Jedyną rzeczą nie wymienioną jest posiadanie wygodnego i regulowanego biurka .

Można to wszystko dodać, zmieniając:

Obecny nr 9: Czy korzystasz z najlepszych narzędzi, które można kupić za pieniądze?

do

Ulepszony # 9: Czy używasz najlepszych narzędzi i sprzętu, które można kupić za pieniądze?

gąbka
źródło
Czy twój numer 6 nie jest identyczny z numerem 8 w teście Joela:
HerbN
To numer 6 Jeffa Atwooda i tak jest.
gąbka
Wygląda na to, że test Joela jest bardziej konkretny, aby pomóc programistom opracować czyste, wolne od błędów oprogramowanie w przeciwieństwie do warunków pracy, z wyjątkiem # 8
Archmede
13

Interesujące jest to, że punkt 8 brzmi teraz:

8. Do programmers have quiet working conditions?

kiedy czytał (coś w stylu)

8. Do programmers have their own office?

i ostatni akapit wciąż się zaczyna:

Teraz przenieśmy je do oddzielnych biur ze ścianami i drzwiami.

Zawsze byłem podejrzliwy wobec tego testu, ponieważ we wszystkich miejscach, w których pracowałem - zarówno jako pracownik, jak i gość - jedynymi osobami posiadającymi własne biura są dyrektorzy i kierownicy wyższego szczebla.

Pisanie oprogramowania w prawdziwym świecie jest zazwyczaj działaniem zespołowym, musisz porozmawiać z kolegami z zespołu, aby odesłać pomysły itp. I jest to trudniejsze w przypadku ludzi w oddzielnych biurach, nawet z systemami wiadomości błyskawicznych. Umiejętność rysowania i pokazywania kodu i diagramów ludzi bardzo pomaga. Nie oznacza to, że zespoły rozproszone nie mogą działać - oczywiście mogą i robią, to tylko inny zestaw problemów.

Powiedziałbym, że każdy zespół musi znajdować się we własnym biurze 6-8 osób (zakładając, że jest to wielkość zespołu). W ten sposób mogą wchodzić w interakcje bez przeszkadzania innym zespołom (jeśli takie istnieją) i kontynuować pracę bez przeszkadzania zespołowi sprzedaży lub odwiedzającym (w jednym miejscu, w którym pracowałem, wszedłeś przez drzwi wejściowe prosto do strefy rozwoju).

Jeśli pracujesz z innymi programistami, ale każdy pracuje nad oddzielnymi projektami, wspólne biuro może być przydatne - ale tylko wtedy, gdy ściśle przestrzegasz terminów spotkań w pokoju konferencyjnym i dotrzymujesz terminów innych osób itp.

Większość pozostałych to oczywiste prawdy.

ChrisF
źródło
9
Problem polegający na odrzucaniu pomysłów przez członków drużyny polega na tym, że PYTANIE werbalnie jest ogromną rozrywką. Jeśli potrzebujesz poważnej współpracy, pracuj w przestrzeni do współpracy. Ale w przypadku pytań „hej, jak byś to zrobił” lepiej korzystać z czatu.
Matt Olenik
@Matt - Jeśli chodzi o małe rzeczy, które masz rację, ale powierzchnia biurowa jest zawsze ograniczona - żadna firma nie chce wydawać pieniędzy na puste biura - dlatego pomaga w tym posiadanie zespołów we własnej przestrzeni. Możesz zmienić biuro w „przestrzeń współpracy”.
ChrisF
2
Nie możesz nigdy oznaczać ośmiu osób w tym samym pokoju, prawda? Już mnie denerwuje dzielenie pokoju z trzema innymi programistami (z których każdy pracuje nad swoimi własnymi sprawami, z których jeden pracuje nad całkowicie niezwiązanym projektem, a drugi jest facetem zaplecza / bazy danych). Wiem na pewno, że gdybym dzielił pokój z siedmioma innymi facetami, po prostu poszedłbym pocztą.
Baelnorn,
1
@ChrisF: może to jest problem. Czwórka z nas siedząca w tym samym pokoju prawie nie ma ze sobą nic wspólnego, jeśli chodzi o programowanie. To więcej niż 4 osoby pracujące nad 2 1/2 projektów siedzącymi w tym samym pokoju. A teraz dodaj szefa, który absolutnie nie ma nic przeciwko trzymaniu półgodzinnych dyskusji z innym programistą tuż przy biurku, mimo że sala konferencyjna znajduje się po drugiej stronie korytarza . >. <
Baelnorn
1
@ChrisF - „Pisanie oprogramowania w prawdziwym świecie jest działaniem zespołowym, musisz porozmawiać z kolegami z zespołu, aby podrzucać pomysły itp. I jest to o wiele trudniejsze w przypadku ludzi w oddzielnych biurach”. - Jak działają zespoły programistyczne rozmieszczone w różnych lokalizacjach? Blisko współpracowałem z ludźmi z USA, Brazylii lub Indii - IM i Adobe Connect - a także z lokalizacjami, od małych do bardzo dużych rozproszonych zespołów. Twoje środowisko jest bardzo destrukcyjne. Praca w zespołach może być wykonana efektywnie, ale to, co przepisujesz, jest niczym innym (twój pomysł jest od wodospadu z lat 70-tych)
luis.spinal
10

Podoba mi się, ale gdybym używał go do oceny firmy, nie ważyłbym jednakowo wszystkich przedmiotów. Brak kontroli źródła jest znacznie większym problemem niż kupowanie najlepszych narzędzi, które można kupić za pieniądze.

JeffO
źródło
9

Jedyny dla mnie przełom to:

 8. Do programmers have quiet working conditions?

Interesujące jest to pytanie, które najprawdopodobniej nie powiedzie się przy ogłoszeniach o przepełnieniu stosu.

Niektóre pytania są trudne do rozwiązania, szczególnie jeśli w firmie jest więcej niż jeden programista:

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

Większość innych mnie tak naprawdę nie obchodzi. Szczerze mówiąc:

12. Do you do hallway usability testing?

Można wykryć kłamców:

 5. Do you fix bugs before writing new code?
Tom Hawtin - tackline
źródło
20
Myślę, że byłbyś zaskoczony, jak wiele firm nie jest w stanie wykonać kompilacji w jednym kroku i nie ma bazy danych błędów. Prawdopodobnie masz rację co do kontroli źródła, ale twierdzę, że wiele firm używa go po prostu do tworzenia kopii zapasowych kodu i nawet nie zdradza korzyści płynących z kontroli źródła.
Rob Sobers
1
Kiedy zaczynałem przy obecnej pracy, mieliśmy system kontroli źródła, ale kompilacje były wykonywane na maszynie jednego faceta i tylko on znał wszystkie kroki, a błędy były śledzone na papierze. Wszystkie są teraz „naprawione”, ale nigdy nie przyjmę tych rzeczy za pewnik.
HappyCat
6

Muszę powiedzieć, że jest to dobra „linia bazowa”, ale przy każdym narzędziu pomiarowym istnieją inne czynniki. Na przykład żadna firma, dla której pracowałem, nie dokonała codziennych kompilacji (wiem, wiem), ale niektóre z nich były bardzo dobre.

Osobiście mam kilka innych elementów, które chciałbym dodać do listy.

  1. Czy wspierasz edukację programistów, biorąc udział w konferencjach, kupując książki lub coś takiego?
  2. Czy dysponujesz prostym, udokumentowanym procesem przyjmowania nowych narzędzi, jeśli jest to konieczne do wykonywania funkcji zadań
  3. Czy zapewniasz programistom sprzęt i środowisko, które pozwoli im na produktywność.

Przede wszystkim są to elementy, które „wkurzyły mnie” od poprzednich pracodawców, a teraz są to pytania przyspieszone, które zadaję o każdej okazji.

Sprzedawcy Mitchel
źródło
1
Nie ma 3 na liście?
Casebash
Tak, w takiej czy innej formie. Ale moje zestawiam trochę inaczej, więc zostawiłem je tam.
Mitchel Sellers
5

Zgadzam się z większością punktów Joela. Nie jestem pewien co do „testowania użyteczności na korytarzu”. Testy użyteczności, oczywiście, ale w rzeczywistości łapanie kogoś z korytarza i zmuszanie go do przetestowania twojego programu, nawet jeśli to nie jest ich praca? To wydaje się być świetnym sposobem na odstraszenie ludzi.

Tim Goodman
źródło
1
Z pewnością jest to kwestia kulturowa - jeśli nie powoduje nadmiernych zakłóceń i jeśli jest częścią sposobu funkcjonowania firmy, nie powinna „odhaczać ludzi” - zwłaszcza jeśli celem firmy jest tworzenie aplikacji.
Murph,
1
Może chodzi o to, że powinna być częścią pracy innych ludzi?
JeffO
7
cały sens testowania użyteczności korytarza polega na tym, że musi to być osoba, która nie używa regularnie programu. Po zbudowaniu go i / lub spędzeniu wielu godzin na korzystaniu z niego (jak dedykowany tester) Twoje spojrzenie na aplikację zostanie wypaczone
GSto
5

Test Joela nie sprawdza, jak dobry jest zespół. Sprawdza, jak dobrze twój zespół przestrzega testu Joela.

Oto lepszy test tego, jak dobry jest twój zespół. Nazywam to testem GrandmasterB. Ma jedno pytanie.

1) Czy pisane oprogramowanie jest dobre?

Nie ma dla mnie znaczenia, czy przeprowadzasz „test korytarza”, czy nie, czy masz kontrolę źródła lub proces kompilacji (jeśli taki istnieje - nie ma go każdy język). Prawdziwą miarą zespołu jest jakość tworzonego oprogramowania.

Zasadniczo możesz śledzić każdy krok testu Joela i nadal mieć bzdury i produkty, które nigdy nie są wysyłane. Na przykład kontrola źródła nie czyni magicznie lepszym koderem; ułatwia zarządzanie kodem. Posiadanie najnowszej wersji programu Visual Studio nie oznacza, że ​​aplikacja będzie działać lepiej niż gdyby została napisana w programie Visual Studio 2005 .

Grandmaster B.
źródło
14
Nie rozumiesz sedna sprawy. Test Joela nie polega na tym, jak dobre jest oprogramowanie, ale na tym, jak efektywny jest proces produkcji. Zespół, który nie przejdzie testu Joela, może nadal wytwarzać dobre produkty, ale są szanse, że potrwa to znacznie dłużej, a pracownicy będą nieszczęśliwi. Ponadto narzędzia nie odnoszą się tylko do oprogramowania. Oznacza to także sprzęt, od komputera po biurko i klawiaturę.
Matt Olenik,
Myślę, że brakuje ci sensu. Jeśli zespół kończy projekty na czas i produkuje dobrej jakości oprogramowanie, są one z definicji skuteczne. I mają z definicji skuteczny proces.
GrandmasterB
2
Nigdy nie wspominałeś o wysyłce na czas. Byłbym również bardzo zaskoczony, widząc skuteczny zespół, który nie zaliczył (całkowicie) testu Joela. Krytyczne znaczenie ma kontrola wersji, testowanie i użyteczność. Inne przedmioty mogą również stanowić całkiem spore przeszkody.
Matt Olenik
To dobra uwaga, ale główną słabością jest jej subiektywność. Każdy może mieć inne zdanie na temat jakości oprogramowania, w zależności od ich doświadczenia, poziomu umiejętności i perspektywy użytkowania. Ale podoba mi się to.
Bernard Dy
Jeśli ich skuteczny proces jest skuteczny tylko dla członków, którzy są w zespole, szczególnie jeśli zespół jest mały, jak dobrze poradzi sobie ze wzrostem lub w przypadku przedwczesnej katastrofy lub przejścia na emeryturę? Zdolność do stworzenia kodu, który działa dobrze i jest wysyłany na czas w procesie, który właśnie istnieje w głowach ludzi go rozwijających, jest receptą na katastrofę, zespół, który prędzej czy później (prawdopodobnie wcześniej) napotka problem, z którego większość ludzi nie może lub po prostu nie chce odzyskać.
Finni McFinger
5

Chociaż myślę, że ma to sens w ogólnym sensie, znalazłem listę dość skoncentrowaną na konkretnym rodzaju oprogramowania, które robi Fog Creek Software ( zawijanie ). Nie jest to zaskakujące, ponieważ mówi o tym w innym poście, Five Worlds . Poza tym światem jest wiele zmian.

Istnieją pewne warunki, które naprawdę nie mają większego sensu, jeśli tworzysz na przykład oprogramowanie wbudowane dla satelity lub automatu, takie jak codzienne wersje (3) lub testy użyteczności (12).

Khelben
źródło
Zgoda. Po odejściu od aplikacji „top of the stack” wiele współczesnych pomysłów wydaje się być… nieistotnych.
Paul Nathan
Zgadzam się. W korporacyjnych sklepach IT jest wiele prac programistycznych ... na pewno nie tak efektownych, jak tworzenie obkurczaczy. Ponieważ większość tych firm nie prowadzi działalności związanej z oprogramowaniem, większość z nich zazwyczaj otrzymuje około 4 punktów w teście Joela.
Bernard Dy
6
Dlaczego nie miałbyś tworzyć testów jednostkowych dla oprogramowania wbudowanego (i mieć je automatycznie uruchamiane przez system kompilacji)?
Peter Mortensen