JDD - Dług techniczny

Transcript

1. Dług techniczny 
 czyli skryty oprawca organizacji (nie tylko technologicznych) Mateusz Gajewski • @wendigo • JDD Kraków 2017 1
2. Kim jestem • Ostatnie 8 lat spędziłem w Allegro, • 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
3. 3
4. Metafora długu technicznego Ward Cunningham, 1992 4
5. Dług techniczny 1. suma pieniędzy, którą ktoś pożyczył i musi zwrócić, 2. obowiązek dłużnika do spełnienia określonego świadczenia, 3. zobowiązanie moralne wobec kogoś źródło: https://sjp.pwn.pl/slowniki/dług.html 5
6. Dług techniczny Technika to usystematyzowane wykorzystywanie reguł naukowych i wiedzy 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
7. Jako IT dostarczamy „biznesowi” oprogramowanie, aplikacje, architekturę, procesy, technologie, urządzenia, kompetencje, organizację pracy które pozwalają nam świadczyć usługi mające określoną funkcjonalność (fit for purpose) użyteczność (fit for use) 7
8. Systemy muszą mieć odpowiednie -ości Wymagania pozafunkcjonalne normy ISO 9216 niezawodność wydajność dokładność integralność łatwość odporność rzetelność dostępność czytelność pojemność skalowalność dojrzałość jakość stosowalność zgodność odtwarzalność odzyskiwalność analizowalność operowalność utrzymywalność zmienialność testowalność zamienialność rozwijalność efektywność interoperacyjność bezpieczność niezawodność przenośność plastyczność adaptowalność instalowalność bezawaryjność konfigurowalność zastępowalność powtarzalność 8
9. Dług techniczny przejawia się brakiem wymaganej użyteczności 9
10. Przejawem długu technicznego nie jest brak funkcjonalności 10
11. Jak i dlaczego powstaje dług techniczny? 11
12. Kompromis: „A” lub „B” 12
13. „Designing a perfect solution is a destructive endeavor and is elusive to even the most capable software craftsman.” Chris Sterling - Principal Product Manager Spring Cloud 13
14. Wpływ środowiska Ograniczone zasoby: 1. presja czasu, 2. brak odpowiednich danych, 3. finansowania, 4. brak odpowiednich ludzi, 5. brak kompetencji i doświadczenia, 6. brak dostępu do narzędzi, technologii i wiedzy.
 14
15. Klasyfikacja źródeł długu technicznego Żródło: M. Fowler - Technical Debt Quadrant 15
16. Dług techniczny wynika z
 każdej świadomie lub nieświadomie podjętej decyzji, której rosnący w czasie koszt zostanie nieuchronnie poniesiony w przyszłości 16
17. Zaciąganie długu technicznego pozwala nam szybciej dostarczać, zbierać informacje zwrotne, uczyć się i dochodzić do poprawnych rozwiązań 17
18. Ewolucja systemów 
 wg Lehmana 18
19. Ewolucja systemów klasy „E” 1. Ciągła zmienność (continuing change), 2. Wzrastająca złożoność (increasing complexity), 3. Samoregulacja (self regulation), 4. Organizacyjna stabilność (conservation of organisational stability), 5. Zachowanie znajomości (conservation of familiarity), 6. Ciągły wzrost (continuing growth), 7. Degradacja jakości (declining quality), 8. Sprzężenie zwrotne (feedback system). Żródło: Prawa Lehmana ewolucji oprogramowania 19
20. Prawo I: „Ciągła zmienność” „continuing change” 20
21. Prawo II: „Wzrastająca złożoność” „increasing complexity” 21
22. Prawo VI: „Ciągły wzrost” „continuing growth” 22
23. Prawo VII: „Degradacja jakości” „declining quality” 23
24. „If you are not improving, entropy guarantees that you are actually getting worse.” Gene Kim - The Phoenix Project 24
25. Ryzyka związane z długiem technicznym 25
26. 26
27. 27
28. http://blog.hasmanythrough.com/2009/9/3/circle-of-death 28
29. Niespłacanie długu technicznego 1. Nie dostarczanie na czas nowych funkcjonalności, 2. Wzrost ryzyka biznesowego, 3. Zatrzymanie rozwoju firmy, 4. Odpowiedzialność karna, 5. Problem z otrzymaniem kolejnej rundy finansowania (due diligence), 6. Niezadowolenie i odpływ klientów (zła funkcjonalność, niska używalność), 7. Utrata kapitału firmy, 8. Upadek :( 29
30. Spektakularne przypadki 1. 2009: Nasza Klasa - Pan Gąbka i 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
31. Indykatory długu technicznego 31
32. 32
33. Wewnętrzna jakość 1. Czy stosowane są wzorce clean code? 2. 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
34. Struktura komponentów 1. W jaki sposób aplikacja podzielona jest na 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
35. Architektura 1. Czy architektura posiada strukturę i jest spójna? 2. 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
36. Procesy 1. Jaki jest lead time (LT) wprowadzania nowych zmian? 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
37. Organizacja 1. W jaki sposób nabywana i wprowadzana jest nowa 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
38. Produkt 1. Proporcjonalnie ile czasu poświęcane jest na rozwój nowych 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
39. Jak postępować z długiem technicznym? 39
40. Nie ukrywajmy długu technicznego przed biznesem 40
41. Obsługa długu 1. Dług powinien być zarządzany tak samo jak 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
42. Taksonomie długu technicznego 1. Niezamierzony (niska jakość) - wymaga stałych 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
43. Podsumowując… 43
44. Dług techniczny jest w każdej organizacji. 
 Nie jest on tylko i wyłącznie problemem IT. 44
45. Dług techniczny może być strategiczną decyzją podjęta w celu zebrania odpowiedniego doświadczenia 45
46. Dług techniczny może być także wynikiem niekompetencji, głupoty i niekontrolowanego działania entropii 46
47. Nie bój się zaciągać długu technicznego. 
 Rób to świadomie. Spłacaj go konsekwentnie. 47
48. „Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.” Agile Manifesto 48
49. Thanks! 
 contact@serafin.tech Q&A? 49