Metodyka XPrincebalance between

agility and discipline

Wojciech Podgórski

Wydział Informatyki i Zarządzania

Politechnika Wrocławska

2009

Syndrom LOOP i kryzys oprogramowania

Late

Over budget

Overtime

Poor Quality

Próby rozwiązania problemu

Pierwszymi próbami rozwiązania problemu było zwiększenie

dyscypliny w wytwarzaniu oprogramowania. Zaczęły

powstawać standardy, modele dojrzałości, metodyki

zorientowane na dyscyplinę.

Rys. 1 Poziomy Capability Maturity Model for Software (CMM)

Metodyki ciężkie

Powstawanie kolejnych koncepcji poprawy procesu

wytwarzania oprogramowania doprowadziły do

utworzenia grupy metodyk nazywanych

„ciężkimi”. Metodyki ciężkie cechują się przede

wszystkim:

• Zorientowaniem na proces (process oriented)

• Ogromną rolą dokumentacji w projekcie

• Dużą dyscypliną i „silnym” zarządzaniem

• Małą podatnością na zmiany wymagań

Metodyki lekkie

W latach 90-tych, w skutek problemów w wytwarzaniu

złożonych systemów z bardzo zmiennymi wymaganiami,

powstała grupa metodyk nazywanych zwinnymi (lekkimi).

13 lutego 2001 roku, w Snowbird, 17 sygnatariuszy

podpisało tzw. Manifest Zwinnego Wytwarzania

Oprogramowania (Agile Manifesto), który deklarował

zestaw wspólnych zasad dla lekkich metodyk wytwarzania

oprogramowania.

Metodyki lekkie II

Metodyki lekkie cechują się:

• Zorientowaniem na człowieka (people oriented,

human powered, people centric)

• Dobrą i bliską współpracą z klientem

• Adaptacyjnością powstającego oprogramowania

(podatnością na zmiany wymagań)

• Wytwarzaniem działającego oprogramowania,

bardziej niż opracowywaniem dokumentacji

Słabe strony obu podejść

Metodyki ciężkie:

• Nadmierna i zbyt szczegółowa

dokumentacja

• Bardzo mała elastyczność

• Zbyt duża dyscyplina

(eliminuję inicjatywę)

• Powolne procesy

podejmowania decyzji

• Niezdolność adaptacji w

trakcie trwania projektu

Metodyki lekkie:

• Założenie „on-site customer”

• Brak dokumentacji

• Zbyt krótka perspektywa

planowania

• Ryzyko biznesowe dominuje

nad technologią

• Brak „silnego” zarządzania

• Zbyt duża wiara w człowieka…

Idea XPrince

„…every successful venture in a changing world

requires both agility and discipline…”B.Boehm, R. Turner

Balancing Agility and Discipline. A Guide for Perplexed, Addison-Wesley, Boston, 2004.

Czym jest XPrince?

ciężar

XP XPrince

RUP

PRINCE2

Rys. 2 XPrince jako połączenie różnych metodyk

Czym jest XPrince? cd.

XPrince (eXtreme PRogramming IN Controlled

Environments) jest zwinną metodyką opartą o metodyki

RUP, XP oraz PRINCE2, łączącą ich najlepsze cechy.

W grudniu 2004 założono Konsorcjum XPrince, które działa

jako stowarzyszenie i stawia za cel rozwój, pielęgnację

oraz promowanie metodyki.

Struktura zespołu w PRINCE2

Project Board

Senior

User

Senior

SupplierExecutive

Project

Assurance

Project

Manager

DevelopersDevelopers

DevelopersRys. 3 Struktura zespołu w PRINCE2,

źródło: [4]

Struktura zespołu w PRINCE2 cd.

Role w PRINCE2:

• Executive (Dyrektor) – reprezentuje inwestora, odpowiedzialny za

biznesowy sukces projektu

• Senior User (Główny użytkownik) – kieruje użytkownikami

końcowymi, skupia się na użyteczności produktu (usability)

• Senior Supplier (Główny dostawca) – reprezentuje organizację

dostawcy produktu

• Project Assurance (Audytor projektu) – sprawdza i weryfikuje

prace Menadżera Projektu, zdaje raporty Zarządowi Projektu

• Project Manager (Menadżer projektu) – taktyczny poziom

zarządzania, ogniwo pomiędzy Zarządem Projektu, a Programistami

Struktura zespołu w XP

Coach

Customer

Developers

Tester

Tracker

DevelopersDevelopers

Rys. 4 Struktura zespołu w XP, źródło: [4]

Struktura zespołu w XP cd.

Role w XP:

• Coach (Trener) – rozwiązuje problemy organizacyjne i

techniczne, motywuje zespół

• Customer (Klient) – reprezentuje inwestora

• Tracker (Nadzorca) – prowadzi dziennik, wykonuje testy

wydajności grupy

• Tester (Tester) – odpowiedzialny za testy

oprogramowania

Struktura zespołu w XPrince

Project Board

Senior

User

Senior

SupplierExecutive

Project

Assurance

Analyst

Customer

