Temat jakości w metodykach zwinnych jest od zawsze kontrowersyjny. Z jednej strony mamy ludzi mówiących o tym, że MVP to tak naprawdę PoC, czyli Proof of Concept. Z drugiej strony mamy osoby twierdzące, że każda wersja oprogramowania powinna być „potencjalnie wdrażalna”. Zaś z trzeciej – tych, którzy narzekają na niską jakość rozwiązań powstających w agile’owy sposób.
PoC, czyli Proof of Concept
Czym jest Proof of Concept? Popularny PoC to metoda „rozpoznania bojem” trudnego tematu. Nie wiemy, czy coś się da zrobić, więc zamiast analizować temat godzinami, często szybciej jest po prostu spróbować coś zrobić. Bo możemy google’ać bez końca czy dany komponent da się zmusić do specyficznego zachowania, ale często szybciej jest po prostu spróbować to zrobić.
Są takie tematy, że łatwiej jest nam sprawdzić w praktyce, niż badać czy mierzyć teoretycznie. Jeden z przykładów to płytki do prototypowania układów elektronicznych (patrz: zdjęcie). Ale i w życiu codziennym czasami wolimy sprawdzić, zamiast mierzyć i badać.
Jeżeli zastanawiamy się, czy nie zamienić miejscami kubków i talerzy w naszej kuchni, mamy kilka możliwości. Możemy podejść do tematu teoretycznie – pomierzyć obie szafki oraz poszczególne elementy (kubki, talerze, itd.) i policzyć czy się zmieszczą. Możemy też po prostu poświęcić chwilę i poprzestawiać po jednym elemencie z każdego rodzaju, żeby zweryfikować założenia w praktyce.
W ramach tworzonych przez nas rozwiązań, programów, systemów i produktów czasami staniemy przed podobnym wyborem. Analizować, szukać informacji, pytać ekspertów czy po prostu sprawdzić? Jeżeli z naszych szacunków wynika, że PoC, czyli Proof of Concept, nie zajmie nam dużo czasu, warto podejść do tego empirycznie i praktycznie. Czyli po prostu sprawdzić.
Scrumowo często mówimy o „potencjalnie wdrażalnym, gotowym do użycia, zgodnym z Definition of Done Przyroście”. Tu warto podkreślić, ze PoC nie musi być ani wdrażalny, ani gotowy do użycia, ani zgodny z Definition of Done. Jedyne, czego oczekujemy od Proof of Concept to to, że działa. Tym samym też pokazuje, że rzecz, co do której mieliśmy wątpliwości, jest faktycznie możliwa do zrobienia.
PoC bardzo często dotyczą algorytmów, integracji, kwestii wydajnościowych albo pewnego specyficznego wykorzystania bibliotek bądź komponentów. Skoro zaś chcemy tylko i wyłącznie pokazać, że „da się”, to nie musimy się starać o piękny wygląd czy efektywne działanie. Wystarczy, że uruchomimy nasze rozwiązanie w trybie tekstowym z linii komend albo pokażemy dane w postaci XML czy CSV.
Tyle o PoC. A jak się do tego ma MVP?
MVP – 20% funkcjonalności, 100% jakości
W tekście „Jak wyznaczyć MVP?” daliśmy kilka praktycznych porad dotyczących definiowania MVP, czyli Minimum Viable Product. Mowa tutaj o tej „wersji 0.9”, którą już możemy wypuścić i zacząć używać, chociaż nie zawiera ona kompletu funkcjonalności. Ba, bardzo często jest bardzo daleka od bycia wersją finalną!
Jeżeli przebudowujemy system centralny, który obsługuje kilkadziesiąt różnych produktów, to nasze MVP może obsługiwać zaledwie kilka z nich. Albo nawet jeden kluczowy. Ważne, żeby miało wspomniane powyżej cechy – potencjalna wdrażalność, gotowość do użycia, zgodność z Definition of Done. W tym konkretnym przypadku (zastępowanie jednego systemu drugim) wyobraźmy sobie, że odpowiednie funkcjonalności są wyłączane w starym systemie. Czy nowy podoła? Jeśli tak, to świetnie – mamy MVP.
W przypadku budowy nowego rozwiązania, musimy zadać sobie pytanie o to, czy nie będzie wstydu, jak ktoś tego zacznie używać. Istotna jest tu grupa docelowa, bo krewni i znajomi królika wybaczą nam o wiele więcej niż klient masowy.
To, do czego zmierzam w tym wywodzie, to sentencja z nagłówka. Zwykłem ostatnio mawiać, że nawet jeśli nasza wersja 0.5 czy 0.9 zawiera jedynie 20% docelowych funkcjonalności, to niech zawiera 100% jakości. No dobrze, nie zawsze to jest możliwe, ale te 98% powinniśmy być w stanie osiągnąć.
Nasze MVP to nie jest wydmuszka, prototyp ani Proof of Concept. To jest kawałek docelowego rozwiązania. Nie chcemy wracać do MVP, żeby „dociągnąć je jakościowo do reszty”. Prace nad tą częścią powinny być zakończone, a efekty pracy – docelowe. I tak, mówimy tutaj też o architekturze rozwiązania, wydajności i innych wymaganiach niefunkcjonalnych.
Jakoś(ć) to będzie
Częstym zarzutem w kierunku metodyk zwinnych jest fakt, że nie zwracają one uwagi na jakość oraz techniczne aspekty wytwarzanych rozwiązań. Walczymy z tym postrzeganiem w zasadzie od zawsze. Przecież mamy plany długoterminowe, wizję, kamienie milowe, itd. To nie jest tak, że tworzymy niezależne rozwiązania ze Sprintu na Sprint, które potem łączymy na sznurek i gumę do żucia.
Cokolwiek nie wytworzymy, jakkolwiek małe nie są korzyści biznesowe, to technicznie, architektonicznie i technologicznie nasze rozwiązanie powinno być wysokiej, docelowej jakości. Jeżeli nie jest, to nie jest to „wina agile’a”, ale coś po prostu poszło nie tak.
„Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność”
„Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów” – Agile Manifesto
I tutaj dochodzimy do kolejnego aspektu, który często jest zapominany. Mowa o kross-funkcjonalnych zespołach, które powinny zawierać wszystkie kompetencje potrzebne do wytworzenia rozwiązania. To znaczy, że jeśli nasz produkt wymaga prac architektonicznych bądź projektowych, to i takie osoby (architekci, projektanci) powinni się w naszych zespołach znajdować.
Niestety, często spotkamy osobne zespoły architektoniczne (a jeszcze gorzej – analityczne), które nie będąc częściami zespołu, nie mając skin-in-the-game, produkują pomysły oderwane od potrzeb zespołów wytwórczych, a często i samych klientów. Ale tu już znacząco zboczyliśmy z obranego na samym początku tego tekstu kursu.
Niezależnie od konstrukcji naszych zespołów oraz tego, co produkujemy, pamiętajmy – pracując iteracyjnie i przyrostowo, każda kolejna wersja powinna być dla nas powodem do dumy i czymś, co chcielibyśmy zaprezentować. A jeśli tylko chcemy udowodnić sobie i światu, że coś jest możliwe – nie nazywajmy tego MVP. To PoC, czyli Proof of Concept.
