Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

V.A.L.I.D. , czyli system zarządzania jakością

Sprawdź, czym jest system V.A.L.I.D. i zobacz, co pozytywnego może wnieść do pracy w Twojej organizacji.

Czy w czasach nowoczesnego tworzenia oprogramowania wspomaganego przez metodyki zwinne i kulturę DevOps, jest potrzeba globalnego zarządzania podejściem do zapewnienia jakości? Przecież każdy zespół developerski powinien być odpowiedzialny za swój produkt, począwszy od fazy projektowania aż do wdrożenia i utrzymania na produkcji, więc na pewno zależy mu na tym, żeby jakość była na jak najwyższym poziomie.

Nie wątpię w jak najlepsze intencje każdego zespołu produktowego, ale czy można działać według najlepszych praktyk dostarczania oprogramowania, będąc jednocześnie pod presją ze strony biznesu, by jak najszybciej dostarczać nowe funkcjonalności? I wreszcie – czy zespoły rzeczywiście znają dobre praktyki, czy wiedzą, które z nich chcą stosować i czy są w stanie powiedzieć, w jakim stopniu to robią?

Te pytania postawiliśmy sobie kilka lat temu w IDEMIA. Od tamtego czasu udało nam się wypracować bardzo solidne standardy zarządania jakością produktów IT, które tworzymy. Ale zacznijmy od początku…


Ta historia zaczyna się w Łodzi

Co to takiego IDEMIA? Zaczynaliśmy 5 lat temu, w Łodzi, jako oddział globalnej firmy, jeszcze wtedy Oberthur Technologies, w atmosferze mocno startupowej. Pracowaliśmy nad jednym produktem, jako jeden zespół, w gronie kilkunastu bardzo doświadczonych inżynierów, z bardzo niewielkim wpływem z globalnej organizacji. Dano nam wolną rękę w działaniu, więc zbudowaliśmy własne reguły, według których chcieliśmy budować nasz oddział: autonomiczne, cross- funkcjonalne, samoorganizujące się, produktowe zespoły z odpowiedzialnością end-to-end za swoje produkty.

Pracowało nam się tak efektywnie, że dostawaliśmy coraz więcej zleceń na nowe produkty. Żeby mieć szansę ich dostarczenia, musieliśmy urosnąć w siłę. W ciągu pierwszego roku nastąpił gwałtowny wzrost liczby pracowników, na który nie byliśmy gotowi (choć ostatecznie uważam, że poradziliśmy sobie z nim całkiem nieźle). Pracowała już u nas ponad setka programistów IT, tworząc kilka zespołów produktowych. Przy takiej ilości różnych osobowości, wierząc w samoorganizację i nie stawiając przy tym ram, szybko zaczęliśmy zauważać, jak różne jest podejście zespołów do zapewnienia jakości. Jednak ciągle niosąc na sztandarach autonomię zespołów, nie chcieliśmy ingerować w ich pracę i narzucać standardów jakości z zewnątrz.

W zmianie podejścia pomógł nam audyt grupy „Agile Rebels” zajmującej się doradzaniem organizacjom w zakresie zwinnych metod zarządzania projektami IT. Z chłopakami współpracujemy do dzisiaj, korzystając z ich agile coacha, który wspiera nas na co dzień w budowaniu firmy. Raport z audytu jednoznacznie wskazywał, że brakuje nam ogólnie przyjętych, minimalnych kryteriów jakości, wspólnych dla wszystkich produktów i zespołów.

Skoro więc zewnętrzni obserwatorzy potwierdzili nasze przypuszczenia, nie pozostawało nam nic innego, jak zabrać się za wypracowanie tych wymagań. Jednak zanim to zrobiliśmy, musieliśmy sobie odpowiedzieć na jeszcze jedno pytanie: jak to zrobić nie naruszając autonomii danej zespołom ?


Początki V.A.L.I.D. – narzędzia do zarządzania jakością

Postanowiliśmy zacząć od znalezienia tego, co już mieliśmy wspólne dla wszystkich zespołów, w zakresie dbania o jakość produktów. W ten sposób uzyskaliśmy minimalny zbiór wymagań i dobrych praktyk, z którymi nie sposób było polemizować, ponieważ każdy zespół już je stosował. Wśród nich na przykład: pisanie testów jednostkowych, budowanie aplikacji w CI czy zarządzanie backlogiem w Jira. To był dobry początek budowania świadomości (bo o poprawie jakości jeszcze nie mogło być mowy).

Następnym krokiem tworzenia systemu zarządzania jakością było rozpisanie sobie w punktach różnych aspektów wpływających na jakość całego procesu dostarczania oprogramowania i zorganizowaniu paneli dyskusyjnych na każdy z tych tematów dla wszystkich chętnych. W ten sposób udało się wypracować kolejnych kilka praktyk, które chcieliśmy, żeby zespoły używały. Jednocześnie, zyskaliśmy „ewangelistów zmiany”, którzy brali udział w warsztatach i byli jednocześnie członkami zespołów produktowych.


