Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Antyscrum - 10 najczęstszych błędów

Pewnie napisano już miliony stron na temat samego scruma, tego jakie wprowadza benefity, jak ułatwia pracę, jak wykorzystać tę metodykę, by dostarczać lepsze i tańsze oprogramowanie. Bez obaw - nie mam zamiaru ani tego powtarzać ani podsumowywać.
Chcę napisać o czymś zgoła przeciwnym - i nie chodzi mi o stwierdzanie, iż metodyka nie spełnia tego co wcześniej podkreśliłam. Skupię się raczej na pojęciu ostatnio wprowadzonym w moim otoczeniu - na tzw. antyscrumie. W skrócie oznacza ono wszelakie błędy jakie popełniane są w procesie tworzenia oprogramowania pod płaszczykiem stosowania scruma.

Oto 10 najczęstszych sytuacji, które dyskwalifikują w moim pojęciu użycie terminu scrum:
  1. Przeprowadzanie daily scrum'ów - oczywiście nie mówię o samym fakcie ich przeprowadzania, tylko sposobie. W założeniach powinno się odpowiadać na 3 pytania (Co udało mi się zrobić wczoraj?, Co będę robić dziś? Z czym miałem problem?), a samo spotkanie powinno trwać 15 min. Problem zaczyna się w momencie gdy spotkanie przestaje spełniać swoją funkcję - ludzie nie odpowiadają na wszystkie pytania, nie wszyscy odpowiadają (lub nie wszystkich prosi się o wypowiedź?), a w końcu zajmują się omawianiem szczegółów implementacji i spotkanie zamienia sę w dialog dwóch osób.
  2. Brak scrum review, czyli najwięszy problem w każdej metodyce, lub tez w każdym procesie.
  3. Sprint planning meeting - spotkanie mające trwać 8 godzin i w którym udział ma brać cały zespół. Z mojego doświadczenia wynika, iż takie spotkania się nie odbywają - w każdym bądź razie nie trwają 8 godzin tylko podzielone są na 2-3 spotkania ok. godzinne. No i oczywiście nie uczestniczy w nich cały zespół, tylko pewnie postacie go reprezentujące (często kierownik zespołu). Pewnie wg niektórych na takich spotkaniach wystarczy wiedza tych, którzy są tzw. graczami kluczowymi... Tylko, że trochę mi to nie pasuje jeśli chodzi o zasady scruma.
  4. Outputem spotkań sprintowych powinny być backlogi - zbiór zadań do wykonania przez zespół realizujący, z którego 'czerpie' w trakcie trwania sprintu. Często jednak nie ma za bardzo z czego czerpać - każda osoba ma dosłownie kilka zadań, które musi zrobić w określonej kolejności i na dodatek związane jest to z zadaniami innych osób. Najczęściej nie ma sytuacji gdy można wybrać sobie coś z backloga, czy też, by dane zadanie mogła wykonać więcej niż jedna osoba.
  5. W scrumie istnieją 3 role: zespól, scrum master, product owner. No ale ponieważ w firmach pokutują przeróżne przekonania zaszłościowe - trzeba każdemu znaleźć miejsce, nawet jeśli tego miejsca nie ma. Tak więc PM staje się scrum masterem, kierownicy stają się PMami, lub kluczowymi graczami zespołów. Pół biedy jeśli są scrum masterami, ale wtedy często faworyzują swoich ludzi i wrzucają w trakcie spotkań zagadnienia związane z ich pracą nie koniecznie dotyczącą omawianego projektu.
  6. Zbyt duże zespoły - optymalna liczba osób scruma nie powinna przekraczać 7 osób. Jest to najczęściej łąmana reguła. Identyfikuje to problem jako zbyt skomplikowany, a panować nad nim ma jeden scrum master.
  7. Faworyzacja tzw. osób kluczowych - najczęściej wyrażana tym, że najważniejszymi problemami są problemy tych właśnie osób, to one zapraszane są na wszystkie spotkania, one decydują o większości spraw i przytłaczają resztę zespołu. Często jest to wynik zbyt dużego zespołu - jeśli ciężko ogarnąć zbyt duży zespół, najłatwiej skupić się na osobach najbardziej widocznych. Wtedy też najłatwiej osoby kluczowe wykreować.
  8. Brak agentowości - problem związany z dwoma poprzednimi. Agnetowość to moim zdaniem najważniejsza cecha scruma. Po to go wymyślono - by problem podzielić na mniejsze, by rozdzielić go na agentowe zespoły umiejące sobie same poradzić, by uniemożliwić centralne sterowanie, bo przy złożónych problemach się ono nie sprawdza. Ale stare nawyki cięzko zmienić... a najciężej nawyk posiadania kontroli.
  9. Gdzie jest jakość? To zarzut do wszystkich, którzy metodyki zwinne rozumieją na swój sposób. Skoro mamy stworzyć oprogramowanie, to po co się martwić testami, dokumentacją czy przygotowywaniem szkoleń? Jesteśmy zespołem realizującym - piszmy więc kod. Projektowanie czy wymyślenie architektury spowoduje, że system powstanie później. Lepiej zacząć pisać i zbaczyć co z tego wyniknie, klient i tak zmieni zdanie 10 razy, więc po co się zastanawiać - lepiej brać się do roboty. Gorzej jeśli decyzje o elastyczności pokutują później niesamowitą ilością błędów, niemożnością rozszerzalności czy niekończącym się czasem na konserwację.
  10. Czy to agile czy jednak waterfall? A może inna metodyka. Skoro nie mamy sposobu na wprowadzenie elastyczności, czy ogólnie pojmowanego ogarniania zmian, to może po prostu nie jesteśmy w środku zwinnej metodyki? A może jej nie potrzebujemy?
