REFAKTORYZACJA JAKO PRZYKŁAD ZMIANY ORGANIZACYJNEJ - CASE STUDY Z NORDEA BANK AB S.A. "Skrócić czas tworzenia nowej tworzenia nowej funkcjonalności z kilku miesięcy do 30 dni" - to pierwszy cel, który sobie postawiliśmy. Po kilku miesiącach zaprowadził nad nową wersją naszego systemu, refaktoryzacji, eksperymentowania z nowymi technologiami, tworzenia gildii i bliższej współpracy z biznesem. W trakcie prezentacji przedstawimy drogę oraz kluczowe punkty tej zmiany. W szczególności dowiesz się: * Jak definiowaliśmy cele zmiany? * Jak identyfikowaliśmy problemy technologiczne i organizacyjne? * Jak przekonywaliśmy management do refaktoryzacji? * Jak pozyskiwaliśmy kolejne osoby chętne do uczestniczenia w naszej inicjatywie?

1. Refaktoryzacja systemu
eBankowości
Oddolna inicjatywa programistów
w Nordea IT (obecnie Nordea Bank AB)

2. Kontekst
• Nordea IT rozwija eBankowość w krajach
bałtyckich
• Biznes długo czeka na zlecone funkcjonalności
(do kilku miesięcy)
• Niektóre zlecenia są niemożliwe do wykonania
z powodów technologicznych
• Biznes zamawia funkcjonalności „na szybko” u
lokalnych dostawców

3. Cel współpracy (ver. 1)
• Skrócić czas stworzenia nowej funkcjonalności
do 30 dni
• Action-30

5. Potrzeby
Problemy
Dlaczego?
Chcę uniknąć…
Korzyści
Po co?
Chcę
osiągnąć…

6. #1 Root Cause Analysis

7. #1 Root Cause Analysis
• Używanie Struts 1.2
• Nadmierna uniwersalność kodu

8. #2 Analiza architektury

9. #2 Analiza architektury
• Przetwarzanie biznesowe na JSP
• Konieczność przestrzegania architektury Struts
1.2
• Silne zależności od innych systemów
• Duża ilość nieużywanego kodu

10. #3 Analiza procesu dostarczania

11. #2 Analiza procesu dostarczania
• Multitasking (czas przełączenia się: 30-60
min.)
• Pseudoarytmetyka projektowa (%%)
• Nieefektywne spotkania
• Specjalizacja programistów

12. Plan działań
• Pracujemy A’la scrum
– A’la sprint trwa 1m-c
– Czwartek – Pomodoro Day
• Pracujemy po 2 osoby nad 1 zadaniem
• 1 zadanie techniczne na pierwszy sprint
– Kilka zadań organizacyjnych
• Wspólna zgoda na unikanie spotkań

13. A’la sprint #1 - Retro
• ++
– Cel osiągnięty
– Dobrze pracuje się razem; jako zespół i w parach
– Spotkania się ustrukturyzowały i zagęściły
– Udało się poświęcić więcej czasu niż planowaliśmy
• --
– Więcej zespołowego planowania

14. TeamNorms
• Zawsze pracujemy w 2 osoby
• Regularne 15-min standups
• Świętujemy sukcesy
• Unikamy nieproduktywnych spotkań
• Podkręcamy PomodoroDay – tylko
programowanie, zero spotkań
• …

15. Podręcznik refaktoryzacji
• „Żeby dodać nowy feature, musisz…”
• „Użyj modułu mavena, aby…”
• …
• Podręcznik ma formę papierową (flipachart)
– Jest aktualizowany podczas codziennych spotkań
– Docelowa będzie na wiki

16. Obserwacje
• Action-30 żyje własnym życiem, ludzie gadają
• Jak coś jest fajne i ciekawe, to czas się znajdzie
• Manager robi dobrą robotę

17. Sprint #2 Jak przebić się „wyżej”?

18. Sprint #2 Jak przebić się „wyżej”?
• Redukcja wierszy kodu o 3%
• Redukcja CC o 15%
Dla tej próbki kodu można by wykonać 29
testów mniej
– aproksymując po całym kodzie…
• przeliczając wykonane testy na dni robocze…

19. Sprint #2 Wsparcie od biznesu?
• Jakich funkcjonalności do tej pory
odmawialiśmy?
#angularjsworkshop

20. Obserwacje
• Kierownicy projektów proszą o więcej
• Management zainteresowany Action-30
• Programiści z innych zespołów przyłączają się
do inicjatywy
• Wsparcie od całego managementu i top
managementu

21. Zdaniem zespołu Action-30

22. Co dalej?
• Pokazaliśmy biznesowi, że „można”
– Że nie będzie drogie (@see problem)
– Że nie będzie długotrwałe (@see problem)
• Biorą to pod uwagę, gdy powołują nowe
inicjatywy
• Zmiana myślenia, że system nie jest
„zabetonowany”
• Przejmujemy produkty rozwijane przez Grupę dla
krajów nordyckich – development i maintenance
• Wykorzystujemy zdobytą wiedzę

23. Zadanie domowe ;)
• Które wzorce wprowadzania zmian
zostały wykorzystane w trakcie
pracy, o której rozmawiamy?