XPrince

Równowaga między zwinnością a dyscypliną w projektach informatycznych

Metodyka XPrince (eXtreme PRogramming IN Controlled Environments) bazuje na takich znanych metodykach jak PRINCE2, RUP czy XP, łącząc w sobie najlepsze ich cechy. Siła metodyki XPrince

Inspiracją do opracowania metodyki XPrince były wyniki badań prowadzonych w Instytucie Informatyki Politechniki Poznańskiej, mających na celu usprawnienie procesów wytwarzania oprogramowania oraz konfrontacja istniejących metodyk z potrzebami rynku. 

Autorem metodyki jest prof. Jerzy Nawrocki, który do procesu współtworzenia i rozwijania metodyki włączył poznańskie firmy informatyczne.

W grudniu 2004 roku, zapadła decyzja o założeniu Konsorcjum XPrince, które działa jako stowarzyszenie i stawia sobie za cel rozwój, pielęgnację oraz promowanie metodyki XPrince. Prece stowarzyszenia wspierają obecnie 4 poznańskie firmy, w których wdrażana jest metodyka XPrince.

Na czym polega wyjatkowość XPrince?

Medotyka XPrince sprawdza się w przedsięwzięciach informatycznych, ponieważ jest:

• Jest zwinna
  XPrince przyjmuje podstawowe założenie metodyki XP - jest nastawiona na jak najszybsze stworzenie działającego produktu, etapy są w niej krótkie, a zarządzanie zmianami praktykowane przez cały czas trwania projektu. Dzięki temu klient otrzymuje szybko kolejne wersje produktu i ma stałą kontrolę jego zakresu.

• Posiada mechanizmy kontroli
  XPrince kontroluje projekt na różnych poziomach. Kontrolowane są zmiany, kontrolowane jest ryzyko, kontrolowana jest jakość produktu a także jakość pracy kierownika projektu, w tym sensie nawiązuje do metodyki PRINCE2.

 

• Zachowuje optymalny poziom dokumentacji technicznej
  XPrince zakłada dokumentowanie wymagań w postaci przypadków użycia systemu oraz wykorzystanie UML. Są to metody sprawdzone i popularne, dzięki czemu skraca się czas wdrożenia metodyki.

 

• Ma prostą i efektywną strukturę organizacyjną
  XPrince wprowadza przejrzysty podział ról w procesie. Hierarchia w jest zminimalizowana, a odpowiedzialność za elementy procesu praktycznie podzielona. Wprowadzone są np. role głównego analityka, odpowiadającego za biznesowe czynniki ryzyka i architekta, odpowiadającego za ryzyko technologiczne (obie role zaczerpnięto z metodyki RUP). Ich zwierzchnikiem jest kierownik projektu, który zarządza ryzykiem całego projektu, kierując się sygnałami od obu specjalistów.

 

• Jest przejrzysta dla kadry zarządzającej
  Struktura organizacyjna XPrince ułatwia spojrzenie na projekt z poziomu wyższej kadry zarządzającej. Zarząd przedsięwzięcia, jako ciało decyzyjne, jest odseparowany od codziennej pracy w projekcie i kontroluje go na podstawie informacji od kierownika projektu. Dodatkowo, rzetelność informacji przekazywanych przed kierownika projektu jest weryfikowana przez kontrolę projektu (podobnie, jak w metodyce PRINCE2) .

 

• Wykorzystuje zwinne praktyki programistyczne
  XPrince zaczerpnęło z XP zestaw dobrych praktyk programistycznych. Zarządzanie wersjami, ciągła integracja, testy jednostkowe, testy akceptacyjne, implementacja kierowana testami (ang. TDD - Test Driven Development) to praktyki zapewniające wysoką jakość produktu. Z XP przejęte zostało także opracowanie rozwiązań próbnych (ang. spike solution), które w XPrince stosuje się na początku projektu, w fazie opracowania architektury.

Wydarzenia

Najważniejsze wydarzenia:

2007.10.10: Konferencje: CEE-SET 2007 oraz IX KKIO
2007.09.17: Wybór nowych władz Konsorcjum
2006.10.01: Rejestracja wspólnotowego znaku towarowego "XPrince"
2006.08.01: Nowa strona i logo XPrince
2006.06.12: Konferencja: Zarządzanie procesami pracy i obiegiem dokumentów w firmie
2005.09.22: Konferencja Software Project Management GigaCon
2005.07.04: Seminarium pt. Metodyka XPrince
2005.03.31: II Walne Zebranie Członków - zmiany w statucie
2005.01.24: I Walne Zebranie Członków - wybór władz Konsorcjum
2004.12.23: Uruchomienie strony www.xprince.net
2004.12.16: Zebranie założycielskie Konsorcjum XPrince
 

WIKIPEDIA

XPrince

[edytuj]

Z Wikipedii

Skocz do: nawigacji, szukaj

XPrince to nazwa elastycznej metodyki wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną. Nazywa się XPrince (eXtreme PRogramming IN Controlled Environments) i bazuje na trzech innych metodykach: XP, PRINCE2 oraz Rational Unified Process.

