17. Aktualizacja vendorów
17
Przechodziliśmy przez migracje wielu frameworków. W zespole należy na stałe
zarezerwować czas na upgrade vendorów.
Decyzje które okazywały się dobre z perspektywy danego roku, po 10 latach nie zawsze
już takie są.
18. 18
Knowledge Base
Ludzie będą przychodzić i odchodzić. Zamiast
budować wiedzę ekspercką wśród kolegów
i koleżanek, należy ją zapisywać w projekcie
(git, wiki).
Nie tylko ułatwia to onboarding ale także powrót
i zrozumienie decyzji z wielu lat wstecz.
19. 19
Developer Productivity
-
DORA Metrics
Najważniejsze metryki to Lead Time oraz
Deployment Frequency
Deployment frequency to bicie serca zespołu
• Feature
fl
ags
• CD (w 100% automatyczny)
• Odpowiedni poziom testów automatycznych
• No-blame culture (fuckupy beda sie zdarzać)
Praktyki:
20. 20
Developer Productivity
-
Trunk Based Development
Tylko TBD zapewnia pełny Continuous Integration
• Commity do mastera minimum raz dziennie
• Code review (pair programming, stacked commits)
• PR to nie miejsce na dyskusje o designie
• Mindset Done better than perfect
21. 21
Developer Productivity
-
Monolit
-
Monorepo
Monolith jest najlepszym rozwiązaniem na
początku prac nad produktem, lepiej mieć źle
napisany jeden monolit niż dziesiątki złych
mikroserwisów.
Na późniejszym etapie monorepo (mikroserwisy)
jest bardzo dobrym rozwiązaniem.
22. 22
Developer Productivity
-
Deep Work
Należy optymalizować Deep Work w zespole bo
jest on bardzo kosztowny. Zbyt częste spotkania
niszczą produktywność w zespole.
Daily może być w formie asynchronicznej (praca
zdalna)
23. 23
Developer Productivity
-
KISS
Jeżeli zrealizowanie jakiegoś projektu jest
skomplikowane to należy pogadać z managerem
technicznym / architektem / cto aby uprościć
podejście bo pewnie osoba która zlecała nie
wiedziała o tych komplikacjach.
25. 25
Why, Why, Why, Why, Why
Biznes często nie posiada gotowych odpowiedzi i
są to hipotezy jak coś może działać, dlatego trzeba
dopytywać o wszystko.
Jeżeli biznes zaczyna mówić o rozwiązaniach /
technikaliach zamiast problemie to wiedz że jesteś
w czarnej $^*&@
26. 26
Scrum or not to scrum
Scrum się sprawdza gdy zespół
Jeżeli tak zwany toil dochodzi do 50%
czasu to lepiej pomyśleć o Kanbanie
• ma jasny cel a nie roadmape
fi
czerów
• jest wstanie dostarczyć przyrost
biznesowy co każdy sprintu
• wymaga współpracy różnych osób
• rzadko zajmuje się wrzutkami
27. 27
Vendor Lockin
-
AWS
Nie taki straszny i pozwala na:
• zwiększenie skalowalności usług (Aurora)
• zwiększenie bezpieczeństwa
• uproszczenie stacku technologicznego
• skrócenie time to market
28. 28
Support Domain
>
Core Domain
(
?
)
Gdy sam produkt nie ma rozbudowanej logiki to
supportowe domeny bywają równie interesujące:
• DDoS protection
• Spam protection
• Abuse handling
• SSL provisioning
• Global Infrastructure