Sebastian Łaciak Language: Polish Jest tysiące powodów dla których nasze projekty mogłyby być lepsze a świat dzięki temu piękniejszy. Niestety często na drodze stoi manager i brak czasu na pielęgnowanie kodu. Podczas sesji postaram się przekonać Was, że nie stoimy na pozycji przegranej oraz podam wiele argumentów, których będziecie mogli użyć po powrocie do biura. Poruszony zostanie również temat roadmapy.

1. Jak przekonać menadżera,
że czas na refaktoring
jest potrzebny?
Sebastian Łaciak

2. Dług techniczny
• Gdzie możemy go spotkać?
• Ktokolwiek widział, ktokolwiek wie?
• Czym jest?
 Nietestowalny / nietestowany kod
 Architektura lub jej brak
 Duplikacja kodu
 itd…

3. Jak walczyć z długiem?
• Dlaczego nie o refaktoringu itp.?
• Jak przekonać menadżera, że jest nam
potrzebny dodatkowy czas?

4. Priorytety
• Czysty kod
• Nowe technologie
• Rozwój
• Przyjemność z
pracy
• Poprawna
architektura
• Szybki
development
• Kolejne
funkcjonalności
• Redukcja kosztów
• Wyższy zysk
Programista Menadżer

5. One Team One Dream

6. Zaufanie
• Transparentność
• Widoczność
• Małe kroczki

7. Jakiego języka używać?
• Liczby
• Wykresy
• Metryki
• Kolory
• Cele
• Priorytety

8. Jak bardzo źle jest teraz?
• Ile mamy błędów zgłoszonych?
• Jak często klienci zgłaszają kolejne
problemy?
• Jak szybko sami jesteśmy w stanie znaleźć
luki?

9. Jak bardzo źle jest teraz?
• Ilu problemów jesteśmy świadomi, ale nie
chcemy / nie mamy czasu żeby je
poprawiać?
• Ile błędów wprowadziły ostatnie poprawki?
• Ile błędów wprowadziły próby rozszerzenia
funkcjonalności?

10. Analiza zysków i strat
• Ile kosztuje nas poprawianie błędów?
• Ile kosztuje rozszerzanie funkcjonalności?
• Ile będzie kosztować przepisanie /
refaktoring?
• Ile błędów średnio wprowadzamy i koszt
ich rozwiązania?
• Ile będzie kosztowało rozszerzanie?

11. Sonar

12. Plan
• Gdzie chcemy być za 3 – 5 lat?
• Jak chcemy tam dojść?
• Jaki jest szacunkowy koszt?
• Od czego zacząć (plan na najbliższy rok)?

13. Testowalność
• Jakie mamy pokrycie kodu?
• Czy testy jednostkowe są możliwe?
• Czy testerzy są świadomi specjalnych
przypadków?
• Jakie funkcjonalności są / nie są testowane
w regresjach?

14. Przypadki specjalne
• 5% przypadków zabiera 95% czasu
• Ilu klientów ich używa?
• Czy można zastąpić je standardowym
użyciem?
• Ile kosztuje ich utrzymanie?

15. Upraszczanie i standaryzacja
• Konwencje kodowania
• Formatery
• Technologie
• Architektura
• Narzędzia

16. Nowe możliwości
• Jakie funkcjonalności aktualnie są
niemożliwe / zbyt drogie?
• Co dostarczymy „za darmo”?

17. Idealne miejsce pracy
• Innowacyjność
• Rozwój
• Realny wpływ na to co się robi
• Satysfakcja
• Łatwiejsze pozyskiwanie i wdrażanie
nowych pracowników

18. Podsumowanie
„If you can't change your
organization,
change your organization!”
Martn C. Fowler