pracaanalityka

Jakie są największe problemy z Agile w skali? [ciekawe badanie]

Posted by admin

Cześć tu Szymon z analizowac.pl

Wszyscy dobrze wiemy że większość projektów jest rozwijane w metodykach Agile. Oczywiście nie wszystkie ale nawet jak przejrzymy sobie oferty pracy to z 80% ogłoszeń zawiera notkę że musisz znać Scruma. Czy to fajne? Czy to nie jest fajne? Osobiście nie jestem ani fanem ani antyfanem. Ale dzisiaj nie o tym. Dzisiaj o tym jakie wyzwania występują w zespołach Agile robionych w skali. Zapraszam do czytania 🙂

Badanie

No więc zacznijmy od tego skąd bierzemy informację o tych problemach. No oczywiście z przeprowadzonych badań. Badanie przeprowadzono w postaci wywiadów(ustrukturyzowane wywiady czas trwania 50-95minut. Wszystkie były nagrywane.). Wywiady były przeprowadzane z ludźmi z różnych środowisk i z różnym doświadczeniem(z różnych firm, różnych branż). W sumie przeprowadzono wywiady z 17 różnymi ludźmi(6 developerów, 5 Agile Coach, 2 testerów, 1 product owner, 1 analityk, 1 delivery manager, 1 devops) z różnych organizacji z Niderlandów(Dokładnie 6 firm największa miała pomiędzy 50-100tys pracowników a najmniejsza 50-200 pracowników).

Potem wykonano transkrypcję nagrań przez firmę zewnętrzną aby uniknąć jakiś domysłów osób przeprowadzających wywiad. Następnie przeanalizowano transkrypcję. Każdy z analizujących wykonywał analizę samodzielnie i następnie połączono wyniki badania. Wynikiem całej analizy było różne wyzwania które podzielono na 5 kategorii

  1. Wyzwania organizacyjne
  2. Wyzwania testerskie
  3. Wyzwania związane ze zbieraniem wymagań
  4. Wyzwania związane z dokumentowaniem wymagań
  5. Wyzwania związane z architekturą rozwiązania

Przejdźmy więc przez kolejne wyzwania

Wyzwania organizacyjne

1. Zbyt późne odkrywanie że wymaganie jest niewykonalne

Częsta sytuacja powodowana brakiem odpowiedniej koordynacji i komunikacji pomiędzy zespołami. Wynikiem końcowym było zbyt późne odkrywanie że dane wymaganie jest niewykonalne. Jeden team wykonywał aplikację która miała być wystawiona na zewnątrz organizacji. Głównym celem było bezpieczeństwo logowania które było skomplikowanym procesem. Kolejny team dostał wymaganie optymalizacyjne żeby każda strona aplikacji ładowała się maksymalnie 3 sekundy. Niestety nie było możliwości wykonać tego zadania przy logowaniu użytkownika bez przebudowania całej architektury aplikacji. Maksymalnie można było zejść do 10 sekund. Jakby wymagania obu zespołów zderzono wcześniej to byłaby możliwość zaprojektować architekturę rozwiązania inaczej.

2. Robienie założeń przy współpracy pomiędzy zespołami

W wielu zespołach zdarzała się sytuacja że zmieniano funkcjonalności którymi niby opiekował się jeden zespół ale możliwość zmiany miało wiele zespołów. Sporym wyzwaniem był fakt że jeden zespół miał inne wyobrażenie o danym kawałku kodu niż drugi. I tutaj się pojawiały schody ponieważ każdy z zespołów miał swoją definicję(a nawet proces dostarczania oprogramowania) i nie przyszło nikomu do głowy żeby zderzyć się z innymi zespołami. Pojawiały się nawet sytuacje że jeden zespół robił testy bezpieczeństwa a drugi nie. Bywało też tak że jeden zespół zrobił wyszukiwarkę która miała wyszukiwać dane z wykluczeniem danych z oznaczoną flagą a drugi zespół tą flagę pomijał i pokazywał zbyt szeroki zakres danych użytkownikowi końcowemu.

3. Nierówny poziom doświadczenia pomiędzy zespołami

Wszystkie badane zespoły zaznaczyły fakt że w przypadku gdy pojawiała się przynajmniej minimalna różnica w doświadczeniu pomiędzy zespołami(np. odchodził leader technologiczny z danego zespołu) to pojawiał się problem związany z jakością implementacji wymagań. Było to związane z tym że przekazanie wiedzy młodszym programistom było problematyczne(przeważnie przez zwykłe problemy zasobowe).

Wyzwania „Testerskie”

1. Nieodpowiednia specyfikacja przypadków testowych

Zauważono problem gdzie testerzy przychodzili z różnych miejsc i nie byli w stanie z marszu wgryźć się w testowanie tematu. Spowodowane było to tym że pisane przypadki testowe nie miały odpowiedniej jakości(brakowało jednakowego standardu przypadków testowych). Często prowadziło to do sytuacji gdzie tester dawał ok na wdrożenie gdzie developer czuł w kościach że musi być jakiś błąd w tym co oprogramował i stwierdził że sam przetestuje. Po testach developera okazywało się że są błędy i pojawiały się różne oskarżenia uwzględniając nawet takie że „dany tester nic nie robi”

2. Problem z testami integracyjnymi

W przypadku gdy mamy więcej niż jeden zespół to najważniejsze są do wykonania testy integracyjne. Te testy powinny się odbywać na samym początku naszej imprezy. Niestety badanie to wykazało że bardzo często występowała sytuacja gdzie przykładowo

  • Zespoły pracowały w 2 tygodniowych sprintach
  • Wgrywanie wersji która pozwalała na testy integracyjne odbywało się co 3 sprinty
  • wdrożenie na prod było co 6 sprintów
  • po 3 sprintach testy integracyjne wywalały do góry nogami całą pracę związaną z releasem na prod.

