LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA

Transkrypt

1 LEKKIE METODOLOGIE WYTWARZANIA OPROGRAMOWANIA Wykład 11 Przegląd zwinnych metodologii programowania Jacek Dajda Kraków, 10 stycznia 2008

2 Plan wykładu Przypomnienie manifestu. informatycznego Problem 3 zmiennych projektu Scrum i Crystal Strona: 2

3 Przypomnienie manifestu. Problem 3 zmiennych projektu informatycznego

4 Narodziny metodologii zwinnych Snowbird, Utah, Luty ludzi z branży: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas Agile Alliance, koniec Źrodło: Strona: 4

5 Manifest metodologii zwinnych Odnajdujemy lepsze sposoby wytwarzania oprogramowania poprzez jego tworzenie i pomaganie innym w tej działalności. W ramach tej pracy nauczyliśmy się bardziej cenić: Osoby i komunikację od procesow i narzędzi Działające oprogramowanie od kompleksowej dokumentacji Współpracę klienta od negocjacji kontraktow Reagowanie na zmianę od podążania za planem Rzeczy po prawej mają dla nas wartość, ale te po lewej cenimy znacznie bardziej. Strona: 5

6 Kalendarium metodologii zwinnych Dynamic Systems Development Method (1990) Scrum (1995) Adaptive Software Development (1995) Feature Driven Development (1995) extreme Programming (1996) Crystal methodologies (1996) Lean Software Development (1996) Daty należy traktować z pewnym przybliżeniem Strona: 6

7 Problem 4 zmiennych projektu informatycznego 4 zmienne projektu informatycznego: Zakres, Jakość, Czas, Zasoby Powiązane z sobą na zasadzie naczyń połączonych Scope Quality Increase Increase Time Decrease Resources Historia o królewskim obiedzie: dinner.htm Strona: 7

8 Koncepcja rozwiązania problemu proponowana przez metodologie zwinne (The Iron Triangle) quality Balanced quality, savings and fast delivery Quality and fast delivery at all costs Low quality, balanced costs and delivery speed cost-savings fast delivery Strona: 8

9 Schemat cyklu projektu w metodologii zwinnej Start Release Planning Released product, full user feedback, updated requirements Stop Next release? Tasks grouped into iterations Release, up to 6 months Next iteration? Iteration Planning Insights and measurements from previous iterations Iteration, 1 to 4 weeks Reflective Workshops Strona: 9

10 Scrum

11 Inspiracja 1986, Ikujiro Nonaka, Hirotaka Takeuchi, The New New Product Development Game 1995, Ikujiro Nonaka, Hirotaka Takeuchi The Knowledge-Creating Company Doświadczenia japońskich firm w zarządzaniu dużymi przedsiębiorstwami (m.in. Honda, Canon, NEC and Sharp) Wprowadzone pojęcie: Knowledge-creating company celem firmy jest ciągła innowacja (ang. continuous innovation) Podział wiedzy na: jawną i niejawną 4 możliwe schematy przekazywania wiedzy: Jawna jawna Niejawna niejawna Jawna niejawna Niejawna jawna Interesujące są 2 ostatnie: spirala wiedzy Źrodło: Obserwacja menadżerów: sukces odnoszą Ci, którzy potrafią łączyć punkty widzenia kierownictwa i pracowników (model middle-up-down) Strona: 11

12 Powstanie Scrum 1993, Jeff Sutherland, John Scumniotales, and Jeff McKenna, Easel Corporation 1995, Ken Schwaber, Metodologia zwinna dla zarządzania projektem (niekoniecznie informatycznym) Metoda empiryczna: wynik wieloletnich doświadczeń dużych japońskich firm (m.in. Toyota, Honda) Zajmuje się organizowaniem pracy w organizacji, a nie sposobem tworzeniem oprogramowania Niezależna od oprogramowania metodologii tworzenia Pozwala na skalowanie znanych metod, stanowi zewnętrzną warstwę (wrapper) Proces tworzenia oprogramowania zależy od wielu czynnikow. Ważne by być przygotowanym na zmiany i dostarczać użyteczny software Strona: 12

13 Znaczenie nazwy Źrodło: Strona: 13

14 Cykl życia projektu Źrodło: Agile Software Development Methods. Review And Analysis Strona: 14

15 Role w projekcie Podział na: świnie i kurczaki Świnie : Scrum Master - jedna z najistotniejszych ról, opiekun zespołu, pośrednik między zespołem i zarządem, robi wszystko by umożliwić pracę zespołowi zgodnie z regułami Scrum, usuwa przeszkody Product Owner - odpowiedzialny za Product Backlog. Wybierany przez Scrum Mastera, klienta i kierownictwo, podejmuje ostateczne decyzje odnośnie zadań dotyczących Backlogu Scrum Team - samoorganizujący się zespoł odpowiedzialny za realizację zadań w Sprincie. Bierze udział w estymacie zadań, tworzeniu z Backlogu i modyfikacji jego zawartości Kurczaki : Customer - bierze udział przy ustalaniu Backlogu Management - podejmuje dycyzje personalne (Product Owner), dba o przetrzeganie standardów. Bierze udział przy ustalaniu celow i priorytetow projektu Eksperci wymagani w niektórych sprintach, czasami stają się świniami w ramach pracy z zespołem Strona: 15

