Pierwsza część z serii artykułów dotyczących Definicji Ukończenia poświęcona jest w znacznym stopniu przypomnieniu, czym jest Definicja i jak to zobowiązanie zdefiniowane zostało w Scrumie. Pora pochylić się nad tym, co należy wziąć pod uwagę przy sporządzaniu Definicji.

Perspektywa produktu

Celem Scruma jest wytworzenie produktu, który nadawał się będzie do użycia i zaspokoi potrzeby interesariuszy (klientów, użytkowników), ewentualnie będzie odpowiedzią na ich problemy. Sam produkt (czym on jest, przez kogo będzie użytkowany i w jaki sposób) jest źródłem pierwszej perspektywy, jaką należy posłużyć się przy sporządzaniu Definicji Ukończenia.

Trzeba zadać sobie dwa pytania:

  • Czy produkt musi mieć jakieś specyficzne cechy, bez których nie da się go użyć?
  • Czy produkt musi być wytwarzany w jakiś z góry określony sposób, aby możliwe było jego użycie?

Niezbędne cechy produktu

Pisząc o cechach, nie mam na myśli detalicznych funkcjonalności produktu, ale ogólny charakter lub właściwości wytwarzanych rozwiązań. Na przykład, jeśli tworzymy produkt dla osób niewidzących lub słabowidzących, konieczne będzie wyposażenie go w mechanizmy, które takim użytkownikom umożliwią korzystanie z niego. Inny przykład: jeśli wiemy, że produkt (np. serwis internetowy) będzie użytkowany jednocześnie przez tysiące użytkowników, musi mieć on wydajność niezbędną do obsłużenia takiego obciążenia, albo będzie bezużyteczny.

Czasami niezbędne cechy wynikają z branżowych lub wręcz prawnych regulacji związanych z dziedziną, w jakiej funkcjonuje produkt. Taką cechą może być istnienie dokumentacji, która przekazywana jest użytkownikom, żeby mogli z jej pomocą nauczyć się, jak bezpiecznie korzystać z produktu. Bez niej produkt nie zostanie dopuszczony do użycia.

Wymagany sposób wytwarzania produktu

W jaki sposób z tego, czym jest produkt, może wynikać wymóg jego budowania w określony sposób? Jeśli wytwarzamy produkt na potrzeby jakiegoś regulowanego prawnie rynku lub branży, często determinuje to zręby procesu, jakim musimy się posłużyć. I nie dość, że konieczne jest wygenerowanie różnych artefaktów (np. takich, jak wspomniana wcześniej dokumentacja), to jeszcze może być istotne kto i w którym momencie je wytwarza, oraz w jaki sposób się to odbywa.

Przykładowo, systemy informatyczne w bankach muszą być budowane tak, by osobna grupa specjalistów (programistów, testerów etc.) wytwarzała oprogramowanie, a inna grupa specjalistów (administratorów tych systemów, wdrożeniowców etc.) instalowała oprogramowanie i utrzymywała go w działaniu. Jeśli ta segregacja obowiązków nie będzie dochowana, regulator rynku może uznać, że systemy informatyczne banku nie są bezpieczne.

Inny dużo prostszy przykład: Zespół wytwarza aplikację na smartfony i żeby móc umieścić ją w sklepie z aplikacjami musi zapewnić, że przejdzie ona przez proces walidacji i zostanie zaakceptowana do publikacji. Zespół sam tych czynności nie może przeprowadzić, ale aby mieć jakiekolwiek szanse na skuteczną publikację aplikacji w sklepie, musi po swojej stronie (w swym procesie developerskim) zawrzeć wszystkie niezbędne działania, które zapewnią, że walidacja taka będzie czystą formalnością. Inaczej mówiąc, Developerzy nie mogą budować aplikacji, jak im pasuje, ale muszą robić to zgodnie z zasadami narzuconymi przez operatora sklepu z aplikacjami.

Perspektywa standardów