Równowaga między adaptacyjnością a dyscypliną w projektach informatycznych [edytuj]

Nie ma jedynego złotego rozwiązania metodyki tworzenia oprogramowania i każde z podejść, zarówno adaptacyjne jak i zorientowane na dyscyplinę, mają swoje zalety i wady. Metodyki zorientowane na dyscyplinę są zazwyczaj krytykowane ze względu na nadmierną pracę papierkową, małą elastyczność, powolne procesy podejmowania decyzji i niezdolność dostosowania się do zmian w trakcie trwania projektu.

Słabe strony Programowania Ekstremalnego to wymóg, aby klient pracował razem z zespołem (w wielu projektach klienci są zbyt zajęci i nie mogą spełnić tego wymagania), brak dokumentacji papierowej (komunikacja ustna jest bardzo efektywna, lecz w przypadku bardzo złożonego systemu mogą być trudności z wprowadzaniem zmian po upływie pewnego czasu) oraz czasami zbyt krótka perspektywa planowania. Celem, który przyświecał stworzeniu metodyki XPrince, było rozwiązanie problemów związanych ze słabościami XP oraz zachowanie adaptacyjności. W związku z tym metodyka ta integruje metodykę zarządzania projektem (PRINCE2) z metodyką wytwarzania oprogramowania (XP).

Konsorcjum XPrince [edytuj]

Koncepcja metodyki XPrince została zaproponowana przez Jerzego Nawrockiego z Instytutu Informatyki Politechniki Poznańskiej i jest rozwijana przez zespół Inżynierii Oprogramowania. Pod koniec 2004 roku do tego projektu akademickiego przyłączyła się grupa firm wytwarzających oprogramowanie i zostało powołane Konsorcjum XPrince, które przejęło patronat nad rozwijaniem i promowaniem metodyki XPrince. Aktualnie metodyka XPrince jest wdrażana w przedsiębiorstwach będących członkami konsorcjum.

PRINCE2

[edytuj]

Z Wikipedii

Skocz do: nawigacji, szukaj

Spis treści [ukryj] 1 Syntetyczna charakterystyka 2 Historia 3 Procesy 3.1 Przygotowanie założeń projektu/Uruchamianie projektu (Starting up a project) 3.2 Zarządzanie strategiczne projektem (Directing a project) 3.3 Planowanie (Planning) 3.4 Inicjowanie projektu (Initiating a project) 3.5 Sterowanie etapem (Controlling a stage) 3.6 Zarządzanie wytwarzaniem produktów (Managing product delivery) 3.7 Zarządzanie zakresem etapu (Managing stage boundaries) 3.8 Zamykanie projektu (Closing a project) 4 Komponenty 4.1 Uzasadnienie biznesowe 4.2 Organizacja 4.3 Plany 4.4 Elementy sterowania 4.5 Zarządzanie ryzykiem 4.6 Jakość w środowisku projektowym 4.7 Zarządzanie konfiguracją 4.8 Sterowanie zmianami 5 Techniki 5.1 Planowanie oparte na produktach 5.2 Sterowanie zmianami 5.3 Przeglądy jakości 6 Dokumentacja PRINCE2 7 Mocne i słabe strony PRINCE2 8 Szkolenia PRINCE2 9 Zobacz też 10 Bibliografia 11 Linki zewnętrzne 11.1 Materiały po polsku 11.2 Materiały po angielsku 12 Przypisy

PRINCE2 - to metodyka zarządzania projektami oparta na pozytywnych i negatywnych doświadczeniach uzyskanych przez kierowników projektów z krajów anglosaskich. Zastosować ją można do zarządzania i sterowania projektami wszelkiego rodzaju i wszelkiej wielkości.

Nazwa jest skrótem ang. słów: Projects In a Controlled Environment tzn. Projekty w sterowanym środowisku.

Syntetyczna charakterystyka [edytuj]

Co to jest projekt według PRINCE2

Organizacja powołana na pewien czas w celu wytworzenia - w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów - niepowtarzalnych, a wcześniej określonych wyników czy rezultatu.

Czy też

Warunki zarządzania stworzone w celu dostarczenia jednego lub wielu produktów natury biznesowej zgodnie z określonym uzasadnieniem biznesowym.

Właściwości projektu realizowanego według PRINCE2

1. Określony i skończony czas trwania

2. Zdefiniowane i mierzalne produkty biznesowe (wyniki projektu)

3. System działań niezbędnych do budowy produktów biznesowych

4. Określona pula zasobów

5. Struktura organizacyjna z zakresem obowiązków każdej z ról niezbędnej do zarządzania projektem

Rodzaje zasobów w PRINCE2

1. Pieniądze

2. Ludzie

3. Sprzęt (wyposażenie)

Komponenty, procesy a techniki PRINCE2

Stosując różne techniki, każdy proces wykorzystuje i/lub wytwarza komponenty.

Historia [edytuj]

