Coś, co uważam za kłopotliwe od dłuższego czasu, to jak powszechne jest dla wielu w branży używanie terminów takich jak „Scrum, ale ….” w znaczeniu pejoratywnym, sugerując, że zespoły powinny stosować tylko mały zestaw praktyk, które są częścią Scrum. Rzeczywistość jest taka, że aby jakikolwiek zespół Agile był w stanie wielokrotnie dostarczać działające oprogramowanie przez znaczący okres czasu, Scrum sam w sobie nie wystarczy. Czy zdają sobie z tego sprawę, czy nie, ogromna większość zespołów, które nazywają siebie zespołami Scrumowymi, działa jako hybryda Scrum-XP lub hybryda Scrum-Kanban-XP, gdzie stosują przynajmniej podzbiór praktyk technicznych, które pochodzą z XP.
Niech mi będzie wolno nagrać i powiedzieć, że zespoły, które stosują się tylko do praktyk Scrumowych, raczej nie odniosą sukcesu na dłuższą metę, ponieważ przynajmniej podzbiór praktyk technicznych XP jest niezbędny do osiągnięcia ciągłego sukcesu jako zespół dostarczający Agile.
Zauważyłem, że nie ma wystarczającej liczby osób, które rozumieją, co Scrum zawiera, a czego nie, więc zacznijmy od tego.
Czym jest Scrum – zestaw praktyk zarządzania
Scrum jest zastosowaniem empirycznej kontroli procesu, co jest wymyślnym sposobem powiedzenia, że powinniśmy podejmować decyzje w oparciu o doświadczenie, a nie w oparciu o jakiś hipotetyczny zestaw założeń, które nie są ugruntowane w rzeczywistości.
Prosto mówiąc, Scrum składa się z niewielkiego zestawu praktyk zarządzania, które mają pomóc zespołom efektywnie współpracować i dostarczać pracę w sposób iteracyjny (pozwólcie, że podkreślę raz jeszcze – w Scrumie nie ma żadnych praktyk technicznych).
Podsumowując krótko zawartość Przewodnika po Scrumie:
- Istnieje Zespół Scrumowy, który składa się z Deweloperów, Właściciela Produktu i Mistrza Scrumowego.
- Istnieją Wydarzenia Scrumowe, na które składają się: Sprint, Planowanie Sprintu, Codzienny Scrum (aka Codzienny Standup, w XP), Przegląd Sprintu i Retrospektywa Sprintu.
- Istnieją Artefakty Scruma, które składają się z Backlogu Produktu, Backlogu Sprintu i Przyrostu, gdzie Przyrost istnieje tak szybko, jak tylko jeden element z Backlogu Sprintu spełnia Definicję Zrobionego.
- Istnieje Definicja Zrobionego, gdzie każdy Zespół Scrumowy ma wspólne zrozumienie tego, co „zrobione” oznacza dla każdego elementu Backlogu Produktu. Zauważ, że w przeciwieństwie do Kryteriów Akceptacji, Definicja Wykonania jest stosowana globalnie, podczas gdy Kryteria Akceptacji są specyficzne dla poszczególnych Pozycji Rejestru Produktu.
Czym Scrum nie jest
Wbrew powszechnemu przekonaniu, żadna z poniższych rzeczy nie jest częścią Scruma:
- Historyjki użytkownika. Elementy pracy w Backlogu Produktu lub Backlogu Sprintu dowolnego zespołu Scrum są zapisywane jako historyjki użytkownika (często w formacie „Jako <osoba/rola>, chcę <celu>, aby <pożądany wynik>”), ale Scrum nie nakazuje żadnej szczególnej konstrukcji ani formatu. Zauważ, że historyjki użytkownika są częścią XP.
- Szacowanie. Mimo że zdecydowana większość zespołów Scrum wykonuje szacowanie na jakimś poziomie, praktyka szacowania nie jest częścią Scrum.
- Szybkość. Szybkość również nie jest częścią Scruma; pojęcie szybkości projektu jest częścią XP.
- Praktyki techniczne. Jak wspomniano powyżej, w Scrumie nie ma pojęcia praktyk technicznych (CI, CD, programowanie w parach, TDD, itd.). Zdecydowana większość praktyk technicznych, które zespoły zazwyczaj stosują, pochodzi z XP.
Co to jest Extreme Programming?
Minęły ponad dwie dekady od utworzenia pierwszego zespołu Extreme Programming (XP), który pracował nad projektem o nazwie Chrysler Comprehensive Compensation (C3). Metody, które zastosował ten zespół pochodzą w znacznym stopniu z lat 80-tych, kiedy Kent Beck i wielu innych eksperymentowało z lepszymi sposobami tworzenia oprogramowania, tj. alternatywą dla podejścia „wodospadowego”, które stało się dominujące w tym czasie.
Obrazowość pracy zawsze była ważnym sposobem informowania o tym, jak pracują zespoły Agile. Dlatego jako wprowadzenie do XP zalecam, aby każdy, kto chce dowiedzieć się więcej, dobrze przysłużył się zaczynając od tych diagramów:
- Projekt Extreme Programming (diagram end-to-end)
- Iteracja (diagram skupiający się na tym, co dzieje się wewnątrz iteracji; zauważ, że to, co XP nazywa iteracją, jest koncepcyjnie podobne do tego, co Scrum nazywa Sprintem)
- Rozwój (diagram skupiający się na interakcjach i działaniach rozwojowych)
- Kolektywna własność kodu (diagram skupiający się na podstawowych praktykach technicznych)
Uwaga: Dla wizualizacji, która łączy wiele elementów z powyższych diagramów na jednej stronie, zobacz Bill Wake’s Extreme Programming Overview.
Dodatkowa lektura o XP
Jeśli powyższe wizualizacje zaintrygują Cię na tyle, że będziesz chciał przeczytać więcej o XP, zapoznaj się z następującymi źródłami informacji, które są wymienione mniej więcej w kolejności od najkrótszego do przeczytania >najdłuższego do przeczytania:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (patrz także Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka the 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka the WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Dodatkowe odniesienia
Wszystkie odniesienia w tej sekcji pochodzą z witryny XP Dona Wellsa, chyba że zaznaczono inaczej.
- Modele Agile są obrazami, a nie fotografiami (wszystkie modele są złe; niektóre są użyteczne)
- Przysłowia procesu Agile (słowa, którymi powinien kierować się każdy zespół)
- Bill Wake, Arrange, Act, Assert (wzór pisania testów jednostkowych)
- Bill Wake, Sudoku Solver (ciekawa wariacja na temat TDD)
- Bill Wake, Tests from a Hat (kreatywne podejście do pisania testów jednostkowych)
- Honest Plans (jak wygląda estymacja w praktyce)
- Manage Your Goals Instead of Activities (główne różnice między rozwojem Waterfall a Agile)
- The Values of Extreme Programming (Simplicity, Komunikacja, Informacja zwrotna, Szacunek, Odwaga)
- XP i bazy danych (wzorzec oparty na złotych > srebrnych > brązowych bazach danych))
.