Dlaczego teraz
Jestem w trakcie zbierania materiałów/spisywania/nagrywania tytułowego tematu. Bezpośrednim powodem, iż robię to właśnie teraz jest potrzeba projektowa.
Po raz kolejny jestem w nowym zespole. Jest dużo do zrobienia w kwestii dobrych praktyk. Chcę zrobić wszystko co mogę żeby to przyspieszyć, poprzez danie tej wiedzy zespołowi w możliwie przystępny sposób.
To tylko jedna strona medalu. Druga jest bardziej istotna. Robiłem to już wiele razy i zrobię to jeszcze wiele razy. Tak jak to robi konsultant, który pomaga wielu różnym zespołom.
Przybliżę obecną sytuację. Nas – technicznych konsultantów jest dwóch, dział programistyczny firmy której pomagamy ma 20 osób. Jest bardzo dużo pracy do wykonania, a nas mało. Bardzo potrzebuję narzędzi, które pozwolą takie tranzycje lepiej skalować.
Ucinamy scope
Jak to się mówi w Pragmatic Coders „Dobrego Product Ownera poznaje się po tym ile rzeczy potrafi wyrzucić ze scope’u”
O czym NIE będzie:
- backlogu
- (feature toggle – to później)
- dobrej architekturze (ciekawsze wzorce, Hexagon, itp)
- testach (będzie, ale mało)
Co będzie
- Trunk Based Development
- Continous Integration
- Jedno repo – powiedzmy projekt w 7 osobowym zespole
- Dzielenie zadań na mniejsze a commitów na jeszcze mniejsze.
- Skuteczne code review:
- autymatyzacja kolejnych rzeczy
- gdy wystawiam CR to muszę się przyłożyć żeby Reviewerom było łatwiej
- ciągły refactoring (Boys Scout Rule) + refactoring przed feature/bugiem.
Przejście z A do B
Na te kilka tematów można znaleźć materiały i podrzucić zespołowi. Ale to nie takie proste 
Trudno jest sprawić żeby firma/zespół/poszczególni ludzie zmienili swoje codzienne praktyki do których przywykli. Pokaże od kuchni „mój warsztat”, które sprawia, żeby zespół, który nie ma nic z wymienionych praktyk potrafił samodzielnie (bo będzie moment, kiedy przejdę do kolejnego zespołu) działać w oparciu o wszystkie te praktyki.
Idą „ciekawe czasy” na moim blogu i kanale youtube
