W karierze przyjmowałem różne role: programisty, architekta, lidera i mentora, • Aktualnie pomagam organizacjom na różnym etapie rozwoju (w tym startupom) w pozbywaniu się długu technicznego i skalowaniu ich biznesu, • @wendigo na Twitterze, GitHubie, Keybase i Speakerdeck 2
praktycznej do wytwarzania określonego produktu (wyrobu). Składa się z: 1. Zespołu reguł i praw naukowych, 2. Określonej grupy zastosowań, 3. Określonego zestawu produktów wytwarzanych przy użyciu określonych urządzeń, 4. Specjalistycznej wiedzy, wyrażonej zbiorem technologii (metod) wykorzystywanych w pracach badawczych, pomiarach i praktycznych zastosowaniach techniki, 5. Doświadczenia praktycznego, 6. Organizacji, wyrażonej strukturą i systemami. źródło: „The Management of Technology, Perception and Opportunities”, Paul Lowe, 1995 6
ciągłe awarie systemu, 2. 2012: Knight Capital Group - strata 440 mln $ w 40 minut, 3. 2013: Toyota - błąd w kodzie ECM powoduje śmierć kierowcy, 4. 2017: GitLab - usunięcie danych i problem z ich przywróceniem, 5. 2017: AWS - 11h niedostępność regionu S3. 30
Czy kod jest testowany? W jaki sposób? 3. W jaki sposób mierzona jest jakość kodu? 4. Jak często kod jest refaktoryzowany? 5. Jak duża jest duplikacja kodu? 33
komponenty? Ile można ich wydzielić? 2. Jak komponenty integrują się ze sobą? 3. Jak silnie powiązane są ze sobą komponenty? 4. Jak łatwo zidentyfikować można komponenty w których należy dokonać zmianę biznesową? 5. Jak łatwo wymienialne są poszczególne komponenty? 34
Czy architektura odpowiednio wspiera cele biznesowe? 3. Czy architektura wprowadza porządek, integralność i bezpieczeństwo do systemu? 4. W jaki sposób architektura jest udokumentowana i czy jest jednakowo rozumiana? 5. W jaki sposób komponenty integrują się ze sobą na poziomie architektury? 35
2. Jakie zespoły są zaangażowane w proces dostarczania wartości? 3. Jak długo trwa integracja zmian przed wdrożeniem? 4. W jaki sposób testowane są zmiany przed wdrożeniem? 5. Jakie są artefakty procesu wytwarzania oprogramowania? 36
wiedza w organizacji? 2. Jak dobrze pracownicy rozumieją i wspierają cele organizacji? 3. Czy istnieją role lub kompetencje które trudno jest zastąpić (silosy)? 4. Jak łatwe/trudne jest pozyskanie nowych pracowników z odpowiednimi kompetencjami? 5. Ile trwa wdrożenie nowego pracownika w jego obowiązki? 37
funkcjonalności? 2. Czy istnieje dedykowany zespół utrzymaniowy? 3. Kto podejmuje decyzje o wdrożeniu produktu? 4. Jak często wdrażane są nowe funkcjonalności? 5. Jak wiele jest defektów i awarii po wdrożeniu? 38
zarządzamy produktem, który rozwijamy, 2. Dług powinien być priorytetyzowany ze względu na: 1. Koszt (ile będzie kosztować jego spłacenie), 2. Łatwość (jak trudne technicznie jest pozbycie się go), 3. Wpływ (jak możemy ucierpieć żyjąc z nim), 4. Prawdopodobieństwo (jak bardzo prawdopodobny jest negatywny wpływ długu), 3. Powinniśmy szukać globalnych rozwiązań lokalnych problemów. 41
przeglądów i refaktoryzacji, 2. Zamierzony (reaktywny, taktyczny): 1. Skoncentrowany krótkoterminowy - zadania trafiają do backlogu do wykonania po releasie, 2. Nieskoncentrowany krótkoterminowy - spłacany w trakcie bieżącej pracy (refaktoryzacja), 3. Długoterminowy (proaktywny, strategiczny) - zarządzany jak projekt, z odpowiednim budżetowaniem Steve McConnell, “Technical Debt” 42