DevelopersTester

Architect

Coach

DevelopersDevelopers

Project

Manager

Coach

Rys. 5 Struktura zespołu w XPrince,

źródło: [4]

Struktura zespołu w XPrince cd.

Role pochodne w XPrince:

• Architect (Architekt) – kieruje i koordynuje wykonywanie

czynności i artefaktów technicznych, podejmuje decyzje

projektowe, z punktu widzenia programistów jest głównym

projektantem. Rola zaczerpnięta z RUP, pełni również

funkcję trenera z XP, zorientowanego na aspekty techniczne.

• Analyst (Analityk) – definiuje wymagania oraz opisuje projekt

z punktu widzenia biznesu, śledzi ryzyko związane z

funkcjonalnością i jakością produktów. Rola zaczerpnięta z

RUP, pełni również funkcję klienta z XP.

Struktura zespołu w XPrince cd.

• Project Manager (Menadżer Projektu) – jest

odpowiedzialny za środowisko pracy, rozwiązuje

problemy personalne, buduje (zgodnie z

zasadami etyki zaproponowanymi przez S.

Coveya) i motywuje zespół. Rola zaczerpnięta z

PRINCE2, pełni również funkcję trenera z XP,

zorientowanego na zarządzanie zespołem.

Cykl życia projektu w PRINCE2

Rozpoczęcie

projektu

Inicjacja

projektuEtap 1 … Etap k

Zamknięcie

projektu

RozpoczęcieElabor

acjaKonstrukcja Tranzycja

Etap 2

Rozpoczęcie

projektu

Inicjacja

projektu

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

Zamknięcie

projektu

Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince

Elabor

acja

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

(a)

(d)

(c)

(b)

Cykl życia projektu w RUP

Rozpoczęcie

projektu

Inicjacja

projektuEtap 1 … Etap k

Zamknięcie

projektu

RozpoczęcieElabor

acjaKonstrukcja Tranzycja

Etap 2

Rozpoczęcie

projektu

Inicjacja

projektu

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

Zamknięcie

projektu

Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince

Elabor

acja

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

(a)

(d)

(c)

(b)

Cykl życia projektu w XP

Rozpoczęcie

projektu

Inicjacja

projektuEtap 1 … Etap k

Zamknięcie

projektu

RozpoczęcieElabor

acjaKonstrukcja Tranzycja

Etap 2

Rozpoczęcie

projektu

Inicjacja

projektu

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

Zamknięcie

projektu

Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince

Elabor

acja

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

(a)

(d)

(c)

(b)

Cykl życia projektu w XPrince

Rozpoczęcie

projektu

Inicjacja

projektuEtap 1 … Etap k

Zamknięcie

projektu

RozpoczęcieElabor

acjaKonstrukcja Tranzycja

Etap 2

Rozpoczęcie

projektu

Inicjacja

projektu

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

Zamknięcie

projektu

Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince

Elabor

acja

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

(a)

(d)

(c)

(b)

Cykl życia projektu w XPrince

Rozpoczęcie

projektu

Inicjacja

projektuEtap 1 … Etap k

Zamknięcie

projektu

RozpoczęcieElabor

acjaKonstrukcja Tranzycja

Etap 2

Rozpoczęcie

projektu

Inicjacja

projektu

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

Zamknięcie

projektu

Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince, źródło: [4]

Elabor

acja

Wydanie 1 Wydanie k

Przyrost

1.1

Przyrost

1.2

Przyrost

k.2

Przyrost

k.1

…

(a)

(d)

(c)

(b)

Etapy projektu w XPrince

• Rozpoczęcie projektu

Wykonywane przez Menadżera Projektu, obejmuje:

– Ustanowienie zespołu Zarządu Projektu

– Stworzenie wizji systemu

– Zaplanowanie fazy Inicjacji Projektu

• Inicjacja projektu

Wykonywane przez Menadżera Projektu, Analityka i Architekta ma

na celu dostarczenie planu i stworzenie środowiska

organizacyjnego projektu. Dzieli się na:

Etapy projektu w XPrince cd.

• Inicjacja projektu cd.– Zrozumienie celu projektu

– Propozycję wstępnej architektury

– Zaplanowanie projektu i dopracowanie uzasadnienia biznesowego

– Ustalenie kanałów komunikacyjnych i środowiska zarządzania projektem

– Planu fazy elaboracji

• Elaboracja

Dotyczy głównie architektury. Architekt proponuje mechanizmy

architektoniczne oraz rozpoznaje ryzyko z nimi związane, tworzy

szkielet projektu. Analityk i Menadżer Projektu udoskonalają

wymagania i plan projektu.

Etapy projektu w XPrince cd.

• Wydanie

Etap składający się z kilku przyrostów (iteracji) kończący się fazą

tranzycji, przypomina fazę Wydania z XP. Architekt i Programiści

produkują kod i przypadki testowe. Analityk odpowiada za

wymagania i testy akceptacyjne. Po fazie tranzycji, wdraża i

przekazuje się kolejną wersję produktu użytkownikom końcowym.

