[SCRUM] Co to jest?

Sama definicja SCRUM budzi sporo emocji. Niektórzy puryści logiczno-lingwistyczni są bardzo czuli na nazywanie Scrum metodyką projektową.
Metodyka niejawnie zakłada robienie czegoś krok po kroku, Scrum natomiast to: rama pomagającą podczas prac nad projektem. Angielskim słowym najlepiej oddającym ta ideę jest framework.

Dobrze wyjaśnił to Ken Schweber – jeden z autorów SCRUM:

Scrum is not a development method or a formal process, rather it is a compression algorithm for worldwide best practices observed in over 50 years of software development. The Scrum framework is simple to implement and automatically unpacks and encourages a software development team to deploy best practices.

Scrum Papers

Ja jednak uważam, że metodyka to szersze pojęcie, rozumiem je jako ustandaryzowane, zdefiniowane podejście do rozwiązania problemu, pozwolę więc sobie używać określenie „metodyka SCRUM„. Ot, takie moje, blogowe prawo!

Manifest agile

Rozdział ten to pozycja obowiązkowa w każdym opracowaniu nt. SCRUM – jest to deklaracja zasad przyjętych w zwinnych metodykach projektowych, opracowana w 2001 roku:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy.
W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie,
jednak bardziej cenimy to, co po lewej.

Jak to rozumieć:

  1. Ludzi i interakcje ponad procesy i narzędzia.
    AGILE stawia na komunikację i pracę zespołową ponad wyszukane metody porozumiewania się w stylu rozbudowanych portali projektowych z mnóstwem wskaźników. Uważa, że najlepszym sposobem jest bezpośrednia rozmowa i wzajemne zrozumienie.
  2. Działające oprogramowanie ponad obszerną dokumentację.
    Dokumentacja jest potrzebna i każdy rozsądny informatyk zdaje sobie z tego sprawę.
    Najważniejsze aby nie przesłoniła faktycznego celu projektu.
    AGILE stawia na wsparcie procesu produkcji oprogramowania m. in. przy pomocy dokumentacji, a nie robienie z niej celu, który często utrudnia dobry kontakt z Klientem.
  3. Współpracę z klientem ponad formalne ustalenia.
    Znów – nieco pokrętnie – przyznam, że formalne ustalenia, szczególnie na gruncie, na którym przychodzi działać większości firm – są potrzebne.
    W myśl AGILE  nie powinniśmy jednak wychodzić z założenia, że gramy z zamawiającym do „dwóch różnych bramek” i nie możemy sobie ufać.
    Zwinne metodyki programowania zakładają ciągłą współpracę z klientem, jest on obecny na każdym etapie wytwarzania oprogramowania (to bardzo ważne!) .
    Dzięki takiemu podejściu klient może w porę spostrzec, że coś idzie nie po jego myśli i zawrócić nasz okręt z obranego kursy nim ten zdąży się rozpędzić.
    Zespół programistów oczekuje, praktycznie ciągłej, informacji zwrotnej od swojego  Właściciela Produktu, ale o tym nieco później.
  4. Reagowanie na zmiany ponad podążanie za planem.
    Tak – plan jest ważny i w SCRUM praktycznie ciągle będziemy planować (!), jednak w specyficzny, przyjemny sposób.
    AGILE akceptuje zmiany, pokazuje jak je oswajać i sprawia, że są mniej dotkliwe. Zmiana w metodykach zwinnych nie jest czymś niechcianym przed czym musimy bronić się wszelkimi sposobami.

 Zasady Agile

Oprócz manifestu sformułowano także 10 podstawowych zasad Agile, są to:

  1. osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania,
  2. działające oprogramowanie jest dostarczane okresowo,
  3. podstawową miarą postępu jest działające oprogramowanie,
  4. późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
  5. bliska, dzienna współpraca pomiędzy biznesem a deweloperem,
  6. bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim,
  7. ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt,
  8. prostota,
  9. samozarządzalność zespołów,
  10. regularna adaptacja do zmieniających się wymagań.

Zasady są jasne – stanowią rozwinięcie i doprecyzowanie Manifestu.

SCRUM – konkrety

Scrum nie jest złotym środkiem, jest pewną ramą do przyjęcia w projekcie opisująca ogólne sposoby postępowania – o tym już wspominałem – ważne jednak aby to dobrze zrozumieć.

O Scrum mówi się, że jest lekki, łatwy do zrozumienia, ale trudny do opanowania. Dlaczego? Ponieważ znacznie odbiega od klasycznej metody zarządzania projektami do której jesteśmy przyzwyczajenie.
Stawia na prace zespołową i pełne zaangażowanie klienta, współpraca powinna przebiegać w atmosferze zaufania i ciągłego otrzymywania informacji zwrotnej (ang. feedback).

Scrum jest z powodzeniem używany w wielu znanych firmach informatycznych, np: Google, czy Microsoft.

SCRUM wyróżnia następujące role w projekcie:
  • Scrum Master – Mistrz Młyna – czuwa nad prawidłowością korzystania ze Scrum.
  • Development Team – Zespół.
  • Product Owner – Właściciel Produktu – przedstawiciel zamawiającego biorący aktywny udział w pracach Zespołu.
SCRUM wyróżnia następujące Artefakty:
  • Product Backlog – rejestr produktu, uporządkowana lista wszystkiego, co może być potrzebne w produkcie, źródło wymaganych zmian – „zamiennik” rejestru wymagań użytkownika.
  • Sprint Backlog – Rejestr Sprintu – wycinek Backlogu Produktu wybrany do realizacji w danym Sprincie.
  • Increment – przyrost – ukończone elementy Backlogu Produktu.
SCRUM wyróżnia następujące zdarzenia:
  • Sprint  – „jedna iteracja” – trwająca zazwyczaj 3-4 tygodni, podczas Sprintu wytwarzany jest GOTOWY fragment programu.
  • Sprint Planning Meeting – spotkanie podczas którego planowana jest praca do wykonania w Sprincie.
  • Daily Scrum – codzienne, krótkie spotkanie (~15 min.) służy do synchronizacji bieżących prac i zaplanowania działań na najbliższy dzień.
  • Sprint Review – przegląd Sprintu – spotkanie służące do analizy co zostało zrobione w danym Sprincie i odpowiedniej aktualizacji (pielęgnacji) Rejestru Produktu.
  • Sprint Retrospective – Retrospektywa Sprintu – spotkanie dla Zespołu służące do przeglądu działań, analizy i proponowania usprawnień – często (niesłusznie!) pomijane.

Każdy z powyższych punktów oraz sposób planowania prac zostanie omówiony w kolejnych artykułach. Zapraszam.

Pozostałe artykuły o Scrum na moim blogu.

Leave a Reply