Scam, scum, sacrum

4,568 views

Published on

Prezentacja z gościnnego wystąpienia na spotkaniu Project Management Institute (PMI) w Krakowie. Prezentacje punktuje najczęstsze problemy występujące podczas wdrożeń metodyki Scrum w środowisku średniej i dużej organizacji, powodów tych problemów upatrując w przyzwyczajeniach, kulturze organizacyjnej i obawie przed zmianą.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,568
On SlideShare
0
From Embeds
0
Number of Embeds
3,165
Actions
Shares
0
Downloads
29
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Scam, scum, sacrum

  1. 1. Agile Software Development withSacrum. Ken Schwaber, Mike BeedleAgile Project Management with Scum.Ken SchwaberThe Enterprise and Scam. Ken Schwaber© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  2. 2. Sacrum. Ile jest Scruma w Scrumie? Scum. Tomasz Włodarek Scam. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.1.00.00 Materiał udostępniany na licencji Creative Commons (by-nc-nd). bnd
  3. 3. Scrum jest obecny w Polsce. Firmy różnej skali, branż, pochodzeniukapitału. Offshoring, nearshoring, rodzime. Od kilku lat. Wszędzie.Najbardziej popularna ze wszystkich zwinnych metod: 58% Scrum,17% hybryda Scruma z programowaniem ekstremalnym (XP), pozostałełącznie 25% (w tym własne odmiany 5%). State of Agile Survey. 5th annual State of Agile Software Development Survey. VersionOne Inc., 2010Skąd się wziął? Jest głównie promowany oddolnie przez zespołyprojektowe 70%, coraz częściej postrzegany jest jako wymóg branży 33%,rzadziej wdrażany decyzją kierownictwa 26% czy jako wymóg klienta 15%.To interesujący fakt. Warto o tym pamiętać. Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki UEK, 2009© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  4. 4. agile (Agile Software Development)© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  5. 5. Zwinność (ang. agility) oznacza potencjał – w sferzeumiejętności i możliwości – do szybkiego i sprawnegodostosowywania się do zachodzących zmian. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  6. 6. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  7. 7. podczas wdrażania Scruma… ScreamMaster …natychmiast pojawiają się wykręty – ScrumButs. ScrumButs to „powody”, dla których nie można w pełni wykorzystać Scruma, by rozwiązać problemy i uzyskać spodziewanych korzyści. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  8. 8. (Wykręt)(Powód)(Alternatywa)Scrumujemy, ale (nasz Product Owner nie ma czasu)(bo jest bardzozajęty swoimi sprawami)(więc Product Backlog jest przygotowywany przezScrum Mastera)Scrumujemy, ale (Product Backlog jest zamrożony)(bo nasz PM wymagaod nas deklaracji co do zakresu i czasu)(więc nie robimy testów, żebywyrobić się na koniec Sprintów)Scrumujemy, ale (właściwie granice sprintów są umowne)(bo i tak ciąglewchodzi coś nowego)(więc po prostu lecimy z robotą) © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  9. 9. (Wykręt)(Powód)(Alternatywa)Scrumujemy, ale (nie oddajemy Product Ownerowi pracy co sprint)(bo niemamy testerów w zespole, a zresztą i tak trzeba by się integrować zinnymi)(więc zespół QA robi dla nas testy na koniec projektu)Scrumujemy, ale (nie robimy Sprint Review)(bo i tak nikt tego nierozumie)(więc pokazujemy coś Product Ownerowi średnio raz na półroku)Scrumujemy, ale (retrospektywy to strata czasu)(bo i tak się nic niezmienia)(więc po prostu ich nie robimy) © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  10. 10. Fasada. Scrum but. WAGILE*. Quasi–agile. Flaccid Scrum. Kanban?*waterfall agile (sic!) ScrumButs to przejaw postaw kulturowych, tradycyjnie stosowanych praktyk i przyzwyczajeń. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  11. 11. Pierwotny strach przed nieznanym – Ale przecież działamy, jakoś to idzie. Oczywiście mamy problemy, ale kto ich nie ma!? Po co to zmieniać? §  Scrum wymaga zmiany kultury organizacyjnej. Wprowadza rytm i przyspiesza realizację projektów. Organizacja „wyszczupla się” i staje się bardziej efektywna. §  Otwartość i przejrzystość wymagane przez Scruma to nowy sposób robienia biznesu. Ceniona jest aktywność, kreatywność i innowacyjność, punktuje się marnotrawstwo, politykierstwo i arogancję. Decyzyjność przesuwana jest w dół hierarchii. Czasem wymagana jest zmiana struktury organizacyjnej. Czasem wymagane jest nabycie nowych kompetencji. Zdarza się, że ktoś odchodzi z tego powodu. §  Taka zmiana wywołuje strach i opór (od pasywnego do aktywnego) i wymaga odpowiedniego podejścia (otwartości i konsekwencji). Jest ceną, którą płaci się za zwiększoną efektywność organizacji. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  12. 12. Strach przed rozmyciem terminów(zupełnie jakbyśmy teraz je kontrolowali) – W Scrumie nie mogę wyznaczać kamieni milowych. Nie da się wyznaczyć i monitorować ścieżki krytycznej. Nie wiem jaki jest status projektu. To nie dopuszczalne! §  Nieporozumienie. W Scrumie nie planuje się sekwencji czynności, nie tworzy się diagramu Gantta (finish-or-perish!), nie wyznacza się ścieżki krytycznej. Plan zorientowany jest na produkt (wykonane zakresy funkcjonalności, podnoszące wartość produktu), a nie czynności (zadania) prowadzące do ich wytworzenia. §  Kamienie milowe wynikają z ograniczeń czasowych (time–boxes) i obowiązują zarówno na poziomie Sprintu i spotkań w jego trakcie, jak i na poziomie wydań. §  Można je określić mianem nieprzekraczalnych są bowiem stałym elementem procesu. Pozwala to lepiej kontrolować ryzyko, zwiększa dyscyplinę i motywację. §  Dodatkowo na podstawie danych historycznych (empirycznych) można wyznaczyć kiedy zostanie osiągnięty określony zakres funkcjonalny, jaki zakres prac zostanie wykonany w określonym czasie etc. §  Ocena kondycji projektu dokonywana jest na podstawie „twardego” dowodu – działającego (lub nie) oprogramowania o określonej wartości, a nie mętnych miar. §  Szybko widać, że są problemy. Scrum to narzędzie zarządzania ryzykiem. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  13. 13. Strach przed pełzającym zakresem – Jak możemy się zdeklarować do czegokolwiek bez spisania kontraktu na zakres / bez książki wymagań / bez solidnej dokumentacji analitycznej / bez kompleksowego projektu architekury systemu? §  Pełzanie zakresu jest podstawowym problemem w klasycznych projektach, kontraktowanych na zakres i czas, realizowanych kaskadowo. §  Ocenia się, że mimo ogromnych nakładów na etap wstępnego planowania średnio 35% wymagań ulega zmianie w trakcie prac, a około 60% dostarczonej funkcjonalności jest używane rzadko lub wcale. Sprawę pogarsza dyskusyjna kwestia zgłaszanych w ramach gwarancji „usterek” („w dokumentacji po uzgodnieniach nie było co prawda mowy, że ma być, ale nie było też mowy, że ma nie być”) §  Scrum rozwiązuje tę kwestię poprzez ideę etapowego osiągania celów biznesowych, dynamicznego planowania i zaprzęgnięcie zachodzących zmian do wytworzenia przełomowego produktu. §  Scrum dopuszcza zmianę zakresu (wyjątkiem jest okres realizacji Sprintu), przy czym ograniczenie czasowe na wydanie (zakontraktowana liczba Sprintów) lub Sprint (stała liczba dni) wymusza dokonywanie racjonalnych wyborów odnośnie realizacji poszczególnych funkcjonalności. Dotyczy to zarówno ich liczby jak i „bogactwa”. §  Dobór zakresu pracy do kolejnego Sprintu (czy wydania) jest dokonywany przez zestawienie potrzeb biznesowych Product Ownera z realnymi możliwościami produkcyjnymi Zespołu. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  14. 14. Strach przed utratą kontroli nad budżetem – Ile to będzie kosztować? – Ale co dokładnie mamy zrobić? – Nie wiem, to wy jesteście specjalistami, powinniście to wiedzieć! §  Klasyczne metody przyzwyczaiły nas do planowania budżetu na podstawie ustalonego zakresu prac. Tyle, że zwykle nie bardzo wiadomo czego dokładnie oczekujemy, jakie niespodzianki czekają nas po drodze i jak nasze wymagania będą się zmieniać w czasie. §  Większość klasycznie realizowanych projektów IT przekracza budżet o 150% do 1000%, przechodząc przez czasochłonny i stresujący dla obu stron proces zarządzania zmianą. §  W Scrumie ryzyko pozornie jest większe ze względu na możliwość zmiany zakresu, ale: §  koszty są namacalne i policzalne (każdy Sprint kosztuje w przybliżeniu tyle samo i daje efekt w postaci gotowego oprogramowania) §  co Sprint uzyskujemy informację zwrotną §  na tej podstawie zarządzamy ryzykiem np. dostosowując zakres prac do realiów i rzeczywistych potrzeb §  Jest spora szansa, że osiągniemy oprogramowanie spełniające nasze potrzeby (faktyczne, nie wydumane) zanim wydamy cały przeznaczony na projekt budżet. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  15. 15. Strach przed spowolnieniem tempa prac – Mamy 42 projekty w toku, do każdego z nich przypisane są zasoby. Nie możemy tych ludzi nagle przekonfigurować w zespoły scrumowe i pozwolić im skupić się na pojedynczych funkcjonalnościach. Cała organizacja zwolni. §  Klasyczne projekty realizowane są przez wyznaczone do tego osoby i zarządzane przez kierowników projektów. Po zakończeniu prac osoby te przypisywane są do nowych projektów, niekonieczne w tym samym składzie, niekoniecznie w tym samym obszarze systemu. Ogranicza to ich poczucie odpowiedzialności za jakość wykonanej pracy. Cierpi na tym także współpraca zespołowa. Te grupy pracownicze w istocie nie są zespołami i muszą być zarządzane. §  Ponieważ projekty się spóźniają i zawierają błędy pojawiają się trudności w zarządzaniu zasobami, często te same osoby jednocześnie uczestniczą w realizacji wielu projektów, co pozornie zwiększa ilość pracy wykonywanej. W rzeczywistości zostaje wykonana mniejsza ilość pracy, a wykonanie każdej części pracy jest wielokrotnie droższe. Zaczyna się polityka, pojawiają się naciski i rywalizacja o (kluczowe) zasoby. Praca wykonywana jest gorzej i mniej kreatywnie. To kula śniegowa. §  Podstawą wysokiej (hiper) produktywności zespołów scrumowych jest stabilność ich składu i samoorganizacja wokół celów wyznaczanych przez jednego Product Ownera. §  Zespół z czasem wypracowuje stabilne tempo pracy, właściwe dla składu danej grupy i środowiska projektowego. Nie wszystkim to tempo będzie odpowiadać. Niektórzy żyją w świecie marzeń. Zamiast frustrować się, że rzeczywistość nie spełnia naszych oczekiwań, lepiej jest poznać co mamy do dyspozycji i przemyśleć jak najlepiej to wykorzystać. §  Zapewne mniej pracy będzie wykonywane jednocześnie, ale dzięki temu będzie ona kończona szybciej. Poprawiona zostanie przewidywalność i jakość. §  Scrum dopuszcza możliwość realizowania przez jeden zespół scrumowy wielu projektów jednocześnie (np. dla różnych klientów) w obrębie jednego produktu (wspólnej bazy). © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  16. 16. paralelioza Niebezpieczna choroba wywołująca błędne przekonanie, że więcej pracy zostanie zrobione jeśli więcej będzie wykonywane jednocześnie. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  17. 17. Strach przed utratą kontroli(oddaniem odpowiedzialności) – Oni mają decydować?! Przecież będą tak robić żeby się nie narobić! Na ludziach można cokolwiek wymóc tylko z pozycji siły! §  Klasyczny kierownik ponosi pełną odpowiedzialność (za projekt, za produkt, za zespół). Podejmuje decyzje i wydaje dyspozycje – często pod presją czasu, w oparciu o nikłą znajomość tematu i opinie osób trzecich. W razie kłopotów staje się kozłem ofiarnym i sprawa jest jasna. Czyżby? §  Ponieważ (zwykle) mamy do czynienia ze złożonymi przedsięwzięciami, nikt nie jest w stanie podejmować racjonalnych decyzji jednoosobowo. §  Mimo to oddając decyzyjność w dół hierarchii obawiamy się rozmycia odpowiedzialności i nieracjonalnego zachowania ludzi, którym powierzamy obowiązki. Brak zaufania? §  Scrum w klarowny sposób rozdziela odpowiedzialność pomiędzy Product Ownera (biznes), Zespół (propozycje rozwiązań technicznych) i Scrum Mastera (proces i wsparcie organizacyjne). §  Kontrola jest częsta (co dzień, co Sprint, co wydanie), jest przeprowadzana na różnych poziomach przez kwalifikowane do tego osoby i jest elementem procesu (jest nieuchronna). Wszystko to zwiększa zaangażowanie i motywację do przejawiania odpowiedzialnych zachowań. §  Decyzje podejmowane są periodycznie (co Sprint) na podstawie empirycznie stwierdzonych faktów (przyrost lub jego brak) w sposób przejrzysty (jawny). Z faktami nie da się dyskutować. Przejrzystość usuwa politykę. Nie wszystkim to odpowiada. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  18. 18. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  19. 19. samoorganizacja Szybka reakcja na dynamikę otoczenia. Skrócenie czasu podejmowania decyzji. Lepsze rozpoznanie potrzeb, lepsze dopasowanie nakładów do potrzeb. Wzrost motywacji. Odpowiedzialność. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  20. 20. samoorganizacja? Osłabienie zewnętrznej kontroli, ograniczenieingerencji kierownictwa. Większa swoboda działania w zamian za obietnicę zwiększonego zaangażowania. Autonomia. Czy może anarchia? © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  21. 21. fundamentalna potrzeba pewności i gwarancji brak czasu a zatem i przyzwolenia na popełnianie błędów © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  22. 22. kontrola, kontrola, kontrolaPhone Driven Development (PDD) Ograniczanie dostępu do informacji. Brak bezpośredniego kontaktu z klientem lub osobami, które go reprezentują. Brak wglądu w długofalowe plany. (wkrada się kaskadowość) Ograniczanie decyzyjności. Długa i zawiła ścieżka decyzyjna. (wkrada się kaskadowość) Ograniczanie interdyscyplinarności. Osoby o różnych kompetencjach zaangażowane w przedsięwzięcie pracują w izolacji od siebie. Potrzebni pośrednicy i koordynatorzy. Planowanie zasobów. (wkrada się kaskadowość) Ograniczanie autonomii. Rozdzielanie zadań. Wymuszanie zobowiązania. (wkrada się kaskadowość) Ograniczenie zaufania. Zwiększone nakłady na zewnętrzną kontrolę. Zmniejszone poczucie odpowiedzialności. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  23. 23. §  Odwołanie do procesu/planu. Zabijamy kreatywność. W najlepszym przypadku otrzymujemy perfekcyjnie wykonaną przeciętność.§  Przyzwyczajenie. Zawsze tak robiliśmy. Postępuję tak jak moi przełożeni. Taką mamy kulturę pracy.§  Pułapka odpowiedzialności. Jestem za to odpowiedzialny, powierzono mi te obowiązki. Muszę się upewnić, że wszystko będzie wykonane prawidłowo.§  Po prostu powiem im kto/kiedy/jak ma to zrobić. Mikro- zarządzanie (być może zarządzanie w ogólności) wydaje się być łatwiejsze niż przywództwo. W istocie jest bardziej angażujące i daje znacznie gorsze rezultaty długofalowe.§  Powiem im też, że mają to zrobić bezbłędnie, bo jak nie… Tak, to bez wątpienia pomaga. Podobnie jak komenda “pracuj szybciej”.§  Arogancja i/lub ignorancja. Kiedy brakuje zaufania i wzajemnego szacunku pozostają jedynie rozwiązania siłowe. Tymi przypadkami nie chcę się nawet zajmować.© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  24. 24. będzie pan zadowolony © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  25. 25. §  Założeniem Scruma jest fakt, że przedmiotem podlegającym częstej kontroli jest coś zrozumiałego dla wszystkich zainteresowanych, coś podlegającego wszechstronnej ocenie.§  Nie abstrakt (dokument, formularz, projekt, prezentacja, kolor raportu, procent zaawansowania). Konkret. Dowód.§  Zintegrowany, przetestowany, działający software.§  Na całe szczęście to potrafimy robić, prawda?© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  26. 26. Prawie, właściwie, praktycznie,teoretycznie, zasadniczo, jakby,generalnie, ogólnie rzecz biorąc, zgrubsza… w 90% skończone.
  27. 27. Strach przed przejęciem kontroli(podjęciem odpowiedzialności) – Scrum jest kolejną sztuczką managementu, żeby nas jeszcze bardziej przycisnąć. To teraz mamy jeszcze robić ich robotę?! §  Nieporozumienie. W Scrumie odpowiedzialność jest przesuwana w dół hierarchii wraz z decyzyjnością. To Zespół proponuje rozwiązania, Zespół z Product Ownerem ustala realny poziom oczekiwań i Zespół deklaruje ile pracy może zostać wykonane w Sprincie. §  Scrum bazuje na wysokiej motywacji do wykonania dobrej pracy. Motywacja wynika z głębokiego poczucia sensu wykonywanej pracy i poczucia wpływu na bieg wydarzeń. Potrzebna jest przejrzysta i bogata informacja kontekstowa. §  Niewiele osób jest przyzwyczajonych do takiego stylu pracy. Niektóre osoby w ogóle się do tego nie nadają. Niektórzy po prostu potrzebują kierownika. Takie osoby nie zagrzeją miejsca w zespole scrumowym. §  Jeśli produktywność Zespołu nie jest zgodna z oczekiwaną, Zespół poszukuje sposobów jej zwiększenia. Proponuje rozwiązania i oczekuje wsparcia kierownictwa w tym zakresie. §  Wypracowanie takiego podejścia wymaga czasu. Najmniejszy przejaw braku przejrzystości, łamania ustaleń czy braku konsekwencji będzie powodować szybki i gwałtowny regres. To jedno z najczęstszych miejsc załamania. §  Niemniej – jeśli mimo tych wszystkich wysiłków – przedsięwzięcie nie spełnia podstawowych założeń biznesowych, zamyka się je a Zespół jest rozwiązywany lub zmienia się jego skład. Nikt nie powinien być zaskoczony takim obrotem spraw. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  28. 28. Strach przed zaangażowaniem(lub obnażeniem braku kompetencji) – Mam teraz co dwa tygodnie pokazywać jak to działa komuś z biznesu, szkoda czasu, to techniczne sprawy i tak nie skapują! –Przecież dewelopment nie operuje podstawowymi pojęciami i nie zna założeń biznesowych! Nie mam czasu na takie pierdoły. §  Końcowi odbiorcy i reprezentujący ich przedstawiciele biznesu (marketing, Product Management, etc.) nie są przyzwyczajeni do współuczestniczenia w procesie produkcji oprogramowania. Rezultaty są opłakane (przepaść komunikacyjna, produkty nie spełniające oczekiwań, przerzucanie się winą). §  Ponieważ software jest zazwyczaj częścią większej całości, Scrum angażuje obie strony w proces wytwórczy. Obie strony muszą pokonać opór przed wejściem na obszar leżący poza ich podstawowymi kompetencjami. Dialog prowadzony z równorzędnych pozycji – obie strony są od siebie wzajemnie zależne – jest kluczem. §  Jest to możliwe tylko przy założeniu, że proces planowania będzie przejrzysty (informacja kontekstowa – nie tylko co, ale również po co), a swoboda realizacyjna będzie prowadzić do wytworzenia zrozumiałego dla wszystkich i kompletnego (ukończonego) przyrostu. Przejrzystość usuwa politykę. Nie wszystkim to odpowiada. Niektórzy zrobią wszystko by zapobiec przejrzystości. §  Użycie Scruma często prowadzi do odkrycia, że niechęć do współpracy ma swoje źródło w fakcie, że dewelopment ma poważne braki na poziomie inżynierii oprogramowania i/lub biznes niedomaga pod względem wizji produktu, planowania strategicznego czy komunikacji. §  Scrum szybko daje namacalne wyniki w postaci konkretnych obserwacji. To fakty na których można budować. Jeśli będą one prowadzić do zmian, stopniowo zwiększy się zaangażowanie po obu stronach. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  29. 29. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  30. 30. “ Framework within which people can address complex problems and productively and creatively develop products of the highest possible value. –Ken Schwaber © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). ”
  31. 31. “ Process which can address complex problems and develop products for the lowest possible cost. –?! © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd). ”
  32. 32. Scrum umożliwia tranzycję Scrum: (1) narzędzie wykorzystywane do osiągnięcia zwinności (2) ramy metodyczne (framework), w obrębie których ludzie mogą rozwiązywać złożone problemy, tworząc w ten sposób, kreatywnie i produktywnie, produkty o najwyższej możliwej wartości. §  proste reguły i ograniczenia czasowe (time-boxed containers) pozwalają zapanować nad chaosem §  oparcie dla szeregu lekkich (lean) praktyk Scrum jest modelem koncepcyjnym, narzędziem, które pomaga ustalić co jest przeszkodą w produkowaniu oprogramowania o wyższej jakości, lepiej, szybciej. Redukuje zlożoność i pozwala lepiej kontrolować ryzyko. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  33. 33. wybita szyba Członkowie zespołu samoorganizującego się asymilują się z otoczeniem poprzez obserwację, naśladownictwo i wzmocnienie. W ten sposób (powoli) tworzy się kodeks zachowań, którym posługuje się grupa. Daj przykład, a efekt przyjdzie sam. Cierpliwości. Niepożądane zachowania (zwykle wygodniejsze) są zazwyczaj przejmowane szybciej niż poprawne. Brak jednoznacznej, stanowczej i konsekwentnej korekty niepożądanych zjawisk (czy zachowań) zawsze prowadzi do ich eskalacji.Jeśli komuś na czymś nie zależy jest spora szansa, że za chwilę nikomu na niczym nie będzie zależało.© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  34. 34. Wszyscy docenią Scruma, bowiem opisuje on ScreamMasterdokładnie to, co robimy, gdy zostaniemy przyparcido muru. –Jim Coplien (The Scrum Guide, Ken Schwaber, Jeff Sutherland)Paradoksalnie, dopiero kiedy jest naprawdętragicznie zaczynamy postępować właściwie –zbieramy zespół i odwołując się donadrzędnego celu, prosimy o pomoc izaangażowanie, deklarując pełne wsparcie idając wolną rękę.Byle nie było za późno. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  35. 35. to musi wejść w krew Nie da się robić agile’a – trzeba być agile. Poszczególne elementy, techniki i sztuczki nie wystarczą. Liczy się koncept (przesłanie) i umiejętność wykorzystania całego modelu w praktyce. © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  36. 36. Nawet kulawy Scrum pomaga. Krótszy czaswprowadzenia produktu na rynek 63%*, lepsza zdolnośćdo absorbowania zmian 86%*, wzrost produktywności86%*, wzrost jakości produktu 71%*, poprawakomunikacji 93%*, wzrost morale 78%*, spadek ryzykaniepowodzenia projektu 63%*, neutralny wpływ nakoszty realizacji projektu. 41%* wskazuje na pełnysukces realizowanych projektów. Jakby to wyglądałogdybyśmy wykorzystali go w pełni? Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki UEK, 2009© 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania.Materiał udostępniany na licencji Creative Commons (by-nc-nd).
  37. 37. Tomasz Włodarek dziękuję!Projekty szkoleniowo-doradcze realizowane m.in. dla:ABG S.A., Anixe Polska, Apriso Polska, Asseco Business Solutions S.A., ATSI S.A., BLStream, CCAEurope, CD Projekt RED, Copi S.A., GE Money Bank S.A., Getin Bank S.A., Hurra Communications,Logintrans, Nokaut.pl, Quantum Software S.A., Grupa Allegro, RST, Sterkom, Spot.pl, Travelplanet.pl,TRW Polska, TVN, Volantis Systems, VSoft S.A., Young Digital Planet S.A.tomek@poddrzewem.plhttp://www.poddrzewem.plhttp://www.linkedin.com/in/wlodarekOn our loss of wisdom, Barry Schwartz, TED talkhttp://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.htmlThe child–driven education, Sugata Mitra, TED talkhttp://www.ted.com/talks/sugata_mitra_the_child_driven_education.htmlScrum Guide. K.Schwaber, J.SutherlandScrum w Polsce. Raport z badań. red. dr M.Ćwiklicki, UEK, 2009Metodyka Scrum w Polsce w świetle badań. M.Ćwiklicki, T.Włodarek, kwartalnik Nauka igospodarka, 2010State of Agile Survey. 5th annual State of Agile Software Development Survey, VersionOne Inc.,2010Agile Software Development with Scrum. K.Schwaber, M.BeedleAgile Project Management with Scrum. K.SchwaberThe Enterprise and Scrum. K.Schwaber © 2011 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

×