Architektura i deliveryJak pracuje zespół
Szkolenia, które zmieniają sposób podejmowania decyzji w zespole, a nie framework, którego używa. Są uniwersalne — sprawdzają się tak samo w .NET, na JVM czy w Node.
Architektura, która przetrwa zderzenie z rzeczywistością
Jak wyznaczać granice, które nadal mają sens w trzecim roku — i jak wcześnie rozpoznać, że któraś jest w złym miejscu.
- Gdzie postawić granicę — i znacznie częstszy przypadek, gdy lepiej jej nie dodawać
- Własność danych, spójność i sprzężenia ukryte we współdzielonej bazie danych
- Monolit, modularny monolit i usługi — koszty, a nie ideologia
- Dokumentowanie decyzji tak, by kolejny zespół odziedziczył uzasadnienie, a nie tylko wynik
- Odczytywanie istniejącego systemu pod kątem podziałów, które już w nim są
Dladoświadczonych programistów, liderów technicznych, architektów
Planowanie sprintów i estymacja
Dlaczego estymacje się mylą, co z tym zrobić i jak zaplanować sprint, który w środę drugiego tygodnia nadal przypomina rzeczywistość.
- Dzielenie pracy tak, by każdy element dało się skończyć w jednym sprincie
- Estymacja w przedziałach i z poziomem pewności zamiast fałszywej precyzji
- Przepustowość, przenoszone zadania i arytmetyka wiarygodnego zobowiązania
- Definition of Ready i Definition of Done napisane dla Państwa zespołu
- Prowadzenie ceremonii w mniej niż godzinę bez gubienia ich sensu
Dlazespołów deliveryjnych, product ownerów, scrum masterów
Discovery, zakres i roadmapa
Zamiana wstępnego pomysłu w coś, co można wycenić, ułożyć w kolejności i obronić przed osobą, która to podpisuje.
- Dotarcie do prawdziwego wymagania stojącego za zgłoszoną funkcją
- Wykonalność techniczna i spike, który najpierw odpowiada na najdroższą niewiadomą
- Etapowanie, dzięki któremu coś wartościowego trafia na produkcję przed ukończeniem całości
- Budować, kupić czy zintegrować — decyzja na podstawie całkowitego kosztu, a nie intuicji
- Pisanie planu tak, by kompromisy pozostały widoczne po wyjściu z sali
Dlazespołów produktowych, liderów delivery i każdego, kto musi zobowiązać się do terminu
Standardy inżynierskie i flow
Code review, branching, CI/CD i testy, które warto pisać — praktyki decydujące o tym, jak szybko zespół może bezpiecznie działać.
- Code review, które wyłapuje problemy projektowe, a nie formatowanie
- Model branchowania i wydań dopasowany do tego, jak często faktycznie Państwo wdrażają
- Pipeline’y, które padają z prawdziwych powodów i są na tyle szybkie, by im ufać
- Gdzie testy się zwracają, a gdzie po cichu nie
- Uczynienie standardu domyślną ścieżką, by przetrwał kolejny deadline
Dlacałych zespołów inżynierskich
Modernizacja bez zamrażania rozwoju
Wzorzec strangler zastosowany do Państwa systemu — jak wymienić platformę, gdy działa ona produkcyjnie, a roadmapa idzie naprzód.
- Znalezienie pierwszego fragmentu: małego, wartościowego i naprawdę dającego się wydzielić
- Równoległe działanie starego i nowego systemu za tymi samymi adresami URL
- Współdzielone biblioteki i multi-targeting jako most między nimi
- Kolejność prac w warstwie danych, na której takie projekty zwykle utykają
- Czytelne pokazywanie postępów osobom, które je finansują, sprint po sprincie
Dlaliderów i interesariuszy platform legacy
