XPrince: Równoważenie zwinności i dyscypliny. Prezentacja przedstawia metodykę XPrince w kontekście innych metodyk zarówno ciężki jak i lekkich takich jak PRINCE2, RUP oraz XP. Autor opisuje budowe zespołu, cykl życia projektu oraz inżynierię wymgań zastosowaną w XPrince.
eXtensible Markup Language APIs in Java 1.6 - Simple and efficient XML parsin...
[PL] XPrince: balance between agility and discipline
1. Metodyka XPrince
balance between
agility and discipline
Wojciech Podgórski
Wydział Informatyki i Zarządzania
Politechnika Wrocławska
2009
2. Syndrom LOOP i kryzys oprogramowania
Late
Over budget
Overtime
Poor Quality
3. 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)
4. 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ń
5. 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.
6. 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
7. Słabe strony obu podejść
Metodyki ciężkie: Metodyki lekkie:
Nadmierna i zbyt szczegółowa • Założenie „on-site customer”
•
dokumentacja • Brak dokumentacji
Bardzo mała elastyczność
• • Zbyt krótka perspektywa
Zbyt duża dyscyplina planowania
•
(eliminuję inicjatywę) • Ryzyko biznesowe dominuje
Powolne procesy nad technologią
•
podejmowania decyzji • Brak „silnego” zarządzania
Niezdolność adaptacji w
• • Zbyt duża wiara w człowieka…
trakcie trwania projektu
8. 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.
9. Czym jest XPrince?
RUP
XP XPrince
PRINCE2
ciężar
Rys. 2 XPrince jako połączenie różnych metodyk
10. 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.
11. Struktura zespołu w PRINCE2
Project Board
Senior Senior
Executive
User Supplier
Project
Assurance
Project
Manager
Developers
Developers
Developers
Rys. 3 Struktura zespołu w PRINCE2,
źródło: [4]
12. 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
13. Struktura zespołu w XP
Coach
Customer Tracker
Tester
Developers
Developers
Developers
Rys. 4 Struktura zespołu w XP, źródło: [4]
14. 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
15. Struktura zespołu w XPrince
Rys. 5 Struktura zespołu w XPrince,
Project Board źródło: [4]
Senior Senior
Executive
User Supplier
Project
Assurance
Project
Manager
Coach
Analyst Architect
Customer Coach
Developers
Tester Developers
Developers
16. 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.
17. 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.
18. Cykl życia projektu w PRINCE2
Rozpoczęcie Inicjacja Zamknięcie
(a) Etap 1 Etap 2 … Etap k
projektu projektu projektu
Elabor
Rozpoczęcie Konstrukcja Tranzycja
(b) acja
Wydanie 1 Wydanie k
…
(c) Przyrost Przyrost Przyrost Przyrost
1.1 1.2 k.1 k.2
Wydanie 1 Wydanie k
Rozpoczęcie Inicjacja Elabor Zamknięcie
…
(d) Przyrost Przyrost Przyrost Przyrost
projektu projektu acja projektu
1.1 1.2 k.1 k.2
Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince
19. Cykl życia projektu w RUP
Rozpoczęcie Inicjacja Zamknięcie
(a) Etap 1 Etap 2 … Etap k
projektu projektu projektu
Elabor
Rozpoczęcie Konstrukcja Tranzycja
(b) acja
Wydanie 1 Wydanie k
…
(c) Przyrost Przyrost Przyrost Przyrost
1.1 1.2 k.1 k.2
Wydanie 1 Wydanie k
Rozpoczęcie Inicjacja Elabor Zamknięcie
…
(d) Przyrost Przyrost Przyrost Przyrost
projektu projektu acja projektu
1.1 1.2 k.1 k.2
Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince
20. Cykl życia projektu w XP
Rozpoczęcie Inicjacja Zamknięcie
(a) Etap 1 Etap 2 … Etap k
projektu projektu projektu
Elabor
Rozpoczęcie Konstrukcja Tranzycja
(b) acja
Wydanie 1 Wydanie k
…
(c) Przyrost Przyrost Przyrost Przyrost
1.1 1.2 k.1 k.2
Wydanie 1 Wydanie k
Rozpoczęcie Inicjacja Elabor Zamknięcie
…
(d) Przyrost Przyrost Przyrost Przyrost
projektu projektu acja projektu
1.1 1.2 k.1 k.2
Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince
21. Cykl życia projektu w XPrince
Rozpoczęcie Inicjacja Zamknięcie
(a) Etap 1 Etap 2 … Etap k
projektu projektu projektu
Elabor
Rozpoczęcie Konstrukcja Tranzycja
(b) acja
Wydanie 1 Wydanie k
…
(c) Przyrost Przyrost Przyrost Przyrost
1.1 1.2 k.1 k.2
Wydanie 1 Wydanie k
Rozpoczęcie Inicjacja Elabor Zamknięcie
…
(d) Przyrost Przyrost Przyrost Przyrost
projektu projektu acja projektu
1.1 1.2 k.1 k.2
Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince
22. Cykl życia projektu w XPrince
Rozpoczęcie Inicjacja Zamknięcie
(a) Etap 1 Etap 2 … Etap k
projektu projektu projektu
Elabor
Rozpoczęcie Konstrukcja Tranzycja
(b) acja
Wydanie 1 Wydanie k
…
(c) Przyrost Przyrost Przyrost Przyrost
1.1 1.2 k.1 k.2
Wydanie 1 Wydanie k
Rozpoczęcie Inicjacja Elabor Zamknięcie
…
(d) Przyrost Przyrost Przyrost Przyrost
projektu projektu acja projektu
1.1 1.2 k.1 k.2
Rys. 6 Cykl życia projektu w (a) PRINCE2, (b) RUP, (c) XP, (d) XPrince, źródło: [4]
23. 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:
24. 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.
25. 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.
26. 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.
27. 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
28. 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
29. 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].
30. 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.
31. 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
32. Podsumowanie
Twórca
dr hab. inż. Jerzy Nawrocki, prof. PP
33. 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