Agile. Przewodnik po zwinnych metodykach programowania

Table of contents

1. okładka
2. tytuł strony
3. Prawa autorskie strony
4. Opinie o książce Agile. Przewodnik po zwinnych metodykach programowania
5. Dedykacja
6. Spis treści
7. Przedmowa
8. Wprowadzenie
   1. Podziękowania
9. Rozdział 1. Poznaj Agile
   1. Czym jest Agile?
   2. Kto powinien przeczytać tę książkę?
   3. Cele do osiągnięcia
   4. Wpakujemy Ci Agile do głowy wszelkimi możliwymi sposobami
   5. Struktura książki
10. Rozdział 2. Wartości Agile
    1. Lider zespołu, architekt i kierownik projektu wchodzą do baru...
    2. Uniwersalne rozwiązania nie istnieją
    3. Podejście zwinne nas uratuje! Prawda?
       1. Wprowadzenie podejścia zwinnego robi różnicę
       2. Efekty lepsze niż bez stosowania technik
    4. Niespójna perspektywa
       1. W jaki sposób niespójna perspektywa powoduje problemy w projekcie?
       2. Dlaczego niespójna perspektywa prowadzi do wyników tylko trochę lepszych niż bez stosowania technik?
    5. Manifest Agile pomaga zespołom zrozumieć cel stosowania poszczególnych technik
       1. Ludzie i interakcje mają większe znaczenie niż procesy i narzędzia
       2. Działające oprogramowanie jest ważniejsze od wyczerpującej dokumentacji
       3. Współpraca z klientem jest ważniejsza od negocjowania kontraktu
       4. Reagowanie na zmiany jest ważniejsze niż realizowanie planu
       5. Zasady są ważniejsze niż techniki
    6. Jak zrozumieć słonia?
       1. Metodyki pomagają wprowadzić wszystkie elementy jednocześnie
    7. Od czego zacząć wprowadzanie nowej metodyki?
11. Rozdział 3. Zasady Agile
    1. Dwanaście zasad podejścia zwinnego
    2. Klient ma zawsze rację, prawda?
       1. „Rób tak, jak mówię, a nie tak, jak powiedziałem”
    3. Dostarczanie projektu
       1. Zasada numer 1. Naszym priorytetem jest zapewnianie satysfakcji klientów dzięki szybkiemu i ciągłemu dostarczaniu wartościowego oprogramowania
       2. Zasada numer 2. Jesteśmy otwarci na zmiany wymagań nawet na późnych etapach prac. Procesy zwinne pozwalają poradzić sobie ze zmianami w celu zapewnienia klientom przewagi konkurencyjnej
       3. Zasada numer 3. Często dostarczamy działające oprogramowanie; zajmuje to od kilku tygodni do kilku miesięcy, przy czym preferowane są krótsze okresy
       4. Lepszy sposób dostarczania oprogramowania do czytnika e-booków
    4. Komunikacja i współpraca
       1. Zasada numer 4. Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji zespołowi programistów i komunikowania się w jego ramach jest bezpośrednia rozmowa
       2. Zasada numer 5. Pracownicy biznesowi i programiści muszą codziennie współpracować przy projekcie
       3. Zasada numer 6. Opieraj projekty na zmotywowanych osobach. Zapewnij im potrzebne środowisko i wsparcie oraz uwierz, że wykonają zadanie
       4. Lepsza komunikacja w projekcie czytnika e-booków
    5. Przebieg projektu — posuwanie się do przodu
       1. Zasada numer 7. Główną miarą postępów jest działające oprogramowanie
       2. Zasada numer 8. W procesach zwinnych ważna jest możliwość utrzymania tempa programowania. Sponsorzy, programiści i użytkownicy powinni móc w nieskończoność utrzymywać stałe tempo pracy
       3. Zasada numer 9. Ciągła troska o techniczną doskonałość i dobry projekt są zgodne z podejściem zwinnym
       4. Lepsze środowisko pracy dla zespołu rozwijającego czytnik e-booków
    6. Nieustanne ulepszanie projektów i zespołu
       1. Zasad numer 10. Konieczna jest prostota rozumiana jako sztuka maksymalizowania niewykonywanej pracy
       2. Zasada numer 11. Najlepsze architektury, wymagania i projekty są owocem pracy samoorganizujących się zespołów
       3. Zasada numer 12. Zespół regularnie zastanawia się nad tym, jak zwiększyć swoją efektywność, a następnie odpowiednio usprawnia i dostosowuje swoje postępowanie
    7. Projekt w podejściu zwinnym — łączenie wszystkich zasad
