Agile Teoria Scrum

Agile czy Scrum – co było pierwsze?

Swoim zakresem Agile Manifesto obejmuje tworzenie oprogramowania. Scrum natomiast – prawie wszystko co jest tworzone zespołowo a efektem jest wartość dla klienta. Z tej perspektywy można by uznać, że Scrum był pierwszy. 

Scrum to 1995 

I dokładnie tak było. Inspiracją zasad Scrum był artykuł “The New New Product Development Game“, Hirotaka TakeuchiIkujiro Nonaka, który opisywał jak firmy w latach ‘70 i ‘80 tworzyły innowacje. W skrócie – pierwsze kserokopiarki Xerox, aparaty cyfrowe Canon’a czy komputery osobiste. 

Jak widzicie były to innowacyjne produkty, tworzone były w różnych firmach, ale zespoły mały kilka wspólnych cech. 

  1. Built-in instability 
  2. Self-organizing project teams 
  3. Overlapping development phases 
  4. “Multilearning” 
  5. Subtle control 
  6. Organizational transfer of learning 

Zachęcam do przeczytania tego artykułu: https://hbr.org/1986/01/the-new-new-product-development-game  

Historia artykułu jest dziwna – ponieważ nie był on popularny pomimo tak wartościowej treści lecz trafił do twórców Scruma Kena Schwabera i Jeffa Sutherlanda którzy usystematyzowali swoją wiedze i przedstawili idee Scrum a w roku 1995.

Agile to 2001 

Podczas weekendu w 2001 na spotkaniu dotyczącym tematu jak tworzyć oprogramowanie grupa chłopaków  (http://agilemanifesto.org/authors.html ) zdefiniowała manifest zwinnego tworzenia oprogramowania jako odpowiedź na wiele pytań – jak powinno się je tworzyć. 

Obejmuje on 12 zasad http://agilemanifesto.org/iso/pl/principles.html oraz 8 wartości pogrupowanych. Stosowanie się do nich jednoznacznie oznacza, że zachowujemy większość wartości i reguł Scrum’a. Moim zdaniem jest to niejako rozszerzenia Scrum’a na branżę tworzenia oprogramowania. 

Ciężko jest uzyskać efekt stosowania zasad Agile Manifesto bez spójnego i wydajnego zespołu. 

Podsumowanie 

Aktualnie zasady Agile często są tak stosowane, że powstaje totalny bałagan. Agile jest interpretowane jako słowo wytrych umożliwiające nacisk na zespół w kwestii wprowadzania zmian, albo tworzenia niższej jakości kodu byle tylko klient zaakceptował etap. Niestety nie takie było założenie – gdybyśmy wszyscy stosowali Agile Manifesto zgodnie z wytycznymi – nie byłoby kiepskiego oprogramowania a każdy klient byłby zadowolony.