Zarządzanie przez jakość – mamy to!

W wyniku wszystkich wcześniejszych ustaleń powstał zbiór różnych praktyk, co do których wszystkie zespoły zgodziły się, że wpływają pozytywnie na jakość wytwarzanych przez nas produktów i warto je stosować. W oparciu o nie zbudowaliśmy framework, który nazwaliśmy V.A.L.I.D., skupiający wszystkie praktyki w jednym miejscu.

Ważną cechą wspólną wszystkich punktów, które się w nim znajdują, jest to, że nie mówią one, w jaki sposób dany cel osiągnąć, a jedynie pokazują, jakich oczekujemy rezultatów. W ten sposób nie odbieramy autonomii zespołom, a nawet lepiej – wykorzystujemy ją, licząc na kreatywne pomysły, które mogłyby nigdy nie powstać, gdyby wszystkim został narzucony taki sam sposób pracy, w oparciu o te same narzędzia czy procesy.


Dlaczego V.A.L.I.D. ?

Słowo „valid” kojarzy się z jakością, ale nie zostało wybrane tylko z tego powodu. Każda litera wiąże się z filarem, na którym opieramy nasze postrzeganie zapewniania jakości w procesie developmentu produktów. Te filary to: Verified, Automated, Legit, Integrated, Described.

  • Zarzadzanie jakością, pierwszy filar – Verified

Wskazuje na potrzebę weryfikacji czy nasz produkt jest zgodny ze wszystkimi zdefiniowanymi wymaganiami. Wiąże się to w głównej mierze z wykonaniem różnego rodzaju testów, zarówno funkcjonalnych (komponentowych, integracyjnych, end-to-end), jak i niefunkcjonalnych (wydajnościowych, penetracyjnych, wysokiej dostępności). To wszystko ma upewnić właściciela produktu (ang. Product Owner), że otrzymał produkt, który zamawiał. Tutaj też, te zespoły, których produkty przechodzą zewnętrzne certyfikacje (jak np. PCI DSS czy GSMA), powinny upewnić się, że są zgodne z wymaganiami, które pochodzą z tych certyfikacji.

  • Zarzadzanie jakością, drugi filar – Automated

To opisanie jednym słowem strategii, która przyświeca nam od początku naszej działalności – automatyzacji wszędzie tam, gdzie jest ona możliwa. Za tym idzie automatyzacja całego procesu CI/CD czy bardzo silne nastawienie na automatyzację testów. Wszystko po to, żeby skrócić czas dostarczania nowych funkcjonalności i wyeliminować powtarzalne czynności z pracy zespołów tak, aby mogły się skupić na ważniejszych rzeczach.

  • Zarzadzanie jakością, trzeci filar – Legit

Gdzie znajdują się oczekiwania co do reguł, które zespół powinien sobie sam wypracować i za nimi podążać, aby mieć wspólne zrozumienie sposobu pracy i dostarczania produktu. Tutaj znajdziecie takie rzeczy jak definicja gotowości (ang. Definition of Done) czy sposób zarządzania Pull Requestami.

  • Zarzadzanie jakością, czwarty filar – Integrated

Ponieważ produkt powinien być zbudowany zgodnie z wytycznymi „12-factor app”, które uwzględniają zarządzanie zależnościami, konfiguracją czy monitorowaniem stanu produktu i logowaniem zdarzeń. To wszystko, żeby z łatwością zintegrować produkt w całym ekosystemie produkcyjnym.

  • Zarzadzanie jakością, piąty filar – Described

Gdyż trudno mówić o produkcie, który nie ma żadnej dokumentacji. Począwszy od tej, która opisuje nasz produkt z punktu widzenia funkcjonalności, które posiada czy architektury komponentów, a skończywszy na wszystkich samouczkach dla użytkowników czy późniejszych administratorów.


„Framework nie działa”

Takie były częste komentarze w pierwszych tygodniach czy miesiącach po zdefiniowaniu frameworka do zarządzania jakością i oddaniu go w ręce zespołów. W dalszym ciągu dojrzałość produktu i procesu developmentu zależała głównie od dojrzałości osób tworzących zespół i świadomości związanej z zapewnieniem jakości.

Dlaczego nie zadziałało ? Przecież całość powstała z udziałem tych samych osób, które później dostarczają te produkty. Okazało się, że w szerzeniu świadomości o jakości produktu zapomnieliśmy o jednej, bardzo ważnej, grupie osób – właścicielach produktów. Z reguły są to osoby związane z biznesem, którym w pierwszej kolejności zależy na jak najszybszym dostarczeniu produktu czy też nowej funkcjonalności. Nie wszyscy mają świadomość podłoża technicznego, jakie ze sobą niesie wytwarzanie oprogramowania. To też jest specyfika branży IT – ze względu na dużą konkurencję oraz szybko zmieniające się warunki rynku, produkty powinny być dostarczane jak najszybciej.

