Czy zwinny sklep może naprawdę zdobyć 12 punktów w teście Joela? [Zamknięte]

18

Naprawdę podoba mi się test Joela, sam go używam i zachęcam moich pracowników i rozmówców do uważnego rozważenia go. Jednak nie sądzę, żebym kiedykolwiek zdobył więcej niż 9, ponieważ kilka punktów wydaje się zaprzeczać Manifestowi Agile, XP i TDD, które są fundamentem mojego świata.

W szczególności: pytania dotyczące harmonogramu, specyfikacji, testerów i cichych warunków pracy są sprzeczne z tym, co próbujemy stworzyć, i wartościami, które przyjęliśmy, by być naprawdę zwinnym.

Moje pytanie brzmi więc, czy prawdziwy sklep Agile może zdobyć 12 punktów?

Edytować:

Na zalecenie poniżej udzielonego przeze mnie odpowiadającego dodaję link do mojego bloga, na którym pisałem o tym, co skłoniło mnie do opublikowania tutaj pytania.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Wkładam to, ponieważ zgadzam się z większością tego, co zostało powiedziane poniżej i chciałem zadeklarować swoje pełne stanowisko.

Szymon
źródło
3
Jestem sceptycznie nastawiony do pojęcia „prawdziwego sklepu Agile”, ponieważ sugeruje, że istnieje jeden określony sposób, który musi być przestrzegany przez wszystkie zespoły programistów. Również odpowiedź na to pytanie będzie się różnić w zależności od dokładnie zastosowanej metodologii. Zwinne to zbiorowe określenie wielu podejść.
JohnFx,
masz rację, używamy XP, ale chciałem prowadzić tak szeroką rozmowę, jak tylko mogłem.
Simon
3
Nie. Nigdy nie jest to możliwe. Dzięki temu Joel może zwabić cię do swojego towarzystwa, sprawiając, że myślisz, że są lepszym miejscem do pracy, ale wtedy zniewoli cię, a ty będziesz trudzić się w jego podziemnych kopalniach na zawsze! Mwahahahaaaaa!
FrustratedWithFormsDesigner

Odpowiedzi:

21

Mój punkt widzenia jako agilisty:

Czy korzystasz z kontroli źródła?

Tak, oczywiście, ciągła integracja, część XP potrzebuje systemu kontroli źródła, aby móc przypisać do niego kod.

Czy potrafisz wykonać kompilację w jednym kroku?

Tak, jest do tego serwer ciągłej integracji.

Czy robisz codzienne kompilacje?

Jeśli możemy to zrobić w jednym kroku, możemy to zaplanować.

Czy masz bazę danych błędów?

Tak, każde narzędzie do zarządzania „Agile project” może śledzić błędy i dodawać je do zaległości produktu scrum

Czy naprawiasz błędy przed napisaniem nowego kodu?

Tak, są one traktowane priorytetowo w rejestrze produktów

Czy masz aktualny harmonogram?

Tak, zawsze, dzięki zaległościom produktu, zaległościom iteracyjnym, planowi wydania i dokładnym oszacowaniom, które towarzyszą temu dzięki Planning Poker.

Czy masz specyfikację?

Tak, w razie potrzeby każda historia użytkownika zawiera więcej szczegółów. Zachęcamy również do komunikacji między właścicielem produktu a zespołem.

Czy programiści mają ciche warunki pracy?

Tak, pokój z 8 deweloperami jest zwykle bardzo cichy. Staramy się nie umieszczać sprzedawców w tym samym pokoju.

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

Tak, choć cenimy sobie jednostki nad narzędziami, nie martw się Joel, kupujemy licencję na wszystkie twoje produkty;)

Czy masz testerów?

Tak i stanowią integralną część zespołu.

Czy nowi kandydaci piszą kod podczas rozmowy kwalifikacyjnej?

Tak, a zespół bierze udział w tym procesie.

Czy wykonujesz testy użyteczności korytarza?

Tak, nasi testerzy pomagają nam w tym.


źródło
26
Nigdy nie widziałem pokoju, w którym więcej niż 3 programistów byłoby cicho.
whatsisname
3
@whatsisname: na pewno gra w Quake 3;)
5
Cisza nie oznacza śmierci. Oznacza to, że nie ma żadnych zakłóceń, gdy chcesz dostać się do strefy. Mały zespół pracujący razem (zwinne warunki pracy) w oderwaniu od reszty (właściciel produktu pilnuje, aby nie przeszkadzać programistom w trakcie iteracji) jest cichy i stymulujący. Muzyka jest w porządku, czat jest w porządku.
helios
3
@ Simon: „Nie mogę nazwać historii użytkowników„ specyfikacjami ””. „Nie mogę nazwać naszej działalności związanej z planowaniem i opracować„ harmonogram ”. W takim przypadku zaktualizuj pytanie o swoje konkretne problemy. To są najlepsze praktyki Agile. Jeśli ich nie lubisz, wyjaśnij, dlaczego odrzucasz te dwie najlepsze praktyki Agile. „Z trudem nazywam też naszych inżynierów ds. Jakości testerami” To osobisty problem - nie ma nic wspólnego z Agile.
S.Lott,
10
+1: „Staramy się nie umieszczać sprzedawców w tym samym pokoju”. Czy mogę dla ciebie pracować?
Tom Morgan
6