Wiele wymogów wynikających z tego, czym jest produkt i jak będzie używany, jest pochodną różnych standardów. Prawnych, branżowych, technologicznych itd. I jeśli posłużymy się opisaną wcześniej perspektywą produktu, wiele z tych standardów od razu zostanie wzięte pod uwagę.

Nie są to wszystkie standardy, jakie należy rozważyć. Istnieją normy i standardy niewynikające wprost z tego, czym jest produkt, po które wciąż warto sięgnąć. Są opcjonalne, ich użycie generuje dodatkowe koszty, ale jeśli zapewniają wysoką jakość lub wartość produktu, korzyści z posłużenia się takimi standardami mogą być znaczące.

Wyobraźmy sobie bank, w którym dziesiątki Zespołów pracuje nad rozwojem różnorakich produktów: bankowych, informatycznych, połączenia jednych z drugimi itd. Z samego faktu, że to bank, i z charakteru budowanych produktów będzie wynikać jakaś lista cech lub czynności, jakie trzeba wykonać, aby produkty w ogóle powstały. Natomiast bank dla zapewnienia spójności tego, co robią poszczególne Zespoły, może wdrożyć własne standardy i wymagać ich przestrzegania.

Co regulować mogą takie wewnątrzorganizacyjne normy? Na przykład to, jakimi narzędziami i technologiami posługiwać się mają Developerzy, wedle jakich reguł tworzona ma być architektura produktów, czy wymagana jest dokumentacja i jak powinna ona być sporządzana – cokolwiek co organizacja uzna za konieczne do zdefiniowania jako obowiązujący standard.

Dlatego, po przeanalizowaniu perspektywy produktowej, należy ustalić, w jakie standardy, normy i zasady, musi wpisać się produkt z punktu widzenia firmy, przepisów prawa, samej technologii, stosowanych narzędzi itd. I odpowiedzieć sobie tym razem na trzy pytania:

  • Jakie standardy musi spełniać produkt i proces jego wytwarzania?
  • Jakie cechy musi mieć produkt, by spełniać obowiązujące go standardy?
  • W jaki sposób wytwarzać należy produkt, by standardy te spełniał?

Cechy, o jakich piszę, znów należy traktować jako coś bardziej generycznego, niż po prostu konkretne funkcjonalności produktu. Np. jeśli organizacja wytwarza oprogramowanie, może wymagać, by zachowane były określone standardy kodowania, by wykorzystywane były konkretne technologie, by kod przechowywany był w ujednoliconej formie i w standardowych repozytoriach itd.

Inny przykład: jeśli tworzony jest rozbudowany serwis internetowy, rozwijająca go firma może uznać, że wszystkie strony serwisu muszą być zgodne z ogólnie przyjętymi standardami HTML i CSS. Z punktu widzenia użytkowników nie jest to niezbędne (o ile bez tego produkt działa i daje się użytkować), ale z punktu widzenia organizacji trzymanie się tych standardów zwiększa łatwość rozwoju oprogramowania dzięki kompatybilności z narzędziami, łatwiejszemu wdrożeniu nowych programistów do pracy itd.

Standardy mogą wymagać zastosowania konkretnych praktyk albo narzędzi w procesie wytwarzania produktu. Weźmy konkretny przykład: Zespół tworzy sklep internetowy, w którym można zamówić różne towary i zapłacić na nie na wiele sposobów. To wymusi na Zespole stworzenie mechanizmów nie tak, jak sobie sam wymyśli, tylko tak, by w te standardy się wpisać.

Jeśli sklep internetowy obsługuje płatności kartami kredytowymi, to np. w Unii Europejskiej musi obsługiwać mechanizm 3D Secure 2.0 (stan na rok 2022), czyli umożliwić klientowi potwierdzenie każdej transakcji internetowej opłaconej kartą poprzez mechanizmy jego banku.

