Jak sprawić, by Scrum pracował dla zespołu ze zdefiniowanymi rolami?

Kilka podstawowych informacji

Jestem częścią wewnętrznego zespołu programistów. Składa się ona z

• 5 programistów (z doświadczeniem od 2 do 5 lat, jestem jednym z nich)
• 3 pracowników wdrożeniowych (zajmują się wdrażaniem oprogramowania i szkoleniem)
• i 1 kierownik projektu.

Opracowujemy wiele małych i średnich projektów, a ich harmonogramy zwykle się pokrywają. Rozwój wygląda następująco:

1. „Klient” daje nam zestaw wymagań początkowych
2. Rozwijamy system do wspomnianej specyfikacji
3. Przedstaw ten system „klientowi”
4. „Klient” stawia nam dodatkowe wymagania w oparciu o wspomnianą prezentację
5. Powtarzaj 2-4, aż „klientowi” skończą się nowe wymagania lub data docelowa wdrożenia jest bliska
6. Skonfiguruj i wdróż system

To, wraz z faktem, że to „klient” przez większość czasu dotrzymuje terminów (co jest czerwoną flagą, z tego, co widzę tutaj w Programistach i PM.SE) i nie przestrzegamy określonych metodologii rozwoju do kodu kowboja, prawie niemożliwego do utrzymania kodu i błędów, które dostają się między innymi przez produkcję. Dlatego zdecydowaliśmy się na metodologię opartą na Agile, taką jak Scrum.

Dlaczego Scrum?

To była inicjatywa naszego menedżera i wydaje się, że wszyscy się z tym zgadzają, biorąc pod uwagę naszą obecną sytuację.

Problem ze Scrumem

Niektóre elementy Scrum są w konflikcie z naszą obecną konfiguracją, której nie jesteśmy w stanie łatwo rozwiązać, w szczególności charakter „zwinnych transakcji” programistów Agile. Zespół wdrożeniowy nie wie, jak programować, a programiści mają umiejętności komunikacyjne i szkoleniowe poniżej średniej. A ten skład nie zmieni się w najbliższym czasie.

Pytanie

Czy wpłynęłoby to na skuteczność Scrum jako metodologii? Czy należy wprowadzić inne zmiany, aby to zrekompensować? Czy może lepiej byłoby porzucić myśl i pomyśleć o innej metodologii?

W rzeczywistości twój obecny sposób pracy nie jest tak daleko od Scruma, jak mogłoby się wydawać.

W Scrumie otrzymujesz również wstępny zestaw wymagań, wdrażasz je i demonstrujesz wynik, a na podstawie demonstracji możesz otrzymać nowe wymagania lub interesariusze mogą zdecydować, że produkt jest wystarczająco dobry, aby nie było potrzeby dalszego rozwoju.
W twojej sytuacji „klient”, o którym mówiłeś, może otrzymać rolę właściciela produktu w Scrumie (wydają się już wypełniać tę rolę, ustalając priorytety w projekcie i decydując, kiedy jest gotowy do wdrożenia).
Jedną dużą zmianą może być długość iteracji. W Scrumie iteracja powinna trwać od 1 do 4 tygodni.

Jeśli chodzi o skład zespołu i błędność typu jack-of-all-trade, Scrum nie wymaga od wszystkich bycia jack-of-all-trade. Scrum wymaga jedynie, aby zespół jako całość posiadał wszystkie wymagane kompetencje, aby uzyskać produkt z listy wymagań do czegoś, co zostało / może zostać wdrożone.
W twojej sytuacji mogę łatwo zobaczyć zespół na projekt składający się z jednego lub więcej programistów (wykonujących głównie prace związane z wdrażaniem i testowaniem) i członka „personelu wdrożeniowego”, który koncentruje się głównie na tworzeniu podręczników i materiałów szkoleniowych dla funkcji, które programiści wdrażają teraz.

Po tym, jak klient / właściciel produktu zapali zielone światło dla wdrożenia, prace zespołu scrum będą w większości wykonane, aby programiści mogli przejść do innego projektu (i być dostępni tylko na żądanie w celu rozwiązania problemów po wdrożeniu) i wdrożenia personel może przejść do przeprowadzenia szkolenia i wspierania wdrożenia.

Fakt, że upłynął termin, nie jest prawdziwym problemem, pod warunkiem, że istnieje wystarczająca elastyczność w zakresie funkcjonalności w tej wersji.

Pytasz o alternatywy, więc powiem eXtreme Programming (XP). W szczególności myślę, że programowanie w parach może ci tutaj pomóc.

