Jak oswoić Agile
Jak oswoić Agile
Poradnik praktycznie zwinny
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
Spis treści
- 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
60-dniowa gwarancja zwrotu pieniędzy
Leanpub posiada 60-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..
Zarób $8 przy zakupie za $10 i $16 przy zakupie za $20
Płacimy 80% tantiem za zakupy o wartości $7,99 lub więcej oraz 80% tantiem minus stała opłata w wysokości 50 centów za zakupy o wartości między $0,99 a $7,98. Zarabiasz $8 przy sprzedaży za $10 i $16 przy sprzedaży za $20. Więc jeśli sprzedamy 5000 niezwrotnych egzemplarzy twojej książki za $20, zarobisz $80,000.
(Tak, niektórzy autorzy zarobili już znacznie więcej na Leanpub.)
W rzeczywistości autorzy zarobiliponad 13 milionów dolarów pisząc, publikując i sprzedając na Leanpub.
Dowiedz się więcej o pisaniu na Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets, and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