Zaleca się stosowanie równych iteracji.

• Zamknięcie projektu

Etap zaczerpnięty z metodyki PRINCE2, projekt jest zamykany,

identyfikowane są dalsze akcje i następuje ocena projektu.

Inżynieria wymagań w XPrince

Metodyka XPrince, w przeciwieństwie do PRINCE2, posiada i

definiuje inżynierię wymagań jako niezbędny proces

wytwarzania oprogramowania. Wymagania dokumentowane

są w postaci przypadków użycia, wyrażane za pomocą

opisów w języku naturalnym, diagramów UML oraz notacji

BMPN.

Specyfikacja wymagań odbywa się zgodnie z standardem

IEEE 830-1998 Recommended Practice for Software

Requirements Specifications –Description.

Inżynieria wymagań w XPrince cd.

Przypadki użycia związane z funkcjonalnościami oferowanymi przez

system, są klasyfikowane ze względu na swoją istotność i

pracochłonność za pomocą metody UC Points.

Twórcy metodyki XPrince, aby wesprzeć proces inżynierii wymagań,

stworzyli narzędzie w pełni zgodne ze sposobem specyfikacji

przypadków użycia zdefiniowanym w metodyce. Nazwano je UC

Workbench.

http://www.cs.put.poznan.pl/lolek/homepage/UC_Workbench.html

Dobre praktyki w XPrince

Metodyka opiera się na zbiorze dobrych praktyk (best

practices) metodyki XP i innych metodyk zwinnych.

XPrince kładzie jednak szczególny nacisk na kilka z nich,

są to:

1. Programowanie zespołowe

2. Test-driven development (test-first coding)

3. Gra planistyczna (planning game)

4. Refaktoryzacja kodu

Programowanie zespołowe

Techniki programowania zespołowego:

• Programowanie parami XP (2 programistów, 1 komputer)

• Programowanie Side-by-Side (2 programistów, 2 komputery)

• Programowanie indywidualne (+ recenzent) (1 programista)

Autorzy metodyki przeprowadzili wiele badań na temat efektywności

programowania zespołowego. Formalnie metodyka nie definiuje, której

techniki programowania zespołowego powinno się używać. Może być

dowolna, wybrana przez programistę, jeżeli jednak ten wybierze

programowanie indywidualne, zostanie przydzielony mu recenzent.

Jednakże zaleca się używanie techniki Side-by-Side.

Wyniki badań opublikowano w [5].

Podsumowanie

Metodyka XPrince jest metodyką zwinną, powstałą na

podstawie metodyk takich jak RUP, XP i PRINCE2. Łączy w

sobie wszystkie najlepsze cechy powyższych, eliminując

lub minimalizując ich wady.

Z punktu widzenia zarządzania XPrince = PRINCE2, z

punktu widzenia programistów XPrince = XP. Metodyka

rozdziela (zmniejszając w ten sposób) ryzyko biznesowe

(CO robić) i techniczne (JAK robić) odpowiednio na role

Analityka i Architekta.

Podsumowanie

Pozostałe zalety XPrince:

• Posiada mechanizmy kontroli

• Zachowuje optymalny poziom dokumentacji

technicznej

• Ma prostą i efektywną strukturę organizacyjną

• Jest przejrzysta dla kadry zarządzającej

• Wykorzystuje zwinne praktyki programistyczne

• Metodykę cechuje synergia

Podsumowanie

dr hab. inż. Jerzy Nawrocki, prof. PP

Twórca

Bibliografia

1. Dubinsky Y., Hazzan O., Roles in Agile Software Development Teams, Department of

Computer Science, Technion, Israel

2. Kroll P., Kruchten P. Rational Unified Process od strony praktycznej, Wydawnictwa

Naukowo-Techniczne, Warszawa 2007

3. Madeyski L., Wykłady z przedmiotu Wirtualne Przedsiębiorstwo I, Politechnika

Wrocławska, Instytut Informatyki 2008 - http://madeyski.e-informatyka.pl

/download/stud/wirp/Lectures.pdf

4. Nawrocki J., Olek Ł., Jasiński M., Paliświat B., Walter B., Pietrzak B, Godek P.

Równowaga między zwinnością a dyscypliną z wykorzystaniem Xprince, Politechnika

Poznańska, Instytut Informatyki

5. Nawrocki J., Jasiński M., Olek Ł., Lange B. Pair Programming vs. Side-by-Side

Programming, Poznan University of Technology

6. Nawrocki J., Makowski M., Software Development with Xprince, prezentacja firmy DGA,

2004

7. Nawrocki J., Wykłady z przedmiotu Inżynieria Oprogramowania II, Politechnika

Poznańska, Instytu Informatyki 2004 - http://www.cs.put.poznan.pl/jnawrocki/io/

8. Pszczółkowski A., Metodyki Lekkie, http://www.si.pjwstk.edu.pl/dydaktyka/mgr

/2006-2007-winter/Agile_Methodolgies.ppt

9. Konsorcjum XPrince – http://xprince.net

Pytania?

Dziękuje bardzo…