Łącząc osoby o różnych umiejętnościach, nie ma znaczenia, jakie umiejętności: parzenia kawy, testowania, szkolenia itp. Możesz rozprowadzić umiejętności w zespole.

Ale szczerze mówiąc, nie brzmi to tak, jakby SCRUM było dla ciebie tak odległe. Częścią SCRUM jest elastyczność i znajdowanie tego, co jest najlepsze dla Twojego zespołu. Część XP szanuje twój zespół i dostosowuje się. Może za 100 lat możemy mieć bardziej rozwinięty zawód z twardymi i szybkimi zasadami (choć w to wątpię), ale na razie wszystko, co dla ciebie działa, to wszystko, co mamy. Ważne jest, aby mieć pętle zwrotne. Jeśli coś nie działa, zespół musi to omówić i wypróbować nowe rzeczy, aż znajdą coś, co działa.

Jak sprawić, by Scrum pracował dla zespołu ze zdefiniowanymi rolami?

Po prostu to zrób. Według przewodnika Scrum każdy jest deweloperem, ale z powrotem tutaj, na Ziemi, różni ludzie przyniosą różne rzeczy do stołu. I prawie dostałem lynched kiedy sugerował, że niektórzy ludzie są naprawdę testerów podczas gdy inni piszą oprogramowanie.

Niektóre rzeczy, które możesz chcieć rozwiązać:

Sprinty

Wygląda na to, że masz początkową fazę rozwoju, po której następuje seria pozornie sprintów. Zastanów się nad rozwiązaniem tego. Klient nie tylko zobaczy coś wcześnie, ale także lepiej wyczujesz etapy rozwoju.

Naprawiono terminy

To pojawia się od czasu do czasu i rzeczywiście jest upartym cierniem u boku deweloperów, gdzie obecnie pracuję. Scrum ustala prognozy dla sprintu - nic więcej. Tak, możesz trafić w cel po serii sprintów, ale gdy klient przyjrzy się wcześniejszym wersjom, zakres prawdopodobnie zacznie znacznie się pełzać. Nie jest to problem sam w sobie, ale należy uświadomić klientowi, że dalsze prace będą odbywały się w późniejszych sprintach i przekraczają znane wymagania.

Twoja sytuacja może być lepsza dla Kanbana, ponieważ możesz zacząć od tego, co masz i iterować od tego momentu. Oznacza to, że nie miałbyś wstępu do Wielkiego Wybuchu, który przeszkadzałby w twoich bieżących projektach - po prostu zacznij od wizualizacji zadań na tablicy i przyjęcia niektórych praktyk, takich jak retrospektywy i codzienne spotkania.

Musisz być nieco bardziej ostrożny niż w przypadku Scruma, ponieważ nie jest on tak nakazowy: ma więc tendencję do powracania do tego, co było wcześniej, zamiast wpajania właściwego, zwinnego sposobu myślenia.

Scrum nie działa dobrze z osobnymi nakładającymi się na siebie projektami, ponieważ nie masz stabilnego zestawu osób pracujących nad projektem dla pełnego sprintu. Dlatego pojęcia takie jak gadatliwość itp. Mogą cię po prostu przygnębić.

Ale najpierw zapoznanie się z historią zapewniającą klientowi najlepsze koszty / korzyści i wdrożenie jej, w tym w pełni zautomatyzowanych testów, do jakości wystarczającej do wdrożenia, zanim rozpocznie się praca nad kolejną historią, jest użyteczną koncepcją. Podobnie, cały kod napisany, aby historia mogła zostać sprawdzona przez innego programistę, zanim zostanie uznana za „ukończoną”.

Zakładam, że twoi pracownicy wdrożeniowi muszą napisać dokumenty szkoleniowe i referencyjne, mogą być napisane (pierwszy szkic) dla każdej historii przed napisaniem kodu, stając się tym samym testami akceptacyjnymi.

Oczekuję, że na początku każdego projektu, w którym wkład personelu wdrożeniowego byłby najbardziej pomocny dla programistów, są oni w 100% zaangażowani w wdrożenie poprzedniego projektu. Dlatego zastanów się, czy pracownicy wdrożeniowi mogą pracować nad pisaniem artykułów i dokumentacji użytkownika dla następnego projektu, podczas gdy programiści piszą kod dla bieżącego projektu.

„Rozwój zorientowany na zachowanie” z personelem wdrożeniowym piszącym przykład wykorzystywany w testach może działać.

Jest więc trochę Scruma, który ci pomoże, ale spróbuj oprzeć się na Scrumie zamiast używać Scruma.