fot. depositphotos.com
Zaryzykuję stwierdzenie, że oprogramowanie jest fundamentem funkcjonowania obecnego społeczeństwa. Właściwie nie ma sektorów naszego życia, gdzie nie mielibyśmy z nim do czynienia. Sieci energetyczne, komunikacyjne, służba zdrowia, państwo, infrastruktura, rozrywka – niemal wszystko pod spodem ma trybiki oparte na oprogramowaniu. To ono umożliwia przekładanie idei na współczesne usługi i produkty.
Zobacz również
Co więcej, trend zwiększania istotności oprogramowania nie wykazuje sygnałów spowolnienia. Raczej możemy liczyć na jego wzmocnienie. IoT, blockchain, (na razie „weak”) AI – coraz więcej będzie zależało od oprogramowania.
Przynajmniej na razie, w przeważającej większości, oprogramowanie tworzą ludzie. I to ludzie są najsłabszym ogniwem tego systemu. Sprzętowo komputery są w zasadzie niezawodne – o ile są dobrze zaprogramowane.
Houston, mamy problem
My, ludzie, z natury jesteśmy nieprzystosowani do tworzenia oprogramowania. Nasze mózgi są niezłe w wyciąganiu przybliżonych wniosków z dużej ilości informacji, ale zbyt wolno analizują wiele ścieżek systemów złożonych. Często nawet nie dostrzegają ich istnienia.
Movember/Wąsopad: jak marki zachęcają do profilaktyki męskich nowotworów [PRZEGLĄD]![Movember/Wąsopad: jak marki zachęcają do profilaktyki męskich nowotworów [PRZEGLĄD]](https://nowymarketing.pl/wp-content/uploads/2024/11/Cover-photo-2024-11-06T140221-142x0-c-default.png)
W większości oprogramowanie to manifestacja wielowarstwowych systemów złożonych, o milionach ścieżek wykonania. Jedna mała zmiana może mieć ogromne konsekwencje dla zachowania całego systemu. Dlatego programy mają błędy (zwłaszcza te źle napisane), a wraz ze wzrostem ich skali, rozwój drastycznie je spowalnia. Widział to „w akcji” każdy, kto miał okazję uczestniczyć w większym projekcie informatycznym. 15, 100, 200 lub więcej osób zaangażowanych w produkt i dzieje się „antymagia”. Pojawiają się problemy komunikacyjne, niekończące się opóźnienia, narasta frustracja. Co gorsza, produkt ma błędy, a kolejne zmiany prowadzą do nowych błędów. Niektóre są całkiem poważne [1], niektóre tragiczne [2]. Rozwój zwalnia i bywa, że produkt w ogóle nie ma szansy ujrzeć światła dziennego.
Słuchaj podcastu NowyMarketing
Przy takim stanie rzeczy świat rysuje się w czarnych barwach. Z jednej strony męczą się twórcy oprogramowania, z drugiej jego użytkownicy. A skoro spodziewamy się dalszego wzrostu istotności software’u, to możemy założyć, że będzie tylko gorzej.
Błędne koło
Właściwie dlaczego tak trudno nam wynaleźć sposoby okiełznania złożoności oprogramowania? Przecież istnieją produkty całkiem niezawodne. Istnieją firmy, w których udaje się tworzyć rozwiązania w sposób przewidywalny, a ich używanie jest całkiem przyjemne. Problem w tym, że aby takie produkty tworzyć, musimy oprzeć się na wiedzy i doświadczeniu. Na otwartości, zaangażowaniu, pasji i wytrwałości. Musimy być gotowi na zmiany nawyków, gotowi do autorefleksji i szczerości (również z samym sobą) – chętni do skupienia się na produkcie i na jego długoterminowej jakości. Na jakości fundamentów: praktyk pracy zespołowej, designu i kodu. Co więcej, musimy umieć wdrożyć to wszystko w życie.
Rzeczywistość jest niestety brutalna. Ludzie dają się skusić wysokimi zarobkami w branży IT. Rynek twórców oprogramowania przesyca się amatorskim podejściem i brakiem doświadczenia. Pracodawcy nie wiedzą, jak wybierać odpowiednich ludzi i trudno jest im ocenić, kto potrafi tworzyć dobry software. Firmy natomiast nie wiedzą, jak zarządzać rozwojem oprogramowania i próbują stosować paradygmaty tworzenia produktów z innych sektorów (które w tej dziedzinie rzadko kiedy są skuteczne).
To zamyka nas w błędnym kole, w negatywnym sprzężeniu zwrotnym. Pędzimy, by dostarczać jak najwięcej w jak najkrótszym czasie. W efekcie popełniamy więcej błędów, więc próbujemy przyspieszyć pracę i wychodzi tylko gorzej. Pogrążamy się – w najlepszym wypadku – w przeciętności.
Można (należy) inaczej
A gdyby tak przerwać tę spiralę i skupić się na jakości oprogramowania, w tym na jakości procesu jego wytwarzania? To wymaga odwagi. Aby zmienić nasze przyzwyczajenia, musimy postawić na szali krótkoterminowe zyski. My, programiści, my, designerzy, my, Scrum Masterzy, my, Product Ownerzy, my, właściciele biznesu. Właściwie, nie mamy innego wyjścia – jakość to nasza odpowiedzialność i nikt inny za nas o nią nie zadba [3].
W szerszym ujęciu jesteśmy odpowiedzialni nie tylko za nasz mały kawałek kodu/grafiki/produktu. Cegiełka po cegiełce, jakość naszej pracy przekłada się na cały ekosystem wytwarzania oprogramowania i na standardy w branży. A czy, skoro software jest tak istotny, nie powinniśmy potraktować jakości jako najwyższego priorytetu i pozostawić „pędzenie za krótkoterminowymi zyskami” na dalszym planie?
Skupienie na jakości jest nie tylko szansą, aby tworzyć obiektywnie lepsze oprogramowania, ale by poszukać satysfakcji i wartości społecznej w tym, co robimy.
Koniec końców, nagroda może być wielka: przewidywalny i efektywny rozwój produktu, satysfakcja z jego tworzenia i szybszy wzrost naszych umiejętności. Paradoksalnie, nie skupiając się na finansach, a na podwyższaniu jakości, łatwiej jest o te finanse zadbać [4].
Pięknie to brzmi… w teorii, ale co to konkretnie znaczy „skupić się na jakości”?
Po czym poznasz, że jestem piękny
Można pokusić się o opisanie jakościowego produktu software’owego jako takiego, który:
- ma mało błędów,
- pozwala na szybkie dodawania nowych funkcjonalności,
- jego funkcjonalność ma wartość dla użytkownika.
Co jednak znaczy „mało”? Co oznacza „szybkie”? „Wartość”? Dochodzimy więc do sedna: musimy jasno zdefiniować te pojęcia, a później stosować ich odpowiednie mierniki.
Mierzenie jest podstawową praktyką zapewniania przewidywalności i jakości. Ustalenie mierników i ich definicji pozwala nam skonkretyzować pojęcia takie jak: „mało”, „szybko”, „wartościowe”.
Co na przykład możemy mierzyć? W dużym uproszczeniu:
- jakość kodu (np. długość funkcji, złożoność, WMFP)
- jakość UI (np. czas odnalezienia danej funkcji, discoverability),
- naszą wydajność (np. velocity, capacity),
- procent pracy jaki spędzamy na pracy nad produktem/dodawaniem nowych funkcjonalności (np. vs naprawa błędów lub vs. kwestie formalne),
- liczbę błędów na produkcji,
- średni czas naprawy błędu na produkcji,
- szybkość dostarczania nowych funkcjonalności na produkcję (np. lead time),
- częstość deploymentów,
- jak ze zmian korzystają użytkownicy (np. testy A/B),
- opinie i zadowolenie użytkowników.
Za status quo dla metryk możemy przyjąć stan obecny i pracować nad jego ciągłym ulepszaniem (np. x% mniej błędów miesięcznie) [5].
Musimy dążyć do ciągłego ulepszania. Jeśli robimy pomiary raz w roku albo po zakończeniu dwuletniego cyklu rozwoju „pierwszej wersji produktu”, to ryzykujemy, że dostaniemy feedback na temat jego jakości zbyt późno.
I tu na scenę wchodzi szansa, jaką daje fakt, że software jest zdecydowanie innym bytem niż budynek, czy operacja pacjenta na otwartym sercu. Oprogramowanie możemy rozwijać w iteracjach. W krótkich (np. tygodniowych), powtarzalnych cyklach, na początku których stawiamy hipotezy, po czym wdrażamy je w życie, testujemy i wyciągamy wnioski.
Po nitce do kłębka
Nasza przygoda zaczyna się jednak dopiero wtedy, gdy już podejmiemy się mierzenia i nauki pracy iteracyjnej. Na nic nam iteracje, jeśli:
- nie rozwijamy naszych kompetencji w sposób ciągły,
- nie akceptujemy faktu, że są one (też) po to, aby stawiać hipotezy,
- unikamy porażki [6].
Musimy zrozumieć, że każda iteracja to okazja do poprawy – nie tylko produktu, ale też naszego sposobu pracy. Pamiętajmy, że czas poświęcony na intencjonalną naukę podczas pracy nie jest „marnotrawstwem”, a wymaganym, codziennym elementem funkcjonowania każdego zespołu. Ten czas, spędzony na pochylaniu się nad jakością, zwróci się z nawiązką. Musimy zrozumieć, że to suma pracy dostarczonej przez każdego członka zespołu wpływa na finalną jakość.
I tak dotarliśmy do kłębka. Czego się uczyć? Jak zawsze, nie ma jednej prostej odpowiedzi [7]. Po to są nam potrzebne iteracje, abyśmy sami mogli wyciągać wnioski z tego, co działa, a co nie, czego się uczyć i jak korygować kurs.
Ale… bez wkładu teoretycznego ciężko jest wybrać, jakie hipotezy możemy testować. Są pewne obszary, na które warto zwrócić uwagę i które warto nieustannie optymalizować (kolejność i poziom abstrakcji przypadkowe).
- Wskazane jest rozwijanie naszych umiejętności mierzenia. Istnieje spora szansa, że robimy to słabo, a wsparcie specjalistów od data science może wynieść nas na wyższy poziom (tak, mierniki też podlegają ulepszeniom w ramach iteracji!)
- Zrozumienie, jaką wartość dostarczają nasze produkty – czy zespół wie, jakie są cele? Czy rozumiemy, dlaczego użytkownicy wybierają nasz produkt? Jak działa konkurencja?
- Automatyzacja – np. testów na poziomie developerskim (testy jednostkowe) i na poziomie funkcjonalnym – jeśli szybko i automatycznie dostajemy feedback o niezawodności aplikacji, nie tracimy czasu i wzrasta niezawodność.
- Praktyki jakości kodu – od mierzenia jakości kodu poczynając, na praktykach podnoszenia jakości kodu kończąc (TDD, BDD, Code Review, SOLID etc.).
- Praktyki „prowadzenia” projektu – Scrumy, Kanbany, leany, retrospektywy, planowania, refinementy, podział ról – wszystko możemy udoskonalać.
- Transparencja – czy wszyscy mają dostęp do wszystkich informacji, które są im potrzebne do podejmowania decyzji? A może na odwrót, może szum informacyjny jest zbyt duży?
- Skupienie – czy nie robimy zbyt wielu rzeczy naraz? Czy ograniczamy pracę w toku?
To tylko wybiórcze i wysokopoziomowe spojrzenie na zagadnienie jakości oprogramowania. Można spędzić lata, zdobywając doświadczenie we wdrażaniu w/w w życie.
Nadzieja
Oprogramowanie jest bardzo ważne w obecnym społeczeństwie, a jego jakość w większości przypadków nie jest wystarczająca. Dlatego mamy „obowiązek” pracować nad jej podwyższaniem. Nic się jednak nie zmieni, jeśli nie zaczniemy od siebie.
Pytanie: czy będzie Ci się chciało?
Przypisy:
[1] www.computerworld.com/article/3412197/top-software-failures-in-recent-history.html
[2] www.devtopics.com/20-famous-software-disasters/
[3] A jeśli nam nie zależy, to może lepiej poszukać szczęścia gdzie indziej i np. wyjechać w Bieszczady? 😉
[4] Nie mam tu na myśli ignorowania finansów, bo to droga do szybkiej tragedii, czego przykładem może być osławiona historia produkcji Daikatany przez Johna Romero – wikipedia.org/wiki/Daikatana_(gra_komputerowa)#Produkcja
[5] Uwaga na tworzenie „błędnych” mierników vitalitychicago.com/blog/want-high-performing-teams-stop-measuring-wrong-things/
[6] Słynne „safe environment for failure”
[7] Choć bardzo byśmy chcieli, aby świat opierał się na „srebrnych kulach” często jest inaczej en.wikipedia.org/wiki/No_Silver_Bullet