Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Refaktoryzacja systemu
eBankowości
Oddolna inicjatywa programistów
w Nordea IT (obecnie Nordea Bank AB)
Kontekst
• Nordea IT rozwija eBankowość w krajach
bałtyckich
• Biznes długo czeka na zlecone funkcjonalności
(do kilku mie...
Cel współpracy (ver. 1)
• Skrócić czas stworzenia nowej funkcjonalności
do 30 dni
• Action-30
Potrzeby
Problemy
Dlaczego?
Chcę uniknąć…
Korzyści
Po co?
Chcę
osiągnąć…
#1 Root Cause Analysis
#1 Root Cause Analysis
• Używanie Struts 1.2
• Nadmierna uniwersalność kodu
#2 Analiza architektury
#2 Analiza architektury
• Przetwarzanie biznesowe na JSP
• Konieczność przestrzegania architektury Struts
1.2
• Silne zale...
#3 Analiza procesu dostarczania
#2 Analiza procesu dostarczania
• Multitasking (czas przełączenia się: 30-60
min.)
• Pseudoarytmetyka projektowa (%%)
• Ni...
Plan działań
• Pracujemy A’la scrum
– A’la sprint trwa 1m-c
– Czwartek – Pomodoro Day
• Pracujemy po 2 osoby nad 1 zadanie...
A’la sprint #1 - Retro
• ++
– Cel osiągnięty
– Dobrze pracuje się razem; jako zespół i w parach
– Spotkania się ustruktury...
TeamNorms
• Zawsze pracujemy w 2 osoby
• Regularne 15-min standups
• Świętujemy sukcesy
• Unikamy nieproduktywnych spotkań...
Podręcznik refaktoryzacji
• „Żeby dodać nowy feature, musisz…”
• „Użyj modułu mavena, aby…”
• …
• Podręcznik ma formę papi...
Obserwacje
• Action-30 żyje własnym życiem, ludzie gadają
• Jak coś jest fajne i ciekawe, to czas się znajdzie
• Manager r...
Sprint #2 Jak przebić się „wyżej”?
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ć 2...
Sprint #2 Wsparcie od biznesu?
• Jakich funkcjonalności do tej pory
odmawialiśmy?
#angularjsworkshop
Obserwacje
• Kierownicy projektów proszą o więcej
• Management zainteresowany Action-30
• Programiści z innych zespołów pr...
Zdaniem zespołu Action-30
Co dalej?
• Pokazaliśmy biznesowi, że „można”
– Że nie będzie drogie (@see problem)
– Że nie będzie długotrwałe (@see prob...
Zadanie domowe ;)
• Które wzorce wprowadzania zmian
zostały wykorzystane w trakcie
pracy, o której rozmawiamy?
JDD 2016 - Michal Bartyzel, Lukasz Korczynski - Refaktoryzacja Systemu eBankowości
Upcoming SlideShare
Loading in …5
×

JDD 2016 - Michal Bartyzel, Lukasz Korczynski - Refaktoryzacja Systemu eBankowości

41 views

Published on

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?

Published in: Technology
  • Be the first to comment

  • Be the first to like this

JDD 2016 - Michal Bartyzel, Lukasz Korczynski - Refaktoryzacja Systemu eBankowości

  1. 1. Refaktoryzacja systemu eBankowości Oddolna inicjatywa programistów w Nordea IT (obecnie Nordea Bank AB)
  2. 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. 3. Cel współpracy (ver. 1) • Skrócić czas stworzenia nowej funkcjonalności do 30 dni • Action-30
  4. 4. Potrzeby Problemy Dlaczego? Chcę uniknąć… Korzyści Po co? Chcę osiągnąć…
  5. 5. #1 Root Cause Analysis
  6. 6. #1 Root Cause Analysis • Używanie Struts 1.2 • Nadmierna uniwersalność kodu
  7. 7. #2 Analiza architektury
  8. 8. #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
  9. 9. #3 Analiza procesu dostarczania
  10. 10. #2 Analiza procesu dostarczania • Multitasking (czas przełączenia się: 30-60 min.) • Pseudoarytmetyka projektowa (%%) • Nieefektywne spotkania • Specjalizacja programistów
  11. 11. 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ń
  12. 12. 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
  13. 13. TeamNorms • Zawsze pracujemy w 2 osoby • Regularne 15-min standups • Świętujemy sukcesy • Unikamy nieproduktywnych spotkań • Podkręcamy PomodoroDay – tylko programowanie, zero spotkań • …
  14. 14. 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
  15. 15. Obserwacje • Action-30 żyje własnym życiem, ludzie gadają • Jak coś jest fajne i ciekawe, to czas się znajdzie • Manager robi dobrą robotę
  16. 16. Sprint #2 Jak przebić się „wyżej”?
  17. 17. 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…
  18. 18. Sprint #2 Wsparcie od biznesu? • Jakich funkcjonalności do tej pory odmawialiśmy? #angularjsworkshop
  19. 19. 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
  20. 20. Zdaniem zespołu Action-30
  21. 21. 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ę
  22. 22. Zadanie domowe ;) • Które wzorce wprowadzania zmian zostały wykorzystane w trakcie pracy, o której rozmawiamy?

×