A skoro klientom sklep oferuje różne mechanizmy płatności, Zespół musi zapewnić, że oprogramowanie poprawnie obsługuje każdy z nich, nawet jeśli wiążą się one z różnymi protokołami komunikacji, standardami zapisu danych itd. Konieczne będzie zebranie od klienta niezbędnych danych do realizacji płatności, przesłanie ich w określonym formacie, zapewne odpowiednio zaszyfrowanych. Komunikacja taka będzie musiała zmieścić się w określonych ramach czasowych, a sklep internetowy będzie musiał obsłużyć sytuację, gdy płatność się nie powiedzie.

Przy czym, jeśli mowa o standardach, nie zawsze jest to wyłącznie kwestia czysto techniczna. Trzymając się przykładu ze sklepem internetowym: jeśli możliwe będzie zakupienie ubezpieczenia dla nabytych w sklepie produktów, klient musi jawnie wyrazić na to zgodę, potwierdzając skorzystanie z opcjonalnej oferty. Sposób, w jaki to zostanie zrobione od strony technicznej, jest w zasadzie dowolny, tak długo, jak rozwiązanie działa zgodnie z wytycznymi organizacji chroniącej prawa konsumentów.

Często firma chce chwalić się spełnieniem opcjonalnych standardów, bo pozwala to twierdzić, że jej produkty są lepsze, bezpieczniejsze, szybsze, bardziej ekologiczne itd. Aby uzyskać certyfikat zgodności z takimi standardami, konieczne jest wykazanie, że proces wytworzenia produktu pozwolił na trzymanie się ich, co wymusi konkretne działania na Zespole, uniemożliwiając mu jednocześnie zrobienie wielu rzeczy, które prowadziłyby do standardów tych naruszenia.

Przykładem mogą tu być organizacje potwierdzające certyfikatem to, że materiały użyte do wytworzenia produktu (kakao, drewno, dowolne inne surowce) pozyskane zostały w sposób ekologiczny, bez wykorzystania pracy niewolniczej. Wymaga to dostosowania procesu wytwórczego do wymogów tych organizacji oraz audytu, pozwalającego uzyskać stosowny certyfikat. Nie twierdzę, że takie certyfikaty i proces ich przyznawania faktycznie cokolwiek gwarantuje, posługuję się tutaj jedynie przykładem tego, jak standardy wpływać mogą na sposób budowania produktów.

Jest jeden scenariusz, który powoduje, że organizacja wręcz musi oczekiwać od Zespołu wpisania się w ściśle zdefiniowane standardy: dzieje się tak, gdy Zespół buduje produkt, który stanowi część większej całości rozwijanej również przez inne Zespoły. Aby zapewnić spójność technologiczną, architektoniczną i stały poziom jakości całego portfolio rozwiązań dostarczanych przez firmę, poszczególne Zespoły muszą posługiwać się takimi samymi lub wzajemnie kompatybilnymi narzędziami, praktykami i procesami.

Wróćmy na moment do usuniętego już zapisu, jaki kiedyś widniał w Scrum Guide, a który wskazywał, że to organizacja developerska tworzy Definicję Ukończenia. Ten zapis przypominał o konieczności uwzględnienia perspektywy standardów organizacji przy tworzeniu Definicji Ukończenia. Nie nakazywał natomiast bezmyślnego i literalnego skopiowania organizacyjnej Definicji Ukończenia do Zespołu. Wymagał od Zespołu stworzenia Definicji Ukończenia, która jest spójna ze standardami organizacji, o ile takie istnieją. Nic więc się nie zmieniło, natomiast dzięki obecnej formie opisu Definicji w Scrum Guide jest bardziej klarowne, że odpowiedzialność za jej stworzenie ma Zespół Scrum.

Perspektywa Developerów

Czy tylko użytkownicy i organizacja mogą mieć potrzeby związane z konkretnymi cechami produktu lub sposobem, w jaki będzie budowany? Jasne, że nie. Developerzy muszą być w stanie wytworzyć produkt tak, by możliwy był jego długotrwały rozwój przy zachowaniu stałego poziomu jakości (albo wręcz w sposób pozwalający podnieść tę jakość). Dlatego po uwzględnieniu perspektywy produktowej i standardów, należy zastanowić się nad tym:

  • Jakie cechy musi mieć produkt, by Developerzy mogli go skutecznie budować?
  • W jaki sposób musi być produkt budowany, by odbywało się to jak najskuteczniej i jak najbardziej efektywnie?

