LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA

Transkrypt

1 LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA Wykład 12 Przegląd zwinnych metodologii programowania - ciąg dalszy Jacek Dajda <dajda@agh.edu.pl> Kraków, 17 stycznia 2008

2 Plan wykładu Przegląd metodyk Podsumowanie Strona: 2

3 Adaptive Software Development

4 A daptive S oftware Development 1995, Jim HighSmith, Następna RADidal Software Development Celem metodyki jest wspieranie dużych i skomplikowanych projektów poprzez organizację pracy pozwalającą na łatwiejsze dostosowanie się do zmieniającego środowiska ASD kładzie nacisk na kulturę i filozofię pracy niż na konkretne praktyki, rozwiązania, narzędzia Podobnie jak Scrum, ASD może być traktowane jako tzw. Wrapper dla innych metodologii Chyba jedna z najmniej konkretnych zwinnych metodologii Źrodło: Strona: 4

5 Adaptacyjny model wytwarzania oprogramowania Model kaskadowy Model ewolucyjny Model adaptacyjny Źrodło: Strona: 5

6 Źrodło: Agile S oftware D evelopment Methods. R eview And Analysis Strona: 6

7 Role w zespole Brak ścisłego zarysowania struktury, pojawia się Executive Sponsor W ramach spotkań planistycznych tzw. sesji Joint Application Development (JAD) pojawiają się następujące role: Facilitator Scribe Project manager Customers Developers Strona: 7

8 Feature Driven Development

9 Feature Driven Development Pierwsze prace , projekt dla dużego banku w Singapurze, 15 miesięcy, 50-osobowy Twórcy: Jeff Luca, Peter Coad, Stephen Palmer Dziedziną FDD jest projektowanie aplikacji i organizacja projektu Może współpracować z innymi metodologiami Charakterystyka: duże zespoły, nawet do 500 programistów nadaje się do prowadzenia dużych krytycznych projektów umożliwia większy udział programistów niższego stopnia nadaje się do środowisk wymagających modelu formalnego (kaskadowego) jest to podejście łączące filozofię i lekkość XP z tradycyjnym modelem produktu Strona: 9

10 2 główne etapy procesu Specyfikacja (odkrywanie) listy funckjonalności (wyjście to diagramy UML, Color UML) Źrodło: celem jest pozyskanie jak największej ilości wymagań i zaproponowanie model niekiedy mówi się, że w przypadku FDD pozyskany zakres funckjonalności na tym etapie powinien wynosić 70-80% (dla porównania: model kaskadowy 98%-100%, XP - 60%) Strona: 10

11 2 główne etapy procesu (2) Implementacja rozpoczyna się od podziału funkcjonalności na pakiety, każdy pakiet ma być ukończony w ciągu 1 iteracji (1-3 tygodni) pakiet oznacza działajacą funkcjonalność, użyteczną dla klienta programiści dzielą sie na zespoły dla każdego pakietu (zespoły mogą ulegać zmianie, w zależności od dostępności programistów), za pakiet odpowiada szef danego zespołu każda implementacja pakietu zaczyna się od modelowania (UML) w obrębie zespołu, przygotowywane jest kilka modeli (3 osobowe zespoły), a następnie wybrany najlepszy/najlepsze potem następuje właściwy development (testy jednostkowe, code reviews) Strona: 11

12 Proces Strona: 12

13 Cykl życia projektu Strona: 13

14 Role w zespole Project Manager - odpowiedzialny za administrację i finanse, chroni zespoł Chief Architect - odpowiedzialny za całą architekturę, organizuje sesje projektowe Development Manager - prowadzi implementację, rozstrzyga konflikty Chief Programmer - doświadczony programista, bierze udział w planowaniu i projektowaniu Class Owner - członek Feature Teams, odpowiedzialny za implementację wskazanych klas Domain Expert - klient, użytkownik, sponsor. Odpowiedzialny za przekazywanie wiedzy w danej dziedzinie Domain Manager - zarządza ekspertami, rozstrzyga konflikty Release Manager - śledzi postęp, organizuje krotkie spotkania z głownymi programistami Language Guru - ekspert w danej technologii lub języka Build Engineer - odpowiedzialny za proces integracji Toolsmith - wykonuje drobne aplikacje (np. konwersja formatow) przydatne dla zespołu System Administrator - odpowiedzialny za działanie serwerow Tester - odpowiedzialny za zgodność produktu z wymaganami użytkownika Deployer - przygotowuje system do działania, np. konwertuje potrzebne dane Technical Writer - pisze dokumentacje Strona: 14

