Dlaczego Agile nie jest dobry do budowania oprogramowania wysokiej jakości?

Agile polega na upewnieniu się, że buduje się właściwy produkt, a nie na tym, że budujesz produkt we właściwy sposób. Dzięki Agile nie zbudujesz samolotu, gdy klient potrzebuje tylko samochodu. Ale jeśli już wiesz, że twój klient potrzebuje samochodu, Agile nie pomoże ci skutecznie zbudować niezawodnego samochodu. Jeśli Twoja firma ma problemy z jakością oprogramowania lub chce osiągnąć doskonałość techniczną (cokolwiek to znaczy), przykro mi, ale Agile nie pomoże.

Wczesne i ciągłe dostarczanie wartościowego oprogramowania?

W swojej istocie wczesne i ciągłe dostarczanie oprogramowania koliduje z wydajnym budowaniem oprogramowania łatwego w utrzymaniu. Łatwo jest osiągnąć jedno, zaniedbując drugie.

Zamiast próbować wypełnić tę lukę, Agile całkowicie obejmuje tę dychotomię, zachęcając do minimalnego designu, ciągłego refaktoryzowania i redesignu. Tak, oprogramowanie będzie wydawane wcześnie i w sposób ciągły, ale łatwość utrzymania i wydajność wylatują do kosza.

Zawsze istnieją niezamierzone konsekwencje tego, co firmy nagradzają. Czy chcesz uzyskać wysoki procent pokrycia testami? Skończysz ze stosem bezużytecznych testów. Zasady takie jak: „Działające oprogramowanie jest prawdziwą miarą postępu zespołu” i „Zadowolić klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania” powodują, że zespoły programistów dostarczają strumień funkcji wspierany przez niskiej jakości oprogramowanie, zarówno pod względem designu, jak i implementacji. Krótkoterminowe perspektywy mogą wyglądać dobrze, ale w końcu pęknięcia zaczną być widoczne.

Działające oprogramowanie jako miernik postępu?

Odnoszenie się do działającego oprogramowania jako do miary postępu jest podobne do spalonych kalorii jako miary utraty wagi. Możesz dużo ćwiczyć, ale jeśli będziesz też dużo jeść, nie schudniesz. I tako samo z oprogramowaniem: możesz dostarczyć wiele działającego oprogramowania, ale jeśli koniec końców wszystko będzie musiało być refaktoryzowane lub przerabiane, to tak naprawdę nie ma żadnego postępu.

Nagradzanie ciągłego dostarczania oprogramowania bez kary za przeróbki i refaktoryzację nie zachęca nikogo do tworzenia oprogramowania możliwego do utrzymania. Jest to również wyjątkowo nieefektywny sposób budowania oprogramowania. Zamiast myśleć o postępie w ten sposób:

Pomyśl o nim w ten sposób:

Ile designu upfront?

Wśród zwolenników Agile panuje błędne przekonanie, że im więcej designu upfront (na początku projektu), tym trudniej będzie wprowadzać zmiany oraz że jak już się coś wprowadzi do designu, to potem trudno to zmienić.

To daje Ci fałszywy wybór między designem upfront a elastycznością, podczas gdy w rzeczywistości możesz mieć obie te rzeczy. Projekty są jedną z najłatwiejszych i najtańszych rzeczy do zmiany. To istniejący kod jest tym, co jest trudne i kosztowne, jeśli chodzi o zmianę. Zmiana elementu designu to kwestia aktualizacji dokumentu. Zmiana istniejącego kodu, poza wysiłkiem, którego wymaga taka zmiana, może powodować różnego rodzaju problemy: wprowadzać braki, przerwy w kompatybilności wstecznej, problemy z wydajnością, itp...

To, że coś nie zostało z góry jednoznacznie zaprojektowane, nie oznacza, że w pewnym momencie nie trzeba będzie o czymś zadecydować. Pytanie brzmi: jak, kiedy i przez kogo. Dam ci przykład:

Dla wszystkich moich projektów, które obejmują interakcje z bazą danych, wyraźnie dołączam dokładne zapytania i indeksy, które powinny być używane w implementacji. Jeśli zapytań nie ma w projekcie, najprawdopodobniej programista będzie musiał je wymyślić podczas implementacji, a zapytania te będą powodować częste problemy z wydajnością. Minimalne projektowanie i dopracowywanie rzeczy w trakcie developmentu utrudnia pracę programistom i w efekcie kosztuje organizację mnóstwo czasu na rozwiązywanie problemów i przeróbki.

Najlepszy projekt to taki, który może być wdrożony przez każdego programistę. Z większą ilością szczegółów w projekcie, będzie mniej niewiadomych i będzie mniej decyzji do podjęcia podczas realizacji. Ponadto, po wydaniu oprogramowania można uniknąć wielu niespodzianek.

Nie jestem zwolennikiem niekończących się cykli projektowania, ale koncepcje takie jak architektura w początkowej fazie rozwoju (Minimum Viable Architecture) kierują organizację na złą drogę. To tak jakby powiedzieć testy w początkowej fazie rozwoju lub szczęście pracownika w początkowej fazie rozwoju. Nie musimy optymalizować tego typu rzeczy. Im więcej czasu poświęci się na design, tym mniej czasu będzie się spędzać na wdrażaniu, rozwiązywaniu problemów i przeróbkach. Jest to rozwiązanie korzystne dla obu stron. Należy zachęcać do designu i architektury. Lepiej zrobić za dużo niż za mało.

