Początki Agile

Nawet jeśli Twój zespół deweloperski nie przeszedł jeszcze na metody zwinne, takie jak Scrum czy Extreme Programming, bardzo prawdopodobne jest, że przynajmniej rozważa taki krok. „Agile" faktycznie mierzy się z niektórymi największymi problemami, które dręczyły zespoły programistyczne od dziesięcioleci. Wielu product managerów, projektantów i specjalistów ds. zapewnienia jakości jest jednak początkowo zdezorientowanych Agile, bo nie są jeszcze zaznajomieni z własnymi rolami w metodykach zwinnych. Metodyki te z pewnością wymagają tych ról, jednak dezorientację tę przypisuję korzeniom metod zwinnych. Aby wyjaśnić problemy, które „Agile" ma rozwiązywać, i aby dowiedzieć się, jakie wyzwania nadal pozostają, warto, abym opowiedział o początkach Agile.

Wiele osób jest zaskoczonych, gdy dowiaduje się, jak długo istnieje Scrum – najbardziej znana metoda zwinna. Powstał w 1986 roku w Japonii. (To przykład tego, jak długo może minąć, zanim nowy pomysł wreszcie przebije się do mainstreamu.)

Korzenie Agile tkwią w oprogramowaniu na zamówienie

Najważniejsze jest jednak to, że metodyki te wywodzą się ze świata oprogramowania na zamówienie (custom software).

Tworzenie oprogramowania na zamówienie – czyli oprogramowania dla określonego celu i dla konkretnego klienta – przez długi czas było niezwykle trudną formą wytwarzania oprogramowania. Po części wynika to z faktu, że klienci notoryjnie nie wiedzą dokładnie, czego chcą. Mają jednak pewną potrzebę i podpisują umowę z firmą wytwarzającą oprogramowanie na zamówienie lub zasiadają z wewnętrznymi specjalistami IT, którzy mają się tym zająć. Gdy następuje dostarczenie produktu, klienci zazwyczaj mówią, że to nie to, o co im chodziło, i wszystko zaczyna się od nowa przy rosnącej frustracji. Podstawowa potrzeba jednak pozostaje i to zapewniło niepoliczalnym programistom, firmom i dostawcom usług pracę.

Ponadto, przy tworzeniu oprogramowania na zamówienie, przez długi czas stawiano na przegranej pozycji, jeśli chodziło o zatrudnianie i pozyskiwanie najlepszych talentów programistycznych. Wynika to częściowo z tego, że profesjonaliści wolą pracować w firmach tworzących oprogramowanie dla tysięcy lub nawet milionów klientów. Jednym z powodów jest to, że profesjonaliści otrzymują wyższe wynagrodzenie w firmach, których zespoły produktowe mają tworzyć oprogramowanie, którego pragnie wiele osób – bo inaczej nie zarabiają. Firmy te wiedzą, że muszą zatrudniać dobrych ludzi, aby tworzyć udane produkty, i odpowiednio wynagradzają. Jednak tylko niewielki odsetek programistów pracuje przy oprogramowaniu standardowym; większość tworzy oprogramowanie na zamówienie.

Jaka jest przewaga Agile?

Ponieważ w przypadku oprogramowania na zamówienie klient zakłada, że wie, czego chce, rola product managera jest tam rzadkością. Podobnie prawie nigdy nie spotyka się tam projektantów User Experience. Powody są dość złożone i obejmują pewną dozę ignorancji (niewielu w świecie oprogramowania na zamówienie wie, czym zajmują się projektanci UX i po co są potrzebni) oraz wrażliwość na koszty (redukcja kosztów przez zlecenie projektowania programistom). Trzeba uczciwie przyznać, że nielicznych projektantów istniejących w naszej branży natychmiast przejmują firmy produktowe, które zrozumiały, jak ważni są projektanci. Dlatego dla zespołów tworzących oprogramowanie na zamówienie prawie nie zostaje już projektantów do dyspozycji, gdy menedżerowie w końcu zdali sobie sprawę, że ich potrzebują. Podobnie zapewnienie jakości jako odrębna dyscyplina jest rzadkością przy oprogramowaniu na zamówienie, więc od programistów oczekuje się, że przejmą również testowanie.

Kolejnym ważnym elementem zrozumienia świata oprogramowania na zamówienie jest to, że większość projektów jest stosunkowo małych i ma wspierać wewnętrzne działania firmy – np. dział kadr, rozliczenia, produkcję itp. Są to zatem obszary, w których istnieje tylko ograniczona liczba użytkowników, a takie kwestie jak skalowalność i wydajność zazwyczaj nie są aż tak istotne.

Proces kaskadowy

Dawniej przy oprogramowaniu na zamówienie potrzebny był proces kaskadowy, ponieważ różni interesariusze potrzebowali sposobu na śledzenie postępów w trakcie długotrwałego procesu wytwarzania żądanych aplikacji. Właściwie to właśnie tutaj ma swój początek metodologia kaskadowa.

Przy oprogramowaniu standardowym, kupowanym ze względu na jego działanie i zalety, wprowadzono pewne role. Product manager ma zbierać i reprezentować potrzeby wszystkich klientów. Projektanci mają tworzyć użyteczne i pożądane doświadczenia użytkownika, a testerzy z działu zapewnienia jakości mają weryfikować, czy oprogramowanie działa tak, jak obiecano klientowi w materiałach marketingowych.

Rozwiązanie problemów kaskadowych przyniosły metody zwinne

Przy oprogramowaniu na zamówienie nadal pojawiały się te same problemy, gdy chodziło o stworzenie czegoś, co zadowoli klienta. Szczególnie dla tych zespołów metody zwinne oznaczają znaczącą poprawę. Komunikacja między klientami a programistami ulega poprawie. Ryzyko zostaje znacznie ograniczone dzięki mniejszym i częstszym iteracjom. Klienci mogą znacznie szybciej sprawdzić, czy coś im odpowiada, niż gdyby nadal czekali na zakończenie długotrwałego procesu. Metody zwinne pomagają też wprowadzić nowoczesne koncepcje testowania oprogramowania i oszczędzają zespołom godzin spędzonych na tworzeniu dokumentów, które i tak prawie nikt nie czyta i które szybko tracą aktualność.

Agile dla oprogramowania na zamówienie i standardowego

Zasadniczo te zalety oczywiście dotyczą też oprogramowania standardowego, ale zawsze podkreślam, że wtedy konieczne są pewne dostosowania. Innym obszarem, w którym pojawiały się trudności, jest architektura oprogramowania.

Metody zwinne zachęcają programistów, by nie przywiązywali się zbytnio do swojego sposobu realizacji, bo wszystko ma być szybko i łatwo weryfikowalne lub zmieniane. Choć przy oprogramowaniu na zamówienie często działa to dobrze, takie podejście jest zbyt naiwne np. dla dużych usług internetowych obsługujących setki, tysiące lub miliony użytkowników.

Nie jest więc zaskoczeniem, że wiele zespołów pracujących nad oprogramowaniem standardowym miało problemy z metodami zwinnymi, ponieważ korzenie metod zwinnych tkwią w oprogramowaniu na zamówienie. Liczne książki, artykuły i kursy, które nie wspominają ani o product managerach, ani o projektantach User Experience (Interaction Designerach i Visual Designerach), nie są przeznaczone do wytwarzania oprogramowania standardowego.

Zespoły chcące przejść na metody zwinne w wytwarzaniu oprogramowania powinny wcześniej sprawdzić, czy firma, która ma pomóc ich organizacji, rozumie też, czego wymaga oprogramowanie standardowe. Nie zawsze tak jest, ale wystarczająco często.