Jak oswoić Agile
Jak oswoić Agile
$4.99
Minimalna cena
$9.99
Sugerowana cena
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 autorach

Jakub Bażela
Jakub Bażela

Agile Coach i trener Management 3.0, fan Star Wars, pisze na www.baze.la

Arkadiusz Benedykt
Arkadiusz Benedykt

Programista, developer, trener z wieloletnim doświadczeniem. Zawodowo, nieprzerwanie w branży IT pracuje od 2005 roku.

Propagator testów jednostkowych oraz podejścia TDD w którym posiada już ponad 9 lat. Ciągle poszukuje nowych dróg rozwoju aby tworzyć lepsze oprogramowanie jeszcze lepiej spełniające potrzeby użytkowników.

Blog:  benedykt.net

LinkedIn: https://www.linkedin.com/in/arkadiuszbenedykt/

Andy Brandt
Andy Brandt

Andy Brandt is a manager and technology team leader with more than two decades of experience in the IT and telecoms sectors. His diverse experience includes both work for large multinationals and five startups ranging from a computer magazine to software company. Andy has been involved in the Agile movement since 2006. He achieved national recognition as the first certified Professional Scrum Trainer in Poland and has been instrumental in popularizing Scrum in that country.

Andy's specialty is building & leading motivated technology teams.

To learn more visit Andy's LinkedIn profile or visit Andy's blog: The Pragmatic Leader.

Rafał Markowicz
Rafał Markowicz

Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile pracujący z zespołami developerskimi, jednocześnie ekspert w zakresie inżynierii testów i zapewnienia jakości.

Zobacz blog i profil LinkedIn.

O współpracownikach

Kinga Grabowska
Kinga Grabowska

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..

Free Updates. Free App. 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), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). 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

Pisz i publikuj na platformie Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Przeczytaj więcej o pisaniu na platformie Leanpub