Próbowano to rozwiązywać różnymi symulacjami itd. niestety to i tak nie rozwiązywało problemu w 100%.

Wyzwania związane ze zbieraniem wymagań

1. Przeoczanie interesariuszy

Bardzo często pojawiała się sytuacja gdzie przeoczano kluczowych interesariuszy. Było to problemem z racji że dla analityków głównym źródłem informacji o interesariuszach był Product Owner(lub product ownerem był analityk). Prowadziło to do sytuacji gdzie analityk pytał o interesariuszy u przykładowo 3 z pięciu PO a 2 pomijał(bo np. jeden był nieobecny lub nie miał czasu itp.)

Szczególnie ta sytuacja występowała przy małych zmianach w jednym miejscu aplikacji gdzie stwierdzano że „Tylko ten zespół z tego korzysta” i rezygnowano z jakiejkolwiek analizy interesariuszy.

2 . Problemy ze zrozumieniem pracy nad wymaganiami niefunkcjonalnymi

Często zdarzało się że niektóre zespoły pracowały tylko nad wymaganiami funkcjonalnymi a niektóre zespoły bardziej skupiały się na wymaganiach niefunkcjonalnych a wymagania funkcjonalne były w mniejszości. Prowadziło to do tego że niektóre zespoły(te które robiły większość wymagań funkcjonalnych) dostawały większość pochwał i zasług za działanie systemu. Wymaganiami niefunkcjonalnymi zajmowano się tylko wtedy gdy system przestawał działać. Prowadziło to do problemów z atmosferą.

Wyzwania związane z jakością dokumentacji wymagań

1. Zbyt długa definicja ukończenia

W wielu organizacjach próbowano przygotować wspólną definicję ukończenia dla wymagania. Prowadziło to do tego że definicja ukończenia rozrastała się do olbrzymich rozmiarów i udokumentowanie wymagania stawało się mocno czasochłonne. Stworzenie takiej definicji ukończenia doprowadziło tylko do wąskich gardeł.

2. Inne poziomy szczegółowości wymagań

Z drugiej strony pojawiły się problemy z różną interpretacją zapisów definicji ukończenia. Niektóre zespoły tworzyły bardzo szczegółowe PBI a niektóre zespoły tworzyły mniej szczegółowe PBI. Potem pojawiały się zarzuty że dany PBI nie spełnia definicji ukończenia i przez to pojawiały się zgrzyty.

Wyzwania związane z architekturą rozwiązań

1. Brak zarządzania zmianą w architekturze

Wiedza architektoniczna w ciągu kolejnych zmian w systemie ulegała coraz to większej granulacji. Zespoły robiły zmiany z pobieżną konsultacją z Architektem(albo bez konsultacji). Prowadziło to do tego że wiedza o architekturze rozwiązania danego komponentu systemu potrafiła być tylko w jednym zespole który był odpowiedzialny za implementację. To wszystko prowadziło do tego że wiedza o architekturze rozwiązania całego systemu z czasem zanikała.

Podsumowanie

Wyzwań w pracy w skali jest o wiele więcej. Wiadomo. Nie wszystko lubi się skalować. W ramach dalszego researchu zauważyłem też inne zgłaszane problemy. Poniżej tabelka.

LPProblem
1. „Minimalistyczna” dokumentacja i trudności z tworzeniem jakiejkolwiek dokumentacji przez zespół projektowy.
2. Brak wystarczającej dostępności interesariuszy dla każdego zespołu w celu uszczegóławiania wymagań
3.Nieodpowiednia architektura aplikacji nie pozwalająca na rozszerzanie.
4. Problemy z odpowiednią wyceną czasochłonności danego PBI
5. Priorytetyzowanie wymagań uwzględniając perspektywę tylko jednego zespołu
6. Brak śledzenia wymagań z przypadkami testowymi(zespoły testerskie sobie, development sobie)
7. Problemy z analizowaniem zależności pomiędzy modułami aplikacji (już na samym początku developmentu)
8. Niedbałość o wymagania niefunkcjonalne
9. Brak znajomości dziedziny biznesowej przez zespoły
10.Problem z zapewnieniem wystarczających kompetencji w zespołach
11.Brak dbania o backlog sprintu

Czy to oznacza że Agile w skali jest zły? Wątpliwe. Uważam że warto jest poznać to jakie problemy występują aby mieć je z tyłu głowy gdy samemu się w takim środowisku pracuje.

Źródła

  • Erik Kamsties,Jennifer Horkoff,Fabiano Dalpiaz (eds.) – Requirements Engineering_ Foundation for Software Quality_ 24th International Working Conference
  • Rolland, K.H.: “Desperately” seeking research on agile requirements in the context of largescale agile projects. In: Proceedings of the XP 2015 (2015)
  • Alsaqaf, W., Daneva, M., Wieringa, R.: Quality requirements in large scale distributed Agile projects – A systematic literature review
  • Ramesh, B., Cao, L., Baskerville, R.: Agile requirements engineering practices and challenges: an empirical study.

Chcesz zostać Analitykiem IT? Kliknij w baner poniżej

DARMOWA checklista jakości wymagań!

Zapisz się na listę mailową a dam Ci za darmo checklistę jakości wymagań biznesowych.

Uzupełnienie powyższego pola stanowi zgodę na otrzymywanie od analizowac.pl newslettera zawierającego treści marketingowe. Zgodę można wycofać w każdym czasie. Wycofanie zgody nie ma wpływu na zgodność z prawem przetwarzania dokonanego przed jej wycofaniem.