16 Praktyki w Scrum Product Backlog lista, która powinna zawierać zadania bieżące (z estymatami), przyszłe (z priorytetami) oraz idee może zawierać wszystkie zadania związane z projektem (biznesowe i techniczne) za estymaty i priorytety odpowiedzialny Product Owner na podstawie pomiarow Effort estimation - pomiary czasu pracy nad każdą pozycją z Backlogu. Wyznaczane przez Scrum Team i Ownera Sprint - 30 dni pracy zespołu programistycznego nad kolejną działającą wersją systemu. W ich trakcie wykorzystuje się poniższe praktyki Sprint planning meeting - 30 dni pracy zespołu programistycznego nad kolejną działającą wersją systemu. Time boxing ustalanie sztywnych ram czasowych dla pewnych czynności np. sprinty, spotkania planistyczne Strona: 16

17 Product Backlog Źrodło: Strona: 17

18 Praktyki w Scrum (2) Sprint Backlog - ustalany przez zespoł, mistrza i właściela na podstawie aktualnego Product Backlog podczas Sprint planning meeting. Sprint Backlog jest stały na czas trwania sprintu. Daily Scrum meeting - zwołuje Scrum Master, 15 minutowe spotkanie, monitorowanie aktualnego postępu prac, uczestnicy aktywni i obserwatorzy Sprint review meeting - podczas ostatniego dnia sprintu, prezentacja kolejnego inkrementu z udziałem wszystkich, na jego podstawie decyzje odnośnie dalszego rozwoju Źrodło: Scrum and XP from the Trenches Strona: 18

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

20 Skalowanie Scrum Źrodło: Strona: 20

21 Skalowanie Scrum (2) Źrodło: Strona: 21

22 Skalowanie Scrum (3) Źrodło: Strona: 22

23 Obie metodologie mają wiele podobieństw. Wynika to z tego, że XP zaczerpnęło kilka elementów właśnie ze Scruma O ile Scrum jest ogólnym frameworkiem dla prowadzenia projektów, XP skupia się bardziej na metodzie pracy zespołu programistycznego XP przeznaczone jest dla małych zespołów, Scrum można skalować Źrodło: Strona: 23

24 Crystal

25 Crystal Methodologies lata 90, Alistair Cockburn ( zatrudniony przez IBM Consulting Group w celu skonstruowania nowej metodologii Cockburn przesłuchuje zespoły i stwierdza istotną zależność pomiędzy sposobem komunikacji a końcowym sukcesem projektu Źrodło: Agile S oftware D evelopment Methods. R eview And Analysis Strona: 25

26 Crystal Methodologies (2) Najlepiej jest kiedy komunikacja odbywa się w sposob bezpośredni Niestety każdy człowiek ma swoje ograczenia (nawet 10 najlepszych programistow nie wykona dużego projektu w b. krótkim czasie) Dlatego potrzeba większej ilości programistow - niestety komplikuje to komunikację Źrodło: Agile S oftware D evelopment Methods. R eview And Analysis Strona: 26

27 Powstanie rodziny metodologii Crystal Cockburn dochodzi do wniosku, iż w zależności od rozmiarow zespołu potrzebne są nieco inne pratyki - stąd pomysł całej rodziny kilku podobnych metodologii Idea tworzenia metodologii dla konkretnego projektu Źrodło: Agile S oftware D evelopment Methods. R eview And Analysis Strona: 27

28 Rodzina metodologii C rystal Im ciemniejszy kolor tym cięższa metodologia Straty: C (Comfort), D (Discretionary Money), E (Essential Money), L (Life) Jak na razie 2 opracowane i przetestowane metodologie: Crystal Clear i Crystal Orange Crystal Clear - D6 (może do E8, D10), ludzie pracują w tym samym pokoju, 23 miesięczne iteracje, istotna bezpośrednia komunikacja, aktywny udział klienta Crystal Orange - do 40 ludzi w jednym budynku, 1 do 2 lat trwania, istotny czas zakończenia, system średniego ryzyka, istotna komunikacja z przyszłymi członkami zespołu Strona: 28

29 Ludzie w zespole Crystal Clear Crystal Orange Sponsor Sponsor Senior Designer-Programmer Business expert Designer Programmer Usage expert User (min. poł etatu) Technical facilitator Business Analyst/Designer Project Manager Architect Design Mentor Lead Designer-Programmer Other Designer-Programmers UI Designer Writer Tester podzieleni na kilka zespołow np. planowanie, modelowanie, infrastruktura, testy etc. Strona: 29

30 Artefakty pracy Crystal Clear Release sequence Schedule deliveries of user viewings and Annotated use cases or feature descriptions Crystal Orange Requirements document Release sequence Schedule Status reports Design sketches & notes as needed UI design document Screen drafts Common object model A common object model Inter-team specs Running code User manual Test cases Source code User manual Test cases Migration code Strona: 30

31 7 własności projektów C rystal 1. Frequent Delivery 2. Reflective Improvement 3. Osmotic Communication 4. Personal Safety 5. Focus 6. Easy Access to Expert Users 7. Technical Environment with Automated Tests, Configuration Management, and Frequent Integration Crystal Clear wymaga pierwszych 3. Dobry zespoł używa jednak wszystkich 7. Własności mogą być zastosowane rownież w przypadku większych projektow, z wyjątkiem Osmotic Communication Strona: 31