Metodologia i procesy wytwarzania są narzędziami wspierającymi projekt – nie odwrotnie!

Unikamy nadmiaru biurokracji. W wielu projektach bardzo dużą ilość czasu pochłania zaspokojenie różnorakich wymagań formalnych: raportowanie, przygotowywanie analiz ryzyka (i strata cennego czasu na filozoficzne dyskusje o tym, co jest ryzykiem, a co nie) itd. Oczywiście tego typu dokumenty muszą zostać dostarczone, zwłaszcza w firmach funkcjonujących w oparciu o złożone struktury organizacyjne – dlatego piszemy je, jeśli jest to niezbędne. Ale nasza filozofia jest prosta: im jest ich mniej, tym lepiej.

Nie trzymamy się również sztywno jednej metodologii. To wspaniałe, że metodyki zwinne (Agile development) przyjęły się już w świecie wielkich korporacji. Niestety, są one często przestrzegane nazbyt rygorystycznie: czy naprawdę jest aż tak bardzo istotne, by każda historia (story) rozpoczynała się od słów „Jako użytkownik, chcę…”? Czy spotkania statusowe muszą odbywać się dokładnie raz dziennie, tylko dlatego, że metodyka tak mówi? Dogmatycznie traktujemy tylko jedną regułę: to zasady formalne powinny wspierać projekt, nie odwrotnie. W przeciwnym wypadku moment przekazania gotowego programu klientowi nieubłaganie się oddala.

Ludzie i ich współdziałanie nad procedury i narzędzia.
Działające oprogramowanie nad wyczerpującą dokumentację.
Współpraca z klientem nad negocjację umów.

Metodyki zwinne

Projekt jest podzielony na tygodniowe okresy - iteracje. Pod koniec każdego tygodnia planujemy jakie funkcje programu i błędy zostaną zaimplementowane i naprawione w kolejnej iteracji.

W czasie, gdy zespół programistów pracuje nad stworzeniem nowych funkcjonalności i naprawieniem zgłoszonych błędów, analitycy opracowują specyfikację dalszych modułów. Zazwyczaj wiemy z jedno- lub dwutygodniowym wyprzedzeniem, które funkcje aplikacji będą wkrótce wymagały zaimplementowania, dlatego mają one pierwszeństwo przy opracowaniu.

Programowanie zwinne wymaga, by przez cały czas prac nad systemem była dostępna jego działająca wersja. Choć początkowo aplikacja może mieć bardzo ograniczone możliwości, stopniowo się one zwiększają. Istotne jest, że odzwierciedla ona aktualny etap rozwoju systemu i może być testowana i oceniana przez analityków oraz przyszłych użytkowników.

Komunikacja to podstawa

Komunikacja to podstawa: jeśli nie pamiętasz (lub nie jesteś nawet w stanie wymówić) imion swoich współpracowników, jesteś na dobrej drodze do porażki.

Komunikujemy się – w ramach samego zespołu, z klientami i użytkownikami - tak często jak to tylko możliwe. Wielu nieporozumień można uniknąć, jeśli odpowiednio szybko wyjaśni się wątpliwości. Jedynym sposobem uzyskania odpowiedzi na pytania jest rozmawianie z ludźmi.

Dzięki naszemu procesowi wytwarzania oprogramowania, już od samego początku prac nad projektem dysponujemy działającą (choć oczywiście niekompletną) wersją aplikacji. W ten sposób klient widzi postęp prac zgodny z rzeczywistością, a nie swoimi wyobrażeniami lub naszymi obietnicami. Może nam na bieżąco zgłaszać uwagi i wskazywać elementy wymagające korekty.

Analitycy stale współpracują z programistami i natychmiast odpowiadają na zadawane przez nich pytania – wyjaśnienie danego aspektu systemu zajmuje zwykle mniej czasu niż wypicie filiżanki kawy. Dzięki poświęceniu tych kilku minut, projekt może być realizowany bez zbędnych opóźnień. W ten sposób oszczędzamy godziny.

Dzięki współczesnym technologiom komunikacja jest tak łatwa, jak nigdy przedtem. Jednak niezwykle istotny jest też dla nas bezpośredni kontakt z drugim człowiekiem. Tak, używamy Skype’a i doceniamy jego użyteczność, ale spotykamy się też osobiście przy kuflu piwa (lub szklance wody, jeśli ktoś przyjechał samochodem). Bezpośrednia znajomość członków zespołu jest niezbędna do wydobycia z każdego z nas tego, co ma najlepsze. Obcy sobie ludzie nie są w stanie stworzyć zgranej i efektywnej drużyny.