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.

Jak sprzedać refaktoryzację? Nordea Bank AB Case

198 views

Published on

Studium przypadku prac nad refaktoryzacją systemu e-bankowości w Nordea Bank AB w Gdyni.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Jak sprzedać refaktoryzację? Nordea Bank AB Case

  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?

×