agile methodology
TRANSCRIPT
Metodyka agileDaniel Waligóra
Wrocław 16/01/2013
1 / 40
Agenda• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- czym jest „agile”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
2 / 40
• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- czym jest „agile”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
3 / 40
LOOP - błędne LOOP - błędne kołokoło
LOOP - błędne LOOP - błędne kołokoło
4 / 40
•Late (późno)
od 6 do 12 miesięcy
•Over Budget (przekroczony budżet)
50% - 100%(!)
•Overtime (nadgodziny)
•Poor quality (kiepska jakość)E. Yourdon, Marsz ku klęsce. Poradnik dla projektanta systemów
5 / 40
The Standish Group
International Inc.
•zakończone sukcesem (P1)
•zakończone częściowym niepowodzeniem (P2)
•zakończone porażką (P3)
Podział przedsięwzięć informatycznych ze względu na zakończenie:
6 / 40
Raport „Chaos”
7 / 40
• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- czym jest „agile”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
8 / 40
Lata 80-00więcej więcej
dyscypliny!!dyscypliny!!!!
więcej więcej dyscypliny!!dyscypliny!!
!!
9 / 40
•ISO 9000
- v1 - 1987
- v2 - 1994
- v3 - 2000
•CMM (Capability Maturity Model)
- v1 - 1987
- v2 - 1997 (rozpoczęcie prac nad CMM Integration)
-
10 / 40
Wstępny (1)Wstępny (1)
Zarządzany (2)Zarządzany (2)
Zdefiniowany (3)Zdefiniowany (3)
Zarządzany (4)Zarządzany (4)
Optymalizujący (5)Optymalizujący (5)
Proces zdyscyplinowany
Zestandaryzowany, spójny proces
Przewidywalność procesu
Ciągła poprawa procesu
11 / 40
Metody klasyczne Wady
biurokratyzacjabiurokratyzacja
skupienie na skupienie na procesie, nie procesie, nie
produkcieprodukciezabicie inicjatywy i zabicie inicjatywy i
elastycznościelastyczności
12 / 40
• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- dlaczego „lekkie”, „zwinne”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
13 / 40
Dlaczego „lekkie”,„zwinn
e”?
14 / 40
„Wolna amerykanka”„Jazda bez trzymanki”
15 / 40
2001 Snowbird, Utah
16 / 40
•Ludzie i interakcje ponad
procesy i narzędzia
•Współpraca z klientem ponad
negocjacje kontraktu
•Działające oprogramowanie ponad
wyczerpującą dokumentację
•Reagowanie na zmiany ponad
śledzenie planu
Manifest Agile - wartości
17 / 40
Manifest Agile - zasada #1„Satysfakcja klienta
poprzez wczesne i stałe (ciągłe) dostarczanie
oprogramowania.”
18 / 40
Manifest Agile - zasada #2„Zmiana wymagań
nie jest problemem, nawet na
zaawansowanym poziomie tworzeni
a.”19 / 40
Manifest Agile - zasada #3„Działające
oprogramowanie dostarczane często, z
przerwami od kilku tygodni do kilku
miesięcy, przy czym im częściej, tym lepiej.”
20 / 40
Manifest Agile - zasada #4
„Klient jako integralna część zespołu.”
21 / 40
Manifest Agile - zasada #5
„Projekty powierzać osobom
zmotywowanym.”
22 / 40
Manifest Agile - zasada #6
„Rozmowa na żywo jest
najskuteczniejszym sposobem
przekazywania informacji.”
23 / 40
Manifest Agile - zasada #7
„Działające oprogramowanie jest podstawową miarą
postępu pracy.”
24 / 40
Wykres spalania sprintu - SCRUM
25 / 40
Manifest Agile - zasada #8
„Oprogramowanie powinno być tworzone
w stałym tempie.”
26 / 40
Manifest Agile - zasada #9
„Doskonałość od strony technicznej oraz
dobre projektowanie wspomagające
podejście Agile.”
27 / 40
Manifest Agile - zasada #10
„Kluczowa definicja prostoty: sztuka
maksymalizacji pracy jeszcze nie wykonane
j.”
28 / 40
Manifest Agile - zasada #11„Najlepsza
architektura, wymagania i projekty
powstają w samoorganizujących
się zespołach.”29 / 40
Manifest Agile - zasada #12
„Zespół projektowy powinien regularnie weryfikować swoją efektywność oraz
starać się ją poprawiać.”
30 / 40
Przyrastać czy ewoluować?
źródło: http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Przyrost
Ewolucja
31 / 40
Cykl życia projektu - SCRUM
WizjaWizja
Product Product BacklogBacklog
Sprint Sprint backlogbacklog
Sprint Sprint reviewreview ProductProduct
Planowanie sprintu
Przyrost
Daily Daily ScrumScrum
32 / 40
Najpopularniejsze metodyki
• Dynamic Systems Development (1990) - Dane Faulkner
• Scrum (1995) - Ken Schwaber, Jeff Sutherland, Mike Beedle
• Adaptive Software Development (1995) - Jim Highsmith
• Feature Driven Development (1995) - Jeff DeLuca
• eXtreme Programming (1996) - Kent Beck, Ron Jeffries
• Crystal methodologies (1996) - Alistair Cockburn
• Lean Software Development (1996) - Mary and Tom Poppendieck
• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- czym jest „agile”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
33 / 40
Planowanie z klientem w Metodyce Tradycyjnej
Planowanie z klientem w Metodyce Zwinnej
PlanowanPlanowanieie
WytwarzanieWytwarzanie
PlanowaniPlanowaniee
34 / 40
• Kryzys
• Metodyki tradycyjne
• Metodyka Agile
- czym jest „agile”?
- wartości
- zasady
- cechy
• Tradycja vs Zwinność
• Lęki i prawa
35 / 40
•niekompletne wyobrażenie o problemie, a propozycje wykonawcy złe i niepotrzebne
• jego przyszłość zależy od innych ludzi (programistów)
•projekt się przedłuży i pochłonie większy budżet
•produkt będzie kiepskiej jakości, nieużywalny
Lęki klienta:
36 / 40
• nie będzie miał jasno określonych wymagań i będą one zmienne
• klient będzie wymagał zbyt dużo za zbyt mało
• problem będzie przerastał jego możliwości lub pochłonie zbyt dużo czasu
• problem będzie zawierał ukryte „miny”
• na nim spoczywa odpowiedzialność za wszystkie niepowodzenia
Lęki programisty:
37 / 40
• Klient ma prawo do długofalowego planowania z uwzględnieniem kosztów i wariantów
• Klient ma prawo do okresowego wyznaczania priorytetów projektu
• Klient ma prawo do wglądu w postępy projektu oraz dostępu do działającej i aktualnej wersji aplikacji
• Klient ma prawo do zmiany zdania (założeń projektu) bez konieczności płacenia wygórowanych kosztów
Karta praw klienta:
38 / 40
• 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, 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 postępów projektu
Karta praw programisty:
39 / 40
Literatura• Wykłady - Techniki Wytwarzania oprogramowania,
Jacek Dajda, EAiIE AGH
• Manifesto for Agile Software Development http://agilemanifesto.org
• Jeff Patton blog, http://www.agileproductdesign.com
• http://agile.jogger.pl
• Martin Fowler, The Agile Manifesto: where it came from and where it may go http://www.martinfowler.com/articles/agileStory.html
• http://blog.standishgroup.com
• http://wazniak.mimuw.edu.pl40 / 40
Dziękuję za uwagę.