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

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.

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.

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 są 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?

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.

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?

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.