Refaktoryzacja

Refaktoryzacja jest ekstremalnie przereklamowana, a Agile kładzie na to zbyt duży nacisk. Nie oznacza to, że refaktoryzacja nie jest ważna, ale brak refaktoryzacji nie jest tym, co sprawi, że projekt się nie powiedzie. Myślenie, że będziesz w stanie dostarczać oprogramowanie w sposób ciągły tak długo, jak długo będziesz refaktoryzował, jest bardzo naiwne. Poważne problemy designu, które są zwykle odkrywane na późnych etapach, takie jak problemy z wydajnością, niewłaściwe integracje między usługami lub długie czasy odzyskiwania danych w przypadku awarii, nie mogą być rozwiązane przez prostą refaktoryzacje. Są to problemy, które są najdroższe do naprawienia i te, których należy unikać za wszelką cenę.

Przeprojektowanie to nie to samo co refaktoryzacja. Założeniem Agile jest to, że możesz zaprojektować system w trakcie jego budowy, oraz że zmiany w projekcie są tanie tak długo, jak długo robisz testy i utrzymujesz kod w dobrym stanie. Inaczej jest w przypadku systemów złożonych. Tak, można refaktoryzować tyle kodu ile tylko chcesz, ale zmiany w projekcie będą trochę kosztować. Nawet niewielka zmiana w wymaganiach lub funkcjach może spowodować niemal całkowite przeprojektowanie.

Jak się tu znaleźliśmy?

Konsultanci Agile nie budują oprogramowania. Ich zadaniem jest sprzedaż szkoleń. Architekci i programiści oprogramowania mają za zadanie je budować. Można to porównać do sytuacji między krytykiem filmowym a filmowcem. Gdybyś miał zrobić film, czyjej rady byś posłuchał? Tak samo jest z oprogramowaniem. Konsultanci Agile nie mogą powiedzieć Ci, jak efektywnie budować oprogramowanie, które da się utrzymać, ponieważ tak naprawdę nie budują oprogramowania. Do tego potrzebny jest architekt oprogramowania.

Zasady tworzenia oprogramowania łatwego w utrzymaniu

Są to zasady, którymi kieruję się przy tworzeniu oprogramowania, które można utrzymać:

• Design: im bardziej szczegółowy projekt, tym lepiej. Dobry projekt zmniejsza ryzyko, ułatwia pracę programiście i zmniejsza prawdopodobieństwo konieczności kosztownego przepisywania kodu w przyszłości. Lepiej zrobić za dużo niż za mało.
• Tworzenie prototypu: stosowanie się do zasad Agile jest jak budowanie wiecznego prototypu. Uważam jednak, że zbudowanie rzeczywistego prototypu przed rozpoczęciem developmentu jest niezwykle pomocne. Jest to jeden z najlepszych sposobów na sprawdzenie poprawności projektu i uniknięcie kosztownych przeróbek w przyszłości.
• Redukcja ryzyka na wczesnym etapie: jedną z najgorszych rzeczy, jakie mogą się zdarzyć w tworzeniu oprogramowania, jest spędzenie miesięcy lub lat na tworzeniu systemu, a następnie odkrycie, że jest w nim fundamentalna wada, coś, co będzie wymagało dużych ilości przeróbek. Należy tego unikać za wszelką cenę. Do czasu rozpoczęcia developmentu powinno być jasne, że fundamenty są solidne.

Jeśli masz tylko młotek, wszystko wygląda jak gwóźdź

Nie zakładaj, że Twoim głównym wyzwaniem jest to, że nie wiesz, czego chcą Twoi klienci. Jeśli zatrudnisz konsultantów Agile, to właśnie to Ci powiedzą, ale nie musi być to prawdą.

Jeśli tym, czego naprawdę potrzebujesz, jest poprawa jakości Twojej inżynierii oprogramowania, to Agile poprowadzi Cię w przeciwnym kierunku. Będziesz potrzebował innego zestawu praktyk, takich, które nagradzają długoterminowy zrównoważony rozwój.

Pisanie dobrego kodu i refaktoryzacja są niezbędne, ale nie są wystarczające, aby zagwarantować sukces projektu w dłuższej perspektywie. Jeśli ogólny projekt systemu nie jest wystarczająco dobry, nie ma znaczenia, jak łatwy w utrzymaniu jest kod.

Podsumowanie

Jeśli jesteś początkującym programistą lub zmieniasz pracę co kilka lat, jak większość programistów, to bardzo prawdopodobne, że nie widziałeś jeszcze długoterminowych efektów pracy zespołów stosujących zasady Agile. To, nawiasem mówiąc, jest jedną z wad niepozostawania wystarczająco długo w tej samej firmie: nie widzisz rezultatów decyzji podejmowanych przez ciebie, programistów, architektów i menedżerów. Śmiem twierdzić, że ten rodzaj nauki jest bardziej wartościowy niż nauka nowszej technologii lub frameworka w innej firmie.

Wreszcie, należy pamiętać, że ten artykuł nie jest o tym, czy Agile jest stosowany w organizacji prawidłowo, czy też nie. Nawet jeśli wszystko jest wykonywane poprawnie, zasady i praktyki Agile kierują organizację na złą drogę, jeśli chodzi o budowanie trwałego oprogramowania wysokiej jakości w sposób wydajny i ekonomiczny.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.