Zwiększenie świadomości Product Owner’ów poprawiło sytuację, ale postawione ramy w postaci listy dobryk praktyk wciąż nie były wystarczające. Brakowało nam systematyczności. Dlatego też, oprócz ciągłej pracy z zespołami, zdecydowaliśmy się na wprowadzenie wewnętrznych audytów. Nie przepadam za tym słowem, ale mimo wszystko najlepiej obrazuje ono to, co robimy.

Dwa razy w roku zespół niezależnych audytorów spotyka się z zespołami i rozmawia z nimi o tym, jak wygląda ich proces dostarczania pod kątem stosowania praktyk ze zdefiniowanej we frameworku listy. To spotkanie to również świetna okazja do wyciągnięcia od zespołu tych usprawnień, które udało im się wypracować w ostatnim czasie i którymi warto się podzielić z innymi zespołami mającymi podobne problemy.


Żeby było ciekawiej, wprowadziliśmy również elementy grywalizacji. Na podstawie wyników audytu, dla każdego zespołu wyliczany jest wskaźnik realizacji założeń V.A.L.I.D. Jednak sam wskaźnik nie jest tak ważny, jak to, jak jego wartość zmienia się w czasie i dlaczego.

Ważne jest również docenianie tych, którzy starają się najbardziej. Wyróżniać można na różne sposoby. Zaczęliśmy od słownych gratulacji na różnych forach wewnątrz firmy. Ale w tym roku wprowadziliśmy także puchary – jeden za najlepszy wynik a drugi za największy postęp. Inicjatywa spotkała się z dobrym przyjęciem wśród naszych zespołów.


Czy było warto pracować nad systemem do zarządzania jakością V.A.L.I.D.?

Jednym słowem: TAK!

Pracujemy w tym modelu już ponad 4 lata. W ciągu tego czasu poziom jakości naszych produktów wyraźnie się poprawił. Zespoły wiedzą, czego się od nich oczekuje w kontekście jakości i mogą się do tego w każdej chwili odnieść. Status jest transparentny i dostępny w miejscu dostępnym dla wszystkich pracowników.

Jednak rzeczą, z której osiągnięcia jestem szczególnie dumny, jest zdecydowanie większa świadomość programistów, jeżeli chodzi o zasady dbania o jakość produktu. Droga od „po co nam to całe BDD?”, do samodzielnej automatyzacji testów, dbanie o jak najlepszy proces CI/CD uwzględniający jak najwięcej automatycznych weryfikacji produktu oraz wychodzenie z propozycjami nowych praktyk do frameworku nie była łatwa i krótka. Razem z dojrzewaniem V.A.L.I.D.’a dojrzewały również nasze zespoły.

Czy to zburzyło autonomię ? Autonomia jest wciąż nie tylko obecna, ale również istotna w kontekście poszukiwania co raz to lepszych rozwiązań na problemy dotykające wielu zespołów. Zespoły same ustalają, jakie są zasady ich pracy i w jaki sposób dostarczą oczekiwane od nich rezultaty.

Co dalej ? V.A.L.I.D. ciągle ewoluuje. Na przestrzeni tych kilku lat zmieniał się już wielokrotnie. I pewnie jeszcze nie raz się zmieni. To, co wypracowaliśmy i używamy w Polsce, rozprzestrzeniamy obecnie na produkty tworzone w innych krajach – Francji, USA i Indiach.

Obecnie jesteśmy w okresie transformacji z tradycyjnego modelu ITIL do modelu SRE i tam również myślimy o utworzeniu czegoś na kształt V.A.L.I.D.’a co pomoże zebrać i nadzorować dobre praktyki w zakresie monitorowania i utrzymania aplikacji.


A Wy jak zarządzacie jakością produktów?

Mam nadzieję, że opis drogi, którą przeszliśmy w IDEMIA, dał wam obraz tego, jak można podejść do zarządzania jakością produktów w organizacji tworzącej ich kilka czy kilkanaście jednocześnie przez wiele zespołów. Pamiętajcie, że to, co sprawdza się w jednej organizacji, niekoniecznie musi zadziałać w innej. Eksperymentujcie, sprawdzajcie, jak działa i zmieniajcie w razie potrzeby. Ważna jest droga, podczas której na pewno nauczycie się wiele o waszych produktach i o tym, co wpływa na ich jakość.

Zostawiacie wszystko w rękach zespołów, czy również macie mechanizmy działające na poziomie organizacji?

Zobacz kogo teraz szukają