Jak oswoić Agile
Ta książka jest w 100% ukończona
Ukończono 2018-10-17
O książce
Przez ponad dekadę istnienia firmy Code Sprinters, dostawaliśmy setki pytań od naszych klientów, uczestników szkoleń i członków zespołów, którym doradzaliśmy jak dobrze stosować metody z rodziny Agile. W pewnym momencie zauważyliśmy powtarzające się wzorce i chcąc ułatwić pytającym odnajdywanie potrzebnej wiedzy, zaczęliśmy ją katalogować i zapisywać w postaci luźnych notatek, wpisów na blogach, prezentacji na konferencjach. Idąc krok dalej, poddaliśmy rewizji to, co sami znamy ze świata Agile i Scrum (to się chyba nazywa inspekcja i adaptacja, nieprawdaż?) i tak powstało "Jak oswoić Agile". Nazwaliśmy go poradnikiem praktycznie zwinnym, bo zarówno szukający porad "jak zacząć?", jak i osoby z doświadczeniem w zwinnej pracy odnajdą tu wiele aplikowalnej wiedzy.
O współpracownikach
Table of Contents
- Wstęp
-
Scrum – jak zacząć?
- Po pierwsze – Scrum Guide
- Po drugie – szkolenie
- Po trzecie – społeczność
- Po czwarte – praktyka
-
Wszystko, czego nie znajdziecie w Scrum Guide
- Minimalna i maksymalna wielkość zespołu deweloperskiego
- Długość sprintu oraz sposób jej ustalania i obliczania
- Kiedy sprinty mają się zaczynać i kończyć
- Czas trwania zdarzeń w Scrumie
- Pielęgnacja backlogu produktu
- Planowanie sprintu jedno- lub dwuetapowe
- „Commitment” w Scrumie
- Zmiany zakresu prac w czasie sprintu
- Daily Scrum na stojąco i koniecznie rano?
- Feedback w czasie przeglądu sprintu
- Wydania produktu
- Scrum Master a retrospekcja sprintu
- User Stories oraz kryteria akceptacyjne
- Niezależność i pełna zastępowalność w zespole deweloperskim
- O łączeniu ról i kierownikach słów kilka
- Warto rozmawiać
- Scrum Guide nie gryzie!
-
Co Scrum Master robi przez cały dzień?
- Co powinien robić Scrum Master?
- Pozorne lenistwo
- Narzędzia Scrum Mastera
- Aktywne „nic-nieróbstwo”
- Wszyscy muszą być zajęci?
- A gdy już Scrum Master wydaje się niepotrzebny…
-
Czy Scrum Master może być Product Ownerem?
- Czy wolno mi być Scrum Masterem i Product Ownerem w tym samym zespole?
- Product Owner za mało czasu spędza z Deweloperami, by być skutecznym Scrum Masterem
- Różne odpowiedzialności ciężko ze sobą pogodzić
- Ciężko doradzać samemu sobie
- Product Owner zajmuje się produktem, niekoniecznie organizacją
- Jeśli już trzeba łączyć role…
- List do Scrum Masterów
-
Jak dobrze przeprowadzić Planowanie Sprintu?
- Co przygotować przed Planowaniem?
- Elementy Backlogu Produktu
- Jak wygląda samo Planowanie?
- Co po Planowaniu?
-
Przepis na retrospekcję sprintu
- Degradacja Scruma krok po kroku
- Retrospekcja to nie pręgierz
- Trzeba mierzyć siły na zamiary
- Inspect & Adapt
- Forma ma znaczenie
- Przepis na dobrą retrospekcję
-
Delegation Poker w praktyce
- Dyktatorzy i anarchiści
- Siedem poziomów delegacji – Delegation Poker
- Jak zbudować Delegation Board metodą Delegation Pokera?
- Jakie są zalety Tablicy Delegacji?
-
10 praktyk hańbiących dewelopera
- 1. Mój kod moją twierdzą
- 2. Nie commituję kodu do repozytorium
- 3. U mnie wszystko działa
- 4. CTRL+C, CTRL+V, czyli metoda Copy’ego Pejsta
- 5. Brak wcięć – brak formatowania kodu
- 6. Brak modułowości, czyli wielka micha spaghetti
- 7. Rodzynki w misce spaghetti, czyli czego nie chcemy w kodzie aplikacji
- 8. Przedwczesna optymalizacja
- 9. TODO, czyli poprawię to później
- 10. Niemyślenie o przyszłości
-
13 powodów nieudanej automatyzacji testów
- 1. Musimy używać jednego standardowego narzędzia
- 2. Musimy mieć kompletny „framework testowy”
- 3. Musimy mieć narzędzie „dla testerów”
- 4. „Nie wymagajmy od testerów umiejętności programowania”
- 5. Potrzeba ekspertów!
- 6. Tylko testy „czarnoskrzynkowe” są wiarygodne
- 7. Sprawdźmy wszystko przy okazji…
- 8. Skoro test się wykonał, to wszystko działa
- 9. Żeby testować, trzeba znać produkt
- 10. Jak, u licha, przetestować coś takiego…?!
- 11. Nie mamy czasu na automatyzację
- 12. Nie stać nas na to
- 13. Już za późno / jeszcze za wcześnie na automatyzację
- Jak zapewnić sukces automatyzacji testów?
-
Definition of Done dla produktu czy wymagania?
- Co to jest DoD?
- Co warto wiedzieć o DoD
- Co umieszczamy w DoD?
- Jak DoD ma się do kryteriów akceptacyjnych wymagań?
- DoD to nie artefakt w Scrumie
- Czy DoD może być spełnione tylko dla jednego z kilku wymagań?
-
Metoda triangulacji, czyli jak budowane są produkty
- Jak działa GPS
- W poszukiwaniu produktu
- W poszukiwaniu implementacji
- 1 test to za mało
- Dlaczego TDD jest efektywne
- Ludzie i relacje ponad procesy i narzędzia
- Notatki
O wydawcy
This book is published on Leanpub by Code Sprinters
45-dniowa gwarancja zwrotu pieniędzy
Leanpub posiada 45-dniową gwarancję bezwarunkowego zwrotu pieniędzy na każdy zakup w dwóch prostych krokach. Zwroty obsługujemy ręcznie więc środki mogą się pojawić na twoim koncie po kilku dniach. Zobacz warunki świadczenia usług..
