Wprowadzenie do Extreme Programming Ireneusz Cygan s2038

Cel spotkania: Zalety Extreme Programming Motywacje i perspektywy Zakomunikuj pomysły, ale nie głoś ewangelii

Tradycyjny model kaskadowy Cykl rozwoju oprogramowania ma pięć podstawowych kroków: Specyfikacje: Określając "co" Zidentyfikuj potrzeby klienta Zwrócenie uwagi na potrzebne doświadczenie (wiedze) Projektowanie: Decydując "jak" Główny paradygmat: Decyzje o strukturze danych i algorytmach paradygmat OO: Decyduje się na temat klas, obiektów, metod, przypadków użycia Kodowanie Integracja i testowanie Składanie elementów w całość Testowanie próbek niezależnie, oraz po połączeniu Poprawianie błędów Utrzymanie Debagowanie programu

Model tradycyjny, cd. Przykład: (firma Labs Bell) Około 300 ludzi pracujących nad pięcio-komponentowym systemem, do tego system wspierania i system operacyjny. Pierwszy komponent: około 500 000 linii kodu Rozdzielne grupy ludzi dla każdego z cykli wytwarzania: Specyfikacja: 20%    Projektowanie: 30% Kodowanie: 30% Integracja/Testowanie:20% Model kaskadowy Praca w jednej fazie w znacznym stopniu zależała od postępów w drugiej fazie Koszty poprawiania błędów wzrastają dramatycznie z jednej fazy wytwarzania do drugiej Projektowanie bazowało na kompletnej informacji Interfejsy kodowania, protokoły bazowały na pełnym zrozumieniu algorytmów, struktur danych, przypadków użycia Cały cykl zajmuje około 1-2 lat Ten konkretny zajął 3 lata

Problemy „Model kaskadowy przyjmuję, że świat jest skonstruowany w sposób idealny” W prawdziwym świecie: Specyfikacje nigdy nie są kompletne Klient zna aktualną sytuację, ale bardzo trudno mu jest przewidzieć co się wydarzy w przyszłości Klient robi (niedbałe) założenia Różni klienci (nawet w tej samej organizacji) mogą mieć różne wizje Przykłady: North American Anti-ballistic Missile Defense System Podwozie F-16 Pierwsze wypuszczenie zajmuje 1-2 lata Specyfikacje zmieniają się gdy klient identyfikuje nowe potrzeby Prawo, zmiany w środowisku biznesu Modyfikacje kodowania muszą nadążyć za zmienionymi specyfikacjami, projektowanie

Więcej problemów Inne zagrożenia Klient nie widzi żadnego produktu aż do wypuszczenia Wymagania projektu nie spełniają wymagań chwili obecnej Niepotrzebne możliwości projektu Zapomniane możliwości teraz okazują się być bardzo pożądanymi W fazie projektowania można przewidzieć co będzie klientowi najbardziej potrzebne Klient to nie wytwórca Klient aktywnie nie zajął się kosztem opóźnień Jeśli (kiedy?) braknie czasu, klient nie bierze udziału w ustalaniu priorytetów Jeśli (kiedy?) braknie pieniędzy (albo koszt dramatycznie rośnie), projekt może zostać odwołany przed pierwszy wypuszczeniem Wymiana sztabu (najlepiej jeśli ludzie mogą odejść po 2 latach od rozpoczęcia projektu) Późne Testowanie Drogie debugowanie programu

The Extreme Programming (XP) poglądy Zmiany w procesie wytwarzania Zmiana będzie wymagana Rozwój oprogramowania będzie musiał dostosować się do tych zmian Model kaskadowy i jego niska wydajność Nie pożądany długi okres wytwarzania Potrzeba włączenia klienta we wczesnej fazie projektu

XP Zasady Szybka reakcja Reakcja, interpretacja, nauka, szybka implementacja Odnosi się do planowania, rozwoju systemu i wszystkich innych faz. Prostota Założenie, że wszystko będzie na czas Czas zaoszczędzony na poszukiwaniach uproszczeń może być wykorzystany przy bardziej złożonych projektach Zmiany przyrostowe Duże zmiany, robisz wszystko jednocześnie, duży poziom ryzyka Małe zmiany skłaniają do pracy nad nimi Zmiany powiązań Nastąpią czy chcesz tego czy nie Jakość pracy Każdy chce lepszej pracy

Główne artefakty planowania w XP to historie użytkownika (ang. User Stories) planowanie kolejnych małych wydań projekt jest podzielony na iteracje, planowanie kolejnej zaczyna się po zakończeniu ostatniej rotacja ludzi pomiędzy obowiązkami krótkie zebrania na początku każdego dnia pracy dostrajanie XP

Główne artefakty projektowania to prostota wybranie metafory dla systemu używanie kart CRC podczas projektowania używanie prototypów dla konkretnych problemów implementowane jest tylko to co jest niezbędne wszechobecna refaktoryzacja

Główne artefakty programowania to klient jest zawsze dostępny programowanie odbywa się z uwzględnieniem ustalonych standardów najpierw pisze się testy a później implementację cały kod produkcyjny jest wytwarzany w parach

Główne artefakty programowania tylko jedna para w danym momencie integruje swoje zmiany, integracja kodu odbywa się jak najczęściej współwłasność kodu procesowi optymalizacji kodu przydzielany jest najniższy priorytet brak nadgodzin Krótki okres pomiędzy kolejnymi wydaniami.

Główne artefakty testowania to do każdej istotnej części kodu istnieją testy jednostkowe (ang. Unit Tests) wszystkie testy muszą zakończyć się sukcesem zanim kod może zostać zintegrowany w momencie znalezienia błędu tworzony jest nowy test wykrywający znaleziony błąd testy akceptacji są wykonywane często i ich wynik jest publikowany

Wnioski XP Wady Ciągłe zaangażowanie klienta zbyt częste nadgodziny powodują wypalenie się pracowników współwłasność kodu oraz stosowanie najprostszych możliwych rozwiązań, wraz rygorystycznym ich przestrzeganiem podczas przeglądów kodu okazało się problemem podczas wprowadzania nowych programistów do zespołu problemy związane z programowaniem w parach

Wnioski XP Zalety Communication Simplicity Feedback Courage Need constant interactions of customer, developers Pairs help Most problems caused by miscommunication (or lack of communication) Simplicity "What is the simplest thing that could possibly work?" Do not anticipate future requirements (they may not happen) Simplify (refactor) whenever possible Feedback Testing drives development (so you know when something must change and when it is fixed) Customers write "stories", based on current system Consider every release a prototype for the next Courage Move ahead quickly Throw away code that seems hopeless Pause as needed to refactor

Źródła The Basic Reference: Kent Beck, extreme Programming explained: Embrace change Addison-Wesley, 2000. Other books in the Addison-Wesley XP Series. Ken Auer and Roy Miller, Extreme Programming Applied: Playing to Win, Addison-Wesley, 2002. (A practical guide to getting started using extreme programming.) Kent Beck and Martin Fowler, Planning Extreme Programming, (Estimation is a vital part of the extreme programming approach, and this discusses this and related strategic matters.) Giancarlo Succi and Michele Marchesi, Extreme Programming Examined, Addison-Wesley, 2001. (A collection of 33 articles explaining various elements of extreme programming.) William Wake, Extreme Programming Explored, Addison-Wesley, 2001. (Wake's first-hand experiences using extreme programming on actual projects.) Laurie Williams and Robert Kessler, Pair Programing Illunimated, Addison-Wesley, 2003. (Lists both principles and best practices for pair programming.)