O tym jak zwinnie budować niezawodne systemy przeczytać możecie w Manifeście Agile. 15 lat temu grupa 17-stu osób spotkała się w górach w okolicy Salt Lake City i spisała dokument, który zapoczątkował zmianę myślenia osób tworzących oprogramowanie. Składa się on z 4 głównych wartości oraz 12 zwinnych zasad. Zacznijmy od tych pierwszych.
Ludzie i interakcje ważniejsze są od procesów i narzędzi
Aktualnie istnieje wiele świetnych technik i narzędzi ułatwiających tworzenie oprogramowania. Jednak założenie, że same techniki pomogą zespołowi szybciej zakończyć projekt jest błędne. Najważniejsi są ludzie i jeśli oni nie są przekonani do danych procesów lub narzędzi to nie będą korzystać z nich w wydajny sposób. Wszyscy jesteśmy przecież żywymi istotami i każdy z nas ma swoje przyzwyczajenia, preferencje. Dlatego tak ważne jest, żeby zrozumieć wszystkich współpracowników, rozmawiać z nimi i przed wprowadzeniem jakiegoś procesu przekonać do niego cały zespół.
Działające oprogramowanie ważniejsze jest od szczegółowej dokumentacji
W wielu firmach nadal można znaleźć na półkach zakurzone segregatory i mnóstwo bezużytecznych pdf-ów z dokumentacją, z której nikt nie korzysta. Zwinne zespoły odchodzą od tego i bardziej cenią sobie działające oprogramowanie. Działające oznacza tu przynoszące wartość, czyli krótko mówiąc pieniądze. Nie oznacza to, że dokumentacja nie jest w ogóle potrzebna. Należy jednak zwrócić uwagę, że to nie ona odgrywa główną rolę, a jej celem jest ułatwienie zrozumienia i tworzenia oprogramowania. Jedną ze zwinnych metod tworzenia dokumentacji wbudowanej już w samo oprogramowanie są testy. Bardzo często dokumentacja pisana jest przez osoby tworzące oprogramowanie, dlatego taka forma jest z pewnością przyjemniejsza dla programistów.
Współpraca z klientem ważniejsza jest od negocjacji umów
Zespoły zwinne nie powinny traktować się tak, jakby zawierały między sobą kontrakty. W przypadku błędu łatwiej byłoby zrzucić odpowiedzialność na inny zespół i uniknąć krytyki przełożonego. Pamiętajmy, że wszyscy powinni być traktowani jak członkowie jednego zespołu. W podejściu zwinnym znajdziemy Product Owner’a (niekoniecznie musi siedzieć w kodzie), który traktowany jest jak współpracownik, a nie klient, z którym musimy coś negocjować. Ułatwia to współpracę i pozwala skupić się na tym co jest najważniejsze, czyli na tworzeniu oprogramowania.
Reagowanie na zmiany ważniejsze jest od realizacji założonego planu
Praca ściśle z ustalonym planem nie zawsze jest dobra. W momencie, kiedy plan okazuje się błędny tracimy czas i energię na wytworzenie czegoś niepotrzebnego klientowi. Ważne jest, żeby cały czas reagować na zmiany i potrzeby użytkowników. Należy często rozmawiać z klientem i uwzględniać jego nowe pomysły. Łatwiej jest zmienić coś we wcześniejszych etapach wytwarzania produktu.
Połączenie wszystkich tych wartości i stosowanie ich w swoich zespołach prowadzi do bardziej efektywnego wytwarzania oprogramowania. Pamiętajmy jednak, że samo stosowanie zwinnych technik jest niczym. Najważniejsza jest zmiana myślenia i to od niej należy zacząć.