15 Praktyki FDD Domain Object Modelling - eksploracja postawionego problemu Developing by Feature - śledzenie postępu projektu na podstawie drobnych funkcjonalności Individual (Class) Code Ownership - każda klasa ma tylko jednego właściela Feature Teams - małe zespoły właścieli klas, organizowane na potrzeby chwili Inspection - stosowanie najlepszych znanych mechanizmow wykrywania błędow Regular Builds - częste i regularna integracja systemu Configuration Management - śledzenie zmian projektu Progress Reporting - raportowanie postępow projektu (od programisty do managera) Źrodło: Strona: 15

16 Parking Lot - przykład Źrodło: Strona: 16

17 Lean Software Development

18 Powstanie Taiichi Ohno ojciec systemu produkcji w Toyota Lata 50, Zrewolucjonizował proces produkcji, Lean Manufacturing, podstawa to: Budować tylko to co jest w tej chwili potrzebne (Just In Time JIT) Eliminować straty wynikające z: Koszty przechowywania Nadprodukcja Oczekiwanie Zbędny ruch Defekty Nieodpowiednie wykorzystanie umiejętności pracowników Przejrzystość środowiska pracy i dobra komunikacja źrodło: Strona: 18

19 Lean w inżynierii oprogramowania Mary and Tom Poppendieck: Lean Software Development: An Agile Toolkit Standardowa produkcja Magazyn Dodatkowe przetwarzanie Nadprodukcja Transport Oczekiwanie Ruch Defekty Inżyniera oprogramowania Częściowe wykonanie pracy Papierkowa praca Ekstra funkcjonalności Produkt nie spełnia wymagań klienta Oczekiwanie na informacje Przełączanie się pomiędzy zadaniami Defekty Strona: 19

20 7 praw i 22 narzędzi 1. ELIMINATE WASTE 1. Seeing waste 2. Value Strip Mapping 2. AMPLIFY LEARNING 3. Feedback 4. Iterations 5. Synchronization 6. Set-Based development 3. DECIDE AS LATE AS POSSIBLE 7. Options thinking 8. The last responsible moment 9. Decision making 4. DELIVER AS FAST AS POSSIBLE 10. Pull systems 11. Queuing theory 12. Cost of delay 5. EMPOWER THE TEAM 13. Self determination 14. Motivation 15. Leadership 16. Expertise 6. BUILD INTEGRITY IN 17. Perceived integrity 18. Conceptual integrity 19. Refactoring 20. Testing 7. SEE THE WHOLE 21. Measurements 22. Contracts Strona: 20

21 Dynamic System Development Method

22 DSDM - wprowadzenie Początek 1994 w Wielkiej Brytanii, na bazie RAD Właściciel: DSDM Consortium Obecnie wersja 4.2 Framework for Business Centered Development (marzec 2003) Od czerwca ogolnie dostępna w ograniczeniem sprzedaży Strona: 22

23 Podstawowe prawa Zaagnażowanie klienta Zwiększenie roli zespółu programistów, większa niezależność Częste dostarczanie nowych funkcjonalnościes. Dostarczane funkcjonalności powinny być oceniane wg ich przydatności dla obecnych celów biznesowych (lepiej skupić się na krytycznych funkcjonalnościach) Iteracyjny model produkcji oprogramowania Wszystkie zmiany można cofnąć Ogólny zakres funckjonalności ustalony przed rozpoczęciem projektu Testowanie w każdym momencie cyklu projektu (TDD) Komunikacja i koraboracja pomiędzy wszystkimi członkami projektu Strona: 23

24 Proces Strona: 24

25 Role w zespole DSDM wyrożnia 15 ról. Najbardziej znaczące to: Developers i Senior Developers - od analizy do testowania. Starsi programiści wyznaczani są na podstawie doświadczenia w danej dziedzinie lub technologi Technical coordinator - odpowiedzialny za architekturę i jakość produktu. Zarządza zmianami w projekcie Ambassador User i Adviser User - przedstawiciele użytkownikow systemu, Ambasador odpowiedzialny jest za całokształt projektu, doradcy specjalizują się w pewnych dziedzinach projektu Visionary - nadaje projektowi kierunek rozwoju, często pomysłodawca systemu Executive Sponsor - daje pieniądze i może podejmować wszystkie decyzje :-) Strona: 25

26 Wybrane techniki Timeboxing - realizacja produktu w umiejętnie rozdzielonych etapach (zasada 80% w 20%) MoSCoW MUST have - funkjonalność niezbędna dla produktu SHOULD have - funkjonalność potrzebna ale nie krytyczna COULD have - funkcjonalność potrzebna jeśli nie wpływa negatywnie na pozostałe i efektywność systemu WOULD have - funkcjonalność ktorą fajnie by było mieć kiedyś Prototyping - tworzenie prototypow fragmentow systemu we wczesnych fazach projektu Testing - DSDM zakłada wysoką jakość, testowanie ciągłe w ramach iteracji Workshop - spotkania (rożnych) przedstawicieli klienta z zespołem w celu ustalenia wymagań, funkcjonalności Strona: 26

27 Podsumowanie

