What do you think?
Rate this book
Scrum i nie tylko. Teoria i praktyka w metodach Agile
Scrum i nie tylko. Teoria i praktyka w metodach AGILE.
Zarzadzanie projektami za pomoca metod zwinnych, czyli Agile jest tematem zyskujacym coraz wieksza popularnosc. Ciagle zmieniajaca sie rzeczywistosc wymaga technik i narzedzi, aby w sposob prosty i szybki spelniac wymagania klienta, jednoczesnie zachowujac wysoka jakosc produktu. Szczegolnie dotyczy to branzy IT. Ksiazka wychodzi naprzeciw wspomnianym potrzebom. Tematy przedstawione sa tu w przystepny sposob, zarowno dla osob pracujacych w paradygmacie Agile, jak rowniez dla tych, ktorzy dopiero rozpoczynaja swoja przygode z metodykami zwinnymi. SCRUM i nie tylko... to rzetelna wiedza poparta oryginalnymi zrodlami. To ponad siedem lat doswiadczen w polskich i miedzynarodowych Zespolach oraz setki godzin szkolen w jednej ksiazce. Z ksiazki dowiesz sie: • jakie sa metody Agile i jak w pelni wykorzystac ich potencjal; • jak planowac tylko tyle, ile potrzeba i dostarczac produkt iteracyjnie i przyrostowo; • jak nie popelniac najczestszych bledow; • jak sprawdzac postep i reagowac na zmiany; • jak minimalizowac straty i optymalizowac prace; • jak prowadzic wydajne, zmotywowane Zespoly; • jak szacowac, planowac i zawierac kontrakty; • na czym polega Agile Coaching; • jak wprowadzic Agile do Twojej firmy. Publikacja przeznaczona jest dla zespolow projektowych, programistow, testerow, menedzerow, a takze profesjonalistow z pasja do tworzenia niesamowitych produktow.
Zarzadzanie projektami za pomoca metod zwinnych, czyli Agile jest tematem zyskujacym coraz wieksza popularnosc. Ciagle zmieniajaca sie rzeczywistosc wymaga technik i narzedzi, aby w sposob prosty i szybki spelniac wymagania klienta, jednoczesnie zachowujac wysoka jakosc produktu. Szczegolnie dotyczy to branzy IT. Ksiazka wychodzi naprzeciw wspomnianym potrzebom. Tematy przedstawione sa tu w przystepny sposob, zarowno dla osob pracujacych w paradygmacie Agile, jak rowniez dla tych, ktorzy dopiero rozpoczynaja swoja przygode z metodykami zwinnymi. SCRUM i nie tylko... to rzetelna wiedza poparta oryginalnymi zrodlami. To ponad siedem lat doswiadczen w polskich i miedzynarodowych Zespolach oraz setki godzin szkolen w jednej ksiazce. Z ksiazki dowiesz sie: • jakie sa metody Agile i jak w pelni wykorzystac ich potencjal; • jak planowac tylko tyle, ile potrzeba i dostarczac produkt iteracyjnie i przyrostowo; • jak nie popelniac najczestszych bledow; • jak sprawdzac postep i reagowac na zmiany; • jak minimalizowac straty i optymalizowac prace; • jak prowadzic wydajne, zmotywowane Zespoly; • jak szacowac, planowac i zawierac kontrakty; • na czym polega Agile Coaching; • jak wprowadzic Agile do Twojej firmy. Publikacja przeznaczona jest dla zespolow projektowych, programistow, testerow, menedzerow, a takze profesjonalistow z pasja do tworzenia niesamowitych produktow.
- GenresBusiness
280 pages, Paperback
First published January 1, 2014
3 people are currently reading
37 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
February 24, 2020
Pozycja generalnie niezła i opisująca Scrum i metodyki. Co mi się mniej podobało to spolszczone nieco na siłę terminy i czasami ciężko sobie wewnętrznie to tłumaczyć podczas gdy się jest przyzwyczajonym do terminów angielskich.
Cytaty:
Czy w takim razie model kaskadowy można stosować z powodzeniem? Oczywiście, że tak. Muszą być jednak spełnione pewne warunki: zakres projektu i wymagania się nie zmieniają; zespół doskonale zna technologię; zespół dobrze rozumie wymagania; zespół dobrze oszacował zakres prac do wykonania; nic nie wpłynie na zmianę planu.
Jednak, jak powiedział marszałek Helmuth von Moltke, „Żaden plan nie przetrwa kontaktu z wrogiem”. Rzeczywistość potrafi zaskakiwać i psuć nawet najlepsze plany, szczególnie, gdy pracujemy z ludźmi. Dlatego zawsze należy pamiętać, po co stworzyliśmy plan. Nie jest on niezmiennym artefaktem wyrytym w kamieniu jak kalendarz Azteków. To zestaw kroków na drodze do celu, biorący pod uwagę to, co do tej pory wiemy o drodze. Jeżeli sytuacja się zmieni, będzie nam potrzebny nowy plan.
Naszym najwyższym priorytetem jest zadowolenie klienta osiągane przez wczesne i ciągłe dostarczanie wartościowego oprogramowania. 2. Zmiany w wymaganiach są mile widziane nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta. 3. Dostarczaj oprogramowanie często, w odstępach czasu od kilku tygodni do kilku miesięcy, preferując mniejsze odstępy czasu. 4. Ludzie biznesu i deweloperzy muszą pracować razem codziennie przez cały czas trwania projektu. 5. Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie, którego potrzebują, i zaufaj im, że praca zostanie wykonana. 6. Najskuteczniejszą i najwydajniejszą metodą przekazywania informacji w zespole deweloperów jest rozmowa w cztery oczy. 7. Działające oprogramowanie jest podstawową miarą postępu. 8. Procesy Agile promują zrównoważony rozwój [oprogramowania]. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymać stałe tempo. 9. Ciągła koncentracja na technicznej doskonałości i dobrym projekcie (ang. design) poprawia zwinność (ang. agility). 10. Prostota – sztuka zwiększania ilości pracy niewykonanej – jest niezbędna. 11. Najlepsze architektury, wymagania i projekty wyłaniają się z samoorganizujących się zespołów. 12. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje zachowanie.
W trakcie trwania iteracji nie dopuszcza się dużych zmian, ponieważ cały plan pracy przestaje mieć sens i lepiej jest zacząć od nowa. Zmiany mają swoje konsekwencje. Korzystanie z metod zwinnych nie daje klientowi możliwości całkowitej zmiany kierunku projektu bez ich poniesienia. Jeżeli umówiliśmy się na zbudowanie samochodu i mamy gotowe podwozie, to nie można teraz zrobić jachtu. Zwinność ma swoje granice. Jeżeli jednak klient kategorycznie stwierdzi, że już nie potrzebuje samochodu, lecz jachtu i jest gotowy poświęcić zużyte do tej pory środki, to ma prawo do takiej decyzji.
Główną przyczyną nieporozumień podczas pracy nad projektem jest przepaść komunikacyjna pomiędzy sferą biznesu a zespołami deweloperskimi. Jednym ze sposobów na zmniejszenie tej różnicy jest zbliżenie tych dwóch posługujących się swoimi językami światów przez ich połączenie na co dzień. Przedstawiciele świata biznesu dowiedzą się więcej na temat rozwiązań informatycznych, ich ceny i konsekwencji utrzymania. Pracownicy IT będą z kolei uczyć się podstaw myślenia biznesowego, co pomoże im zrozumieć potrzeby i zaproponować najlepsze rozwiązania zamiast takich, które biznesowi wydają się oczywiste.
Produktywność mierzona w punktach funkcyjnych jest zazwyczaj dziesięć razy większa w zespołach samoorganizujących się. Głównymi czynnikami blokującymi zwinność projektów są kontrola i brak zaufania ze strony kierownictwa.
Kod napisany w pośpiechu i bez przemyślenia sprawia wiele problemów, zarówno w utrzymaniu, jak i podczas rozwijania systemu. Na początku liczymy na to, że na dalszych etapach będziemy dostarczać funkcjonalności szybciej, ale wraz ze wzrostem złożoności systemu nasz plan odwraca się o sto osiemdziesiąt stopni i działa przeciwko nam. Pojawiają się wtedy nowe problemy, począwszy od brakującej dokumentacji, przez zduplikowany kod, na modułach mających zbyt wiele funkcji skończywszy
Ostatnio popularne stało się pojęcie Total Cost of Ownership (TCO), czyli całkowity koszt posiadania. Bierze on pod uwagę nie tylko koszt wyprodukowania sytemu w analizowanym momencie, ale także koszt utrzymania go w przyszłości. Biznes powinien być świadom tego problemu i brać go pod uwagę przy podejmowaniu decyzji odnośnie do budowy systemu. IT powinno wspomagać biznes, informując go o dokładnych konsekwencjach wyboru architektury systemu i podejścia.
Projektant wie, że osiągnął doskonałość, nie wtedy, kiedy nie można nic dodać, ale wtedy, kiedy nie można nic ująć.
Patrząc na Manifest i 12 Zasad Agile, można łatwo sprawdzić, czy praktyki wykorzystywane podczas pracy nad projektem mogą być uznane za zwinne i czy można powiedzieć „używamy Agile”. Często jednak zdarza się, że przy wprowadzaniu Agile do organizacji Manifest jest rozumiany zero-jedynkowo – jesteśmy Agile, więc nie piszemy dokumentacji, jesteśmy Agile, więc nie planujemy, jesteśmy Agile, więc nie mamy standardów.
Dużo bardziej skuteczna jest relacja zbudowana na trosce o wspólne cele. Dbaj o częstą interakcję i staraj się, jak najlepiej zrozumieć świat i potrzeby biznesu. Często prezentuj postęp prac i wyniki, żeby zbudować zaufanie klienta, pokazując mu, że został wysłuchany, a kierunek projektu jest wytyczony na podstawie informacji zwrotnej.
Pracownik nie jest winien swojemu pracodawcy służalczego posłuszeństwa. Jest mu jedynie winien usługę, za którą otrzymuje zapłatę będącą nie łaską, ale zasłużonym wynagrodzeniem.
Zarządzać można majątkiem, nieruchomościami, plantacją. Ludzi można co najwyżej prowadzić. Jeżeli chcesz uzyskać najlepsze rezultaty, w pełni wykorzystując umiejętności członków zespołu, powinieneś ich motywować. Trzeba zaspokajać potrzeby zespołu i jego indywidualnych członków, rozwiązywać problemy i ich wspierać. Ludzie osiągają najlepsze efekty w środowisku, które wspiera ich potrzeby.
Czas poświęcony na rozwiązywanie tych problemów będzie zwykłym marnotrawstwem. Dlatego ważna jest szybka integracja, automatyczne testy regresywne, wczesne testowanie i natychmiastowa naprawa wykrytych błędów. Naprawienie błędu powinno mieć wyższy priorytet niż jakakolwiek nowa praca.
Zespół wspólnie decyduje, czy kod można uznać za wystarczająco prosty, biorąc pod uwagę cztery atrybuty tworzące akronim TUBE: testowalny (ang. Testable), zrozumiały (ang. Understandable), przeglądalny (and. Browsable) i wytłumaczalny (ang. Explainable).
awanie priorytetów”. od 2011 roku za namową Jima Copliena w Scrum Guide używa się określenia „ordered” zamiast „prioritized”, sugerując ułożenie według kolejności zamiast według priorytetów. Tłumaczone jest to faktem, że Właściciel Produktu może widzieć priorytety ze swojego punktu widzenia, ale kolejność ich implementacji może być inna ze względu na różne czynniki, takie jak wartość biznesowa, ryzyko, zależność implementacji. Właściciel Produktu wybiera stosowne kryteria uporządkowania listy.
Nie powinniśmy pochopnie zmieniać długości Sprintu ustalonej na początku projektu. Z pewnością niedopuszczalna jest modyfikacja długości w zależności od ilości pracy do wykonania i przedłużanie Sprintu, żeby ukończyć pracę na zasadzie „krótkiej dogrywki”. Jest to kusząca opcja, jeżeli zespół twierdzi, że dwa dni wystarczą mu na dostarczenie wszystkich funkcjonalności, podczas gdy ukończona jest jedynie połowa. Poza złamaniem zasad Scrum takie postępowanie wiąże się z wyrabianiem złych nawyków, brakiem dyscypliny i utratą okazji do nauki na własnych błędach. Czasem Zespół musi ponieść porażkę, aby nauczyć się lepiej pracować i rozumieć konsekwencje wyborów dokonywanych w Sprincie.
Sprinty następują po sobie bez przerw. Jeżeli Zespół uważa, że tempo iteracji jest zbyt wyczerpujące albo pojawiają się nadgodziny, należy zmniejszyć zakres pracy w Sprincie.
Właściciel Produktu może zaakceptować lub odrzucić wynik Sprintu, istnieją zatem dwie możliwości: Sprint zaakceptowany i Sprint odrzucony. Jest jeszcze trzecia możliwość – Sprint anulowany. Anulowanie Sprintu (ang. Sprint cancellation), czyli przerwanie pracy przed upłynięciem timeboxu, jest bardzo poważną decyzją, wykonywaną zgodnie ze ścisłymi zasadami postępowania oraz skutkującą nieprzyjemnymi konsekwencjami.
Scrum Master pilnuje tych zasad (przynajmniej w pierwszych Sprintach Zespołu), szybko przerywając niepożądane wypowiedzi i reagując na próby rozproszenia Zespołu. Jego zadaniem jest nauka utrzymania skupienia i uwidocznienie zaangażowania każdego z członków Zespołu we wspólne osiągnięcie
Planowanie Sprintu, Zespół Deweloperski skupia się na pracy w danym Sprincie. Zarazem nie rozmyśla dalej „co by było, gdyby”, nie trwa w generowaniu możliwych rozwiązań. Interesuje ich jedynie perspektywa tego Sprintu i jego celu. Osiągnięcie celu Sprintu to jedyna rzecz, jaka powinna w tym momencie interesować zespół. Dlatego tak bardzo istotne jest podkreślanie ustalenia dobrego Celu Sprintu i dopiero określenie pracy do wykonania.
Lider powinien również zapewniać motywację i oparcie w trudnych chwilach. Kiedy w trakcie pracy pojawiają się trudności, a jest to nieuchronne, członkowie Zespołu będą zwracać się do swojego lidera i w nim szukać oparcia. Jeżeli lider będzie nadal zarażał optymizmem i zagrzewał członków Zespołu do dalszej pracy, to przeniosą dla niego przysłowiowe góry. Jeżeli zaś skupi się na sobie i również wpadnie w mroczny nastrój, to atmosfera podczas pracy nad projektem wyssie energię z każdego.
Lider nie powinien widzieć rzeczy gorszymi niż są. Powinien zobaczyć je dokładnie takimi, jakimi są, i zrobić wszystko, żeby stały się lepsze. Jeżeli jakiś element jest zły i nie działa, to narzekanie nie zmieni nic oprócz pogorszenia i tak już niezdrowej atmosfery. W obliczu problemów Scrum Master kieruje uwagę Zespołu na szukanie rozwiązań, przypomina poprzednie sukcesy i dopinguje Zespół.
Następnie prosimy uczestników o opinię na temat przebiegu Retrospekcji. Można to zrobić, korzystając z wykresu R.O.T.I. (ang. Return on Time Invested). Na wykresie każdy z uczestników zaznacza w skali 1-5, jak według niego spożytkował czas. 1 – Zdecydowanie mniejsza wartość niż zainwestowany czas. 3 – Tyle samo uzyskanej wartości, ile zainwestowanego czasu. 5 – Zdecydowanie więcej wartości niż zainwestowanego czasu. Oczywiście, jeżeli wynikiem tego ćwiczenia będzie zgrupowanie wyników w zakresie 3 i mniej, to warto spytać uczestników, co ich zdaniem może podnieść ten wynik. Jest to retrospekcja Retrospekcji.
Detailed Appropriately, czyli odpowiednio doprecyzowany. Innymi słowy, elementy Rejestru Produktu powinny mieć odpowiedni poziom szczegółowości. Co to znaczy odpowiedni poziom? Elementy, które mają być ukończone w trakcie najbliższych dwóch Sprintów (takie jak na przykład User Story), powinny zawierać wystarczającą ilość informacji, żeby Zespół mógł je wykonać. Elementy, które nie będą wykonane w najbliższym czasie, powinny zawierać mniejszą liczbę szczegółów. Im bardziej odległy jest element, tym mniej szczegółów powinien posiadać. Takie działanie sprawia, że Rejestr Produktu jest gotowy dla Zespołu w wystarczającym stopniu i nie tracimy czasu na opracowywanie rzeczy, które nie są implementowane teraz i może wcale nie zostaną wdrożone. Estimated, czyli oszacowany. Oszacowanie elementów znajdujących się w Rejestrze Produktu ma bardzo duże znaczenie z punktu widzenia planowania pracy i wydań produktu. Trzeba dbać o to, żeby wszystkie elementy potrzebne do ukończenia produktu znalazły się na tej liście i zostały oszacowane. Oczywiście, im bardziej odległy jest zaplanowany termin ich wykonania, tym mniej o nich wiemy. Zupełnie normalna jest więc mniejsza dokładność oszacowania wielkości odległego elementu. Więcej informacji na temat szacowania i planowania znajduje się w rozdziałach 12 i 13. Emergent, czyli ciągle powstający. Rejestr Produktu istnieje tak długo jak sam produkt i stale ulega zmianom. Elementy będą dodawane, usuwane, dzielone na mniejsze i zmieniane. W miarę zdobywania wiedzy o produkcie, technologii, potrzebach klienta możemy również zmieniać priorytety i oszacowania. Punkt ten odzwierciedla zasadę Agile – zmiana jest mile widziana. Prioritized, czyli uporządkowany pod względem priorytetów. Obecnie zamiast używać pojęcia priorytety mówi się o odpowiednim miejscu na liście, jednak w gruncie rzeczy chodzi o to samo. Elementy, których wykonanie przyniesie największą wartość, powinny znajdować się na górze Rejestru Produktu. W ten sposób Zespół wykonując kolejne elementy z listy, będzie dostarczał największą możliwą wartość produktu. Oczywiście korzystając ze Scruma po zmianach w 2011 roku, w tym punkcie mamy na myśli uporządkowanie pod względem kolejności, a nie priorytetów.
Jeżeli Zespół korzysta z dobrze rozwiniętego środowiska testów automatycznych lub Ciągłej Integracji, dobrą praktyką jest przygotowanie testów opisujących otwarte defekty. Testy te mogą być skonfigurowane tak, aby nie wpływać na stan wynikowy buildu systemu, ale zawsze są obecne w raportach jako znane błędy.
Narzucanie architekta zespołom źle na nie działa, bo nie czują się one odpowiedzialne za kształt i jakość rozwiązania. Złym pomysłem jest też architekt projektujący rozwiązanie na takim poziomie, że zespół ma to tylko zaimplementować.
Wymagania zazwyczaj są niejasne. Wymagania są kością w gardle, która sprawia, że rozmowy między klientem a Zespołem albo biznesem a IT łatwo eskalują w konflikty i szukanie winnego. Czasami okazuje się, że autor wymagania sam już nie pamięta, co miał na myśli, formułując wymaganie. Zgodnie ze słowami Alberta Einsteina można powiedzieć: „Jeśli ktoś nie umie czegoś wytłumaczyć innej osobie, to znaczy, że sam tego nie rozumie”. W tradycyjnym podejściu do wytwarzania oprogramowania kolejni specjaliści przekazują sobie spisaną specyfikację i wykonują pracę tak, jak ją zrozumieli.
Użytkownik nigdy nie wie, czego chce, dopóki system nie będzie w użyciu. Jest to reguła będę wiedział, kiedy to zobaczę. (ang. I’ll Know It When I See It). Prawo Humphreya
Jak głosi stare powiedzenie, założenia są przyczyną wszelkich niepowodzeń. Im więcej założeń przyjmiesz, tym więcej możliwości pomyłki.
Cytaty:
Czy w takim razie model kaskadowy można stosować z powodzeniem? Oczywiście, że tak. Muszą być jednak spełnione pewne warunki: zakres projektu i wymagania się nie zmieniają; zespół doskonale zna technologię; zespół dobrze rozumie wymagania; zespół dobrze oszacował zakres prac do wykonania; nic nie wpłynie na zmianę planu.
Jednak, jak powiedział marszałek Helmuth von Moltke, „Żaden plan nie przetrwa kontaktu z wrogiem”. Rzeczywistość potrafi zaskakiwać i psuć nawet najlepsze plany, szczególnie, gdy pracujemy z ludźmi. Dlatego zawsze należy pamiętać, po co stworzyliśmy plan. Nie jest on niezmiennym artefaktem wyrytym w kamieniu jak kalendarz Azteków. To zestaw kroków na drodze do celu, biorący pod uwagę to, co do tej pory wiemy o drodze. Jeżeli sytuacja się zmieni, będzie nam potrzebny nowy plan.
Naszym najwyższym priorytetem jest zadowolenie klienta osiągane przez wczesne i ciągłe dostarczanie wartościowego oprogramowania. 2. Zmiany w wymaganiach są mile widziane nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta. 3. Dostarczaj oprogramowanie często, w odstępach czasu od kilku tygodni do kilku miesięcy, preferując mniejsze odstępy czasu. 4. Ludzie biznesu i deweloperzy muszą pracować razem codziennie przez cały czas trwania projektu. 5. Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie, którego potrzebują, i zaufaj im, że praca zostanie wykonana. 6. Najskuteczniejszą i najwydajniejszą metodą przekazywania informacji w zespole deweloperów jest rozmowa w cztery oczy. 7. Działające oprogramowanie jest podstawową miarą postępu. 8. Procesy Agile promują zrównoważony rozwój [oprogramowania]. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymać stałe tempo. 9. Ciągła koncentracja na technicznej doskonałości i dobrym projekcie (ang. design) poprawia zwinność (ang. agility). 10. Prostota – sztuka zwiększania ilości pracy niewykonanej – jest niezbędna. 11. Najlepsze architektury, wymagania i projekty wyłaniają się z samoorganizujących się zespołów. 12. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje zachowanie.
W trakcie trwania iteracji nie dopuszcza się dużych zmian, ponieważ cały plan pracy przestaje mieć sens i lepiej jest zacząć od nowa. Zmiany mają swoje konsekwencje. Korzystanie z metod zwinnych nie daje klientowi możliwości całkowitej zmiany kierunku projektu bez ich poniesienia. Jeżeli umówiliśmy się na zbudowanie samochodu i mamy gotowe podwozie, to nie można teraz zrobić jachtu. Zwinność ma swoje granice. Jeżeli jednak klient kategorycznie stwierdzi, że już nie potrzebuje samochodu, lecz jachtu i jest gotowy poświęcić zużyte do tej pory środki, to ma prawo do takiej decyzji.
Główną przyczyną nieporozumień podczas pracy nad projektem jest przepaść komunikacyjna pomiędzy sferą biznesu a zespołami deweloperskimi. Jednym ze sposobów na zmniejszenie tej różnicy jest zbliżenie tych dwóch posługujących się swoimi językami światów przez ich połączenie na co dzień. Przedstawiciele świata biznesu dowiedzą się więcej na temat rozwiązań informatycznych, ich ceny i konsekwencji utrzymania. Pracownicy IT będą z kolei uczyć się podstaw myślenia biznesowego, co pomoże im zrozumieć potrzeby i zaproponować najlepsze rozwiązania zamiast takich, które biznesowi wydają się oczywiste.
Produktywność mierzona w punktach funkcyjnych jest zazwyczaj dziesięć razy większa w zespołach samoorganizujących się. Głównymi czynnikami blokującymi zwinność projektów są kontrola i brak zaufania ze strony kierownictwa.
Kod napisany w pośpiechu i bez przemyślenia sprawia wiele problemów, zarówno w utrzymaniu, jak i podczas rozwijania systemu. Na początku liczymy na to, że na dalszych etapach będziemy dostarczać funkcjonalności szybciej, ale wraz ze wzrostem złożoności systemu nasz plan odwraca się o sto osiemdziesiąt stopni i działa przeciwko nam. Pojawiają się wtedy nowe problemy, począwszy od brakującej dokumentacji, przez zduplikowany kod, na modułach mających zbyt wiele funkcji skończywszy
Ostatnio popularne stało się pojęcie Total Cost of Ownership (TCO), czyli całkowity koszt posiadania. Bierze on pod uwagę nie tylko koszt wyprodukowania sytemu w analizowanym momencie, ale także koszt utrzymania go w przyszłości. Biznes powinien być świadom tego problemu i brać go pod uwagę przy podejmowaniu decyzji odnośnie do budowy systemu. IT powinno wspomagać biznes, informując go o dokładnych konsekwencjach wyboru architektury systemu i podejścia.
Projektant wie, że osiągnął doskonałość, nie wtedy, kiedy nie można nic dodać, ale wtedy, kiedy nie można nic ująć.
Patrząc na Manifest i 12 Zasad Agile, można łatwo sprawdzić, czy praktyki wykorzystywane podczas pracy nad projektem mogą być uznane za zwinne i czy można powiedzieć „używamy Agile”. Często jednak zdarza się, że przy wprowadzaniu Agile do organizacji Manifest jest rozumiany zero-jedynkowo – jesteśmy Agile, więc nie piszemy dokumentacji, jesteśmy Agile, więc nie planujemy, jesteśmy Agile, więc nie mamy standardów.
Dużo bardziej skuteczna jest relacja zbudowana na trosce o wspólne cele. Dbaj o częstą interakcję i staraj się, jak najlepiej zrozumieć świat i potrzeby biznesu. Często prezentuj postęp prac i wyniki, żeby zbudować zaufanie klienta, pokazując mu, że został wysłuchany, a kierunek projektu jest wytyczony na podstawie informacji zwrotnej.
Pracownik nie jest winien swojemu pracodawcy służalczego posłuszeństwa. Jest mu jedynie winien usługę, za którą otrzymuje zapłatę będącą nie łaską, ale zasłużonym wynagrodzeniem.
Zarządzać można majątkiem, nieruchomościami, plantacją. Ludzi można co najwyżej prowadzić. Jeżeli chcesz uzyskać najlepsze rezultaty, w pełni wykorzystując umiejętności członków zespołu, powinieneś ich motywować. Trzeba zaspokajać potrzeby zespołu i jego indywidualnych członków, rozwiązywać problemy i ich wspierać. Ludzie osiągają najlepsze efekty w środowisku, które wspiera ich potrzeby.
Czas poświęcony na rozwiązywanie tych problemów będzie zwykłym marnotrawstwem. Dlatego ważna jest szybka integracja, automatyczne testy regresywne, wczesne testowanie i natychmiastowa naprawa wykrytych błędów. Naprawienie błędu powinno mieć wyższy priorytet niż jakakolwiek nowa praca.
Zespół wspólnie decyduje, czy kod można uznać za wystarczająco prosty, biorąc pod uwagę cztery atrybuty tworzące akronim TUBE: testowalny (ang. Testable), zrozumiały (ang. Understandable), przeglądalny (and. Browsable) i wytłumaczalny (ang. Explainable).
awanie priorytetów”. od 2011 roku za namową Jima Copliena w Scrum Guide używa się określenia „ordered” zamiast „prioritized”, sugerując ułożenie według kolejności zamiast według priorytetów. Tłumaczone jest to faktem, że Właściciel Produktu może widzieć priorytety ze swojego punktu widzenia, ale kolejność ich implementacji może być inna ze względu na różne czynniki, takie jak wartość biznesowa, ryzyko, zależność implementacji. Właściciel Produktu wybiera stosowne kryteria uporządkowania listy.
Nie powinniśmy pochopnie zmieniać długości Sprintu ustalonej na początku projektu. Z pewnością niedopuszczalna jest modyfikacja długości w zależności od ilości pracy do wykonania i przedłużanie Sprintu, żeby ukończyć pracę na zasadzie „krótkiej dogrywki”. Jest to kusząca opcja, jeżeli zespół twierdzi, że dwa dni wystarczą mu na dostarczenie wszystkich funkcjonalności, podczas gdy ukończona jest jedynie połowa. Poza złamaniem zasad Scrum takie postępowanie wiąże się z wyrabianiem złych nawyków, brakiem dyscypliny i utratą okazji do nauki na własnych błędach. Czasem Zespół musi ponieść porażkę, aby nauczyć się lepiej pracować i rozumieć konsekwencje wyborów dokonywanych w Sprincie.
Sprinty następują po sobie bez przerw. Jeżeli Zespół uważa, że tempo iteracji jest zbyt wyczerpujące albo pojawiają się nadgodziny, należy zmniejszyć zakres pracy w Sprincie.
Właściciel Produktu może zaakceptować lub odrzucić wynik Sprintu, istnieją zatem dwie możliwości: Sprint zaakceptowany i Sprint odrzucony. Jest jeszcze trzecia możliwość – Sprint anulowany. Anulowanie Sprintu (ang. Sprint cancellation), czyli przerwanie pracy przed upłynięciem timeboxu, jest bardzo poważną decyzją, wykonywaną zgodnie ze ścisłymi zasadami postępowania oraz skutkującą nieprzyjemnymi konsekwencjami.
Scrum Master pilnuje tych zasad (przynajmniej w pierwszych Sprintach Zespołu), szybko przerywając niepożądane wypowiedzi i reagując na próby rozproszenia Zespołu. Jego zadaniem jest nauka utrzymania skupienia i uwidocznienie zaangażowania każdego z członków Zespołu we wspólne osiągnięcie
Planowanie Sprintu, Zespół Deweloperski skupia się na pracy w danym Sprincie. Zarazem nie rozmyśla dalej „co by było, gdyby”, nie trwa w generowaniu możliwych rozwiązań. Interesuje ich jedynie perspektywa tego Sprintu i jego celu. Osiągnięcie celu Sprintu to jedyna rzecz, jaka powinna w tym momencie interesować zespół. Dlatego tak bardzo istotne jest podkreślanie ustalenia dobrego Celu Sprintu i dopiero określenie pracy do wykonania.
Lider powinien również zapewniać motywację i oparcie w trudnych chwilach. Kiedy w trakcie pracy pojawiają się trudności, a jest to nieuchronne, członkowie Zespołu będą zwracać się do swojego lidera i w nim szukać oparcia. Jeżeli lider będzie nadal zarażał optymizmem i zagrzewał członków Zespołu do dalszej pracy, to przeniosą dla niego przysłowiowe góry. Jeżeli zaś skupi się na sobie i również wpadnie w mroczny nastrój, to atmosfera podczas pracy nad projektem wyssie energię z każdego.
Lider nie powinien widzieć rzeczy gorszymi niż są. Powinien zobaczyć je dokładnie takimi, jakimi są, i zrobić wszystko, żeby stały się lepsze. Jeżeli jakiś element jest zły i nie działa, to narzekanie nie zmieni nic oprócz pogorszenia i tak już niezdrowej atmosfery. W obliczu problemów Scrum Master kieruje uwagę Zespołu na szukanie rozwiązań, przypomina poprzednie sukcesy i dopinguje Zespół.
Następnie prosimy uczestników o opinię na temat przebiegu Retrospekcji. Można to zrobić, korzystając z wykresu R.O.T.I. (ang. Return on Time Invested). Na wykresie każdy z uczestników zaznacza w skali 1-5, jak według niego spożytkował czas. 1 – Zdecydowanie mniejsza wartość niż zainwestowany czas. 3 – Tyle samo uzyskanej wartości, ile zainwestowanego czasu. 5 – Zdecydowanie więcej wartości niż zainwestowanego czasu. Oczywiście, jeżeli wynikiem tego ćwiczenia będzie zgrupowanie wyników w zakresie 3 i mniej, to warto spytać uczestników, co ich zdaniem może podnieść ten wynik. Jest to retrospekcja Retrospekcji.
Detailed Appropriately, czyli odpowiednio doprecyzowany. Innymi słowy, elementy Rejestru Produktu powinny mieć odpowiedni poziom szczegółowości. Co to znaczy odpowiedni poziom? Elementy, które mają być ukończone w trakcie najbliższych dwóch Sprintów (takie jak na przykład User Story), powinny zawierać wystarczającą ilość informacji, żeby Zespół mógł je wykonać. Elementy, które nie będą wykonane w najbliższym czasie, powinny zawierać mniejszą liczbę szczegółów. Im bardziej odległy jest element, tym mniej szczegółów powinien posiadać. Takie działanie sprawia, że Rejestr Produktu jest gotowy dla Zespołu w wystarczającym stopniu i nie tracimy czasu na opracowywanie rzeczy, które nie są implementowane teraz i może wcale nie zostaną wdrożone. Estimated, czyli oszacowany. Oszacowanie elementów znajdujących się w Rejestrze Produktu ma bardzo duże znaczenie z punktu widzenia planowania pracy i wydań produktu. Trzeba dbać o to, żeby wszystkie elementy potrzebne do ukończenia produktu znalazły się na tej liście i zostały oszacowane. Oczywiście, im bardziej odległy jest zaplanowany termin ich wykonania, tym mniej o nich wiemy. Zupełnie normalna jest więc mniejsza dokładność oszacowania wielkości odległego elementu. Więcej informacji na temat szacowania i planowania znajduje się w rozdziałach 12 i 13. Emergent, czyli ciągle powstający. Rejestr Produktu istnieje tak długo jak sam produkt i stale ulega zmianom. Elementy będą dodawane, usuwane, dzielone na mniejsze i zmieniane. W miarę zdobywania wiedzy o produkcie, technologii, potrzebach klienta możemy również zmieniać priorytety i oszacowania. Punkt ten odzwierciedla zasadę Agile – zmiana jest mile widziana. Prioritized, czyli uporządkowany pod względem priorytetów. Obecnie zamiast używać pojęcia priorytety mówi się o odpowiednim miejscu na liście, jednak w gruncie rzeczy chodzi o to samo. Elementy, których wykonanie przyniesie największą wartość, powinny znajdować się na górze Rejestru Produktu. W ten sposób Zespół wykonując kolejne elementy z listy, będzie dostarczał największą możliwą wartość produktu. Oczywiście korzystając ze Scruma po zmianach w 2011 roku, w tym punkcie mamy na myśli uporządkowanie pod względem kolejności, a nie priorytetów.
Jeżeli Zespół korzysta z dobrze rozwiniętego środowiska testów automatycznych lub Ciągłej Integracji, dobrą praktyką jest przygotowanie testów opisujących otwarte defekty. Testy te mogą być skonfigurowane tak, aby nie wpływać na stan wynikowy buildu systemu, ale zawsze są obecne w raportach jako znane błędy.
Narzucanie architekta zespołom źle na nie działa, bo nie czują się one odpowiedzialne za kształt i jakość rozwiązania. Złym pomysłem jest też architekt projektujący rozwiązanie na takim poziomie, że zespół ma to tylko zaimplementować.
Wymagania zazwyczaj są niejasne. Wymagania są kością w gardle, która sprawia, że rozmowy między klientem a Zespołem albo biznesem a IT łatwo eskalują w konflikty i szukanie winnego. Czasami okazuje się, że autor wymagania sam już nie pamięta, co miał na myśli, formułując wymaganie. Zgodnie ze słowami Alberta Einsteina można powiedzieć: „Jeśli ktoś nie umie czegoś wytłumaczyć innej osobie, to znaczy, że sam tego nie rozumie”. W tradycyjnym podejściu do wytwarzania oprogramowania kolejni specjaliści przekazują sobie spisaną specyfikację i wykonują pracę tak, jak ją zrozumieli.
Użytkownik nigdy nie wie, czego chce, dopóki system nie będzie w użyciu. Jest to reguła będę wiedział, kiedy to zobaczę. (ang. I’ll Know It When I See It). Prawo Humphreya
Jak głosi stare powiedzenie, założenia są przyczyną wszelkich niepowodzeń. Im więcej założeń przyjmiesz, tym więcej możliwości pomyłki.
November 27, 2024
Całkiem dobre rozwinięcia punktów jednak już od czasu wydania wyszło kilka updatow scrum guide.
Niepotrzebne spolszczenia kluczowych terminów, które bywają dezorientujące
Niepotrzebne spolszczenia kluczowych terminów, które bywają dezorientujące
January 6, 2025
Dobrze omówione praktyki i aspekty Scrum plus generalnie omowienie Agile 4/5
Displaying 1 - 3 of 3 reviews