Agile - metodyki zwinne.
Spis treści:
1. Wstęp do metodyk zwinnych – manifest i zasady Agile.
2. Dostarczanie oparte na wartości – ocena, planowanie, dostarczanie, weryfikowanie i monitorowanie wartości.
3. Zaangażowanie interesariuszy – współpraca i komunikacja, przywództwo (rozdział w opracowaniu).
4. Wydajność zespołów – co to jest, od czego zależy i jak ją poprawiać.
5. Planowanie adaptacyjne – koncepcje planowania, estymacja, planowanie zwinne.
6. Problemy – jakość, wykrywanie, zapobieganie i rozwiązywanie problemów.
7. Ciągłe doskonalenie – retrospekcje i udoskonalanie procesów.
8. Opis najpopularniejszych metodyk – SCRUM.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
This is a presentation on "Lean & Agile Organizational Leadership: History, Theory, Models, & Popular Ideas," which are emerging models for managing high-risk, time-sensitive R&D-oriented new product development (NPD) projects with demanding customers and fast-changing market conditions (at the enterprise, portfolio, and program levels). It establishes the context, provide a definition, and describe the value-system for lean and agile methods, principles, and core ideas. It provides a brief history and comparative analysis of agile methods (i.e., Crystal Methods, Scrum, Dynamic Systems Development Method, Feature Driven Development, and Extreme Programming), project management models (i.e., Radical, Adaptive, Extreme, Agile, and Simplified Agile), and portfolio frameworks (i.e., Enterprise Scrum, Scaled Agile Framework, Large Scale Scrum, Disciplined Agile Delivery, and Recipes for Agile Governance). Then it provides multiple histories of the fields of organizational leadership, administration, and management over the last 100 years. It then introduces, delves into, describes, and provides a brief survey and comparative analysis of emerging theories, models, and methods of lean and agile leadership (i.e., Agile, Employee, Radical, Lean, and Leadership 3.0). Finally, it closes with an expose of the top organizational change paradigms most closely aligned with the field of lean and agile development, project management, and portfolio management methodologies (along with a unique summary of the major tenets, principles, and practices of lean & agile organizational leadership). This briefing has been warmly received by multiple U.S. government agencies, contractors, and university audiences throughout Baltimore-Washington, DC.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
This is a presentation on "Lean & Agile Organizational Leadership: History, Theory, Models, & Popular Ideas," which are emerging models for managing high-risk, time-sensitive R&D-oriented new product development (NPD) projects with demanding customers and fast-changing market conditions (at the enterprise, portfolio, and program levels). It establishes the context, provide a definition, and describe the value-system for lean and agile methods, principles, and core ideas. It provides a brief history and comparative analysis of agile methods (i.e., Crystal Methods, Scrum, Dynamic Systems Development Method, Feature Driven Development, and Extreme Programming), project management models (i.e., Radical, Adaptive, Extreme, Agile, and Simplified Agile), and portfolio frameworks (i.e., Enterprise Scrum, Scaled Agile Framework, Large Scale Scrum, Disciplined Agile Delivery, and Recipes for Agile Governance). Then it provides multiple histories of the fields of organizational leadership, administration, and management over the last 100 years. It then introduces, delves into, describes, and provides a brief survey and comparative analysis of emerging theories, models, and methods of lean and agile leadership (i.e., Agile, Employee, Radical, Lean, and Leadership 3.0). Finally, it closes with an expose of the top organizational change paradigms most closely aligned with the field of lean and agile development, project management, and portfolio management methodologies (along with a unique summary of the major tenets, principles, and practices of lean & agile organizational leadership). This briefing has been warmly received by multiple U.S. government agencies, contractors, and university audiences throughout Baltimore-Washington, DC.
This slide is a discussion of Traditional Project Management V Agile Project Management. Where and how both fits in, why should we go for Agile Project Management, What is Agile etc. is dealt in detail,
We are doing Agile well..We have been Agile now.. Is it just an assumption or do we have data to support it? Do metrics add any value or they are just a fad? Good metrics affirm & reinforce Agile principles. They open up the conversation and help the teams to improve. They are not only for management, it is for everyone who wants to inspect and adapt.
So this presentation is about how metrics can be used effectively in Agile to enable transparency and improve the overall efficiency at the team/ program and portfolio level.
Teresa Torres - An introduction to modern product discovery - Productized16Productized
The world of product management is changing quickly. In the past five years alone, we’ve seen the rise of The Lean Startup, design thinking, the Jobs-to-be-done framework, design sprints, OKRs, and much more. It can be hard for product teams to keep up. In this talk, you’ll learn a simple framework for how to make sense of all of these trends. You’ll learn how to mix and match methods in a way that leads to a coherent strategy that leads to better products.
Teresa is a product coach helping teams adopt user-centered, hypothesis-driven product development practices, and is the creator of Product Talk. She works with companies of all sizes on integrating user research, experimentation, and the right analytics into the product development process resulting in better product decisions.
10 steps to a successsful enterprise agile transformation global scrum 2018Agile Velocity
Presented at Scrum Gathering Minneapolis, Senior Agile Coach and Trainer Mike Hall provides leaders and managers 10 steps to a successful enterprise Agile transformation.
This deck consists of total of fourty four slides. It has PPT slides highlighting important topics of Agile Delivery PowerPoint Presentation Slides. This deck comprises of amazing visuals with thoroughly researched content. Each template is well crafted and designed by our PowerPoint experts. Our designers have included all the necessary PowerPoint layouts in this deck. From icons to graphs, this PPT deck has it all. The best part is that these templates are easily customizable. Just click the DOWNLOAD button shown below. Edit the colour, text, font size, add or delete the content as per the requirement. Download this deck now and engage your audience with this ready made presentation. http://bit.ly/2Q7lImJ
An explanation of Agile and how it relates to frameworks like Scrum.
What is Agile: https://agile-mercurial.com/2019/01/28/what-is-agile-1-minute-explanation-video/
Blog: https://agile-mercurial.com
YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg
Twitter: https://twitter.com/agile_mercurial
Tumblr: https://agilemercurial.tumblr.com/
The process of adopting Agile in any organization is challenging in many ways. It is especially challenging in larger organizations because of complex infrastructures, numerous legacy systems and mature organizational cultures. These larger organizations often underestimate the difficulty of getting Agile right.
This presentation will focus on the common challenges of Agile adoption. Tips are provided to help improve the chances of Agile adoption success.
Product roadmaps are an important product management tool. But traditionally, they map features onto a timeline that often extends many months into the future. This makes them hard to apply in an agile context where change and uncertainty are present. My talk shows how you can use agile product roadmaps, roadmaps that describe the value the product should create, align the stakeholders and development teams, and unburden the product backlog while avoiding premature commitments and preserving the ability to inspect and adapt.
Strefa PMI - Project Management Quarterly issued by PMI Poland Chapter
Kwartalnik o zarządzaniu projektami, wydawany przez PMI Poland Chapter.
Spis treści:
STREFA WIEDZY
Project and Program Integration as a Concept for Achieving Success on Megaprojects – Virginia A. Greiman
Ukryty potencjał innowacji – Grzegorz Szałajko
Siedem szkół zarządzania projektami – Marta Bobińska
Zmiana paradygmatu. Kompetencje miękkie w zarządzaniu projektami – Agnieszka Dobosz
Galaktyka certyfikacji Agile – Mirosław Dąbrowski
Wdrożeniowe case study – Katarzyna Żurowska
Jak projektem zmieniać świat? – Krzysztof Kowal
Wszystko co dobre jest testowane – Maciej Obrzydowski, Bartłomiej Zarembski
STREFA WYWIADU
Projects deliver no value! – wywiad z Markiem Smalleyem
STREFA PMI PC
Co motywuje pokolenie Y? – Małgorzata Kusyk, Aleksandra Jaworska, Przemysław Przytuła, Radosław Rząsa, Rafał Sowiński
„Bądź zmianą, którą pragniesz ujrzeć w świecie” – Katarzyna Schaefer, Natalia Wiśniewska, Aleksandra Wisz
Wrocław inspiruje innowacją – Mirosław Dąbrowski
Be S.M.A.R.T! Żyj z pasją! – Katarzyna Wójcik, Marta Woch-Czajkowska, Marcin Kosidłowski
STREFA WYDARZEŃ
Przy okrągłym stole o wyzwaniach wobec PMO – Anna Bilny
Jak stosować Lean i Six Sigmę poza produkcją? – Kamila Czerniak
NetVision 2015 – największa konferencja na Pomorzu. Relacja z wydarzenia – Marta Sawicka, Agnieszka Sawicka, Paulina Radwańska
STREFA STUDENTA
Jak rzuciłam sobie wyzwanie… czyli mój pierwszy projekt – Natalia Piątek
Studenckie projekty „niemożliwe” – Maciej Radyno
STREFA RECENZJI
O skutecznym kierowaniu ludźmi – Wojciech Danowski
Kompleksowo o zarządzaniu projektami – Natalia Piątek
Zwinne zarządzanie organizacją – strategia, wdrożenie, organizacje oraz ludzie – Mirosław Dąbrowski
Polak potrafi. Rodzime przypadki projektowe – Szymon Pawłowski
STREFA FELIETONU
Multitasking – wróg publiczny numer jeden – Jerzy Stawicki
This slide is a discussion of Traditional Project Management V Agile Project Management. Where and how both fits in, why should we go for Agile Project Management, What is Agile etc. is dealt in detail,
We are doing Agile well..We have been Agile now.. Is it just an assumption or do we have data to support it? Do metrics add any value or they are just a fad? Good metrics affirm & reinforce Agile principles. They open up the conversation and help the teams to improve. They are not only for management, it is for everyone who wants to inspect and adapt.
So this presentation is about how metrics can be used effectively in Agile to enable transparency and improve the overall efficiency at the team/ program and portfolio level.
Teresa Torres - An introduction to modern product discovery - Productized16Productized
The world of product management is changing quickly. In the past five years alone, we’ve seen the rise of The Lean Startup, design thinking, the Jobs-to-be-done framework, design sprints, OKRs, and much more. It can be hard for product teams to keep up. In this talk, you’ll learn a simple framework for how to make sense of all of these trends. You’ll learn how to mix and match methods in a way that leads to a coherent strategy that leads to better products.
Teresa is a product coach helping teams adopt user-centered, hypothesis-driven product development practices, and is the creator of Product Talk. She works with companies of all sizes on integrating user research, experimentation, and the right analytics into the product development process resulting in better product decisions.
10 steps to a successsful enterprise agile transformation global scrum 2018Agile Velocity
Presented at Scrum Gathering Minneapolis, Senior Agile Coach and Trainer Mike Hall provides leaders and managers 10 steps to a successful enterprise Agile transformation.
This deck consists of total of fourty four slides. It has PPT slides highlighting important topics of Agile Delivery PowerPoint Presentation Slides. This deck comprises of amazing visuals with thoroughly researched content. Each template is well crafted and designed by our PowerPoint experts. Our designers have included all the necessary PowerPoint layouts in this deck. From icons to graphs, this PPT deck has it all. The best part is that these templates are easily customizable. Just click the DOWNLOAD button shown below. Edit the colour, text, font size, add or delete the content as per the requirement. Download this deck now and engage your audience with this ready made presentation. http://bit.ly/2Q7lImJ
An explanation of Agile and how it relates to frameworks like Scrum.
What is Agile: https://agile-mercurial.com/2019/01/28/what-is-agile-1-minute-explanation-video/
Blog: https://agile-mercurial.com
YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg
Twitter: https://twitter.com/agile_mercurial
Tumblr: https://agilemercurial.tumblr.com/
The process of adopting Agile in any organization is challenging in many ways. It is especially challenging in larger organizations because of complex infrastructures, numerous legacy systems and mature organizational cultures. These larger organizations often underestimate the difficulty of getting Agile right.
This presentation will focus on the common challenges of Agile adoption. Tips are provided to help improve the chances of Agile adoption success.
Product roadmaps are an important product management tool. But traditionally, they map features onto a timeline that often extends many months into the future. This makes them hard to apply in an agile context where change and uncertainty are present. My talk shows how you can use agile product roadmaps, roadmaps that describe the value the product should create, align the stakeholders and development teams, and unburden the product backlog while avoiding premature commitments and preserving the ability to inspect and adapt.
Strefa PMI - Project Management Quarterly issued by PMI Poland Chapter
Kwartalnik o zarządzaniu projektami, wydawany przez PMI Poland Chapter.
Spis treści:
STREFA WIEDZY
Project and Program Integration as a Concept for Achieving Success on Megaprojects – Virginia A. Greiman
Ukryty potencjał innowacji – Grzegorz Szałajko
Siedem szkół zarządzania projektami – Marta Bobińska
Zmiana paradygmatu. Kompetencje miękkie w zarządzaniu projektami – Agnieszka Dobosz
Galaktyka certyfikacji Agile – Mirosław Dąbrowski
Wdrożeniowe case study – Katarzyna Żurowska
Jak projektem zmieniać świat? – Krzysztof Kowal
Wszystko co dobre jest testowane – Maciej Obrzydowski, Bartłomiej Zarembski
STREFA WYWIADU
Projects deliver no value! – wywiad z Markiem Smalleyem
STREFA PMI PC
Co motywuje pokolenie Y? – Małgorzata Kusyk, Aleksandra Jaworska, Przemysław Przytuła, Radosław Rząsa, Rafał Sowiński
„Bądź zmianą, którą pragniesz ujrzeć w świecie” – Katarzyna Schaefer, Natalia Wiśniewska, Aleksandra Wisz
Wrocław inspiruje innowacją – Mirosław Dąbrowski
Be S.M.A.R.T! Żyj z pasją! – Katarzyna Wójcik, Marta Woch-Czajkowska, Marcin Kosidłowski
STREFA WYDARZEŃ
Przy okrągłym stole o wyzwaniach wobec PMO – Anna Bilny
Jak stosować Lean i Six Sigmę poza produkcją? – Kamila Czerniak
NetVision 2015 – największa konferencja na Pomorzu. Relacja z wydarzenia – Marta Sawicka, Agnieszka Sawicka, Paulina Radwańska
STREFA STUDENTA
Jak rzuciłam sobie wyzwanie… czyli mój pierwszy projekt – Natalia Piątek
Studenckie projekty „niemożliwe” – Maciej Radyno
STREFA RECENZJI
O skutecznym kierowaniu ludźmi – Wojciech Danowski
Kompleksowo o zarządzaniu projektami – Natalia Piątek
Zwinne zarządzanie organizacją – strategia, wdrożenie, organizacje oraz ludzie – Mirosław Dąbrowski
Polak potrafi. Rodzime przypadki projektowe – Szymon Pawłowski
STREFA FELIETONU
Multitasking – wróg publiczny numer jeden – Jerzy Stawicki
czyli sposoby na zachowanie wysokiej jakości produktów. Z artykułu dowiesz się m. in.: jakie są typowe problemy i sposoby radzenia przy realizacji dużych projektów; poznasz procesy planowania oraz sposoby dzielenia projektów na etapy. Zapraszamy do lektury.
Czym jest jakość architektury korporacyjnej i jak ją oceniać? Andrzej Sobczak
Pierwsza część kursu "Czym jest jakość architektury korporacyjnej i jak ją oceniać? ". Cały materiał dostępny jest na Akademii Standardów IT (http://www.akademiastandardowit.pl).
Czym są metodyki w zarządzaniu projektami? Czy znajdują zastosowanie w przypadku projektów e-marketingowych? Jakie są ich zalety i ograniczenia? Czy to skuteczny sposób na niektóre z problemów w trakcie realizacji projektów, a może istnieją jakieś „złote rady”?
Jak skutecznie zarządzać projektami internetowymi. Praktyczne porady jak zarządzać zmianą, budżetem, harmonogramen, jak zarządzać wieloma projaktami, itd.
Podstawy Project Portfolio Management na przykładach wdrożeń. Informacje o narzędziach i metodzie implementacji. Kilka dobrych praktyk z przeszości :-) - prezentacja dla IPMA w Szczecinie
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Zarządzanie projektem jest jedną z kluczowych kompetencji współczesnego Menedżera/rki. Ważna jest oczywiście stosowana metodyka, lecz ważniejsza wydaje się filozofia zarządzania projektami wyrażana w planowaniu działań, uzasadnianiu ich, a także wyznaczaniu konkretnych celów do osiągnięcia. W prezentacji, która doskonale wprowadza w założenia matodyki zarządzania projektami, zaprezentowano Matrycę Logiczną Projektu - prostą metodykę opracowaną przez zespół pod kierownictwem Artura Smolik. Oparta jest ona na: sprawności, skuteczności, ekonomiczności i racjonalności działania.
W prezentacji znajdziecie Państwo wstęp do metodyki projektowej oraz opis narzędzia wspierającego zarządzanie projektami MLP by A. Smolik.
Prezentację opracowała Joanna Plata.
Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development.
Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling:
http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/
Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadcza...PMI Szczecin
Prezentacja Michała Koniewicza z 9. spotkania PMI Szczecin w dn. 22 marca 2016 r., pn. "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie".
Scrum, choć jest wciąż popularny i lubiany, to zwykle nie jest już zwinny (Agile). Co robi różnicę? Jak bycie zwinnym zmienia myślenie o zadaniach ludzi w IT? Czym w praktyce różni się praca w zespole tradycyjnym i zwinnym? Wreszcie jak rozpoznać u potencjalnego pracodawcy prawdziwy Agile? Przy okazji odpowiedzi na te pytania sprostujemy wspólnie najczęściej pojawiające się przekłamania na temat Scruma i Agile.
2. Metodyki zwinne
Spis treści
1. Wstęp do metodyk zwinnych – manifest i zasady Agile
2. Dostarczanie oparte na wartości – ocena, planowanie,
dostarczanie, weryfikowanie i monitorowanie wartości
3. Zaangażowanie interesariuszy – współpraca i komunikacja,
przywództwo
4. Wydajność zespołów – co to jest, od czego zależy i jak ją
poprawiać
5. Planowanie adaptacyjne – koncepcje planowania, estymacja,
planowanie zwinne
6. Problemy – jakość, wykrywanie, zapobieganie i rozwiązywanie
problemów
7. Ciągłe doskonalenie – retrospekcje i udoskonalanie procesów
8. Opis najpopularniejszych metodyk – SCRUM
2014-04-29Łukasz Rzepecki
2
3. Metodyki zwinne
Projekty pracownika wiedzy
• Rewolucia przemysłowa (XVIII – XX w.) – jest źródłem
większości idei zarządzania projektami
- 3. rewolucja przemysłowa – naukowo-techniczna (formalnie trwa
do dziś): wykresy Gantt’a, WBS PMI – PMBOK (1983 r.)
• Rewolucja informacyjna (od 2. połowy XX w.) – bazuje
na tzw. pracownikach wiedzy:
- specjaliści w danej dziedzinie
- wymagana wiedza a nie tylko umiejętności
- komunikowanie się i transfer wiedzy ważniejsze od “instrukcji”
2014-04-29Łukasz Rzepecki
3
5. Metodyki zwinne
Praca przemysłowa vs praca wiedzy
Praca przemysłowa Praca wiedzy
Efekty pracy są widoczne Pracy nie widać
Praca jest ciągła i taka sama Praca jest zmienna
Nacisk na wykonywanie czynności Nacisk na tworzenie/zmienianie rzeczy
Mała decyzyjność (struktury i procedury) Częste podejmowanie różnych decyzji
Skupienie się na właściwych odpowiedziach Skupienie się na właściwych pytaniach
Zdefiniowanie zadania Zrozumienie zadania
Zarządzanie i kontrola Większa autonomia
Ważniejsza ilość Ważniejsza jakość
Sztywne standardy Innowacje
Wydajność zgodna ze standardami Ciągła nauka i doskonalenie
Pracownik kosztem Pracownik zasobem
2014-04-29Łukasz Rzepecki
5
6. Metodyki zwinne
Zarządzanie projektami wiedzy
• Próbowano stosować te same koncepcje i techniki z
pracy przemysłowej do projektów pracowników wiedzy
- Praca do wykonania często nie była tak dobrze określona jak w
branży przemysłowej
- Prowadziło to do niepowodzeń i frustracji
• W odpowiedzi powstały koncepcje zwinnych metodyk
zarządzania
• Przez lata wytworzyło się wiele różnych koncepcji –
pionierem branża informatyczna
2014-04-29Łukasz Rzepecki
6
7. Metodyki zwinne
Manifest Agile (2001 r.)
• Wytwarzając oprogramowanie i pomagając innym w tym
zakresie, odkrywamy lepsze sposoby wykonywania tej pracy.
W wyniku tych doświadczeń przedkładamy:
- Ludzie i interakcje ponad procesy i narzędzia
- Działające oprogramowanie ponad obszerną dokumentację
- Współpraca z klientem ponad formalne ustalenia
- Reagowanie na zmiany ponad podążanie za planem
• Doceniamy to, co wymieniono po prawej stronie, jednak
bardziej cenimy to, co po lewej
• Deklaracja współzależności (DOI) – poszerza manifest o
zastosowania w innych projektach niż IT
2014-04-29Łukasz Rzepecki
7
8. Metodyki zwinne
Zasady Agile
• Zadowolenie klienta poprzez szybkie dostarczanie użytecznego
oprogramowania
• Otwartość na zmiany, nawet w późnym etapie projektu
• Działające oprogramowanie dostarczane jest często (tygodnie, nie miesiące)
• Działające oprogramowanie jest głównym wskaźnikiem postępu
• Regularność (stały rytm) i ciągłość pracy
• Bliska, codzienna współpraca pomiędzy biznesem a zespołem
• Komunikacja face-to-face jest najlepszą formą komunikacji (kolokacja)
• Projekty tworzą zmotywowane jednostki, którym należy zaufać
• Ciągła uwaga na doskonałość technologiczną i dobry design
• Kluczowa jest prostota – sztuka maksymalizowania ilości pracy nie wykonanej
• Samoorganizujące się zespoły
• Regularna adaptacja do zmieniających się okoliczności
2014-04-29Łukasz Rzepecki
8
10. Metodyki zwinne
Trójkąt ograniczeń
2014-04-29Łukasz Rzepecki
10
4 podstawowe ograniczenia każdego projektu:
Zmieniając jeden z parametrów należy zmienić pozostałe,
w przeciwnym razie nie dotrzymamy parametru środkowego
11. Metodyki zwinne
Macierz kompromisów projektowych
Parametr
Ustalony
(dokładnie 1)
Optymalizowany
( dokładnie 1)
Negocjowany
(pozostałe 2)
Czas X
Budżet X
Zakres X
Jakość X
Kluczowy parametr,
nie podlegający
żadnym negocjacjom
w trakcie trwania
projektu
Np. realizując projekt
jak najszybciej,
najtaniej, jak
najwięcej prac lub
dbając o jakość.
Te dwa parametry
mogą się zmieniać o
określonych
granicach
2014-04-29Łukasz Rzepecki
11
12. Metodyki zwinne
Kiedy stosować Agile
• Klasyka Agile:
- “Ruchomy cel”, np. prace badawcze
- Nieznany/niedookreślony efekt końcowy
• Kiedy faktycznie stosować Agile:
- Cel jest znany i może być bardzo dobrze określony
- …ale wiemy, że na pewno ulegnie zmianie ;)
- Kiedy rezultat projektu jest bardzo trudny/kosztowny do
modyfikacji (vs łatwy/możliwy do zmiany po koszcie zbliżonym
do pierwotnego)
• np. budowa domu, mostu, software pudełkowy
2014-04-29Łukasz Rzepecki
12
13. Metodyki zwinne
Sukces realizacji projektów – duże/małe
2014-04-29Łukasz Rzepecki
13
The Standish Group: Chaos Manifesto 2013 – Think Big, Act Small
• od 1985 r.
• 50k projektów
• 60% US, 25% EU
• połowa Fortune 1000
• 20% firmy małe
14. Metodyki zwinne
Sukces realizacji projektów małych
2014-04-29Łukasz Rzepecki
14
The Standish Group: Chaos Manifesto 2013 – Think Big, Act Small
• od 1985 r.
• 50k projektów
• 60% US, 25% EU
• połowa Fortune 1000
• 20% firmy małe
16. Metodyki zwinne
Rodzaje metodyk zwinnych
• Extreme Programming (XP)
- Daje techniki wytwarzania oprogramowania
- Jest bardzo mało zarządzania
- Trzeba łączyć ją z metodykami zarządzania
• Lean
- Główną zasadą jest eliminacja strat – „Wartością jest to, co klient uzna za wartościowe”
- Przykładem myślenia Lean jest twierdzenie, że nie należy wykonywać wszystkich analiz na
początku, bo zajdą zmiany
- Może być stosowany na poziomie wytwarzania i organizacji
• Scrum
- Zapewnia znakomite podejście oparte na zespole
- Porządkuje (priorytetyzuje) pracę
- Potrzebuje dodatkowego podejścia na poziomie zarządzania projektem (np. DSDM Atern)
- Często łączony z XP (Scrum zapewnia zarządzanie zespołem, a XP techniki wytwarzania)
2014-04-29Łukasz Rzepecki
16
17. Metodyki zwinne
Rodzaje metodyk zwinnych
• DSDM Atern (Dynamic Systems Development Method)
- Najstarsza na świecie metodyka Agile, powstała w 1995 roku (PRINCE2
powstał w 1996!)
- Jako jedyna w pełni opisuje zarządzanie projektami Agile
- Jest w ciągłym rozwoju, a DSDM Atern jest jej najnowszą wersją
• Agile Project Management
- Na początku projektu tworzony jest plan wysokiego poziomu oparty o zarys
wymagań i rozwiązanie widziane „z lotu ptaka”
- Projekt jest realizowany w sposób iteracyjny i przyrostowy
- Kolejny przyrost jest budowany w oparciu o produkt wytworzony w
poprzedniej iteracji
- Szczegółowy plan każdego kroku jest tworzony przez zespół, a nie
Kierownika Projektu
2014-04-29Łukasz Rzepecki
17
18. Metodyki zwinne
Metodyki zwinne i ich zasady
• SCRUM – Transparency, Inspection, Adaptation
• Extreme Programming (XP) – Simplicity, Communication,
Feedback, Courage, Respect
• Lean Software Development – Eliminate waste, Empower the
team, Deliver fast, Optimize the whole, Build quality in, Defer
decisions, Amplify learning
• Kanban Development – Visualize the workflow, Limit WIP,
Manage flow, Make process policies explicit, Improve
collaboratively
• Dynamic Systems Development Method (DSDM)
• Crystal
• Lean Startup
2014-04-29Łukasz Rzepecki
18
20. Metodyki zwinne
Dostarczanie oparte na wartości
• Value-Driven Delivery – to kluczowy komponent każdej
metodyki zwinnej
• Powodem realizacji każdego projektu jest wygenerowanie
jakiejś wartości biznesowej
• Ryzyka projektowe (zagrożenia), to anty-wartości
• Maksymalizacja wartości wymaga redukcji ryzyka
• Szybkie dostarczanie wartościowych elementów:
- eliminuje ryzyko porażki
- buduje zaufanie sponsora projektu (udowadnia możliwość realizacji
projektu)
- angażuje zespół
2014-04-29Łukasz Rzepecki
20
21. Metodyki zwinne
Tematyka
• Ocena wartości
• Planowanie wartości
• Dostarczanie wartości
• Weryfikowanie wartości
• Śledzenie i raportowanie wartości
2014-04-29Łukasz Rzepecki
21
23. Metodyki zwinne
Ocena wartości
• Projekty biznesowe najlepiej oceniać za pomocą
narzędzi finansowych, takich jak:
- ROI – zwrot z inwestycji
- NPV – bierząca wartość netto
- IRR – wewnętrzna stopa zwrotu
• W niektórych przypadkach, gdy projekt nie generuje
bezpośrednio przychodów, można oszacować koszty
nie zrealizowania projektu
• W ostateczności projekt można uznać za niezbędny i
nie szacować jego wartości
2014-04-29Łukasz Rzepecki
23
24. Metodyki zwinne
Wskaźniki finansowe
• Zwrot z inwestycji (ROI)
- ROI = 0, gdy przychody z projektu pokrywają jego koszty
- To suma wygenerowanych przychodów minus koszty (należy
uwzględnić infalcję i ew. koszty oprocentowania pożyczek)
• Wartość bieżąca netto (NPV)
- Wartość pieniądza w czasie zmienia się (pieniądze w przyszłości
będą mniej warte niż obecnie)
- NPV określa aktualną wartość przyszłych przychodów
- Pozwala określić bliższy prawdzie czas zwrotu i wartość inwestycji
• Wewnętrzna stopa zwrotu (IRR)
- Oznacza stopę dyskonta, przy jakiej NPV=0
- Projekt jest opłacalny gdy IRR > oprocentowanie
2014-04-29Łukasz Rzepecki
24
26. Metodyki zwinne
Planowanie wartości
• Karta projektu
- Powinna zawierać odpowiedź na W5H: What, Why, Who, When,
How – z naciskiem na How
- Jak zamiany będą zatwierdzane i porządkowane w backlogu po
zatwierdzeniu?
- Mniejsze znaczenie ma co będzie wykonane, bardziej jak
• Mapowanie strumienia wartości
- Ilustruje przepływ informacji wymaganych do zrealizowania procesu
- Pomaga ustalić miejsca strat – marnowania czasu i opóźnień
- Efektywność procesu = czas przynoszący realną wartość / łączny
czas pracy w danym procesie
2014-04-29Łukasz Rzepecki
26
28. Metodyki zwinne
Straty - rodzaje
• Częściowo wykonana praca
• Dodatkowy proces
• Dodatkowe funkcjonalności
• Przełączanie sie między zadaniami
• Oczekiwanie
• Ruch
• Wady
2014-04-29Łukasz Rzepecki
28
29. Metodyki zwinne
Straty – typowe w IT
• Kod oczekujący na testy
• Wymagania czekające na implementację
• Tworzenie nigdy nie używanej dokumentacji
• Nadmiarowe, niepotrzebne akceptacje
• “Wodotryski” i zbędne features w kodzie
• Technologiczne nice-to-haves
• Praca przy wielu projektach równocześnie (switching)
• Czekanie na ocenę/przegląd prototypów/dokumentów
• Czekanie na zatwierdzenie dokumentów
• Komunikacja przy zespołach rozproszonych
• Błędy w specyfikacji wymagań wymagające naprawy
• Wady w oprogramowaniu
2014-04-29Łukasz Rzepecki
29
30. Metodyki zwinne
Porządkowanie wg wartości dla klienta
• Aby projekt przynosił jak najszybciej wartość dla klienta niezbędne jest
poznanie co to dla niego oznacza – zaangażowanie klienta
• Każda metodyka zwinna ma swój odpowiednik, np.:
- Scrum – product backlog
- FDD – feature list
- DSDM – prioritized requirements list
• Modele porządkowania:
- Priorytet wysoki/średni/niski – mało efektywne
- MoSCoW – Must/Schould/Could have, Would like to have but not…
- Monopoly Money – rozdział budżetu na wymagania przez sponsora
- Metoda 100 punktów – każdy interesariusz ma dowolność w głosach
- Analiza Kano – Exciters/Satisfiers/Dissatisfiers/Indifferent
- Model porządkowania wymagań – ocena 1-9 korzyści z posiadania danej funkcjonalności,
straty za jej nie posiadanie (klient) oraz kosztu i ryzyka (zespół), następnie wg ustalonych
wag porządkuje się wymagania
2014-04-29Łukasz Rzepecki
30
31. Metodyki zwinne
Lista rankingowa
• Bardzo prosta ale skuteczna metoda sortowania wymagań wg
kolejności oznaczającej wartość dla klienta
- Eliminuje stratę czasu na zastanawianie się nad porządkowaniem
• Lista może określać po których wymaganiach następuje wydanie
oraz które aktualnie się nie mieszczą w budżecie (pod kreską, na
później)
• Pomaga zarządzać zmianą, klient decyduje w którym miejscu na
liście umieścić daną zmianę
• Nowe wymagania umieszczone wyżej spychają pod kreskę nie
mieszczące się w budżecie
• Używa się jednej listy work-to-be-done bez rozdziału na źródło (tzn.
oryginalny backlog + zmiany + błędy + nowe)
2014-04-29Łukasz Rzepecki
31
32. Metodyki zwinne
Mapa drogowa projektu
• To wizualny przegląd planu wydań produktu
• Story Maps – pomagają wybrać i zgrupować
wymagania do poszczególnych wydań:
- Backbone – niezbędna funkcjonalność, która musi być
- Walking skeleton – najprostszy system, który będzie działał
- Dodatowe funkcjonalności – wszystkie pozostałe, posortowanie
wg ważności (mniej/bardziej opcjonalne)
2014-04-29Łukasz Rzepecki
32
35. Metodyki zwinne
Zarządzanie ryzykiem
• Ryzyko - to zdarzenie lub okoliczności które mogą się
wydarzyć i wpłynąć na projekt – ryzyka mogą być zarówno
negatywne (zagrożenia) jak i pozytywne (możliwości)
• Ryzykiem należy zarządzać i analogicznie do jak
najszybszego dostarczania wartości w projekcie należy
również jak najszybciej identyfikować i przeciwdziałać
ryzykom zagrażającym projektowi
• Wymagania mogą mieć określony poziom ryzyka – te o
wyższym ryzyku powinno się realizować wcześniej
• Backlog powinien zawierać również akcje zapobiegające
zidentyfikowanym ryzykom (poziom ryzyka można określić
jako wartość/wpływ x prawdopodobieństwo)
2014-04-29Łukasz Rzepecki
35
38. Metodyki zwinne
Kontraktowanie
• Projekty zwinne, w odróżnieniu od tradycyjnych, starają się określić
dostępne zasoby i czas oraz pozostawić elastyczną funkcjonalność,
starając się dostarczyć produkt o jak najlepszej możliwej jakości
• Idea możliwości nie dostarczenia pełnej funkcjonalności czy też braku
dokładnej wyceny całego projektu może być przez niektórych nie do
zaakceptowania
• Szczegółowy kosztorys wymaga opracowania wnikliwej analizy i
rzetelnej specyfikacji, co również jest procesem czasochłonnym i
kosztownym
• Kontrakt i tak musi zawierać metody na nieprzewidziane przypadki:
zmiany zarówno uzasadnione jak i nieprzewidziane, problemy
techniczne, możliwość niepowodzenia – w metodykach zwinnych
współpraca z klientem (zaufanie) jest ważniejsza od negocjowania
umów
2014-04-29Łukasz Rzepecki
38
39. Metodyki zwinne
Kontraktowanie
• W zwinnych metodykach ważniejsze jest skupienie się na
dostarczeniu jak najszybciej wartościowego produktu niż debaty jak
będą negocjowane zmiany i jakie tak na prawdę są kryteria
akceptacyjne
• Wymagają również od biznesu większego zaangażowania się w
trakcie poszczególnych iteracji
- Ciągłe ponowne porządkowanie wymagań
- Szacowanie wartości żądanych zmian w stosunku do pozostałej pracy
• Typy kontraktów zwinnych:
- DSDM – zapłata za spełnienie testów a nie wykonanie specyfikacji
- Pieniądze za nic, Zmiany za darmo
- Stała cena uzależniona od wyników
- Pakiety o stałej wartości
2014-04-29Łukasz Rzepecki
39
41. Metodyki zwinne
Money for Nothing and Change for Free
• Na starcie projektu określona jest stała cena (fixed-price) za pracę do
wykonania oraz stawka za wszelkie prace dodatkowe
• Klauzula “zmiany za darmo”
- Jeśli klient jest zaangażowany, PO może porządkować backlog i dokonywać zmian, o ile
całkowita praca się nie zwiększa (wymagania o mniejszej ważności są zdejmowane lub
upraszczane)
• Klauzula “pieniądze za nic”
- Opcja wcześniejszego zakończenia kontraktu w dowolnym momencie przez klienta, kiedy
uzna, że produkt spełnia jego oczekiwania
- Klient płaci np. 20% pozostałej, niewykonanej wartości kontraktu
• Klient może korzystać z tych zapisów tylko jeśli współpracuje aktywnie z
zespołem w trakcie każdej iteracji
• Brak współpracy oznacza, że klauzule tracą ważność
- Każda zamiana będzie traktowana jak praca dodatkowa
- Klient musi zapłacić za (a dostawca wykonać) cały kontrakt
2014-04-29Łukasz Rzepecki
41
43. Metodyki zwinne
Stała cena uzależniona od wyników
• Kontrakt typu fixed-price, w którym obie strony dzielą się
ryzykiem – potencjalnymi zyskami i kosztami
• Ustala się różną stawkę godzinową w zależności od
szybkości zakończenia projektu:
- Wcześniej – dostawca przepracuje mniej ale po wyższej stawce
godzinowej (klient sumarycznie zapłaci mniej)
- Na czas – jak w standardowym kontrakcie
- Później – dostawca przepracuje więcej ale po niższej stawce (klient
zapłaci więcej)
• Jeśli projekt się wydłuży to obie strony tracą pieniądze i będą
niezadowolone – wykonawca przeznaczy więcej zasobów po
niższej stawce a klient musi zapłacić więcej
2014-04-29Łukasz Rzepecki
43
44. Metodyki zwinne
Pakiety o stałej cenie
• Ustalenie stałej ceny za poszczególne fragmenty projektu
• Łagodzi ryzyko niedoszacowania i przeszacowania poprzez
zawężanie zakresu pracy i kosztów do poszczególnych
modułów
• Dostawca ma prawo reestymować pozostałe pakiety, gdy
pojawiają się nowe informacje lub nowe ryzyka
• Dostawca nie musi wliczać dużego marginesu w budżecie na
ryzyko, gdyż jest ono podzielone na mniejsze pakiety
• Klient może również wprowadzać zmiany do
nierozpoczętych pakietów i ew. zmieniać priorytety lub
zakres prac
2014-04-29Łukasz Rzepecki
44
46. Metodyki zwinne
Narzędzia
• Klasyczne harmonogramy (Gantt)
- Są skomplikowane i nieprzyjazne – nieczytelne, trudne do zmiany
- Ograniczają liczbę osób, które mają na nie wpływ
- Zwykle PM aktualizuje harmonogram sam dla siebie
- Narzucają sposób i dokładność raportowania
• Narzędzia zwinne (np. tablice zadań i Kanban)
- Nie zapewniają integralności danych i udokumentowania przebiegu
prac – ale czy to kiedykolwiek było potrzebne?
- W niektórych środowiskach niezbędne jest prowadzenie równolegle
sformalizowanej dokumentacji
- Są zrozumiałe przez wszystkich i dostępne dla wszystkich
- Ułatwiają prace grupową i wymianę informacji, są przyjazne
2014-04-29Łukasz Rzepecki
46
47. Metodyki zwinne
Limitowanie WIP
• Duże poziomy “pracy w toku” powodują szereg problemów:
- Konsumują zainwestowane pieniądze i nie przynoszą żadnych korzyści (zwrotu z
inwestycji)
- Ukrywają wąskie gardła i problemy z wydajnością (gdy wszystko jest w toku nie
wydać gdzie jest faktycznie problem – na jakim etapie pracy a wszyscy są zajęci)
- Zwiększają ryzoko konieczności wykonania dużej części pracy od nowa (np.
zmiany wpływające na dużą liczbę WIP)
• Celem metodyk zwinnych jest eliminowanie WIP
• Jedną z metod jest stosowanie tablic Kanban, które limitują ilość pracy
w projekcie na różnych etapach
• Celem jest optymizacja przepustowości w projekcie a nie
wykorzystania zasobów!
• Prawo Little – czas realizacji zadań jest proporcjonalny do rozmiaru
kolejki zadań w toku
2014-04-29Łukasz Rzepecki
47
50. Metodyki zwinne
Weryfikowanie wartości
• Rezultaty projektów IT są nieuchwytne, nienamacalne
• Bardzo często odbiorca informacji inaczej ją interpretuje (występuje
luka semantyczna)
- Istotne jest zidentyfikowanie luki jak najwcześniej aby wyeliminować ryzyko
wykonywania pracy od nowa
• W weryfikowaniu wartości dla klienta pomocne jest porządkowanie
co iterację pozostałych wymagań – daje to obraz co jest istotne dla
klienta i jaka wg niego jest definicja sukcesu
• Częste demonstracje wykonanych funkcjonalności są kluczowe w
projektach IT
- Dopiero wtedy pojawiają się prawdziwe wymagania: IKIWISI
(I’ll Know It When I See It)
- Eliminują lukę semantyczną
2014-04-29Łukasz Rzepecki
50
52. Metodyki zwinne
Analiza luk jakości
Analiza luk jakości – przykład dla fi rmy
opracowującej projekty
2014-04-29Łukasz Rzepecki
52
Jaka jest luka jakości gdy
specyfikacja powstaje wiele
miesięcy przed realizacją
projektu i/lub tworzy ją
wręcz inny podmiot niż
wykonawca (np. SIWZ)?
54. Metodyki zwinne
Wartość wypracowana (Earned Value)
• Krzywa-S – pokazuje wydatki w projekcie (np. nakład pracy
w czasie) ale nie postęp wykonania projektu
• Wykres Gantta pokazuje postęp w harmonogramie ale nie
stopień wykorzystania budżetu
• Wartość wypracowana (EV) – zaakceptowane prace
- Umożliwia porównanie bieżącej wydajności (zrealizowanej pracy)
do zaplanowanej, w określonym punkcie czasu
- Kluczowa jest jakość wstępnego planu (wartość wymagań)
- Uwaga! W projektach zwinnych plany się zmieniają i utrudniają
wykorzystanie metody EV do weryfikowania wydajności pracy ale
jest to dobre narzędzie do wizualizacji i prognozowania
2014-04-29Łukasz Rzepecki
54
56. Metodyki zwinne
Wykres skumulowanych przepływów
(CFD)
• Wykres warstwowy pokazujący na jednym wykresie
całkowitą pracę w projekcie, na którą składają się:
- Praca pozostała do wykonania (backlog produktu)
- Praca w toku (WIP)
- Praca zakończona (EV)
• Wykres pomaga też oszacować długość cyklu realizacji
zadań poprzez analizę wartości pracy w toku (zgodnie z
prawem Little są to wartości proporcjonalne)
2014-04-29Łukasz Rzepecki
56
58. Metodyki zwinne
Wąskie gardła i teoria ograniczeń
• Wykres CFD pracy w toku można podzielić na
poszczególne aktywności i uszeregować warstwy wg
kolejności działań
• Jeśli któryś z obszarów się rozszerza, to znaczy, że
wąskie gardło jest w warstwie poniżej
• Umożliwia to wykrycie problemu w skali całej
organizacji bez drobiazgowego analizowania każdego
obszaru
2014-04-29Łukasz Rzepecki
58
60. Metodyki zwinne
Wykres spalania ryzyka
• Na początku projektu tworzy się listę ryzyk, analogicznie do
product backloga
• Zaangażowani powinni być wszyscy interesariusze i zespół
• Dla każdego ryzyka określa się:
- Koszt jego wystąpienia (wartość finansowa lub w skali punktowej,
np. mały 1 – duży 3)
- Prawdopodobieństwo wystąpienia (procentowo lub również w skali,
np. 0-3)
- Sumarycznie każde ryzyko ma określoną wartość (np. 0-9)
• Co iterację lub ustalony okres czasu (np. miesięcznie)
dokonuje się weryfikacji ryzyk i rysuje wykres spalania
ryzyka – analogicznie jak burndown chart dla wymagań
2014-04-29Łukasz Rzepecki
60
63. Metodyki zwinne
Interesariusze projektu
• To wszystkie osoby i grupy, na które będą miały wpływ na projekt
oraz których projekt będzie dotyczył
• W projektach pracownika wiedzy rezultaty prac są często
nienamacalne i nieuchwytne – prowadzi to do powstawania luki
semantycznej w zrozumieniu przez wykonawcę intencji klienta
• Zasady angażowania interesariuszy:
- Istotne jest zidentyfikowanie odpowiednich interesariuszy, którzy pomogą w
zrozumieniu wymagań i celów
- Zaangażowanie powinno być widoczne i monitorowane
- Aktywne zarządzanie zainteresowaniem – świętowanie postępów
- Częste dyskusje co oznacza “done” – eliminacja luki
- Eksponowanie progresu (dema) i możliwości oraz limitów zespołu
- Dyskutowanie estymat i prognoz – prawdziwa wydajność projektu
2014-04-29Łukasz Rzepecki
63
64. Metodyki zwinne
Wspólne zrozumienie
Eliminowanie luki semantycznej poprzez:
• Makiety – szybki sposób na wizualizację produktu i zrozumienie
przez wszystkich interesariuszy produktu
• Personas – przykładowi interesariusze projektu, np. różni
użytkownicy (opis, wartości dla nich, zainteresowania)
• Historyjki, backlog
- Często mają formę “Jako <Rola> Chcę <Funkcjonalność> Aby <Korzyść>”
(ważne kto i dlaczego) lub Given, When, Then
- Powinny być INVEST, tzn. Independent, Negotiable, Valuable, Estimatable,
Small, Testable
- Obejmują Pionowy zakres funkcjonalny
- Mogą być grupowane pionowo w Features a te w Epics jak również
poziomo w Themes oraz planowane w Story Maps
2014-04-29Łukasz Rzepecki
64
71. Metodyki zwinne
Ludzie i interakcje ponad procesy i
narzędzia
• COCOMO (I, II) – popularny model estymacji
oprogramowania
• 7 czynników mających wpływ na koszt, a w nich:
- Czynniki ludzkie – 33%
- Produkt – 10%
- Procesy i narzędzia – 3%
• Wpływ czynników ludzkich jest 10x większy niż wpływ
stosowanych (lub nie) procesów i narzędzi
• Sprawny zespół jakoś sobie poradzi bez żadnych procesów i
narzędzi, najlepsze T&T nic nie poradzą w sytuacji
niedoświadczonego i niezgranego zespołu
2014-04-29Łukasz Rzepecki
71
72. Metodyki zwinne
Przywództwo adaptacyjne
Formowanie się zespołów zwykle obejmuje cykl:
• Formowanie (forming) – grupa uczy się o sobie
- Kierowanie (directing) – co jest do zrobienia, pomoc w problemach
• Burza (storming) – wewnętrzna rywalizacja w pseudozespole
- Coaching – główny cel, to rozwiązywanie konfliktów
• Normowanie (norming) – potencjalny zespół, uczy się sprawnej
współpracy ze sobą
- Wsparcie (supporting) – zespół pracuje wg własnych reguł, rola
wspierająca, egzekfowanie reguł zespołu, stawianie wysokich celów
• Sprawne działanie (performing) – zespół pracujący jak jeden,
autonomiczny, umocowany, samozarządzający i regulujący się
- Delegowanie (delegating) – lider stawia zespołowi wyzwania a nie zadania,
problemy do rozwiązania wewnętrznie przez zespół
2014-04-29Łukasz Rzepecki
72
74. Metodyki zwinne
Inteligencja emocjonalna
• To zdolność do zaóważania (identyfikowania), oceny
(szacowania) i wpływania na emocje: własne, innych, grup
• Dobra metoda na elastyczne zarządzanie i przywództwo
zmiennymi zespołami
Etapy:
• Samoświadomość (self: recognize)
- Zrozumienie własnych emocji (co mnie denerwuje, frustruje, cieszy,
zadowala itp.) i umiejętność ich prawidłowej oceny
- Pewność siebie - mamy wpływ na własne emocje i na to jak na nie
reagujemy (np. czy pozwalamy aby coś nas dalej denerwowało czy
jakoś zareagujemy)
2014-04-29Łukasz Rzepecki
74
75. Metodyki zwinne
Inteligencja emocjonalna
• Samokontrola (self: regulate)
- Sumienność
- Zdolność adaptacji
- Motywacja
• Nastrój i zachowanie liderów wpływa na wszystkich innych!
• Świadomość społeczna (others: recognize)
- Empatia - rozumienie otoczenia (np. kiedy jakieś problemy mają
człokowie zespołu)
• Umiejętności społeczne (others: regulate)
- Wpływanie, inspirowanie, przewodzenie i rozwijanie innych tak aby
pomóc w ich pracy i współpracy zespołowej
2014-04-29Łukasz Rzepecki
75
76. Metodyki zwinne
Empowerment
Samo-organizujące się zespoły:
• Wykorzystanie wiedzy zespołu jak najlepiej wykonać daną pracę i
naturalnej zdolniści ludzi do rozwiązywania złożonych problemów
• Przedstawianie celów a nie zadań wraz ze sposobem ich
wykonania (to zespoł jest ekspertem)
• Pozwolenie zespołom na własną organizację codziennej pracy (w
ramach podstawowych reguł panujących w organizacji)
• Delegowanie odpowiedzialności za sukces projektu na zespół w
celu osiągnięcia założonych celów (downward serving)
• Celem lidera jest ochrona przed czynnikami zewnętrznymi,
eliminowanie przeszkód, komunikowanie wizji, wsparcie…
2014-04-29Łukasz Rzepecki
76
77. Metodyki zwinne
Empowerment
Samo-zarządzające się zespoły:
• Zespół wytwarza wewnętrzne normy i podejmuje lokalne
decyzje (technologia, priorytety, estymacje)
• Zespól ma duża dowolność – ale w granicach sprintu!
• Złe decyzje (np. technologiczne, złe estymaty) są
dyskutowane na retrospekcji w celu zapobiegnięcia
podobnym sytuacjom w przyszłych sprintach
• Samoorganizacja i samozarządzanie to tylko cele!
• Na początku projektu żaden zespół taki nie jest, może to być
długoterminowym celem zespołu postawionym w fazie
normowania się zespołu.
2014-04-29Łukasz Rzepecki
77
78. Metodyki zwinne
Budowanie wydajnych zespołów
• Zespół powinien być niewielki (do 12 osób) co ułatwia
budowanie wzajemnych relacji i bezpośrednią komunikację
• Członkowie zespołu powinni mieć komplementarne
umiejętności i rozpowszechniać je w zespole (umożliwienie
zamiany ról, wykonywanie różnych zadań)
• Cele członków zespołu powinny być spójne (zrównane) z
celami projektu
- Indywidualne zobowiązanie do osiągnięcia wspólnego celu
- Świadomość każdego jak cele postawione grupie będą mierzalne i
w jaki sposób będą realizowane przez zespół
- Wzajemna odpowiedzialność członków zespołu za rezultaty
2014-04-29Łukasz Rzepecki
78
79. Metodyki zwinne
Motywowanie zespołów
• Wynagrodzenie jest za pojawianie się w pracy
• Produktywność w pracy każdego jest inna i zależy w
istotnym stopniu od zmotywowania i zaangażowania
• Etapy produktywności:
- Podważanie i opór (-)
- Pasywna zgodność (0)
- Aktywne uczestnictwo (+)
- Oddanie i poświęcenie (++)
- Pasja i wprowadzanie innowacji (+++)
• Kluczowe jest zrównanie celów indywidualnych członków
zespołu z celami projektu
2014-04-29Łukasz Rzepecki
79
81. Metodyki zwinne
Motywowanie zespołów
• Zrozumienie zarówno osobistych czynników motywujących (i
demotywujących) poszczególne osoby jak i cały zespół (np.
poprzez rozmowy 1-1)
• W większości projektów jest możliwość zaspokojenia
niektórych celów osobistych, choćby tymczasowo
• Wyjaśnienie przez kogoś z wysokiego szczebla organizacji
dlaczego projekt jest ważny dla firmy, jakie są związane z
nim nadzieje (wizja) istotnie może wpłynąć na
zaangażowanie
• Istotne jest świętowanie sukcesów zespołów
• Ew. nagrody dla całych zespołów a nie indywidualne
2014-04-29Łukasz Rzepecki
81
83. Metodyki zwinne
Codzienne stand-upy
• To kluczowy element w praktykach zwinnych
• Krótkie (max. 10-15 min.) codzienne spotkanie mające na
celu wyeliminowanie konieczności innych spotkań
• To spotkania zespołu dla zespołu (nie dla kierownictwa)
• Każdy członek zespołu po kolei odpowiada na 3 pytania:
- Co zrobiłem od poprzedniego spotkania?
- Co planuję zakończyć dzisiaj?
- Czy są jakieś blokady lub zależności utrudniające pracę?
• Wszelkie rozpoczynające się dyskusję (np. jak coś
rozwiązać, sprawy techniczne) należy odłożyc na bok (np.
indywidualna rozmowa zaangażowanych osób po stand-
upie)
2014-04-29Łukasz Rzepecki
83
84. Metodyki zwinne
Coaching i mentoring
• Pomaga zespołom utrzymać kierunek działań,
przezwyciężać problemy i ciągle polepszać
umiejętności
• Powinien być realizowany równolegle indywidualne i z
całym zespołem
• Coaching zespołowy ma miejsce głównie na granicach
sprintu (planowanie, przegląd/demo, retrospekcja)
• Coaching indywidualny głównie w trakcie sprintu
- Spotkania 1-1 umożliwiające prywatną rozmowę na temat ew.
problemów i skarg – szczere z pozytywnym nastawieniem i
poszanowaniem do zgłaszanych uwag
2014-04-29Łukasz Rzepecki
84
85. Metodyki zwinne
Coaching i mentoring
Pomocne działania:
• Spotkanie się w pół drogi – nie naciskać do osiągnięcia
bezpośrednio punktu końcowego (“bo tak ma być”) ale
wymyślać rozwiązania pośrednie
• Zagwarantowanie poufności – poprzez jej dochowanie
• Współpraca z innymi lidierami – mająca na celu
rozwiązywanie problemów między zespołami i spójną
komunikację w organizacji
• Pozytywne traktowanie – nawet jeśli kogoś nie lubimy
należy to odłożyć na bok aby pomóc danej osobie
2014-04-29Łukasz Rzepecki
85
86. Metodyki zwinne
Burza mózgów
Pomagają zidentyfikowac różne możliwości, rozwiązywać
problemy, znajdywać drogi do ulepszeń:
• Quiet writing – każdy członek zespołu w określonym czasie
spisuje pomysły indywidualne, eliminuje wpływ i
oddziaływanie innych
• Round-Robin – każdy po kolei zgłasza pomysł, zesół musi
być komfortowy z dzieleniem się pomysłami przed sobą
• Free-for-All – każdy kto chce zgłasza spontanicznie nowy
pomysł, stymuluje dyskusję, zespołowe wetowanie i
rozwijanie pomysłów
2014-04-29Łukasz Rzepecki
86
87. Metodyki zwinne
Burza mózgów
Pomysły należy następnie uporządkować:
• MoSCoW – technika oparta o wartość:
- Must have
- Should have
- Could have
- Would like to have, but not this time
• Głosowanie – każdy dostaje określoną liczbę głosów (dla
każdego w wysokości ok. 20% z liczby pomysłów) i
przydziela pomysłom głosy wg własnego uznania (można
przydzielić więcej niż 1 głos dla danego pomysłu)
2014-04-29Łukasz Rzepecki
87
88. Metodyki zwinne
Przestrzeń pracy
• Metodyki zwinne rekomendują interakcje face-to-face oraz
kolokowanie całych zespołów we wspólnym miejscu pracy,
co poprawia pracę grupową i dzielenie się informacjami
• Caves and common – otwarta przestrzeń pracy oraz
miejsca na prywatne rozmowy lub tymczasową pracę w
odizolowaniu umożliwiającą skupienie się i koncentrację
• Komunikacja osmotyczna – to użyteczne informacje
przepływające mimowolnie między członkami zespołu
podczas zwykłych konwersacji
• Milcząca wiedza (tacit knowledge) – niepisana wiedza ale
funkcjonująca w zespole/firmie (na głośno zadane pytanie
ktoś z otoczenia prawdopodobnie będzie znał odpowiedź)
2014-04-29Łukasz Rzepecki
88
89. Metodyki zwinne
Zespoły rozproszone
• To standard, nie wyjątek (ok. połowa zespołów zwinnych jest
rozproszona – tzn. przynajmniej 1 osoba pracuje zdalnie)
• Niezbędne znalezienie substytutów dla korzyści z
współpracy face-to-face, komunikacji osmotycznej i milczącej
wiedzy oraz lepszych relacji w zespole
• Wykorzystanie narzędzi komunikacji on-line
• Przynajmniej pierwsze spotkanie powinno obejmować cały
zespół
• Problem - osoby poza zasięgiem wzroku łatwiej ignorować,
mają mniejszy wpływ i poważanie
2014-04-29Łukasz Rzepecki
89
90. Metodyki zwinne
Narzędzia
• Low-Tech, High-Touch
- Wykorzystanie realnych namacalnych i prostych przedmiotów
polepsza komunikację i pracę grupową
- Niechęć do korzystania ze skomplikowanych narzędzi
- Najczęściej wykorzystywane: tablica z zadaniami (to do, doing,
accepted), user stories zapisane na karteczkach, karty do
planning pokera
• Narzędzia on-line
- Pomocne przy pracy w zespołach rozproszonych
- Np. wirtualna tablica, strony wiki, webowe systemy zarządzania
2014-04-29Łukasz Rzepecki
90
92. Metodyki zwinne
Tematyka – narzędzia i techniki
• Koncepcje planowania
- Timeboxing
- Stopniowe doprecyzowanie
- Proces na miarę
- Minimalna funkcjonalność nadająca się do sprzedaży (MMF)
• Estymacja
- Wideband Delphi, Planning Poker
- Czas idealny
- Szacowanie porównawcze, Story Points
- Estymacja przez podobieństwo
• Planowanie zwinne
- Planowanie iteracji i wydań
2014-04-29Łukasz Rzepecki
92
93. Metodyki zwinne
Tematyka – wiedza i umiejętności
• Koncepcje planowania
- Analiza oparta o wartość
- Dekompozycja i porządkowanie oparte o wartość
- Gry Agile
• Estymacja
- Szacowanie czasu, budżetu i kosztów
- Zasady kosztorysowania
• Planowanie zwinne
- Karta projektu
2014-04-29Łukasz Rzepecki
93
95. Metodyki zwinne
“Mapa nie jest terytorium” (A.
Korzybski)
• Celem metod zwinnych jest eliminacja pracy nie
przynoszącej bezpośrednio wartości biznesowej
• Planowanie z tego punktu widzenia jest trwonieniem
czasu (waste – odpad)
• Celem każdej metodyki jest eliminacja odpadów
• Z punktu widzenia wydajności najlepiej byłoby zaplanować
projekt w całości raz i do tematu nie wracać
• Jest to nieefektywne dla projektów angażujących w
większości tzw. pracowników wiedzy (knowledge worker)
• Powinno się zaplanować replanning i zaakceptować, że
wstępny plan na pewno będzie zawierał wady
2014-04-29Łukasz Rzepecki
95
96. Metodyki zwinne
Timeboxing
• Dzielenie czasu pracy na krótkie etapy o stałej długości
• Zespół bierze do wykonania w iteracji tyle pracy ile uważa, że będzie
w stanie wykonać (zwykle na 2 tygodnie)
• Niewykonana praca wraca na koniec iteracji do backloga
• Pomaga w ocenie rezultatów, zbierania informacji zwrotnych,
kontrolowaniu kosztów i ryzyka
• Architectural spike – okres czasu dedykowany na PoC
• Narzędzie służące motywowaniu i skupieniu się na zakańczaniu pracy
• Ludzie mają skłonność do rozpraszania się i wykonywania wielu
rzeczy naraz nieefektywnie – analogicznie w projektach
• Pomaga walczyć z prawem Parkinsona (praca zajmie cały
przydzielony czas) i syndromem studenta (praca na deadline)
2014-04-29Łukasz Rzepecki
96
97. Metodyki zwinne
Stopniowe doprecyzownie (progressive
elabor.)
• Proces uszczegółowania gdy pojawiają się nowe
informacje i detale
• Na początku projektu planuje i estymuje się wstępnie
pracę do wykonania
• Szczegółowo planuje się tylko najbliższe iterację,
kolejne zawierają coraz mniej detali
• Poziom czasu poświęconego na fazy projektu:
- Wstępne planowanie – 10-15%
- Wydanie wersji (iteracje) – 80-85%
- Zamknięcie – 5%
2014-04-29Łukasz Rzepecki
97
98. Metodyki zwinne
Dopasowanie procesu (process
tailoring)
• Ma na celu indywidualne dopasowanie procesów do
aktualnej sytuacji w projekcie i w organizacji
• Zmiany następują w efekcie retrospekcji w projekcie
• Spotkanie na koniec iteracji z zespołem i biznesem mające
na celu odpowiedź na 3 pytania:
- Co idzie dobrze?
- Które obszary wymagają ulepszenia?
- Co powinno być realizowane w inny sposób?
• Problemy są rozwiązywane poprzez burzę mózgów
• Rozwiązania są testowane i analizowane przez kilka iteracji
a następnie wdrażane na stałe lub zmieniane
2014-04-29Łukasz Rzepecki
98
99. Metodyki zwinne
Minimally Marketable Feature (MMF)
• Każde wydanie oprogramowania powinno być sensowne,
użyteczne i wartościowe dla klienta
• MMF oznacza rozwiązanie kompletne na tyle aby było
użyteczne dla klientów/użytkowników ale na tyle małe, że nie
reprezentuje całego projektu
• Udostępnia biznesowi korzyści zanim cały projekt będzie
gotowy
• Umożliwia szybszy zwrot z inwestycji podczas gdy zespół
kontynuuje rozwijanie kolejnych funkcjonalności
• Np. ołówek: MMF – pozostawia ślad na papierze, dodatkowa
funkcjonalność – gumka do mazania itp.
2014-04-29Łukasz Rzepecki
99
100. Metodyki zwinne
Analiza oparta o wartość
• Na każdym etapie projektu zadajemy pytania:
- Jaka jest wartość biznesowa danej funkcjonalności?
- Które funkcjonalności mają najwyższą wartość biznesową?
• Następnie porządkujemy pracę tak aby dostarczyć w
pierwszej kolejności funkcjonalności o najwyższej wartości
biznesowej
• Należy wziąść pod uwagę również koszt ich wytworzenia
(element o wartości 5 ale kosztujący 4 ma niższą wartość
biznesową od elementu o wartości 3 kosztującego 1)
• Uwaga na zależności – realizacja zadań o niskiej wartości
może być niezbędna, żeby zrealizować te o wyższej
2014-04-29Łukasz Rzepecki
100
101. Metodyki zwinne
Dekompozycja i porządk. oparte o
wartość
• To proces wydobywania wymagań od biznesu,
porządkowania oraz włączania w proces produkcyjny
• Kick off – powinien obejmować wysiłek na zdefiniowanie
wizji projektu na wysokim poziomie oraz wyrównanie wśród
wszystkich interesariuszy wspólnej misji, celów i kryteriów
sukcesu (tak samo rozumianych)
• Warsztaty – mają na celu wyodrębnienie z wizji
potencjalnych wymagań (candidate feature list)
• Lista jest następnie porządkowana wg wartości biznesowej i
ryzyk oraz poddana iteracyjnemu procesowi realizacji
• Następuje dalsze stopniowe doprecyzowanie wymagań
2014-04-29Łukasz Rzepecki
101
102. Metodyki zwinne
Dekompozycja i porządk. oparte o
wartość
• W metodykach zwinnych nie doprecyzowuje się dokładnie
wymagań z góry, są “gruboziarniste” – doprecyzowanie
następuje w trakcie postępu projektu
• Pomaga to utrzymać projekt zbalansowany, bez
nadmiernego (niepotrzebnego) wykonania w niektórych
obszarach
• Opóźnia się decyzje o detalach implementacji do ostatniej
chwili (last responsible moment) – nie wykonuje się
funkcjonalności, które mogą (prawie na pewno) się zmienić
w wyniku nowych informacji lub zmian
• Zmiany wprowadzane wcześniej kosztują mniej
2014-04-29Łukasz Rzepecki
102
103. Metodyki zwinne
Gry Agile
Remember the Future
• Badania wykazały, że jest istotna różnica gdy poprosi się o
odpowiedź na pytanie “Co system powinien robić?” (zwykle
następuje generowanie kompletnej listy potencjalnie
niepotrzebnych funkcjonalności) od poproszenia o
wyobrażenie sobie punktu w przyszłości – po releasie
zakończonym z sukcesem – i “przypomnienie sobie” co
zostało wykonane w ramach projektu
• Każdy interesariusz przez 20 minut spisuje na karteczkach
wymagania, dzieki którym udało się zrealizowac projekt
• Kolejne 20 minut wspólnie grupują i wyjaśniają sobie
wymagania oraz eliminują duplikaty
2014-04-29Łukasz Rzepecki
103
104. Metodyki zwinne
Gry Agile
Prune the Product Tree
• Gra pomaga w zrozumieniu porządkowania i zdefiniowania
kolejności prac
• Wykorzystanie burzy mózgów w celu narysowania drzewa
wymagań i funkcjonalności oraz zależności
• Pień reprezentuje to co wiemy lub zostało już wykonane
• Gałęzie to nowe funkcjonalności lub wymagające
zaprojektowania
• Wymagania zależne umieszcza się dalej na gałęzi lub wyżej
drzewa
2014-04-29Łukasz Rzepecki
104
105. Metodyki zwinne
Gry Agile
Speedboat
• Gra pomaga w wyodrębnieniu ryzyk i możliwości
• Niektórzy potrzebują możliwości i sposobu na
wyartykułowanie swoich wątpliwości przed
przystąpieniem do pracy
• Kiedy ich obawy zostaną zaóważone i “zapisane” będą
mogli z mniejszym obciążeniem przystąpić do dalszej
pracy i lepiej współpracować
2014-04-29Łukasz Rzepecki
105
108. Metodyki zwinne
Estymacja
• Jest niezbędna do szacowania rozmiaru i akceptowania
projektów, ustalania pracy możliwej do wykonania w
ramach wydania bądź iteracji, wyliczeń ROI/IRR/NPV
• Powinna być określana jako przedziały uwzględniające
niepewność
• Wstępne szacunki są najmniej dokładne, należy
reestymować projekt (czas i koszt) cały czas w jego
trakcie
• Nie powinna się tym zajmować tylko 1 osoba lecz cały
zespół, który jest/będzie zaangażowany w pracę
2014-04-29Łukasz Rzepecki
108
109. Metodyki zwinne
Wideband Delphi
• Metoda iteracyjna, adaptacyjna oparta o zespół ekspertów
• Każdy członek zespołu estymuje anonimowo
- Eliminacja skłonności do zgadzania się z liderem i przyjmowania opinii innych zamiast własnych
ocen danego problemu
• Sesja zaczyna się od podziału całego projektu na fragmenty (estymowane osobno),
specyfikuje się problem, przyjmuje założenia i ograniczenia projektu (w tym minimalne)
• Definiuje się wspólne jednostki estymacji i kryteria zakończenia procesu wyceny (np.
różnice w wycenach max. +/- 20%)
• Iteracja zaczyna się od dyskusji nt. złożoności problemu
• Każdy na kartce zapisuje zadania i ich estymaty wg uznania
• Na koniec iteracji sumy estymat są zapisywane na tablicy (bez wskazywania autorów)
• Jeśli są zbyt duże różnice robi się kolejną iterację
• Na koniec tworzy się wspólną główną listę zadań z wszystkich
2014-04-29Łukasz Rzepecki
109
110. Metodyki zwinne
Planning Poker
• Rozwinięcie poprzedniej metody
• Oparta na kartach z wartościami (często liczby
Fibonacciego: 1, 2, 3, 5, 8, 13, 21, 34) wyrażającymi
czasochłonność mh/md lub inne jednostki np. Story Points
• Wymagania są czytane kolejno i każdy jednocześnie głosuje
• Przyjmuje się wycenę większości, drobne różnice się pomija,
jeśli ktoś miał zdecydowanie odmienne zdanie jest
dyskutowane a głosowanie jest powtarzane aż do
osiągnięcia konsensusu przez zespół
2014-04-29Łukasz Rzepecki
110
111. Metodyki zwinne
Czas idealny
• Zwykle praca w ciągu dnia jest rozpraszana i
przerywana przez inne aktywności, nie związane
bezpośrednio z wykonaniem zadania (spotkania, e-
maile, kawa itp.)
• Szacowanie wg czasu idealnego zakłada pominięcie
wszelkich rozpraszających czynników, tzn. pracę
skupioną wyłącznie nad danym zadaniem i przy
założeniu, że nie ma żadnych innych przeszkód do jego
wykonania
2014-04-29Łukasz Rzepecki
111
112. Metodyki zwinne
Szacowanie porównawcze, Story Points
• Pomaga rozwiązać problem ludzi z dokładnym szacowaniem
całkowitego czasu pracy jak również zwalczyć niechęć do
skomplikowanego procesu wycen
• Łatwiej jest opisywać zjawiska przez porównanie do innych
znanych (np. coś jest 2x większe od…) niż określać je dokładnie
• Bazuje na pracy już wykonanej przez zespół w projekcie
(porównanie do estymat zakończonych zadań)
• Pozwala łatwiej pogodzić się z niewłaściwymi estymacjami (jeśli
wycena nie była w godzinach to przekroczony czas pracy nie
informuje wprost, że estymacja była błędna)
• Zmiana wyceny może nastąpić zawsze gdy tak uzna zespół, w
szczególności gdy pojawiają się nowe informacje
2014-04-29Łukasz Rzepecki
112
113. Metodyki zwinne
Szacowanie porównawcze, Story Points
• Definicja SP wychodzi z zespołu projektowego, to on ustala
co oznacza 1SP (np. stworzenie prostego ekranu aplikacji
lub 1 dzień idealny), SP między zespołami i w różnych
projektach mogą oznaczać co innego
• Estymaty w SP powinny być all-inclusive (zawierać testy,
refactoring itp.), nie powinno wprowadzać się mnożników
• Suma estymat szczegółowych zadań/wymagań może się
różnić od wstępnej ogólnej wyceny wymagania/wydania
• Estymaty w SP powinny być relatywne (4x5SP = 20x1SP) a
nie określać stopnia skomplikowania
• Powinno się brac pod uwagę 3 aspekty: złożoność problemu,
wymagany nakład pracy oraz ryzyko
2014-04-29Łukasz Rzepecki
113
114. Metodyki zwinne
Estymacja przez podobieństwo (affinity est.)
• Proces grupowania wymagań w kategorie/kolekcje, np. wg
ich estymat
• Daje możliwość łątwiejszego porównania czy w danej
kategorii wymagania są faktycznie o porównywalnej
wielkości
• Można do tego wykorzystać tablicę podzieloną na pionowe
kolumny, z których każda określa estymację lub jakiś
przedział
• Po wycenie nowego wymagania lub rewycenie porównuje się
czy jego wielkość faktycznie wydaje się być podobna do
innych w danej kolumnie – możliwość dyskusji
2014-04-29Łukasz Rzepecki
114
115. Metodyki zwinne
Szacowanie czasu, budżetu i kosztów
• Określenie rozmiaru projektu – np. Planning Poker, w czasie
idealnym lub innych jednostkach (SP)
• Skalkulowanie wymaganego nakładu pracy w
godzinach/dniach/tygodniach/miesiącach roboczych –
wymaga przeliczenia estymat z uwzgl. dostępności zasobów
(w tym – określenie stosunku godzina robocza/idealna dla
każdego z członków zespołu)
• Zaplanowanie harmonogramu z uwzględnieniem
wymaganych dni roboczych i rozmiaru zespołu
• Wyliczenie kosztu projektu wg stawek wynagrodzeń oraz
innych kosztów + rezerwa na ryzyko i niepewność
2014-04-29Łukasz Rzepecki
115
116. Metodyki zwinne
Zasady kosztorysowania
• Do określenia kosztu projektu należy wyliczyć koszt każdego
z członków zespołu – np. roczne wynagrodzenie (koszt) /
liczba tygodni w roku (52)
• Do kosztu należy doliczyć inne obciążenia firmy (czynsz,
sprzęt, administracja)
• Powinno się unikać określania dokładnej ceny lecz podawać
przedziały, na różnych etapach projektów IT inne:
- Wizja – cena: 25-400% / harmonogram (czas): 60-160%
- Definicja, zakres projektu – 50-200% / 80-125%
- Specyfikacja wymagań, ident. historyjek – 66-150% / 85-115%
- Specyfikacja projektowa, gotowy backlog – 80-125% / 90-110%
- Dokładna specyfikacja, 50% wykonane – 95-105% / 98-105%
2014-04-29Łukasz Rzepecki
116
118. Metodyki zwinne
Planowanie zwinne
Istotnie różni się od planowania tradycyjnego:
• Wersje testowe i demo ujawniają prawdziwe wymagania, które
wymagają replanningu
- Zamiast tworzyć szczegółowe specyfikacje lepiej zbudować prototyp aby lepiej
zrozumieć problem i wykorzystać go do dalszego planowania
• Planowanie zwinne, to większy wysiłek w trakcie projektu niż przed
jego rozpoczęciem
- Ważniejsze jest określenie ryzyk i niepewności
- Uszczegóławianie w trakcie sprzyja lepszemu dopasowaniu wraz z nowymi
informacjami
- Zwykle planowanie zajmuje sumarycznie więcej czasu od tradyc.
- Eliminuje ryzyka błędnego zaplanowania już na początku
• Normą są zmiany w trakcie realizacji projektu
- Podejście kierowanego pocisku zmierzającego do ruchomego celu
2014-04-29Łukasz Rzepecki
118
120. Metodyki zwinne
Karta projektu
• To pierwszy i podstatowy dokument projektowy
• Odpowiada na 5 pytań (W5H):
- O czym jest projekt – wizja, misja, cele
- Dlaczego jest realizowany – racjonalne wyjaśnienie biznesu
- Kiedy się rozpocznie i zakończy – plan
- Kto będzie zaangażowany – lista interesariuszy
- Gdzię będzie realizowany – fizycznie i technicznie
- Jak będzie realizowany – opis podejścia, zasady realizacji
• Okeślenie przez interesariuszy celów projektu w 140 zn.
• Nie ma standardów – może to być zarówno 1 strona jak i
skomplikowany szczegółowy dokument, ważne aby był
2014-04-29Łukasz Rzepecki
120
121. Metodyki zwinne
Planowanie iteracji i wydań
• Projekty zwinne dzielą się na wydania i iteracje
• Wydanie to zbiór iteracji, których realizacja skutkuje
dostarczeniem wartościowego produktu bieznesowi/klientowi
• Wydanie może byc uzależnione od terminu (deadline, np.
targi) lub osiągnięcia określonej funkcjonalności – w
zależności od tego, z wykorzystaniem informacji o prędkości
zespołu, szacujemy co uda się zrobić w danym czasie lub
kiedy osiągniemy daną funkcjonalność
• Do planowania wydań stosuje się Story Maps – podział
najpierw wg zależności a później funkcjonalności
2014-04-29Łukasz Rzepecki
121
122. Metodyki zwinne
Planowanie iteracji i wydań
• Planowanie iteracji robi zespół wybierając wymagania o
najwyższym priorytecie, które uda się zaimplementować,
przetestować i dostarczyć na koniec iteracji
• Istotne jest określenie głównych celów do osiągnięcia na koniec
iteracji z biznesem – klientem lub Product Ownerem (w celu
właściwego doboru wymagań)
• W przypadku Scruma, PO powinien przyjść na planning
przygotowany ze świeżo uporządkowanym backlogiem
- Pierwszą połowę spotkania PO opowiada o wymaganiach, które chciałby
zrealizować a zespół zobowiązuje się do wykonania określonych wymagań
w ramach swoich możliwości
- Przez drugą połowę spotkania zespół dzieli wymagania na zadania oraz
dyskutuje jak będą realizowane – powstaje sprint backlog
- Przypisywanie zadań do osób może być później i może się zmieniać
2014-04-29Łukasz Rzepecki
122
125. Metodyki zwinne
Czas cyklu
• Mierzy jak długo zajmuje wykonywanie zadań (od rozpoczęcia do
akceptacji)
• Jest blisko związany z pojęciem pracy w toku (Work in progress –
WIP)
• Duża liczba WIP wiąże się z problemami:
- Oznacza inwestycję w toku, z której nie ma zwrotu
- Ukrywa wąskie gardła i maskuje problemy z wydajnością
- Zwiększa ryzyko potencjalnych zmian – duża liczba niezaakceptowanych
wymagań w toku, mogących wpływać na siebie
• Długi czas cyklu zwiększa liczbę WIP – dlatego metody zwinne
dążą do jego skracania i dzielenia pracy na fragmenty
• Czas cyklu = WIP / przepustowość
2014-04-29Łukasz Rzepecki
125
126. Metodyki zwinne
Czas cyklu
• Pojęcie to jest użyteczne do analizowania wad i napraw
• Można niezależnie monitorować czas cyklu naprawy wad
• Im dłużej wady są nienaprawione tym są kosztowniejsze
• Kluczowe jest szybkie wykrywanie problemów na jak
najwcześniejszym etapie aby zredukować ryzyko
wykonywania pracy od nowa:
- Programowanie w parach
- Continuous integration
- Test-driven development
- Partycypacja interesariuszy
- Częste demonstracje produktu (opinie od biznesu/klienta)
2014-04-29Łukasz Rzepecki
126
127. Metodyki zwinne
Niewykryte wady (escaped defects)
• To wady, które nie zostały wykryte na etapie produkcji
ani kontroli jakości i przedostały się do oprogramowania
działającego produkcyjnie, ew. wykryte przez klienta
• Są najbardziej kosztowne do naprawy
• Monitorowanie liczby takich wad pojawiających się w
poszczególnych wydaniach może pomóc w ich
eliminacji w przyszłości
2014-04-29Łukasz Rzepecki
127
129. Metodyki zwinne
Standardy jakości
• Dotyczą tego co zespół będzie robił aby zapewnić jakość i
właściwą wartość produktu?
• Standardy mogą być spisane lub nieformalne w postaci
wymagań i wytycznych, za które zespół bierze
odpowiedzialność
• Źródła wiedzy o standardach jakości:
- Standardy formalne – spisane
- Monitorowanie, audyty
- Rozmowy i dyskusje
- Przeglądy (dema)
- Retrospekcje
2014-04-29Łukasz Rzepecki
129
130. Metodyki zwinne
Standardy jakości – praktyki
• Mierzenie jakości przez testy i akceptację biznesu/klienta
• Testy automatyczne
• Zapewnienie aby testowanie było częścią każdej iteracji
• Staranie się naprawy 90% wad w następnej iteracji
• Ujednolicenie rozumienia kryterów akceptacyjnych wśród
developerów, biznesu i ew. osób odpowiedzialnych za jakość
• Akceptacja naprawy wad nie przez developerów a biznes
• Współpraca osób wykrywających wady z developerami
mająca na celu umożliwienie powtórzenia błedu
• Monitorowanie liczby wad, rządań zmian i wyjaśnień oraz
utrzymania wskaźników w poziomach tolerancji
2014-04-29Łukasz Rzepecki
130
131. Metodyki zwinne
Przyczyny problemów
• Popełnianie błędów ludzkich
• Działania zachowawcze – zwłaszcza w przypadku wysokiej
niepewności, wykorzystanie dotychczasowej wiedzy, która
nie jest najoptymalniejsza do wykonania danego zadania
• Wynajdywanie nowych metod (narażonych na wady) zamiast
wykorzystania gotowych, sprawdzonych, re-używalnych
rozwiązań
• Przyzwyczajenie – unikanie zmian gdy są konieczne
• Brak konsekwencji we wdrażaniu nowych rozwiązań
2014-04-29Łukasz Rzepecki
131
133. Metodyki zwinne
Metody zapobiegania problemom
• Continuous Integration – zapobieganie problemom
wynikającym z częstego dołączania nowego kodu przez
różnych członków zespołu do repozytorium projektu
• Risk-Based Spike – krótkie ćwiczenie typu PoC mające na
celu przeanalizowanie sposobu rozwiązania problemu w celu
pomniejszenia ryzyka przed właściwą implementacją
• Test-Driven Development (TDD) – testy są pisane przed
kodem, wymaga zastanowienia się jak rozwiązanie będzie
testowane i jak ma działać, testy nie przejdą dopóki napisany
kod nie będzie spełniał założonych kryteriów
- Red Green Refactor (Red Green Clean)
2014-04-29Łukasz Rzepecki
133
134. Metodyki zwinne
Metody zapobiegania problemom
• Acceptance Test-Driven Dev. (ATDD) – przeniesienie testowania
z kodu na wymagania biznesowe, 4 etapy:
- Discuss – omówienie wymagań, kryteriów akceptacyjnych
- Distill – ustrukturyzowanie i wprowadzenie testów do narzędzia typu FIT
(Frmrk For Integrated Testing) lub FitNesse
- Develop – kodowanie i podpięcie kodu do testów
- Demo – końcowe testy akceptacyjne i demo produktu
• Częsta weryfikacja i walidacja – funkcjonuje na każdym poziomie
projektów zwinnych, np. programowanie w parach/code review,
testy jednostkowe, stand-upy, testy akceptacyjne, przegląd
iteracji/demo itp. – każde z tych działań ma na celu jak najszybcie
wykrycie i wyeliminowanie problemów
2014-04-29Łukasz Rzepecki
134
135. Metodyki zwinne
Rozwiązywanie problemów
3 fazy:
• Zebranie danych – mające na celu wspólny pogląd na problemy
- Timeline – zaznaczenie wydarzeń (+/-/!) na linii czasu i emocji zesp.
- Triple Nickels – 5 pomysłów x 5 iteracji w zespole na karteczkach
• Wnioski – przeanalizowanie zebranych danych, interpretacja,
zrozumienie następstw
- Burza mózgów – wygenerowanie, przefiltrowanie i posortowanie
- 5 pytań Dlaczego – dojście od ogółu do rdzenia/przyczyny problemu
- Fishbone – diagram doprecyzowujący Five whys
• Decyzje co zrobić – jasne decyzje
- Short Subjects – np. Keep/Drop/Add, Zacznij/Przestań/Więcej/Mniej
- SMART – Specific, Measurable, Attainable, Relevant, Timely
2014-04-29Łukasz Rzepecki
135
136. Metodyki zwinne
Zaangażowanie zespołu w rozw. problemów
• Zaangażowanie zespołu w rozwiązywanie problemów jest
bardzo ważne:
• Brak konieczności “sprzedaży” rozwiązania zespołowi
• Zespół jest bliżej szczegółów i może znać lepsze rozw.
• Zespół wygeneruje bardziej praktyczne rozwiązania
(uniknięcie odpowiedzi “nie da się”)
• Ludzie zapytani o pomoc lubią zastanawiać się i pracować
nad najlepszymi rozwiązaniami oraz doceniają to
• Prośba o pomoc pokazuje zaufanie a nie słabość
• Wpływa na porządany sposób zachowań w organiazcji
2014-04-29Łukasz Rzepecki
136
138. Metodyki zwinne
Retrospekcja
• To wydarzenie odbywające się po sprincie mające na celu
naukę i refleksję aby doskonalić metody działania i pracę
zespołową ze sprintu na sprint a nie dopiero po projekcie (jak
klasyczne lessons learned)
• Typowe spotkanie składa się z kilku etapów (czas trwania dla
sprintu 2-tygodniowego, to max. 2 godziny):
- Przygotowanie – 5%
- Zebranie informacji – 30-50%
- Wnioski – 20-30%
- Decyzje co zrobić – 15-20%
- Zamknięcie – 10-15%
2014-04-29Łukasz Rzepecki
138
139. Metodyki zwinne
Retrospekcja
Przygotowanie
• Ma na celu skoncentrowanie się na celach spotkania, wytworzenie
przyjaznej atmosfery sprzyjającej rozmowie na problematyczne
tematy, zaplanowanie tematów do dyskusji
• Pomocne narzędzia:
- Check-In – podsumowanie w 1-2 słowach przez każdego po kolei czego
oczekuje od spotkania, głównego tematu do podjęcia lub odczuć co do
retrospekcji
- Focus On / Focus Off
- ESVP – Explorers, Shoppers, Vacationers, Prisoners – anonimowa ankieta
jakie są nastroje na spotkanie i omówienie wyników
- Working agreements – praca w podgrupach nad tematyką retrospekcji
2014-04-29Łukasz Rzepecki
139
140. Metodyki zwinne
Retrospekcja
Zebranie informacji
• Stworzenie wspólnego obrazu co się wydarzyło podczas
iteracji/wydania/projektu – zebranie obserwacji, faktów, odkryć
• Narzędzia (rozdz. VI):
- Timeline
- Triplce nickels
- Color code dots
- Mad, sad, glad
- Locate strengths
- Satisfaction histogram
- Team radar
- Like to like
2014-04-29Łukasz Rzepecki
140
141. Metodyki zwinne
Retrospekcja
Wnioski
• Czas na ocenę informacji i wyciągnięcie z nich
wniosków, celem jest pomoc w zrozumieniu implikacji
odkryć i podjętych decyzji
• Narzędzia (rozdz. VI):
- Burza mózgów
- Five whys
- Fishbone
- Prioritize with dots
- Identify themes
2014-04-29Łukasz Rzepecki
141
142. Metodyki zwinne
Retrospekcja
Decyzje co zrobić
• Zastanowienie się co można zmienić w kolejnych iteracjach i
co zrobić inaczej
• W tym etapie zespół identyfikuje i porządkuje działania do
podjęcia, tworzy plan ew. eksperymentów, ustala mierzalne
cele do osiągnięcia i spodziewane rezultaty
• Narzędzia (rozdz. VI):
- Short subjects
- SMART goals
- Retrospective planning game
- Circle of questions
2014-04-29Łukasz Rzepecki
142
143. Metodyki zwinne
Retrospekcja
Zamknięcie
• Refleksja na temat samej retrospekcji
• Narzędzia:
- Plus/Delta – spisanie w dwóch kolumnach pomysłów co idzie
dobrze (+) i co można by zmienić (Δ) w retrospekcjach
- Helped (Pomocne), Hindered (Utrudnienia), Hypothesis
(Przypuszczenia) – rozmowa na temat samego procesu
retrospekcji, jak go poprawić w kolejnych iteracjach
- Return on Time Invested (ROTI) – czy zespół sądzi, że poświecony
czas został dobrze wykorzystany
- Uznania – wzajemne podziękowania za pomoc, wkład w
rozwiązywanie problemów itp.
2014-04-29Łukasz Rzepecki
143
144. Metodyki zwinne
Dzielenie się wiedzą
• Jest kluczowe w projektach zwinnych, w środowiskach
pracownika wiedzy
• Odbywa się na wielu poziomach – podczas dema (zespół-
klient), wiedza niepisana w środowisku f2f, poprzez
komunikację osmotyczną, na stand-upach, retrospekcjach
• Klutura organizacyjna powinna promować dzielenie się
wiedzą, odkrycia i innowacje a nie jednostki które mają dużą
wiedzę (guru) ale się nią nie dzielą (klasyczne podejście)
• Najlepszym sposobem do zachęcania do pracy grupowej,
wzajemnej pomocy i dzielenia się wiedzą jest mierzenie
efektów o poziom wyżej – tzn. nie konkretnego pracownika
ale całego zespołu, nie zespołu ale całego działu itp.
2014-04-29Łukasz Rzepecki
144
145. Metodyki zwinne
Udoskonalanie procesów
• Ma na celu lepsze dopasowanie metodologii do środowiska
projektu
• Np. Kanban zaleca modyfikowanie metodologi do własnych
potrzeb ale Scrum jest mniej elastyczny
• Niektórzy promują podejście “proces per projekt”
• Kluczowe jest doświadczenie zespołów w realizacji kilku
projektów by-the-book a dopiero później ich modyfikowanie
do własnych potrzeb
• Proste projekty o znanej technologii i dokładnej specyfikacji
wymagań wcale nie potrzebuja metodyk zwinnych! Z drugiej
strony jeśli projekt jest w stanie chaosu metodyki zwinne
również nie pomogą
2014-04-29Łukasz Rzepecki
145
146. Metodyki zwinne
Udoskonalanie procesów
• Analiza procesu
- Antywzorce:
• Jeden rozwmiar dla wszystkich projektów
• Nietolerancyjny
• Ciężki
• Upiększony
• Niewypróbowany
• Użyty raz
- Kryteria pozytywne:
• Projekt został zakończony i sprzedany
• Lider nie został zwolniony
• Zespół pracowałby ponownie w ten sam sposób
2014-04-29Łukasz Rzepecki
146
147. Metodyki zwinne
Udoskonalanie procesów
• Kryteria sukcesu
- Komunikacja face-to-face
- Nadmiar narzutu metodologii jest kosztowny – minimalizacja
produkowanej dokumentacji
- Większe zespoły wymagają cięższych metodologii
- Projekty krytyczne wymagają większych rygorów metodyki
- Informacje zwrotne i częsta komunikacja redukują potrzebę
dostarczania częstych pośrednich rezultatów
- Ważniejsza jest dyscyplina, umiejętności i zrozumienie niż procesy,
formalności i dokumentacja
- Wydajność można zwiększać tylko w środowiskach bez wąskich
gardeł
2014-04-29Łukasz Rzepecki
147
148. Metodyki zwinne
Udoskonalanie procesów
• Stosowanie nowych praktyk
- Nie stosować dopóki nie jest to niezbędne
- Czy jest jakieś inne rozwiązanie – głównego problemu?
- Czy nowe rozwiązanie faktycznie coś poprawia?
- Próbować nowe praktyki w małych dawkach (kilka iteracji)
- Analizować skutki uboczne – retrospekcje
• Proces ciągłego doskonalenia
- Analogia Plan-Develop-Evaluate-Learn do Plan-Do-Check-Act Deminga
- Iteracyjne i przyrostowe tworzenie jest formą ciągłego doskonalenia a
informacje zwrotne od klienta kierują zespół na finalne rozwiązanie
• Samoocena – nie tylko proces i produkt ale równiez zespół
wymaga oceny, jak działa i co wymaga poprawy
2014-04-29Łukasz Rzepecki
148
151. Metodyki zwinne
SCRUM
• Określa ramy postępowania przy rozwiązywaniu złożonych
problemów adaptacyjnych – optymalizuje elastyczność,
kreatywność i produktywność
• Podejście iteracyjne i przyrostowe w celu zwiększenia
przewidywalności i lepszej kontroli ryzyka
• Opiera się na:
- Przejrzystości – wszystkie aspekty procesu muszą być widoczne,
jasne i jednakowo zrozumiałe przez wszystkich (np. wspólna
definicja “ukończonej” pracy – DoD)
- Inspekcji – częsta weryfikacja realiacji celów sprintu
- Adaptacji – jeśli któryś z aspektów projektu wykracza poza ramy,
należy szybko dokonać niezbędnych korekt
2014-04-29Łukasz Rzepecki
151
152. Metodyki zwinne
Zespół Scrumowy (Development Team)
• Jest samo-organizujący się i międzyfunkcjonalny
- Zespół sam decyduje jak najlepiej wykonać pracę
- Nie jest kierowany przez nikogo z zewnątrz
- Posiada wszelkie kompetencje do wykonania pracy – nie jest
zależny od osób spoza zespołu
• Dostarcza ukończone produkty iteracyjnie i przyrostowo
- Zwiększone szanse na wczesne uzyskanie informacji zwrotnej
- Nieprzerwana dostępność działającej użytecznej wersji
• Zespół Scrumowy, to:
- Product Owner – właściciel produktu
- Zespół developerski
- Scrum Master
2014-04-29Łukasz Rzepecki
152
153. Metodyki zwinne
Właściciel Produktu (Product Owner)
• To pojedyńcza osoba, nie komitet
• Może reprezentować interesy grupy osób
• Wszelkie zmiany w backlogu muszą przechodzić przez
właściciela produktu
• Cała organizacja musi respektować jego decyzje (treść i
kolejność elementów w backlogu)
• Nikt inny nie może nakazać zespołowi realizacji innych
wymagań
2014-04-29Łukasz Rzepecki
153
154. Metodyki zwinne
Właściciel Produktu (Product Owner)
• Odpowiada za maksymalizację wartości produktu i pracy
• Jest jedyną osobą zarządzającą backlogiem produktu:
- Jasne artykułowanie elementów backlogu
- Ustalanie kolejności elementów w sposób pozwalający osiągać założone
cele i misje
- Optymalizowanie wartości pracy wykonywanej przez zespół
- Zapewnianie dostępności, przejrzystości oraz że jest jasny i zrozumiały
przez wszystkich
- Dobrze opisuje to, czym zespół będzie się zajmował w dalszej kolejności
- Zapewnianie, że zespół rozumie elementy backlogu w wymaganym stopniu
• Może zlecić realizację tych zadań na zespół ale właściciel produktu
pozostaje za nie w pełni odpowiedzialny
2014-04-29Łukasz Rzepecki
154
155. Metodyki zwinne
Zespół developerski
• Złożony jest z profesjonalistów, którzy tworzą przyrost
• Jest uprawniony do samodzielnego organizowania własnej pracy i zarządzania
nią
• Nikt (nawet Scrum Master) nie może nakazać zespołowi jak przekształcać
elementy backloga w przyrosty
• Nie uznaje tytułów innych niż “developer” (np. nazwa stanowiska czy ranga
starszy/młodszy) ani podzespołów
• Mimo, że pojedyńcze osoby mogą mieć specjalizację, to odpowiedzialność za
rezultat ponosi solidarnie cały zespół
• Zespołowi nie wolno podejmować działań w oparciu o to co mówią inne osoby
niż właściciel produktu
• Idealny rozmiar, to 3-9 osób (+ PO i SM)
• Product Owner i Scrum Master mogą być członkami zespołu, jeśli
jednocześnie wykonują też pracę wynikająca z backloga
2014-04-29Łukasz Rzepecki
155
156. Metodyki zwinne
Scrum Master
• Jest odpowiedzialny za to aby Scrum był zrozumiany i był
stosowany, szczególnie gdy nie jest jeszcze w pełni przyjęty i
rozumiany w danej organizacji
• Wspiera właściciela produktu w technikach efektywnego
zarządzania backlogiem i maksymalizowania wartości
• Wspiera zespół scrumowy w rozumieniu i praktykowaniu
zwinności i empirycznego podejścia rozwoju produktu
• Wspomaga przebieg zdarzeń scrumowych – jeśli jest to
konieczne lub zostanie o to poproszony
• Coachuje zespół w zakresie samoorganizacji
• Usuwa przeszkody ograniczające postęp pracy zespołu
2014-04-29Łukasz Rzepecki
156
157. Metodyki zwinne
Zdarzenia w Scrumie
• Są okazją do inspekcji i adaptacji – niewykonanie któregoś z
nich redukuje przejrzystość i możliwość dokonania inspekcji i
adaptacji, które są filarami Scruma
• Wprowadzają regularność i ograniczają konieczność
organizowania innych spotkań
• Wszystkie zdarzenia są organiczone czasowo (timeboxing)
• Zdarzenia w Scrumie:
- Sprint
• Planowanie sprintu (Sprint Planning)
• Codzienny Scrum (Daily Scrum)
• Przegląd sprintu (Sprint Review)
• Retrospektywa sprintu (Sprint Retrospective)
2014-04-29Łukasz Rzepecki
157
158. Metodyki zwinne
Sprint
• Musi posiadać cel – opis tego co ma powstać, cel uspójnia działania zespołu
• Iteracja ograniczona czasowo do maksymalnie 1 m-ca
- Dłuższy czas wzmaga ryzyko zmiany definicji celów i zwiększa złożoność
- Inspekcja i adaptacja są regularne
• Czas trwania jest ustalany w momencie rozpoczęcia i nie może być zmieniany ale
najlepiej aby miały stałą długość przez cały projekt
• Wytwarza przyrost – ukończony, gotowy do użycia i potencjalnego wydania
• Zakres pracy może być wyjaśniany trakcie sprintu z PO
• Może również być renegocjowany z PO jeśli pojawiają się nowe informacje, np. charakter
prac okazuje się inny od zaplanowanych
• Nie można wprowadzać zmian zagrażających realizacji celów sprintu bądź obniżających
cele jakościowe
• W trakcie sprintu zespół może uczestniczyć w doskonaleniu backloga (max. 10% czasu
sprintu)
• Może być przerwany tylko przez PO np. jeśli zdezaktualizują się cele
2014-04-29Łukasz Rzepecki
158
159. Metodyki zwinne
Planowanie sprintu
• Spotkanie całego zespołu scrumowego, maksymalnie 8h dla 1-
miesięcznego sprintu
• Co może zostać zrobione w Sprincie?
- Zespół prognozuje zakres prac, które może zrealizować
- PO omawia założenia sprintu oraz elementy backloga, które temu służą
- Zespół scrumowy uzgadnia cel sprinta a zespół developerski podejmuje
zobowiązanie które elementy backloga wykona
• W jaki sposób wybrany zakres pracy zostanie zrealizowany?
- Zespół planuje w jaki sposób elementy backloga produktu zostaną
przekształcone w ukończony przyrost – tworzy projekt i zadania
- Wybrane elementy backloga produktu wraz ww. planem tworzą backlog sprintu
• Zespół może zaprosić na spotkanie inne osoby z wiedzą techniczną
lub z danej domeny
2014-04-29Łukasz Rzepecki
159
160. Metodyki zwinne
Codzienny Scrum
• Zdarzenie zespołu developerskiego (tylko), max. 15 minut, o stałym miejscu i
porze, wygodnej dla wszystkich, za którego przebieg jest odpowiedzialny sam
zespół
• Scrum Master jest jednakże odpowiedzialny za to aby zdarzenie miało miejsce
i trwało nie dłużej niż 15 minut
• Służy synchronizacji działań, ocenie postępu prac, trendów i zaplanowaniu
następnych 24 godzin (to nie tylko status)
• Każdy członek zespołu udziela pozostałym informacji:
- Co wykonał od poprzedniego spotkania aby pomóc zespołowi przybliżyć się do osiągnięcia
cel sprintu?
- Co zrobi w tym celu do następnego spotkania? (planowanie!)
- Czy widzi jakiekolwiek przeszkody w realizacji celu przez zespół?
• Po codziennym scrumie członkowie zespołu mogą szczegółowo omówić
wybrane zagadnienia i problemy
• Jest to spotkanie kluczowe dla procesu inspekcji i adaptacji
2014-04-29Łukasz Rzepecki
160
161. Metodyki zwinne
Przegląd sprintu
• Spotkanie całego zespołu scrumowego i kluczowych interesariuszy na
zakończenie sprintu, max. 4h dla 1-miesięcznego sprintu
• Celem jest inspekcja przyrostu i ew. dostosowanie backloga produktu w celu
zwiększenia dostarczanej wartości
• To spotkanie robocze a nie statusowe:
- PO wyjaśnia, które funkcjonalności uznał za ukończone
- Zespół prezentuje wykonany przyrost oraz wyjaśnia co poszło dobrze a gdzie były problemy i
jak zostały rozwiązane
- PO omawia aktualny backlog produktu
- Uczestnicy rozważają co najlepiej wykonać w następnej kolejności aby dostarczyć
maksymalną wartość
- Rewiduje się czas, budżet i wprowadza ew. zmiany do backloga
- PO dokonuje podsumowania całej pozostałej do wykonania pracy i porównuje ją ze stanem
poprzednim (ocena możliwości realizacji celów w wyznaczonym terminie, np. wykorzystując
wskaźnik prędkości pracy)
- Rezultatem jest zaktualizowany backlog produktu
2014-04-29Łukasz Rzepecki
161
162. Metodyki zwinne
Retrospektywa sprintu
• Spotkanie zespołu scrumowego, odbywające się
między przeglądem i planowaniem sprintów, max. 3h
dla 1-miesięcznego sprintu
• Ma na celu autoinspekcję własnych działań zespołu i
opracowaniu planu usprawnień na kolejny sprint:
- Sprawdzenie, co działo się w ostatnim sprincie, z
uwzględnieniem ludzi, relacji, procesów i narzędzi
- Co się sprawdziło a co wymaga usprawnienia
- Opracowanie plananu usprawnień
• np. doprecyzowanie definicji “ukończenia”
2014-04-29Łukasz Rzepecki
162
163. Metodyki zwinne
Artefakty Scruma
• Artefakty w Scrumie, to:
- Backlog produktu
- Backlog sprinta
- Przyrost – suma wszystkich ukończonych elementów backloga
produktu zgodnie z definicją DoD zespołu scrumowego
• Musi być zachowana ich pełna przejrzystość
• Są podstawą podejmowanych decyzji mających na celu
optymalizację wartości i kontrolę ryzyka
• Zadaniem Scrum Mastera jest dbanie o ich przejrzystość
- Inspekcja
- Wyłapywanie różnic między oczekiwaniami a wynikami
2014-04-29Łukasz Rzepecki
163
164. Metodyki zwinne
Backlog produktu (Product Backlog)
• Jedyne źródło wymagań: lista wszystkich cech, funkcji, wymagań, ulepszeń i korekt błędów
• Elementy zawierają: opis, kolejność, oszacowanie, wartość
• PO jest za niego odpowiedzialny ale oszacowania dokonuje wyłącznie zespół developerski
• Nigdy nie jest kompletny, ewoluuje wraz z produktem i środowiskiem, dynamicznie się zmienia
• Doskonalenie backloga (refinement) – ciągła praca zespołu scrumowego: przeglądanie i
korygowanie
- Dodawanie szczegółów, oszacowań, porządkowanie
• Istnieje tak długo jak produkt
• Jeśli nad jednym produktem pracuje kilka zespołów scrumowych, to korzystają z tego samego
backloga
• Elementy najwyżej, na najbliższy sprint, muszą być szczegółowo opisane i możliwe do realizacji
w ramach sprintu
- Statusy: Nieprzygotowane Przygotowane (gotowe do realizacji, wystarczająco zrozumiałe i wystarczająco
małe) Ukończone
2014-04-29Łukasz Rzepecki
164
165. Metodyki zwinne
Backlog sprintu (Sprint Backlog)
• To zbiór elementów backloga produktu wybranych do realizacji na dany sprint,
rozszerzony o:
- Plan dostarczenia przyrostu produktu
- Plan realizacji celu sprintu (praca niezbędna wg zespołu developerskiego do jego
osiągnięcia)
• Wystarczająco szczegółowy
• Jest modyfikowany przez zespół developerski w trakcie trwania sprintu (w
miarę realizacji celów i wyłaniania się nowych informacji aby je osiągnąć)
- Dodatkowa praca jest dodawana do backloga sprintu z zbędne elementy usuwane – tylko
zespół developerski może go zmieniać!
• W miarę postępu prac aktualizowane jest oszacowanie pozostałej do
wykonania pracy w sprincie (przynajmniej raz dziennie podczas codziennego
scruma)
• Na koniec sprintu nowy przyrost musi być ukończony i być przetestowany z
poprzednimi przyrostami (muszą działać razem)
2014-04-29Łukasz Rzepecki
165
166. Metodyki zwinne
Definicja ukończenia (DoD)
• Każdy musi rozumieć co oznacza ukończenie elementu
backloga produktu albo przyrostu produktu (pracy w
kolejnym sprincie)
• Zespół scrumowy musi mieć wspólne rozumienie DoD
• Celem każdego sprintu jest dostarczenie gotowej do
wydania funkcjonalności, zgodnie z aktualną definicją
ukończenia funkcjonującą w zespole scrumowym
• Konwencja, standardy i wytyczne w organizacji
stanowią minimum definicji ukończenia – jeśli ich nie
ma musi je wypracować sam zespół
2014-04-29Łukasz Rzepecki
166
167. Metodyki zwinne
Podsumowanie Scruma
• Scrum istnieje tylko w swojej pełnej postaci
• Może stanowić ramy dla innych technik, metodyk i
praktyk
2014-04-29Łukasz Rzepecki
167