28 Dużo podobieństw Role w zespole Wspólne: klient, programista, coach/faciilator/scrum master, tracker/skryba, sponsor etc. Szczególne: toolsmith, doomsayer Cykl życia projektu Iteracyjność, krótkie wydania Podejście do udziału klienta w projekcie Zaangażowanie i decydowanie o zakresie projektu Planowanie i estymacja Plan zgrubny i zmienny Oparte na optymalizowanych estymatach zespołu Automatyzacje i narzedziowe wsparcie zespołu Ciągła integracja Automatyzacja testów (jednostkowych, integracyjnych, akceptacyjnych) Timeboxing, optymalizacja kosztów Unikanie zbędnych funkcjonalności Efektywna praca w bez nadgodzin Strona: 28

29 Lęki klienta Jego wyobrażenie o problemie jest niekompletne, a to co proponuje jest złe lub niepotrzebne Każda decyzja jest wiążąca i nie da się jej odkręcić Jego przyszłość zależy od pracy innych ludzi (programistow) Płaci za dużo za zbyt mało Nie będzie znał postępow prac Projekt się przedłuży i pochłonie większy budżet Gotowy produkt nie będzie spełniał jego potrzeb Programiści przygotują szajs, ktorego nie będzie się dało używać Programiści będą go chcieli oszukać, nikt nie powie mu prawdy Strona: 29

30 Lęki programisty Nie będzie miał jasno określonych wymagań lub będą one zmienne Klient będzie wymagał zbyt dużo za zbyt małe pieniądze Postawiony problem będzie przerastał jego możliwości lub zajmie mu zbyt dużo czasu Problem zawiera ukryte miny Nikt mu nie pomoże, gdy napotka trudny problem Klient nie doceni jego wysiłku a jedynym wyznacznikiem pracy będą terminy Na nim spoczywa odpowiedzialność za wszystkie niepowodzenia projektu Strona: 30

31 Karta praw klienta Klient ma prawo do długofalowego planowania z uwzględnieniem kosztów i wariantów Klient ma prawo do cotygodniowego wyznaczania priorytetow projektu Klient ma prawo do wglądu w postępy projektu oraz dostępu do działającej wersji aplikacji, ktora zawiera nowe funkcjonalności z każdym tygodniem pracy Klient ma prawo do zmiany terminarza i sposobu redukcji zadań, a także do rezygnacji z projektu w każdej jego fazie Klient ma prawo do zmiany zdania (założeń projektu) bez konieczności płacenia wygorowanych kosztow Strona: 31

32 Karta praw programisty Programista ma prawo do przedstawiania własnych estymat zadań projektowych, a także do ich zmiany Programista ma prawo do produkowania wysokiej jakości kodu niezależnie od okoliczności Programista ma prawo do wiedzy o tym, które zadania są najważniejsze i powinny zostać zrealizowane w najbliższym czasie Programista ma prawo do otrzymywania pomocy ze strony klienta, szefów oraz członków zespołu Programista ma prawo do uczciwego raportowania postepów projektu Strona: 32

33 Metodyki tradycyjne a metodologie zwinne Zakres (wymagania) Zasoby Czas Ryzyko Tradycyjne metodyki Dobrze określony, dobrze zrozumiany, niezmienny Zatwierdzone i dostępne, budżet jest wystarczający, ludzie znają zadania, technologie i narzędzia Ściśle określony, dobrze sprecyzowane cele (milestone'y) Dobrze rozumiane, średnie znaczenie Metodologie zwinne Nie do końca określone, nieznane lub niepewne, podatne na zmiany Nie w pełni dostępne lub zaakceptowane, potrzeba proof of concept, budżget niepewny albo nie pozostawiający pola manewru, potrzeba nowych umiejętności Nie do końca określony (otwarty), cele niesprecyzowane, podatne na zmianę Nowe technologie, nieznane, duże znaczenie Strona: 33

34 Jak wyglądąć będą metodologie wytwarzania oprogramowania za 20 lat? Formalizm/złożoność metodologii Duże skomplikowane projekty Złożone zarządania projektem Trudne panowanie nad projektem? Programowanie strukturalne Szybkie prototypowanie Małe projekty Asembler, C Złoty środek? Być może metody zwinne... Czas Strona: 34

35 Bibliografia Adaptive Software Development Jim Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems Jim Highsmith, Agile Project Management: Creating Innovative Products Feature-Driven Development Stephen R. Palmer, John M. Felsing: A Practical Guide to Feature-Driven Development Lean Software Development Mary Poppendieck and Tom Poppendieck: Lean Software Development: An Agile Toolkit Mary Poppendieck and Tom Poppendieck: Implementing Lean Software Development: From Concept to Cash Dynamic System Development Method DSDM Consortium, Jennifer Stapleton: DSDM: Business Focused Development, Second Edition Strona: 35