Zwinne szkolenie

Zeszłoweekendowa warsjava była chyba pierwszym większym Warszawskim spotkaniem ludzi zainteresowanych zwinnymi metodykami. Jej sukces (ponad 100 osób z tego co wiem i z tego co widziałem) pokazuje, że zwinne tematy są nie tylko ciekawe, ale przede wszystkim ważne. Idąc za ciosem zdecydowaliśmy się jako Pragmatists podzielić się naszą wiedzą i doświadczeniami dojścia do tego co osiągnęliśmy w większych szczegółach. A osiągnęliśmy myślę, że dość niezwykłą rzecz. Jesteśmy zespołem, który realizuje to o czym mówi: krótkie iteracje, TDD, programowanie w parach, prawdziwy shippable product na koniec każdej iteracji,  i wiele innych zwinnych praktyk wcielonych w życie. Ale przede wszystkim jesteśmy ukierunkowani na przynoszenie wartości, na pokonywanie barier i problemów, na dawanie swojego czasu, wiedzy, doświadczenia i zaangażowania naszym klientom. Staramy się skupiać na poprawianiu swojej efektywności i jakości.
Zdecydowaliśmy się więc zorganizować otwarte dwudniowe szkolenie ze Zwinnego Rozwijania Oprogramowania. Szkolenie planowane jest dla 15~20 osób zainteresowanych pogłębieniem swojej wiedzy w tym zakresie i zdobyciem nowych doświadczeń. Szkolenie prowadzić będę ja wraz z Krzyśkiem Jelskim, który na warsjavie i ostatniej javarsovii zajmował się tematem TDD oraz ma za sobą dobre parę lat doświadczenia pracy w zwinnych zespołach. Obiecujemy nie tylko masę wartościowej, konkretnej wiedzy, ale również dobrą zabawę pomagającą utrwalić i zweryfikować nowe umiejętności.

Szczegóły dotyczące szkolenia są tu: http://pragmatists.pl/szkolenie. W razie wątpliwości / pytań piszcie.
Zapraszam!

Po WarsJawie

W ten weekend była warsjawa. Kto nie był niech (raczej) żałuje. To chyba było pierwsze większe spotkanie w Warszawie dotyczące zwinnych metodyk. I na pierwszy rzut oka widać było, że brakuje takich spotkań. Po pierwsze - było chyba ponad 100 osób, co od razu wskazuje na to, że temat jest ciekawy. Po drugie - to, że trzeba takie spotkania organizowa widać po pytaniach. Masa dotyczących estymacji (o co w ogóle chodzi), długości i zawartości spotkań, itp. Czyli dość podstawowe.
Oczywiście świetnie, że ludzie chcą się uczyć i poznawać, z drugiej szkoda, że jest jeszcze tak mało doświadczeń.
Tak czy siak, Łukasz (wraz z resztą organizatorów): wielkie dzięki za zorganizowanie tego spotkania!

Jeśli ktoś chce przejrzeć moją prezentację (zanim organizatorzy wrzucą ją na parleys'a), to jest ona tu: 
I Twój zespół może być zwinny.

I jeszcze jedno. Strasznie mnie wkurza zwrot "w agile'u" (wielokrotnie słyszałem go na warsjawie). Po angielsku słowo agile jest przymiotnikiem. To tak jakby powiedzieć "w zwinny'u używamy iteracji" :-P
Zresztą większość zdań tego typu jest i tak nieprawdziwych - manifest zwinnego rozwijania oprogramowania bardzo mało mówi o konkretnych praktykach. Zamiast tego lepiej powiedzieć "w scrum'ie" albo "w XP" gdy odnosimy się do praktyk konkretnej metodyki.
Z drugiej strony, utożsamianie zwinnego myślenia (jako podejścia, filozofii) z konkretną metodyką jest również błędem (szczególnie częste jest to w przypadku scrum'a, i szczególnie nieprawdziwe) - metodyki definiują procesy i praktyki, nie skupiają się raczej na wartościach (no, poza XP oczywiście).

Wprowadzenie do zwinnego rozwijania oprogramowania

W związku ze zbliżającą się konferencją warsjawa (na której będę opowiadał o transformacji zespołów na zwinne metodyki), oraz brakiem czegoś podobnego w języku polskim, poświęciłem parę wieczorów i napisałem wprowadzenie do zwinnego rozwijania oprogramowania (zwykle nazywane jest to agile introduction).

W czasie warsjawy nie będzie żadnej prezentacji wprowadzającej do zwinnego myślenia i zwinnych metodyk, więc jeśli ktoś nie miał z nimi dotychczas praktycznego kontaktu, nieskromnie polecam!

http://pragmatists.pawellipinski.com/Downloads/Pragmatists%20-%20Zwinne%20Rozwijanie%20Oprogramowania.pdf

Przedwczesna optymizacja

Przeglądając stronę wikipedii dotyczącą eXtreme Programming znalazłem wśród praktyk programistycznych następujące zalecenie: 'leave optimization till last'. No i faktycznie zdaje się, że jest to dość uznana zasada. Przywołuje na myśl znane zdanie Donalda Knutha

Premature optimization is the root of all evil.

Z drugiej strony zwinne metodyki zalecają utrzymywanie projektu przez cały czas jego rozwoju w stanie gotowości do wdrożenia. Scrum nazywa to potentially shippable product - na koniec każdej iteracji przygotowujemy więc wszystko co niezbędne, żeby produkt tej iteracji można było wdrożyć (nie dlatego, żeby to faktycznie co iterację robić, tylko dlatego, by utrzymywać taką możliwość i dać klientowi prawo do decyzji co do tego kiedy chce aplikację wdrożyć, zaprezentować użytkownikom itp. Poza tym robiąc to jesteśmy pewni, że projekt jest cały czas zintegrowany, i że nasz system CI i proces tworzenia oprogramowania są dobre. No i jeszcze kwestia morale zespołu, gdy wie, że projekt jest non-stop w stanie jakościowo gotowym na produkcję).

Wracając do zostawiania optymizacji na koniec, zupełnie nie zgadzam się z tym. To klasyczny przypadek zostawiania gdzieś praktyk fazowych (waterfall'owych). Jak można nazwać aplikację potencjalnie gotową do wdrożenia, jeśli nie jest wystarczająca wydajnościowo?
Tak więc optymizujmy kod w czasie jego rozwijania. Może nawet warto dodać do Definition of Done zadań zespołu warunek akceptowalności pod względem wydajnościowym.

Oczywiście we wszystkim należy zachować umiar. Ważne jest, by wydajność była akceptowalna / zadowalająca. To może oczywiście oznaczać bardzo rygorystyczne warunki np. dla systemów RT. Szczegółowy fine-tuning wydajności jakichś elementów aplikacji można jednak faktycznie zostawić na później. To znaczy jak się już okaże, że faktycznie jest problem wydajnościowy i będzie wiadomo dokładnie gdzie. Oczywiście nie sądzę, żeby było dobrym pomysłem czekanie aż okaże się to w środowisku produkcyjnym - dla aplikacji dla których wysoka wydajność jest ważna można ją kontrolować stale w czasie rozwoju aplikacji w przeznaczonym do tego środowisku CI z automatycznymi testami wydajnościowymi. Natomiast powinniśmy dbać o nieograniczanie (głównie architektonicznie) naszych możliwości optymizacji.

Z resztą powyższy cytat z Knuth'a nie jest kompletny (a większość programistów zna tylko ten jego fragment). Kompletny brzmi tak:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.