12. Rozdział 4. Scrum i samoorganizujące się zespoły
    1. Zasady podejścia Scrum
    2. Akt I. Ja móc Scrum?
    3. W zespole stosującym podejście Scrum wszyscy są właścicielami projektu
       1. Mistrz Młyna pomaga zespołowi podejmować decyzje
       2. Właściciel Produktu pomaga zespołowi zrozumieć wartość oprogramowania
       3. Wszyscy są właścicielami projektu
          1. Jak Właściciele Produktu, Mistrzowie Młyna i członkowie zespołu mogą stać się lepszymi świniami?
          2. To nie miejsce dla kurczaków
       4. Wartości ważne w podejściu Scrum
    4. Akt II. Aktualizacje stanu są dobre w sieciach społecznościowych!
    5. Codzienne spotkania są dla całego zespołu
       1. Informacje zwrotne i cykl widoczność – kontrola – adaptacja
       2. Ostatni sensowny moment
          1. Chwileczkę — czy nie da się uniknąć zatorów, wcześniej planując pracę?
       3. Jak przeprowadzać skuteczne codzienne spotkania?
    6. Akt III. Sprintem prosto w mur
    7. Sprinty, plany i retrospekcje
       1. Podejście iteracyjne czy przyrostowe?
       2. Sukces sprintu zależy od Właściciela Produktu
       3. Widoczność i wartość
          1. Inspirujące cele motywują wszystkich w zespole
       4. Jak zaplanować i przeprowadzić efektywny sprint w podejściu Scrum?
    8. Akt IV. Pies goniący samochód
13. Rozdział 5. Planowanie w Scrumie i wspólne zobowiązanie
    1. Akt V. Nie do końca przygotowani na nieoczekiwane
    2. Historie użytkowników, szybkość i ogólnie przyjęte praktyki w podejściu Scrum
       1. Spraw, aby oprogramowanie było przydatne
       2. Historie użytkowników pomagają budować funkcje, które będą stosowane
       3. Warunki satysfakcji
       4. Wartość historii w punktach i szybkość
          1. Dlaczego przypisywanie punktów historiom się sprawdza?
       5. Wykresy postępu prac
       6. Planowanie i przeprowadzanie sprintu z wykorzystaniem historii, punktów, zadań i tablicy zadań
       7. Ogólnie przyjęte praktyki scrumowe
    3. Akt VI. Runda honorowa
    4. Jeszcze o wartościach w Scrumie
       1. Techniki zadziałają także bez uwzględniania wartości (ale nie nazywaj wtedy tego Scrumem)
       2. Czy kultura firmy jest zgodna z wartościami Scruma?
14. Rozdział 6. XP i otwartość na zmiany
    1. Akt I. Nadgodziny
    2. Podstawowe techniki XP
       1. Techniki związane z programowaniem
       2. Techniki związane z integrowaniem kodu
       3. Techniki związane z planowaniem
       4. Techniki związane z zespołem
       5. Dlaczego zespoły boją się zmian i jak techniki mogą pomóc w tym obszarze?
    3. Akt II. Zmieniliśmy strategię, ale ciągle przegrywamy
    4. Wartości XP pomagają zespołom zmienić nastawienie
       1. XP pomaga programistom nauczyć się współpracy z użytkownikami
       2. Techniki są stosowane tylko wtedy, gdy zespół naprawdę w nie wierzy
    5. Budowanie właściwego nastawienia zaczyna się od wartości XP
       1. Wartości XP
       2. Wybrukowane dobrymi chęciami
    6. Akt III. Zmiana sytuacji
    7. Zrozumienie zasad XP pomaga otworzyć się na zmiany
       1. Zasady XP
       2. Zasady XP pomagają zrozumieć planowanie
       3. Zasady XP pomagają w zrozumieniu technik i na odwrót
       4. Pętle z informacjami zwrotnymi
15. Rozdział 7. Prostota i projektowanie przyrostowe w XP
    1. Akt IV. Nadgodziny, część II — znów to samo
    2. Kod i projekt
       1. Antywzorce i „zapachy kodu” (czyli jak stwierdzić, że przekombinowałeś)
       2. Zespoły stosujące XP zwracają uwagę na „zapachy kodu” i poprawiają go
       3. Haczyki, przypadki brzegowe i kod, który ma zbyt wiele zadań
          1. Chwileczkę — ale co złego jest w platformach wielokrotnego użytku?
          2. Na czym polega różnica między biblioteką a platformą?
       4. „Zapachy kodu” oznaczają wysoką złożoność
    3. Decyzje związane z kodem i projektem podejmuj w ostatnim sensownym momencie
       1. Likwidowanie długu technicznego dzięki bezlitosnej refaktoryzacji
          1. Czy refaktoryzacja to nie to samo co przeróbki? I czy przeróbki nie są największym źródłem błędów?
          2. Czy nie lepiej jest zapobiegać takim problemom dzięki przygotowaniu już na początku solidnego projektu? Czy nie jest bezpieczniej budować kod od razu w prawidłowej formie?
       2. Stosuj ciągłą integrację do wykrywania problemów z projektem
       3. Unikaj monolitycznych projektów
    4. Projektowanie przyrostowe i holistyczne techniki XP
       1. Zespoły pracują najlepiej, gdy czują, że mają czas na zastanowienie
       2. Członkowie zespołu ufają sobie i wspólnie podejmują decyzje
       3. W XP techniki dotyczące projektowania, planowania, zespołu i holistyczne tworzą ekosystem sprzyjający innowacjom
       4. Projektowanie przyrostowe a projektowanie z myślą o wielokrotnym użyciu
       5. Gdy jednostki komunikują się w prosty sposób, system może się rozrastać przyrostowo
       6. Dobry projekt to efekt prostych interakcji
    5. Akt V. Ostateczny wynik