Ktoś zaraz mi powie - 'Ale skoro jest tak źle, skoro nie są spełnione podstawowe założenia scruma, to jak w ogóle ktokolwiek może taki proces określać tym terminem?'. Otóż to - proces ten nazywam ostatnio mianem antyscrum :) Kierownicy, dyrektorzy, PMowie, a nawet zespoły realizujące twierdzą, że stosują scruma, a nawet chwalą się tym nie zdając sobie sprawy z podstawowych błędów jakie popełniają.
Najczęstszym wytłumaczeniem jest właśnie agile - 'Nie musimy się sztywno trzymać regułek. w końcu to agile. Bierzemy ze scruma to, co nam pasuje.'. Niby prawda, tylko jeśli jedyne co pasuje, to fakt ustanowienia codziennych spotkań i pseudo Backlog, to może wymyślmy dla tej metodyki oddzielną nazwę.
Inne usprawiedliwienie: 'O co chodzi? Nasza metodyka działa. Skoro działa, to jest ok.'. Problem w tym, że gdy zorientujemy się, że metodyka nie działa, to na pewno będzie już za późno. Scrum jest metodyką, która ma rozwiązywać problemy i na bieżąco je identyfikować. Antyscrum na to nie pozwala - oddalenie się od ludzi realizujących projekt, brak podsumowań, niedbałe codzienne spotkania, to najprostsza droga do lawiny nieszczęść.
Apeluję o zwracanie uwagi na szczegóły - nawet jeśli dotyczą agile'a. Agile nie oznacza ani braku dokumentacji, ani nie stosowania się do reguł i procesów, ani ogólne pojmowanej anarchii. Jest sposobem na to by wprowadzić do procesu elastyczność, tak by zoptymalizować to co chcemy zoptymalizować - jakość, budżet czy termin.
Opublikowane 19 lipca 2009 21:21 przez fusion
Filed under: , ,

Komentarze:

20 lipca 2009 06:58 by Procent

# re: Antyscrum - 10 najczęstszych błędów

Ciekawe, z jedną uwagą której nie potrafię sobie darować:). SCRUM to METODYKA, pojęcie często mylone z METODOLOGIĄ (tak jak i w powższym tekście). Zaryzykuję minidefinicje:

metodyka - zbiór metod do zastosowania;

metodologia - nauka o metodach

20 lipca 2009 08:53 by leszcz

# re: Antyscrum - 10 najczęstszych błędów

No proszę... :) Więc jednak agile to nie ma wyglądać tak jak na komiksach XKCD i dilberta? :) Czekam na dalsze ciekawe krytyczne uwagi do błędów popełnianych przy realizacji projektów.

20 lipca 2009 10:14 by fusion

# re: Antyscrum - 10 najczęstszych błędów

Dzieki - metodologię zamieniłam na metodykę :0

20 lipca 2009 11:36 by dotnetomaniak.pl

# Cold Fusion : Antyscrum - 10 najczęstszych błędów

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

22 lipca 2009 18:38 by Gutek

# re: Antyscrum - 10 najczęstszych błędów

hahaha % widze ze nauka nie poszla na marne :) Twoja tez nie ;) choc w pracy maja mnie juz dosc jakiedy ich poprawiam :D

Komentarze anonimowe wyłączone