Jak aktualny jest test Joela? [Zamknięte]

Zamknięte . To pytanie jest oparte na opiniach . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby można było na nie odpowiedzieć faktami i cytatami, edytując ten post .

Zamknięte 6 lat temu .

Chcę przekonać moich partnerów, że powinniśmy mieć specyfikację i że błędy powinny zostać naprawione przed napisaniem nowego kodu. Czy powinienem odwołać się do testu Joela ? Czy uważasz, że test Joela jest aktualny? Myślę, że brak specyfikacji to złe zarządzanie projektami. Czy zgadzasz się z testem Joela? Czy możesz coś dodać Nie wspomina na przykład o Open Source.

issue-tracking specifications joel-test

— Niklas
źródło

Test Joela dotyczy procesów tworzenia oprogramowania i zatrudniania programistów. W jaki sposób jest związany z tym licencjonowanie oprogramowania lub czy publikujesz lub nie publikujesz swojego źródła?

— Marjan Venema

Dzięki Marjan za pytanie. Myślałem, że odkąd wymyślono test Joela, Open Source jest trendem i jeśli ktoś bardzo negatywnie odnosi się do Open Source, prawdopodobnie chciałbym wiedzieć, w jaki sposób zespół jest przeciwny otwartemu źródłu, jeśli tak jest. Zgadzam się, że problemy z prawami autorskimi mogą wykraczać poza zakres, ale programista nie może współpracować z zespołem, który uważa, że open source to kwestia możliwości przeglądania źródła, a także pytanie 13 może brzmieć „Czy masz system tworzenia kopii zapasowych?” i 14 „Czy masz silniejsze zabezpieczenia niż MD5?” gdzie odpowiedzi powinny być tak.

— Niklas

Ok, to ma sens. Wysiłki związane z otwartym oprogramowaniem powinny być nie tylko „konsumowane”, ale także przyczyniać się, choć niekoniecznie, za pomocą kodu (pomyśl wsparcie finansowe). Systemy tworzenia kopii zapasowych są ważne, ale nie ograniczają się do rozwoju, i dlatego nie dodam ich do testu Joela. Ale gdybym przeprowadził wywiad z firmą, która nie zrobiła nic z kopiami zapasowymi, pobiegłbym do drzwi. Bezpieczeństwo też nie dodałbym. W przypadku bezpieczeństwa opracowanego oprogramowania może to nie stanowić problemu (aplikacje wewnętrzne), więc nie daje odpowiedzi tak / nie, a bezpieczeństwo nie musi być specyficzne dla rozwoju.

— Marjan Venema

Dziękujemy za podzielenie się ze mną wiedzą. To prawda, że tworzenie kopii zapasowych jest ważne, ale nie zależy od rozwoju.

— Niklas

Wiele dobrych pytań generuje pewien stopień opinii w oparciu o doświadczenie ekspertów, ale odpowiedzi na to pytanie będą zwykle prawie w całości oparte na opiniach, a nie na faktach, referencjach lub konkretnej wiedzy specjalistycznej.

— komar

Odpowiedzi:

Myślę, że test Joela jest aktualny - jest tak samo aktualny jak inne oprogramowanie, które jest „ponadczasowe”.

Robienie produktu (w tym tworzenie oprogramowania) bez specyfikacji to tylko szaleństwo.

Skąd wiesz, gdzie chcesz iść?

Jest tylko jedna kwestia, którą powiem na temat pisania specyfikacji (tak naprawdę nie sądzę, że specyfikacje Joela są bardzo dobre ... lepsze niż nic, ale nie tak dobre, jak mogłoby być). Chodzi o to:

Pisząc specyfikację, mów tylko to, co musi zrobić produkt, a nie jak to zrobić.

Oznacza to, że nie dyktujesz szczegółów implementacji w specyfikacji. To działalność projektowa i pozostawiasz to doświadczeniu i kreatywności projektantów.