Można też powiedzieć, że po uwzględnieniu standardów organizacji (i wszelkich innych), należy zastanowić się również nad standardami, których chcą się trzymać sami Developerzy.

Jakich cech mogą oczekiwać od produktu Developerzy? Posłużmy się przykładem organizacji, która wymaga od wszystkich Zespołów, by produkty, jakie budują, były przetestowane przez kompetentnego testera. Developerzy mogą uznać, że manualne testy są niewystarczające i potrzebują ich automatyzacji. Żeby dało się operować produktem za pomocą narzędzi, które wykonają testy automatyczne, produkt musi być wyposażony w stosowne mechanizmy, które na to pozwolą. Nie są one potrzebne użytkownikom, nie wynikają też ze standardów organizacji, ale dzięki umożliwieniu łatwej automatyzacji testów, Developerzy dostarczać będą produkt szybciej i zapewne będzie on lepszej jakości.

Inny przykład: Developerzy mogą tworzyć na swoje potrzeby dokumentację, która ułatwi im zrozumienie, jak działa produkt i podejmowanie decyzji odnośnie do sposobu implementacji nowych funkcjonalności. Dokumentacja ta nie jest przeznaczona dla użytkowników (bo nie są oni Developerami), nie musi być też wymagana przez organizację – jest więc standardem zespołowym (developerskim).

Podobnie może być z praktykami i narzędziami. Np. organizacja może wymagać, by Zespół rozwijający oprogramowanie poddał napisany kod stosownemu przeglądowi przez eksperta, który oceni poprawność implementacji, a Developerzy stwierdzą, że sensowniej byłoby posłużyć się praktyką programowania w parach (ang. pair programming), która sensownie użyta może zastąpić konieczność przeglądu gotowego kodu.

Albo: organizacja wymaga, by tworzone były testy jednostkowe dla każdego kawałka kodu napisanego przez programistów. Developerzy mogą ten efekt uzyskać, posługując się praktyką Test-Driven Development (w skrócie TDD), która nie jest (wbrew nazwie) związana z testowaniem, tylko z projektowaniem dobrego kodu, ale której efektem ubocznym będzie powstanie wymaganych przez organizację testów jednostkowych.

Złożenie trzech perspektyw

W każdej z omówionych perspektyw ujawnić się mogą cechy albo czynności, jakie należy wykonać, aby powstał produkt:

  • nadający się do użycia z punktu widzenia użytkowników,
  • spełniający standardy, w tym te firmowe,
  • możliwy do dalszego rozwoju przez Zespół Scrum.

Powstaje w ten sposób pewien zbiór wymogów. Znajdują się w nim trzy rodzaje warunków:

  • czynności, jakie trzeba wykonać,
  • narzędzia i praktyki, którymi trzeba się posłużyć,
  • cechy, jakie musi mieć produkt i sposób potwierdzenia, że faktycznie je ma (czyli kolejna czynność, najczęściej mająca charakter testów).

Wydaje się, że ta lista będzie ogromna, ale tak naprawdę te trzy perspektywy bardzo głęboko i mocno się przenikają. Gdy już przeanalizujemy perspektywę produktu, rozważając standardy (w tym organizacyjne), jedynie uzupełnimy listę, która już i tak jakieś standardy uwzględniła. To samo dotyczyć będzie perspektywy Developerów.

I tu bardzo ważna uwaga: to jeszcze nie jest Definicja Ukończenia, a jedynie dobra podstawa do jej sporządzenia.

Ciąg dalszy nastąpi

W trzeciej części tej serii artykułów wyjaśniam, w jaki sposób użyć poczynionych ustaleń na temat produktu, obowiązujących przy jego wytwarzaniu standardów i potrzeb Developerów do sporządzenia Definicji Ukończenia.