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

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ć?

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?

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.

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.

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?

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.

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.

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 .

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).