@Sławku S. Osobiście określiłbym całość tak: craftsmanship manifesto, punkty 2-4 zawierają się w agile manifesto. Craftsmanship manifesto, punkt 1 rozszerza agile manifesto.

Odnośnie dodawania wartości. Mamy pierwszą iterację i wykonujemy jakiś interfejs. Jeśli całkowicie olejemy usability i pokażemy to klientowi, możemy być pewni, że w drugiej iteracji będziemy to poprawiać, może i od zera. Jeśli jednak zrobimy coś sensownego (niekoniecznie super), a klient stwierdzi, że interfejs jest dobry, to jest OK. Usability oceniają użytkownicy software’u, a nie jego twórcy – jeśli wystarcza, to czego chcieć więcej.

O punkcie pierwszym, czyli well-crafted software nie wypowiadałem się we wpisie, ponieważ na ten temat nie mam wyrobionego ostatecznego zdania. Z jednej strony bardzo ważny jest design i przewidywanie przyszłych problemów, z drugiej – KISS. Dlatego wydaje mi się, że chyba najlepszym sposobem zapewniania well-craftedness w agile’owych projektach jest refaktoring zgodnie z myślą Fowlera.

Przykład: klient mówi, że w aplikacji będzie kilka sposobów naliczania podatku – jeden najważniejszy, kluczowy dla klienta (P1) i inne o niskim priorytecie. Od razu więc rozważamy wzorzec strategii. OK, zrobione, software jest well-crafted. Kilka iteracji dalej dowiadujemy się od klienta, że będzie tylko jeden sposób naliczania podatku, bo firma ostatecznie nie weszła na rynek poza Polską. Efekt jest taki, że wzorzec strategii wprowadza tylko niepotrzebną komplikację kodu, a software już nie jest well-crafted. :)

A odchodząc od wyimaginowanych przypadków, a przechodząc do osobistych doświadczeń. Mnie chyba bardziej ciągnie do well-craftedness niż KISS. Sławek G. wie, że czasami zapominałem o KISS podczas pracy nad my.spartez.com.

Odnośnie mapowania manifestów AgileCraftsmanship to wszystko zależy od interpretacji (jak to z każdym manifestem bywa) – jak zauważył mój imiennik powyżej. Mówi się, że Agile z pozoru jest prosty więc wszystkim wydaje się, że zrozumieli.

W odniesieniu do Twojej interpretacji Craftsmanship miałbym następujące komentarze:

• dodawanie wartości nie jest jedynie „dawaniem klientowi działającego software’u co każdą iterację”. Klient płaci za to więc nic mu nie dodajemy. Dodawanie ma miejsce gdy wnosisz coś nowego – przykładowo o czym on np nie pomyślał na podstawie swojego doświadczenia (np dajmy na to aspekty usability).
• ma to ścisły związek z „productive partnerships” z 4. punktu – partnerstwo czyli nie jedynie wykonawstwo za pieniądze. Chodzi o coś więcej – o to czy np. zależy Ci na sukcesie produktu czy jedynie na stawce godzinowej/miesięcznej. Ale to głębszy problem, w który może być uwikłane partycypowanie w profitach projektu. Tego typu modele nie są u nas jeszcze popularne i pewnie długo nie będą z wieli względów.
• Odnośnie interakcji w zespole – owszem są ważne. Ale manifest mówi o tym w skali bardziej globalnej – w skali community.
• No i najważniejszy punktu: 1 – „well crafted” zamiast rzeźby w rzadkim g:)))

Bo może ty i ja (i kolega) rozumieją intuicyjnie co Agile Manifesto ma na myśli, ale jest cała kupa ludzi którzy zrozumieją jakoś inaczej – np „individuals and interactions” znaczy więcej status meetingów :-P

Czy mógłbyś jeszcze wskazać te elementy mojej prezentacji, które chciałbyś zgłębić, bo wydały się zbyt pobieżnie omówione, albo zainteresowały Cię szczególnie? Chciałbym rozwinąć temat na swoim blogu, może z innymi dodatkami (wiki, screencasty) i szukam pomysłów od czego zacząć.

Jeszcze raz dziękuję, że zostałeś do samego końca konferencji i mojej prezentacji. Opinie uczestników…bezcenne! Zapraszam na Javarsovia 2010. Bezpłatnie!