U źródeł metodyki PRINCE2 leży PROMPT (Project Resource Organisation Management Planning Technique) metodyka prowadzenia projektów informatycznych opracowana przez firmę prywatną Simpact Systems Limited w połowie lat 70. Na zamówienie rządowe wzbogacono metodykę o kwestię zarządzania jakością. Część standardu pod nazwą PROMPT II została w 1983 r. wprowadzona w jednostkach administracji rządowej Wielkiej Brytanii. Po wykupieniu praw do metodyki PROMPT przez firmę LBMS, w 1989 r. brytyjska agenda rządowa Central Computer and Telecommunications Agency (CCTA) opublikowało standard pod nową nazwą - PRINCE (Projects in Controlled Environments) i wskazała jako zbiór najlepszych praktyk zarządzania projektami informatycznymi. Wkrótce jednak metodyka zaczęła być stosowana także poza obszarem IT.

PRINCE2 został opublikowany po raz pierwszy w 1996 r. jako ogólna metoda zarządzania projektami niezależna od dziedziny biznesowej zastosowania. PRINCE2 szybko zdobywał popularność i stał się standardem de facto w Wielkiej Brytanii. Zyskuje też coraz szersze uznanie na całym świecie stanowiąc główną alternatywę (nie wykluczającą) dla metodyki PMBOK instytutu PMI. Ostatnie zmiany zostały opublikowane w 2005 przez Office for Government Commerce (OGC) - następcę CCTA. W 2009 roku została opublikowana nowa wersja^[1].

Programowanie ekstremalne (ang. eXtreme Programming, XP) - to paradygmat i metodyka programowania mające na celu wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces.

Podstawą ekstremalnego programowania jest synergia wynikająca ze stosowania rozmaitych praktyk, które same w sobie mają wiele zalet, lecz mogą być trudne w zastosowaniu. Łączne użycie tych praktyk ma zapewniać wyeliminowanie niedogodności każdej z nich.

Podstawowe założenia zostały sformułowane przez Kenta Becka. Stroną, która służyła do wymiany poglądów na temat programowania ekstremalnego było pierwsze na świecie Wiki Portland Pattern Repository założone przez Becka i Cunninghama.

Spis treści [ukryj] 1 Zalecenia 1.1 Iteracyjność 1.2 Nie projektować z góry 1.3 Testy podzespołów 1.4 Ciągłe modyfikacje architektury 1.5 Programowanie parami 1.6 Stały kontakt z klientem 2 Kwestie kontrowersyjne 3 Zobacz też 4 Linki zewnętrzne

Zalecenia [edytuj]

Iteracyjność [edytuj]

Program tworzy się w iteracjach (krótkie, przyrostowe kroki programistyczne) - i co ważniejsze - planuje tylko następną iterację. Efektem każdej iteracji (kilka tygodni) powinna być wersja programu spełniającą założenia dla danej iteracji. Następnie planuje się co zrobić dalej.

Odpowiada to zasadzie Open Source: "release early, release often" (wczesne i częste wydania).

Nie projektować z góry [edytuj]

Nie można z góry przewidzieć, jaka architektura będzie najlepsza dla danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania programu.

Testy podzespołów [edytuj]

Testy podzespołów pisze się zanim w ogóle zacznie się pisać kod - najlepiej na początku iteracji. Potem pisze się kod, który potrafi je wszystkie przejść. Takie testy dają zapewnienie (o ile testy są dobrze napisane), że to, co ważne, zostanie zaprojektowane, na to zaś, co nie jest ważne, programiści nie będą tracić czasu.

Ciągłe modyfikacje architektury [edytuj]

Architektura nie jest czymś, czego nie wolno ruszać. Jeśli modyfikacja architektury ułatwi przejście danej iteracji i nie zepsuje wyników testów uzyskanych na poprzednich, należy ją wykonać. Pod tę zasadę podlega także usuwanie wszystkich znanych błędów przed rozszerzeniem funkcjonalności.

Programowanie parami [edytuj]

Programiści piszą w parach: jedna osoba pracuje przy klawiaturze i jest głównym koderem, druga obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające. Programiści programujący w parze zamieniają się rolami co kilkadziesiąt minut. Ta technika umożliwia wyłapanie wielu błędów oraz wzajemną naukę. Kod, którym zajmuje się tylko jedna osoba, ma tendencje do stawania się całkowicie niezrozumiałym dla kogokolwiek innego niż autor, więc dodatkowy programista zwiększa jakość kodu.

Nie jest jasne, czy sumarycznie łączna wydajność pracy przy takiej metodzie jest wyższa, taka sama, czy niższa niż w tradycyjnym programowaniu indywidualnym.

Stały kontakt z klientem [edytuj]

Specyfikacje są prawie zawsze wieloznaczne, dziurawe i sprzeczne ze sobą. Tak więc należy mieć stały kontakt z tym, dla kogo to oprogramowanie jest tworzone (klient zamawiający program, czy też użytkownicy końcowi). Jeśli kontakt jest dobry, można się nawet obyć bez specyfikacji.

Kwestie kontrowersyjne [edytuj]

• Brak dokładnej specyfikacji.

• Konieczna stała dostępność przedstawiciela klienta.

• Wspólna "własność" kodu - każdy może zmieniać dowolny fragment systemu.

---