An Introduction to Extreme Programming

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

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

– 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.)

Document Outline