Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Wprowadzenie do Extreme Programming Ireneusz Cygan s2038.

Podobne prezentacje


Prezentacja na temat: "Wprowadzenie do Extreme Programming Ireneusz Cygan s2038."— Zapis prezentacji:

1 Wprowadzenie do Extreme Programming Ireneusz Cygan s2038

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

3 Tradycyjny model kaskadowy Cykl rozwoju oprogramowania ma pięć podstawowych kroków : 1.Specyfikacje: Określając "co" –Zidentyfikuj potrzeby klienta –Zwrócenie uwagi na potrzebne doświadczenie (wiedze) 2.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 3.Kodowanie 4.Integracja i testowanie –Składanie elementów w całość –Testowanie próbek niezależnie, oraz po połączeniu –Poprawianie błędów 5.Utrzymanie –Debagowanie programu

4 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 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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.

13 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

14 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

15 Wnioski XP Zalety Communication –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

16 Źródła The Basic Reference: Kent Beck, extreme Programming explained: Embrace change Addison-Wesley, Other books in the Addison-Wesley XP Series. Ken Auer and Roy Miller, Extreme Programming Applied: Playing to Win, Addison- Wesley, (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, (A collection of 33 articles explaining various elements of extreme programming.) William Wake, Extreme Programming Explored, Addison-Wesley, (Wake's first- hand experiences using extreme programming on actual projects.) Laurie Williams and Robert Kessler, Pair Programing Illunimated, Addison-Wesley, (Lists both principles and best practices for pair programming.)


Pobierz ppt "Wprowadzenie do Extreme Programming Ireneusz Cygan s2038."

Podobne prezentacje


Reklamy Google