16. Rozdział 8. Lean, unikanie marnotrawstwa i spojrzenie na całość
    1. Myślenie odchudzone
       1. Rozumiesz już wiele z wymienionych wartości
       2. Zobowiązanie, myślenie w kategoriach opcji i programowanie oparte na opcjach
          1. Zespoły scrumowe zobowiązują się do dostarczania wartości, ale same określają, jak to zrobić
          2. Projektowanie przyrostowe, programowanie oparte na opcjach i inne techniki zapewniania opcji zespołowi
    2. Akt I. I jeszcze jedna sprawa...
    3. Kreowanie herosów i myślenie magiczne
    4. Eliminowanie marnotrawstwa
       1. Wykorzystaj mapę strumienia wartości, aby lepiej dostrzegać marnotrawstwo
    5. Lepsze zrozumienie produktu
       1. Dostrzeganie całości
       2. Znajdź podstawowe przyczyny wykrytych problemów
    6. Dostarczanie tak wcześnie, jak to możliwe
       1. Wykorzystaj wykres warstwowy do wizualizowania prac w toku
       2. Kontroluj zatory dzięki ograniczaniu zakresu prac w toku
       3. Systemy pull pomagają zespołom eliminować ograniczenia
17. Rozdział 9. Kanban, przepływ i nieustanne doskonalenie
    1. Akt II. Ciągły wyścig
    2. Zasady podejścia Kanban
       1. Znajdź punkt wyjścia i eksperymentalnie wprowadzaj zmiany
          1. Chwileczkę — więc Kanban nie określa, jak mam prowadzić projekty?
       2. Do systemu trafiają historie, wychodzi z niego kod
          1. Każdy zespół programistyczny stosuje system — czy o tym wie, czy nie
          2. Kanban nie jest metodyką budowania oprogramowania ani systemem zarządzania projektami
    3. Doskonalenie procesu za pomocą podejścia Kanban
       1. Wizualizowanie przepływu pracy
          1. Wykorzystaj tablicę kanbanową do zwizualizowania przepływu pracy
       2. Limity prac w toku
          1. Dlaczego nie ustalić limitu prac w toku na jedną funkcję, aby spotykać się po ukończeniu każdego zadania? Czy krótsze pętle nie są lepsze?
    4. Pomiar przepływu i zarządzanie nim
       1. Do pomiaru przepływu i zarządzania nim wykorzystaj skumulowane wykresy przepływu i wykresy warstwowe prac w toku
          1. Budowanie skumulowanego wykresu przepływu i używanie go do obliczania średniego czasu przebywania elementów w systemie
          2. Wykorzystaj skumulowany wykres przepływu do eksperymentowania z limitami prac w toku i zarządzania przepływem
       2. Prawo Little’a pozwala kontrolować przepływ prac w systemie
          1. Skoro zespół i tak musi wykonać wszystkie prace pomocnicze, co się dzieje z pozostałymi zadaniami, którymi się zajmował? Nie akumulują się w innym miejscu?
       3. Zarządzanie przepływem za pomocą limitów prac w toku w naturalny sposób zapewnia bufor
       4. Opisz polityki obowiązujące w procesie, aby wszyscy mieli ten sam punkt widzenia
    5. Zachowania emergentne w Kanbanie
18. Rozdział 10. Coach metodyk zwinnych
    1. Akt III. I jeszcze jedna sprawa (znów?)...
    2. Coachowie rozumieją, dlaczego ludzie nie zawsze chcą się zmieniać
       1. Coachowie zwracają uwagę na sygnały ostrzegawcze wskazujące na to, że zespół ma trudności z wprowadzaniem zmian
    3. Coachowie rozumieją proces uczenia się
       1. Wykorzystaj model Shuhari, aby pomóc zespołowi poznać wartości metodyki
    4. Coach rozumie, dzięki czemu metodyka działa
    5. Zasady coachingu
19. Skorowidz
20. O autorach
21. Kolofon
22. Przypisy
    1. Rozdział 1. Poznaj Agile
    2. Rozdział 2. Wartości Agile
    3. Rozdział 3. Zasady Agile
    4. Rozdział 4. Scrum i samoorganizujące się zespoły
    5. Rozdział 5. Planowanie w Scrumie i wspólne zobowiązanie
    6. Rozdział 6. XP i otwartość na zmiany
    7. Rozdział 7. Prostota i projektowanie przyrostowe w XP
    8. Rozdział 8. Lean, unikanie marnotrawstwa i spojrzenie na całość
    9. Rozdział 9. Kanban, przepływ i nieustanne doskonalenie