Witajcie drodzy czytelnicy.

Tytuł tego blogu w dość pokrętny ;) sposób oddaje dwie najważniejsze koncepcje, które będą osią opisywanych przeze mnie zagadnień.

Pierwsza część tytułu odnosi się do sytuacji w której proste stosowanie reguł opisanych w SCRUM guide (wraz z najbardziej popularnymi ich implementacjami) nie wystarczy aby zagwarantować sukces projektu. Wielkość zespołu developerskiego, złożoność systemu który tworzycie oraz umocowanie w organizacji (zarówno Twojej jak i klienta) może zmusić was do niezłego gimnastykowania się, aby  zakończyć przedsięwzięcie sukcesem.

W tym miejscu chciałbym jednak uspokoić scrumowych purystów. Opisywane przez mnie metody i techniki i nie łamią fundamentalnych zasad scrum’a, lecz raczej stanowią ich uzupełnienie lub konkretną implementację.   

Druga część tytułu odnosi się do sposobu, w jaki będę prowadził ten blog. Koncentrować się będę na konkretnych problemach które pojawiły się w moim projekcie, pomyśle na ich rozwiązanie oraz subiektywnych obserwacjach po dokonaniu zmiany. Nie jest to kolejny Agile’owy blog teoretyczny. Jest to relacja wojenna mojego zespołu … bezpośrednio z okopów.*

* Pomysł zaczerpnąłem w serii książek Henrika Kniberga „SCRUM/Lean from trenches”

Zespół do którego należę zaangażowany jest w tworzenie i rozwój systemu związanego z realizacją transakcji finansowych. Jest to typowe rozwiązanie backend’owe z małą ilością elementów GUI (głównie konfiguracja) oraz wieloma połączeniami do systemów zewnętrznych. System składa się z kilkudziesięciu modułów rozmieszonych na 26 serwerach  wirtualnych. Sam zespół w chwili obecnej liczy 13 developerów, 2 testerów, 2 administratorów, jednego developera BI, Scrum Mastera oraz Project Managera. Daje to 20 osób nie licząc „ludzi” po stronie naszego klienta. Oczywiście z powodu tego, że system rozwijany jest od kilku lat oryginalny skład zespołu zdążył się w między czasie prawie całkowicie zmienić. Można więc powiedzieć, że z tego powodu mamy sporo tzw. „legacy code’u”. Ciekawie prezentuje się też proces deploymentu. Każda nowa funkcjonalność musi przejść przez 3 środowiska: developerskie, pre-produkcyjne oraz oczywiście produkcyjne. Na każdym z tych środowisk wymagane jest przeprowadzenie testów oraz sporządzenie raportu z testów. Aby było jeszcze zabawniej za instalacje odpowiedzialny jest osobny team,  znajdujący się po stronie klienta i oczywiście zlokalizowany w Indiach. Dodatkowo mamy jeszcze osobne zespoły do utrzymania sieci, maszyn wirtualnych, bazy danych, pierwszej linii suportu. Każdy z nich ma osobnego managera oraz niechętnie (czytaj wcale) chce dzielić się uprawnieniami z zespołem deweloperskim.  Wszystko to przekłada się na długość procesu deploymentu, który obecnie średnio wynosi około 40 dni.

Po przeczytaniu akapitu powyżej Ci z was, którzy przeszli przez proces „forsowania” podejścia zwinnego w swoich firmach z pewnością zidentyfikowali trzy najczęściej stosowane argumenty z kategorii „Agile jest super ale u nas się nie da, ponieważ ….” … no właśnie ponieważ … zespół jest za duży, system się nie nadaje (brak GUI, zależność od zewnętrznych dostawców), podejście/procedury w firmie klienta są nieodpowiednie.

Oczywiście że „się da” chociaż prosto i bezboleśnie nie jest. O tym jak wyglądała walka z przeciwnościami w naszym zespole przeczytasz w dalszej części niniejszego blogu.

Nie stosuj technik i pomysłów które prezentuję na tym blogu. Nie bezpośrednio. To co zadziałało u mnie w zespole nie oznacza, że zadziała w twoim. Zanim wprowadzisz zmianę do waszego procesu tworzenia oprogramowania dokładnie ją przemyśl. Zwróć szczególną uwagę na ludzi z którymi pracujesz, zarówno w twoim zespole jak po stronie klienta. Jeśli zdecydujesz się na wprowadzenie prezentowane przez mnie pomysłu dokonaj w nim kilku zmian, które dostosują go do Twoich realiów projektowych. Mam też nadzieję, że moje posty stanowić też będą swego rodzaju bodźcem do tworzenia zupełnie nowych koncepcji i pomysłów. Jeśli tak się stało w sekcji komentarzy podziel się ze mną i innymi czytelnikami swoją koncepcją.