[Jest tylko jeden wyjątek od tej reguły: czasami określony lub implementowany szczegół jest wymagany lub wymagany, w którym to przypadku należy go wprowadzić. Na przykład, jeśli oprogramowanie musi być napisane w PHP i nie podlega negocjacjom, wtedy wchodzi specyfikacja Powinno być bardzo mało takich przypadków.]

Mogę dodać: brak śledzenia błędów jest aktem równego szaleństwa. Jest to po prostu najbardziej nieprofesjonalny i głupi sposób działania i doprowadzi do wielkiego bólu i cierpienia.

— szybko
źródło

Dzięki za bardzo szybką i cenną odpowiedź. Innym przykładem szaleństwa, które do mnie dotarło, było stwierdzenie, że wszystko powinno mieć ten sam priorytet. Wygląda na to, że postępowanie przeciwne do tych szalonych zasad doprowadzi do sukcesu.

— Niklas

„wszystko ma taki sam priorytet” - znane również jako „wszystko jest na pierwszym miejscu”. To jest szczera bzdura. Wszystko powinno być traktowane priorytetowo, brutalnie, w kategoriach SZKODY DLA BIZNESU. Następnie pracujesz nad numerem 1. Jeśli z jakiegoś powodu zatrzymałeś się na numerze 1, pracujesz nad numerem 2. I tak dalej. Jeśli masz ludzi, którzy z jakiegoś powodu nie mogą pracować nad numerem 1 i kończą nad numerem 9 - to w porządku, pod warunkiem, że istnieje dobry powód. („Czułem, że to i jego wspólna podróż” NIE jest dobrym powodem). Zmiana priorytetów jest również OK. Robienie tego częściej niż raz w tygodniu jest również szaleństwem.

— szybko_now

Dzięki za mądrość. Zgadzam się całkowicie, że wszystkim należy nadać priorytet. Mój partner stwierdził również, że nie powinniśmy mieć problemów ani narzędzia do śledzenia problemów. Ale uważam, że dokumentowanie problemów jest słuszne i nawet lider rynku utrzymuje narzędzie do śledzenia problemów. Ponownie, działanie przeciwne od reguły będzie działać ...

— Niklas

@ 909Niklas Prawdopodobnie powinieneś poszukać innego partnera, aby twoje przyszłe życie było wygodniejsze ...

— Marcel

+1 tylko dla: Pisząc specyfikację, mów tylko to, co produkt musi zrobić, a nie jak to zrobić.

— Marcel

Będę tu grał adwokata diabła i sugeruję, że Test Joela nie jest aktualny. To jest zbyt ogólne. W miarę dojrzewania technologii pytania powinny być bardziej szczegółowe niż w momencie pisania testu.

Dokumenty specyfikacji, przynajmniej duże wstępne dokumenty specyfikacji nie są już potrzebne, ponieważ mamy historie użytkowników i zwinne procesy programistyczne. To pytanie należy zmienić na „Czy poziom dokumentacji jest odpowiedni do opracowywanych rozwiązań?” Mniejsze, ściślejsze historie użytkowników dostarczane co dwa tygodnie są znacznie bardziej przydatne w większości przypadków niż obszerny dokument opisujący szczegółowo produkt. Jeśli jednak budujesz kolejnego łazika Mars, możesz potrzebować szczegółowego dokumentu projektowego. Gdybyś zapytał, czy firma ma specyfikacje projektowe, nie byłbym zaskoczony, gdy usłyszałbym odpowiedź „nie do końca, używamy zwinnych procesów i historii użytkowników”.

Po drugie, pytanie „codzienne wersje” powinno zmienić się w pytanie o ciągłą integrację. O ile nie budujesz oprogramowania, którego budowa zajmuje wiele godzin (co nie zajmie 99,99% miejsc), należy zadać pytanie, czy firma stosuje ciągłą integrację.

Większość testu Joela naprawdę się nie datowała. To wciąż dobry sposób na uzyskanie informacji o środowisku pracy.

— Stephen
źródło