[PL] XPrince: balance between agility and discipline

2,820 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,820
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
52
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

[PL] XPrince: balance between agility and discipline

  1. 1. Metodyka XPrince balance between agility and discipline Wojciech Podgórski Wydział Informatyki i Zarządzania Politechnika Wrocławska 2009
  2. 2. Syndrom LOOP i kryzys oprogramowania Late Over budget Overtime Poor Quality
  3. 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. 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. 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. 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. 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. 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. 9. Czym jest XPrince? RUP XP XPrince PRINCE2 ciężar Rys. 2 XPrince jako połączenie różnych metodyk
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32. Podsumowanie Twórca dr hab. inż. Jerzy Nawrocki, prof. PP
  33. 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
  34. 34. Pytania?
  35. 35. Dziękuje bardzo…

×