Czy masz aktualny harmonogram?

To jest zwinne. Scrum wymaga od nas zobowiązania się do wydania. Posiadanie aktualnego harmonogramu oznacza wiedzieć, co zostanie zrobione (i nie zostanie zrobione) w wersji oraz jak wygląda zaległość.

Czy masz specyfikację?

To jest zwinne. Architektura (i powiązany opis) jest niezbędna. To określa formę. Przypadki użycia (lub historie użytkowników) są niezbędne i określają funkcjonalność.

Czy programiści mają ciche warunki pracy?

Nie widzę, jak Agile wymaga hałaśliwego, zakłócającego i irytującego środowiska.

Czy masz testerów?

Um. Kiedy robimy TDD, że testerzy. Gdy przekazujemy kod właścicielowi produktu, przed zaangażowaniem klientów mogą być zaangażowani dodatkowi testerzy.

W jaki sposób przeczy to metodom Agile lub manifestowi Agile?

S.Lott
źródło
4

Myślę, że odpowiedź brzmi tak, sklep Agile powinien być w stanie to zrobić. Specjalnie do twoich punktów.

  • Planowanie polega na jasnym zdefiniowaniu funkcji, które zamierzasz rozwiązać. To zdecydowanie możliwe do osiągnięcia.
  • „Ciche warunki pracy” nie dotyczą dźwięku w miejscu pracy, lecz eliminują hałas niezwiązany z projektem / programowaniem. Chodzi o to, aby programiści nie musieli wkładać wysiłku, aby zablokować rozproszenie
  • Sprawne sklepy powinny testować wcześnie, a tak naprawdę chodzi o to, żeby ktoś inny niż programista testował kod, tak naprawdę chodzi o Joela.
jzd
źródło
3

Jak myślisz, dlaczego posiadanie harmonogramu (na przykład) jest niezgodne z programowaniem Agile?

Jest bardzo mało prawdopodobne, że będziesz pracować od sprintu do sprintu, absolutnie nie mając pojęcia, dokąd chcesz iść ze swoim produktem. Tak, po każdym sprincie będziesz musiał ponownie sprawdzić i skorygować harmonogram, ale nadal będziesz go mieć.

Po stwierdzeniu typu „w pierwszym kwartale planujemy wydać funkcje A, B, C, aw drugim kwartale obecnie przyglądamy się funkcjom X, Y, Z” nadal jest harmonogramem. Istnieje każda szansa, że ​​X stanie się W, ale to pozwala ci być zwinnym.

Wzięcie kolejnej rzeczy z listy - specyfikacji. Co to jest historia użytkownika, jeśli nie specyfikacja?

ChrisF
źródło
1
Być może semantyka, ale są to bardzo obciążone terminy. Plan wydania, z którym się zgadzam. Nie mam harmonogramu. Twierdzę, że nie masz pojęcia, nad czym dokładnie będziesz pracował nad jedną iteracją. Wiesz, co zamierzasz zrobić, ale prawdopodobnie nie zawsze będzie się tego trzymał. Czy nie o to chodzi w byciu zwinnym? Problem polega na tym, że jeśli mówię „harmonogram” komukolwiek spoza dewelopera, mają one pewne oczekiwania i celowo nie trzymam się wielu z nich. Co gorsza, jeśli zapytam „czy masz harmonogram?”, Wtedy ktoś, kto ma milową mapę GANTT, również powie „tak” i nie można mi tego odróżnić.
Simon
1
@Simon - przypuszczam, że jest to semantyka, ale argument wciąż trwa. Te rzeczy nie są całkowicie niezgodne z metodologiami Agile.
ChrisF
0

Myślę, że spojrzę na to z innej perspektywy niż większość tutaj. Jeśli zdobywasz 9 w teście Joela, wyprzedzasz krzywą. Wiele miejsc walczyłoby o trafienie 5 lub 6, a tym bardziej od 9 do 12.

Czy masz trudności z zatrudnieniem dobrych ludzi? Jeśli nie, to 12 w teście Joela, choć szlachetny cel, może nie być problemem. Jeśli Twoi pracownicy są w stanie funkcjonować w środowisku, które masz, powiedziałbym, że dobrą robotą jest ocenianie tak wysoko, jak Ty.

Jesse McCulloch
źródło
Myślę, że moje obecne miejsce pracy ma około półtora, a inne miejsca, które widziałem, są mniejsze. 6 byłoby super.
sevenseacat
Tak, dokładnie. Trafiliśmy 4 ...
Jesse McCulloch
Nie sądzę, że widziałem nigdzie, za 15 lat, który uzyskałby wynik wyższy niż 2.
Carson63000,