Rozłóżmy na czynniki pierwsze Inkrement, w oryginale nazwany The Increment, a w oficjalnym tłumaczeniu określony jako Przyrost. Jest to jeden z elementów Scruma, które traktowane są najbardziej po macoszemu. Gorzej ma się chyba tylko Cel Sprintu.
The Increment
Tradycją na naszym #białkowym blogu stało się, że rozpoczynamy od definicji. Także i tym razem postaram się odczarować angielsko brzmiący „Increment”, bardzo często określany polskawo brzmiącym słowem „Inkrement”. Słowo to znaczy nic innego niż przyrost i to właśnie jako Przyrost zostało przetłumaczone w oficjalnym Podręczniku Scrum.
I tak jak niektórzy z uporem maniaka będą odmieniali słowo Epic na rozmaite sposoby, tak i niektórzy z nas będą mówić „Inkrement”. W niektórych branżowych materiałach można napotkać na stwora z zupełnie innej krainy, czyli „Wdrażalny Przyrost Oprogramowania”. Z jednej strony dobrze opisuje to, czymże ten Przyrost jest, ale fraza ta jest zdecydowanie za długa jak na nasze potrzeby.
„The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” – Scrum Guide
Niezależnie od ulubionej nazwy na oryginalny Increment, znaczy on zawsze to samo: wszystkie elementy Backlogu Sprintu, które zostały ukończone wraz z wartością wszystkich poprzednich Inkrementów. Inaczej mówiąc: jest to wszystko to, co zrobiliśmy w ramach projektu, ze wskazaniem na rzeczy zrealizowane w ostatnim Sprincie.
Inkrement czyli Przyrost
Zarówno oryginalny Increment, jak i polski Przyrost wyraźnie wskazują na jego sposób powstawania – etapami czyli iteracyjnie. Nie ma tu miejsca ani na wielki wybuch, ani na wieloletni wysiłek. To, czego zarys przekazał nam Product Owner tworzymy po kawałku.
„An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint.” – Scrum Guide
Przyrost powstaje po trochu w każdym Sprincie. Wierni idei empiryzmu powinniśmy sprawdzić co zrobiliśmy, jak nam poszło i zdecydować czy jest to dobry kierunek, czy też może należałoby go zmienić. Robimy to między innymi na spotkaniu zwanym Sprint Review. Nie uda nam się tego zrobić, jeżeli praca, którą wykonaliśmy, nie nadaje się do oglądania.
Nasze dzieło musi być sprawdzalne. To znaczy, że ktokolwiek nie zechce podziwiać owoców naszej pracy, powinien móc to zrobić. Sama sprawdzalność to jednak za mało. Nasz Inkrement powinien spełniać jeszcze kilka warunków.
Wdrażalny Przyrost Oprogramowania
Wspomniany wcześniej „Wdrażalny Przyrost Oprogramowania” zawiera kluczowe słowo: „wdrażalny”. Nasze dzieło ma nie tylko działać i być pozbawione uciążliwych błędów, ale także być możliwe do wdrożenia. Oznacza to, że sami przed sobą musimy przyznać, że wszystkie czynności wymagane przed ewentualnym wdrożeniem zostały wykonane.
Rozkładanie tych czynności na poszczególne wymagania z backlogu i realizowanie ich w ramach Sprintów, to wielka zaleta iteracyjnego podejścia do wytwarzania oprogramowania. Nie tylko oszczędzamy sobie pracy związanej z dopasowaniem wszystkich zmian na samym końcu, ale dzięki Continuous Integration jesteśmy zawsze gotowi do wydania.
„At the end of a Sprint, the new Increment must be „Done,” which means it must be in useable condition and meet the Scrum Team’s definition of „Done”.” – Scrum Guide
Do osiągnięcia tego stanu, wszystkie zespoły pracujące nad jednym produktem powinny uzgodnić Definicję Ukończenia, zwaną też DoDą (od angielskiego Definition of Done). Nią jednak zajmiemy się przy innej okazji. Dość powiedzieć, że musi ona zawierać wymagania, które zapewnią pełną wdrażalność naszego Przyrostu.
Inkrement zdatny do użytku
„The increment must be in useable condition regardless of whether the Product Owner decides to release it.” – Scrum Guide
Kolejne podkreślenie pochodzi prosto z Podręcznika Scrum. Przyrost musi być zdatny do użytku! Ten warunek spełnia jedynie coś, czego możemy zacząć używać od zaraz, po decyzji Product Ownera o wdrożeniu.
Inkrement to nie „jeszcze musimy przygotować skrypty aktualizujące bazę danych”, ani nie „muszę wyłączyć nieukończone funkcjonalności”. Jeśli mamy pełne wsparcie dla DevOps, to decyzja o wdrożeniu powinna być równie prosta co wysłanie e-maila.
To jest zresztą bardzo dobry papierek lakmusowy dla naszego Przyrostu. Zadajmy sobie pytanie „co jeszcze musimy zrobić, jeśli chcielibyśmy używać naszych nowych funkcjonalności od jutra?” Prawidłowa odpowiedź to „podjąć decyzję dziś, a w nocy wdrożyć nową wersję oprogramowania”. Jeżeli mamy jakieś „ale”, to koniecznie trzeba dodać je do naszego Definition of Done lub zautomatyzować.
Dlatego też niezwykle ważne jest patrzenie na nasz Increment jako na całość. Podobnie jak wewnątrz Scrum Team nie ma „mojego” i „twojego”, tak w Przyroście nie ma „wdrażalnych” i „niewdrażalnych” funkcjonalności. Albo całość jest gotowa, albo nie.
The Increment, Inkrement – nasza duma
Jak więc rozumieć Inkrement? Nie jest to jedynie „zrobiona robota”, takie myślenie zbytnio upraszcza znaczenie tego artefaktu. Wiemy już, że są to zrealizowane funkcjonalności wraz z kompletnym wsparciem do ich wdrożenia i używania, ale to w dalszym ciągu nie pokrywa wszystkich niuansów.
„The increment is a step toward a vision or goal.” – Scrum Guide
Sam Scrum Guide sugeruje, żebyśmy przyjrzeli się wspominanemu na początku Celowi Sprintu i wizji. Te dwa elementy zwyczajowo kojarzą nam się z Product Ownerem – to on o nie dba, a i w wielu przypadkach je wyznacza. To nie znaczy jednak, że zespół działa nieświadomie bądź błądzi po omacku. PO szerzy swoją wizję w ramach Scrum Teamu.
Pamiętajmy, że to wizja (a także nielubiany przeze mnie cel) są tym, do czego zmierzamy. Przyrost powinien powodować zbliżanie się z określonym Velocity do ustalonego punktu docelowego. Nawet jeśli mamy działający i wdrażalny Inkrement, nawet jeśli napracowaliśmy się w pocie czoła cały Sprint, to wszystko to na nic, jeśli zrobiliśmy coś, co się nikomu nie przyda.
„Zdatny do użytku”, „gotowy do wdrożenia”, „działający” – jak najbardziej. Ale przede wszystkim – „przynoszący wartość biznesową” czy „spełniający określone potrzeby klienta”. Dlatego gdziekolwiek nie zabrniemy w ramach naszych rozważań na temat Scrum, zawsze pamiętajmy, żeby to co robimy faktycznie było wartościowe.
