Dziękuję za ciekawe pytanie.

Odniosę się do niego z perspektywy osoby zajmującej się obszarem ITIL. Sądzę, że do mojej odpowiedzi dołączą się koleżanki i/lub koledzy zajmujący się obszarem Agile.

Jak rozumiem, punktem wyjścia dla tego pytania jest założenie, że chcemy połączyć powyższe praktyki. Warto jednak zadać sobie pytanie, na ile danej organizacji potrzebne są poszczególne praktyki czy standardy, na ile mają zastosowanie. Często spotykam się z organizacjami wytwarzającymi oprogramowanie, które z uporem maniaka starają się „wdrożyć” ITIL-a. Dodam, że nie są to organizacje świadczące usługi IT w rozumieniu ITIL-a, nie utrzymują żadnej infrastruktury dla użytkowników końcowych, nie odpowiadają za poziom usług w całości. Organizacje te wytwarzają oprogramowanie, które jest wdrażane, utrzymywane i częściowo serwisowane po stronie klienta. W takim wypadku zastosowanie biblioteki ITIL będzie ograniczone.

Przeanalizujmy jednak przypadek organizacji świadczącej usługi IT, w tym wytwarzającej oprogramowanie, które następnie jest wdrażane, utrzymywane i serwisowane przez tą organizację. Zastanówmy się, jak zastosować procesy ITIL-owe w zespole pracującym zgodnie z ideą DevOps. Posłużę się tutaj przykładami rozwiązań, w tworzeniu których uczestniczyłem jako konsultant.

Próbując zmapować funkcje ITIL-owe na podejście DevOps, tę część zespołu, która odpowiada za analizę, programowanie, testy, wdrożenie (Dev) można potraktować jako funkcję Technical Management zdefiniowaną w bibliotece  ITIL-a. Zespół ten realizuje m.in. procesy takie jak Change Management czy Release Management. 

Z kolei część zespołu odpowiadająca za utrzymanie, być może częściowo za testy, za serwis (Ops) potraktować należy jak ITIL-ową funkcję Service Desk. To grono osób odpowiada za obsługę incydentów, zapytań i wniosków o usługę. Z perspektywy użytkownika jest pierwszą linią kontaktu, stara się samodzielnie obsłużyć jak największą część zgłoszeń i dopiero jeśli nie jest w stanie tego zrealizować, ze względu na kompetencje czy uprawnienia, angażuje inne funkcje, m.in. Technical Management. Service Desk ma odciążać pozostałe funkcje w zakresie bieżącej obsługi użytkowników i jednocześnie zapewniać profesjonalne wsparcie użytkowników, cechujące się m.in. szybkim dostarczaniem rozwiązań i kompleksową komunikacją z użytkownikami.

Idąc tym tokiem, na „zintegrowany” zespół DevOps, należy nałożyć jednak pewien podział, kierując się funkcjami ITIL. Należy  wyodrębnić funkcję Service Desk (Ops), która obsługuje użytkowników w momencie, gdy pojawiają się incydenty, zapytania, czy wnioski o usługę. Zespół ten może być wyznaczony w specyficznych warunkach na zasadzie dyżuru i obsługi zgłoszeń z tzw. doskoku – jeśli pojawia się zgłoszenie, obsłużenie go jest dla tej grupy najwyższym priorytetem działania, po jego obsłudze następuje powrót do zespołu projektowego. Dla pozostałej części zespołu (Dev) najwyższy priorytet mają działania rozwojowe. Grupa Dev do obsługi zgłoszeń angażowana jest tylko w wyjątkowej sytuacji, braku wiedzy, czy kompetencji z zespole serwisowym, przy określonych kategoriach, czy priorytetach zgłoszeń, zagrożeniach ciągłości biznesu klienta, itp.

Ponieważ priorytetyzacja może sprawiać pewien problem osobom będącym „wewnątrz” zespołu DevOps, zwłaszcza w przypadku realizacji wspólnego serwisu dla wielu zespołów projektowych, rozważyć można wprowadzenie dodatkowej roli, której zadaniem jest ocena sytuacji i określenie priorytetu działania dla danej grupy. Osoba ta powinna mieć pełne informacje na temat warunków zawartych w umowach projektowych i serwisowych oraz wgląd w zgłoszenia od użytkowników. Oczywiście dobrze byłoby, gdyby umowy projektowe i utrzymaniowe z klientem zawierały szczegółowe zasady określania priorytetów. Poszukując zakresu odpowiedzialności dla tej roli, częściowo zaczerpnąć można z roli Service Level Managera.

To, na co jeszcze warto zwrócić uwagę w tym przypadku, to zapewnienie odpowiednich narzędzi personelu serwisu, np.: baza znanych błędów i rozwiązań, system ticketowy, baza konfiguracji CMDB.

W Internecie znajdują się artykuły na ten temat. Trzeba trochę poszukać. Przykłady:

http://blog.itil.org/2014/07/allgemein/integrating-agile-and-itsm/

http://theagileexecutive.com/2010/02/19/the-agile-flywheel/

Kolega wcześniej opisał dość wyczerpująco problem z punktu widzenia ITIL-a. Z punktu widzenia zespołu Dev, ma on listę cech do dostarczenia. To biznes musi zdecydować co w danym momencie jest dla niego ważniejsze. Jeżeli nagle pojawi się nowa cecha, która z punktu widzenia biznesu musi być dostarczona jak najszybciej, to zespół powinien ją dostarczyć, rezygnując z dostarczenia cech, które są mniej istotne.

W zespole znajduje się przedstawiciel biznesu. Powinien on ocenić wpływ zmiany i podjąć najlepszą w tym konkretnym wypadku decyzję, jak postąpić. Oczywiście kluczowy w tym momencie jest sposób zarządzania zmianą i konfiguracją w organizacji.

DevOps wskazuje, że cele biznesowe Developerów, Operacji oraz ich procesów są wspólne. Obie są częściami tego samego procesu biznesowego.

Agile zapewnia ścisłą współpracę pomiędzy biznesem a operacjami i developerami. Biznes jest tutaj decydentem i łącznikiem pomiędzy tymi dwoma zespołami, synchronizującym ich pracę. Jeżeli biznes podejmuje złe decyzje np. ciągle zaburzając pracę zespołu developerów, efektywność tego zespołu będzie bardzo niska i biznes nie uzyska w założonym czasie oczekiwanych rezultatów. Z drugiej strony, jeżeli nagle okaże się, że pewna cecha produktu, o której nikt wcześniej nie pomyślał, jest niezbędna do wykorzystania tego produktu, to biznes podejmie decyzję o zmianie kierunku pracy zespołu, licząc się ze wszystkimi konsekwencjami tego kroku.

Podstawowym problemem organizacji dla wdrożenia DevOps, są konieczne zmiany kultury organizacji. Trzeba znaleźć taki sposób oceny i motywowania pracowników, aby opłacało im się współpracować. A współpraca ta musi być mierzona i oceniana dla całego cyklu DevOps.

Ważne jest też patrzenie na współpracę Dev i Ops jako na jeden proces. Sprint nie jest celem. Sprint jest narzędziem do osiągania celów przez biznes. I z tego punktu widzenia nie widać "zaburzeń". Sprint ma po prostu wspomagać realizację celów biznesowych.

DevOps to także wspólne narzędzia dla Dev i Ops, dzięki którym informacje przepływają szybciej i są podejmowane lepsze decyzje.

Podsumowując - jak korzystać z tych pomysłów? Skutecznie.

Kto za to odpowiada? Biznes. Tylko on wie, co dla niego jest najlepsze - kiedy stabilizacja, a kiedy częsta zmiana.