Dlaczego potrzebuję SCRUM zamiast mniej formalnego, lżejszego procesu dla mojego zespołu?

25

Chciałbym rozpocząć moje pytanie od stwierdzenia, że ​​rozumiem, że SCRUM lub jego pochodna jest prawdopodobnie dobrym sposobem na zarządzanie tworzeniem oprogramowania. Wygląda na to, że wszystkie duże firmy i moi menedżerowie używają go lub korzystali z niego, i tak naprawdę nie mogę się kłócić z całym tym doświadczeniem. Jednak staram się zrozumieć „dlaczego”, a całe czytanie, a nawet moje oficjalne szkolenie SCRUM w pracy nie jest dla mnie wystarczające. To tylko cała retoryka. Więc przychodzę tutaj, szukając odpowiedzi.

Do tej pory rozwijałem w zespołach po 4-5 członków bardzo skutecznie, całkowicie samoorganizując się i bez potrzeby szkolenia, metodologii lub specjalnego oprogramowania. Po prostu dyskusje w kostkach, spotkania ad hoc i recenzje kodów jeden na jednego. Jestem teraz w pozycji, w której powiedziano nam, że SCRUM jest drogą, do której należy, i wszystkim, co się z tym wiąże. Kiedy opisują mi SCRUM, czytam takie rzeczy:

  • Osoby i interakcje dotyczące procesów i narzędzi
  • Działające oprogramowanie w obszernej dokumentacji
  • Współpraca z klientami w zakresie negocjacji umów
  • Reagowanie na zmianę po wykonaniu planu

To świetnie, ale wydaje mi się, że to zdrowy rozsądek. Dlaczego ta potrzeba została skodyfikowana? Powiedziano mi, że metodologia pomaga nam reagować na zmiany. Co konkretnieaspekty SCRUM pozwalają mi być tak elastycznym, że wcześniej nie osiągałem tego w moich spotkaniach ad hoc, rozmowach sześcianowych i spotkaniach programistów? Wyjaśniają potrzebę posiadania działającej dostawy co dwa tygodnie lub sprintu. W moim konkretnym projekcie nie ma „klienta”, oprogramowanie nie zostanie ukończone przez rok lub dłużej, a tymczasem prawdopodobnie będę co miesiąc demo kierownictwa wyższego kierownictwa. Skąd więc wyraźna potrzeba dostawy co drugi tydzień? Podkreślają znaczenie spotkania poświęconego planowaniu sprintu, podczas którego cały zespół przedstawia historie i zadania do następnego sprintu. Nie różni się niczym od zaimprowizowanych spotkań planistycznych, które odbyłem w przeszłości. Dlaczego musi się to zdarzać co drugi poniedziałek, i dlaczego cały zespół musi być zaangażowany? Rozumiem koncepcję „posiadania” produktu przez każdego członka, ale faktem jest, że tylko kilka osób może naprawdę przyczynić się do podziału każdej historii na zadania, podczas gdy reszta patrzy leniwie.

Ponownie rozumiem, że większość ludzi stoi za tym procesem, więc musi on działać i muszę się przyłączyć. Chciałbym tylko zrozumieć, dlaczego. Czy mój problem polega na tym, że już ćwiczę te rzeczy i po prostu nie lubię ich niepotrzebnie kodyfikować? A może jeszcze nie widziałem zalet tych technik, ponieważ są one wykonywane nieprawidłowo? Wszelkie prawdziwe , osobiste informacje lub porady na ten temat, w przeciwieństwie do gry, do której przywykłem, byłyby bardzo mile widziane.


źródło
Nie jestem pewien, czy rozumiem, co rozumiesz przez „bardziej lekki”. Czy to w ogóle ... nic? Brak procesu? A może podobnie jak niektóre specyfikacje, zadania JIRA i indywidualny wkład programisty? Wyjaśnij więc, co masz na myśli.
Schultz9999
nie potrzebujesz tego. jestem pewien, że scrum działa jako model dla większych zespołów, w których jest więcej zmiennych, niż możesz sobie wyobrazić, lub w sytuacjach, gdy menedżer nie jest dobrym naturalnym liderem i potrzebuje pewnego rodzaju szkolenia / szablonu do naśladowania. wygląda na to, że nie należysz do żadnej z tych kategorii, więc moje kondolencje. inny dobry zespół gryzie biurokratyczny pył.
leeny 11.01.11
4
Przez bardziej lekki rozumiem po prostu mniej sztywny. Oczekuję, że programiści planują zadania, przeglądają kod, oceniają, co nie działa, co jakiś czas dzielą się tym, co robią. Nie uważam jednak, że te rzeczy muszą być tak rygorystyczne, np. Planować co drugi poniedziałek, wstawać codziennie o tej porze, retrospektywnie co drugi piątek, ustawiać sprinty itp. Czuję, że już dużo robię SCRUM obejmuje, ale bez wyraźnego kierunku, terminologii lub porządku dziennego.
Czy spojrzałeś na techniki i zasady Kanban lub Lean? Wygląda na to, że masz już dość zwinny proces. Lean może pomóc Ci poprawić bez ograniczania płynnych, działających procesów. Kanban stosuje również „kadencję” zamiast sprintu, co oznacza, że ​​każde spotkanie może odbywać się według własnego rytmu, zamiast pracować z wszystkimi innymi spotkaniami w cyklu 2-tygodniowym.
Lunivore,
2
Mówisz o Scrumie, ale cytujesz Manifest Agile. Scrum polega na definiowaniu artefaktów, ról, spotkań, sprintów, pomiarów itp. Zdecydowanie możesz być zwinny bez wdrażania Scruma, a przeważnie możesz robić Scruma, a nie być zwinny.
Guy Sirton,

Odpowiedzi:

13

Myślę, że są dwa aspekty, aby odpowiedzieć na twoje pytanie, ale pozwól mi zacząć od gratulacji za pracę z ludźmi, którzy wydają się być wystarczająco inteligentni i kompetentni, aby móc właściwie pracować bez ściśle określonego procesu i nadal dostarczać produkt. Niestety nie jest tak w przypadku wszystkich zespołów oprogramowania, więc być może jednym z twoich problemów ze Scrumem może być to, że ty i twoi współpracownicy nie potrzebujesz tak naprawdę rzutu na ciebie, abyś był bardziej skuteczny. Możesz już być skuteczny.

Inne zespoły nie są i potrzebują bardziej rygorystycznie zdefiniowanego procesu oraz wskazówek, które pomogą im załatwić sprawę. Nie oznacza to, że zespoły te są bardziej głupie lub mniej zdolne, to po prostu oznacza, że ​​mogą mieć problemy z samoorganizacją lub pracą z dyscypliną jako zespół. Może to być również proste doświadczenie edukacyjne, gdy przybywa się z miejsca, w którym ludzie pracują głównie sami, do wspólnej pracy w zespole. Scrum może pomóc w osiągnięciu celu, ponieważ oferuje kilka wskazówek, które są zarówno łatwe do zrozumienia, jak i do przestrzegania, ale wystarczająco skuteczne, aby wywrzeć presję na zespół, aby zaczął się zbierać.

Ponieważ Scrum nie mówi nic o sposobie tworzenia oprogramowania, pozostawia zespołowi swobodę samodzielnego decydowania (np. Nadal możesz wykonać sprint stosując raczej konserwatywną metodę wodospadu, o ile robisz to na koniec sprintu).

Zespół jest jednym problemem. Inną kwestią jest zarządzanie i zaufanie kierownictwa. Tutaj Scrum może być dobry, ponieważ jest przejrzysty i pozwala wszystkim interesariuszom zobaczyć postępy zespołu w określonych cyklach. Więc to nie jest „robimy postępy, niestety nie możemy ci teraz nic pokazać, ale uwierz nam, skończymy na czas”. To może być nawet prawda, ale może być uspokajające dla każdego menedżera, aby faktycznie miał regularne demo, gdzie zobaczyłby, że rzeczywiście nastąpił postęp.

Scrum nie jest srebrną kulą. Może nie działać z niektórymi zespołami z różnych powodów, być może w przypadku niektórych zespołów samoorganizacja nie działa. Może dla ciebie jest na odwrót i wygląda na to, że proces został zrzucony na już produktywny i zorganizowany zespół.

W razie wątpliwości proponuję po prostu spróbować i przekonać się. Jeśli to nie działa, a większa część zespołu nie lubi takiej pracy, nie rób tego. Jednak sprawdź to przez kilka miesięcy (mówię kilka miesięcy, ponieważ kilka pierwszych sprintów i tak będzie niezręcznych i potrzebujesz czasu na dostosowanie szczegółów), a następnie ponownie ocenisz.

Anne Schuessler
źródło
Dzięki za odpowiedź. Na pewno będę tego próbował, ponieważ muszę, więc mam nadzieję, że w miarę upływu czasu proces ten ulegnie poprawie. Robisz dwa dobre punkty. Chociaż mogę być nieskończenie pewny swoich umiejętności i własnego zespołu w zakresie wykonywania zadań, tego samego nie można powiedzieć o każdym zespole w firmie, więc zrozumiałe kierownictwo chciałoby, aby proces zachęcał do takiego zachowania. Ponadto, chociaż wiem, że mój menedżer ufa naszej pracy i naszemu słowu, musi być widoczna dla innych zainteresowanych stron, takich jak te, które wchodzą w interakcje z klientem lub kierownictwem.
11

Może to budzić kontrowersje, ale Scrum najlepiej zmniejsza obawy związane z zarządzaniem Agile lub korzysta z zespołu o słabych osiągnięciach. Jeśli Twój zespół działa świetnie, osiąga cele, zarabia pieniądze i jest szczęśliwy, Scrum nic ci nie kupi, ponieważ wszystko, co zrobi, to zaburzy równowagę działań, które wykonujesz (i zapewni sukces zespołowi). Scrum nie jest srebrną kulą. Z mojego doświadczenia wynika, że ​​pomaga to tylko zespołom, które na początku miały słabą ocenę i komunikację. Zespołowi pracującemu nad realistycznymi szacunkami w środowisku efektywnej komunikacji przeszkadza jedynie proces produkcji Scrum.

Wierzcie lub nie, dobre zespoły programistyczne istniały przed pojawieniem się Scruma. Scrum pomaga złym się lepiej.

zaraz
źródło
„Wierzcie lub nie, dobre zespoły programistyczne istniały jeszcze zanim pojawił się Scrum. Scrum pomaga złym poprawić się”. Z drugiej strony przeciwstawiłbym się temu, że z punktu widzenia zarządzania były one tak rzadkie, że twoja obserwacja jest dyskusyjna.
Ben
+1 (+100, gdybym mógł): To samo doświadczenie tutaj.
Giorgio
7

Większość odpowiedzi tutaj podaje już powód, choć nieco pośredni. Odpowiedź Anne jest szczególnie pouczająca, gdy dotyka przejrzystości. Oznacza to, że pozwala menedżerom zobaczyć, co się dzieje. I odpowiedź Schultza również to dotyka, gdy mówi o ludziach, którzy nie są w stanie ukryć faktu, że zwlekają.

Chciałbym więc powiedzieć to, co już mówią inni, ale w bardziej bezpośrednim języku: głównym celem SCRUM nie jest zarządzanie tworzeniem oprogramowania, głównym celem SCRUM jest pomiar rozwoju oprogramowania.

Inne systemy próbowały już wcześniej, a ludzie zaproponowali niezliczone miary, aby spróbować zmierzyć rozwój oprogramowania, ale zawiodły. SCRUM odwraca problem i przenosi ciężar pomiaru na menedżerów i na samych programistów. Logika jest prosta: kto lepiej oszacuje, ile czasu zajmuje zrobienie czegoś, niż ci, którzy sami wykonują pracę?

Problem polega na tym, że programiści są dobrze znani z tego, że są zbyt optymistyczni. Zapytaj programistę, ile czasu zajmuje zrobienie czegoś, a on zwykle nie docenia, jak trudne jest to zadanie. SCRUM zapewnia narzędzia do kontrolowania tego:

  • codzienne spotkania w celu oceny postępów i uzyskania pełnego obrazu projektu
  • szacunki są dokonywane w „punktach” zamiast godzin / dni w celu wyodrębnienia czasu wyjazdu
  • wykresy spalania i tabele tortów / zając w celu wizualizacji prędkości punktów
  • historie i zadania na tablicy, aby uzyskać ogólny widok obciążenia pracą
  • sprinty i iteracje działające jak terminy, dzięki czemu możemy mierzyć postępy
  • określone role mistrza scrum, właściciela i członka zespołu, aby uniknąć pokusy oszukiwania

itp.

Możesz zauważyć, że wszystkie powyższe funkcje głównie powodują dwie rzeczy:

  1. Mierzą pracę. Albo praca do wykonania, albo praca do wykonania, albo praca ukończona.
  2. Bardzo starają się uniknąć problemu nadmiernie optymistycznego programisty, aby uzyskać lepsze, bardziej realistyczne oszacowanie.

Im dłużej wdrażasz SCRUM, tym dokładniejsze będzie twoje oszacowanie. W rzeczywistości osobiście uważam, że bieganie sprintem + zaległości + sam wykres wypalenia wystarczą, aby wyleczyć większość programistów złych szacunków dotyczących tego, ile czasu zajmuje zrobienie czegoś.

Slebetman
źródło
Dziękuję Ci! Rozważę teraz pomiar jako ważny element oceny SCRUM. Przypuszczam, że to prawda, że ​​chociaż mogę zaufać mojemu zespołowi, że stworzy swój własny harmonogram i skutecznie się rozwija, może być trudno zobaczyć szerszy obraz postępu bez wyraźnych historii użytkowników i regularnej akceptacji klientów. Wydaje mi się, że jedną kwestią jest to, że chociaż miło jest widzieć wyraźny, wizualny postęp, nie zawsze przekłada się to na to, jak „zrobione” osobiście uważam za projekt. Często wymyślam własne obszary wymagające poprawy, które wymagają rozwijania, a SCRUM ogranicza tę kreatywność.
2
Osobiście prowadzę zmodyfikowany SCRUM, w którym okresowo (raz na cztery lub pięć sprintu) przeprowadzamy sprakt refaktorski. Różnica między zwykłym sprintem a sprintem refaktora polega na tym, że podczas sprintu refaktora programiści przesyłają wszystkie historie. Zasadniczo ignorowanie priorytetów właściciela produktu. Mój szef uznaje to za zło konieczne, aby uniknąć zgnilizny kodu. Czasami historie uruchamiają refaktor, gdy więcej niż jeden programista uważa, że ​​kod, który należy dotknąć, jest „szczęśliwy”. Kiedy tak się dzieje, pozwalam programistom na przesyłanie własnych historii.
slebetman
(ciąg dalszy). Programiści przesyłający historie są oczywiście, ściśle mówiąc, odradzani. Jednak SCRUM nie działa poprawnie, jeśli jakość kodu spada. Jeśli Twój kod to taki bałagan, że wdrożenie historii zajmuje tygodnie, nie jesteś już „zwinny”. Spróbuj zasugerować dwie powyższe zmiany w zarządzaniu. Nie trać też z oczu faktu, że SCRUM to tylko narzędzie - takie, które wymaga dużo praktyki, aby używać go poprawnie, ale w końcu tylko narzędzie.
slebetman 11.01.11
Uwaga dodatkowa: pierwotnie sprzedałem pomysł sprintu refaktorowego kierownictwu, wykonując sprinty refaktorskie tylko tydzień, a nie pełny. W dzisiejszych czasach jest to pełny sprint, ale dzieje się tak głównie dlatego, że produkt jest zasadniczo w pełni rozwinięty i jest teraz w trybie konserwacji / przyrostowej aktualizacji.
slebetman 11.01.11
+1 za komentarz Slebetmana o sprintach refaktora. To brzmi jak skuteczny sposób na pozbycie się długu technicznego. Jeśli robisz to regularnie, a nie wtedy, gdy sprawy wymykają się spod kontroli, a właściciel produktu i menedżerowie są w porządku, mogę sobie wyobrazić, że pomaga to naprawić wszelkie problemy z jakością kodu, które wystąpiły podczas ostatnich sprintów.
Anne Schuessler,
2

Osobiście uważam, że celem SCRUM jest zaspokojenie starszych organizacji, w których wyższe kierownictwo nie może lub nie pozostanie w tyle za bardziej uproszczonym procesem. Pracuję jako architekt (kurczak) przez około rok w dziale, który mocno wykorzystuje SCRUM. Moje wcześniejsze doświadczenie to start-upy z Doliny Krzemowej, z których większość korzystała z dużo bardziej uproszczonego, ad hoc i wysoce iteracyjnego (czasem tygodniowego lub nawet codziennego wypychania) procesu zorientowanego na funkcje. Uważam, że SCRUM, przynajmniej sposób, w jaki go wdrażamy, jest nadmierny pod względem procesu (i pod pewnymi względami większy niż wodospad (przynajmniej z perspektywy dewelopera). Aby być sprawiedliwym, powiem, że jednym z aspektów naszego procesu jest Odchodzi od tego, że nasi właściciele produktów są bardziej zbliżeni do analityków wymagań w organizacji IT. W wyniku tego mają tendencję do stępiania informacji pochodzących z firmy, a co gorsza, pozostawiają firmę nieprzewidzianą dla zespołu programistów (co wymaga regularnych kolejnych wlewów historii użytkowników). Niemniej jednak w moim przyszłym starcie nie używałbym SCRUM. Prawdopodobnie użyłbym go tylko w sytuacji, gdy zarządzanie wymaga dodatkowego obciążenia.


źródło
„Osobiście uważam, że celem SCRUM jest zaspokojenie starszych organizacji, w których wyższe kierownictwo nie może lub nie pozostanie w tyle za bardziej uproszczonym procesem”. Możesz tak myśleć, ale doświadczenie pokazało mi, że Scrum to zestaw praktyk, które pomagają dostarczać oprogramowanie na czas i do wyższej jakości, zachowując zwinność (zdolność reagowania na zmieniające się wymagania). Czy te praktyki pomagają starszym organizacjom lub firmom z wyższym kierownictwem kochającym wodospad, nie ma znaczenia.
Ben
1

Nie będę rozmawiać z perspektywy purysty. Czuję, że jesteś w stanie wykonać to w sposób podobny do tego, co mówi Scrum. Jednak najważniejsze jest to, że jesteś w stanie uruchomić program. Co się stanie, jeśli będziesz na wakacjach przez miesiąc?

Widzę scrum jako mechanizm usprawniający wszystko, co robisz i nadający temu pewne określone aspekty. W ten sposób, pod twoją nieobecność, ktoś inny może go również replikować i powielać również w innych projektach. Jednak scrum nie jest srebrną kulą. Widziałem wielu ludzi, którzy właśnie zaczęli używać Scruma (ponieważ jest modne) i zostali ciężko pobici, ponieważ nie rozumieli jego istoty.

PS: Scrum nie nakazuje, by twój sprint musiał trwać dwa tygodnie. Może to być miesiąc (twoja sprawa).

Pradeep
źródło
Twoje zdanie na temat nieobecności jest dobre. Niezależnie od tego, jak silny jestem, mój zespół musi być równie skuteczny, niezależnie od tego, czy w biurze jest dwóch członków zespołu, czy sześciu. Jeśli tylko kilka kluczowych osób planuje przeglądanie kodu, sprawdzanie postępów itp., Grupa może być zbyt zależna od tych osób, aby wszystko działało sprawnie. SCRUM powinien być w stanie pomóc wszystkim w przyjęciu właściwego sposobu myślenia.
1

Najpierw zobacz moje komentarze do pytania.

SCRUM to zwinny paradygmat tworzenia oprogramowania. Jako taki sam jest zwinny. Nie zakłada, że musisz podążać za jego klasycznym modelem. I wątpię, czy ktoś faktycznie to robi. Pracowałem w kilku organizacjach i każdy zespół dostosowywał ją do swoich potrzeb. Nie jest niczym niezwykłym, że nie ma klienta / konsumenta, jeśli chodzi o wydanie jakiegoś publicznego produktu / biblioteki / API. Nigdy go nie miałem. W moim przypadku nasz GM działał jak jeden, co IMO przypominało brak.

2-tygodniowe sprinty są trudne. Bardzo trudne. 3 tygodnie są lepsze, ale tak naprawdę są dla doświadczonych i zaznajomionych z zespołem procesowym. Mieliśmy 4 tygodnie lub miesiąc. To dało nam wystarczająco dużo czasu na „osiedlenie się”, że tak powiem na początku, i większą pewność siebie na końcu dzięki większej ilości testów. Podobało mi się to i trzymałbym się co najmniej 3 tygodni.

Drugi zespół, z którym współpracowałem, nie miał nic oprócz zaległości. Spotkaliby się razem, zdawali raport o stanie i o tym, co będzie dalej, i tyle. Gdy wszystko zostanie zrobione, pojawią się kolejne zaległości. Wiedzieli, że to nie był SCRUM, ale to działało dla nich i to jest ważne.

Czy to jest lżejsze? Z pewnością tak jest. Ale to nie jest SCRUM. W SCRUM podoba mi się to, że promuje dyscyplinę. Ludzie odczuwają presję codziennego dostarczania czegoś. Każdy wie, co robią inni, a on ponosi porażkę, wszyscy to wiedzą. Nawet jeśli ktoś próbuje to zatuszować (czytaj kłamstwo), staje się to oczywiste znacznie wcześniej niż w przypadku innych procesów. Więc kiedy się różnisz i upraszczasz, jak w przypadku tego zespołu, musisz być pewien, że robisz to z właściwymi ludźmi. W przeciwnym razie może się po prostu rozpaść naprawdę szybko, degradując do bezsensownych spotkań o statusie, gdzie wszyscy po prostu zostaliby i pomyśleli: „Co ja tu robię? Wiem, co muszę zrobić, więc do diabła?”

To moje dwa centy. Zajmuję się opracowywaniem SCRUM: planuję pracę, dzielę się na zadania, oceniam je, obserwuję postępy. To naprawdę pomaga mi być na bieżąco. Zastosowałem kilka rzeczy z SCRUM do projektów, które zleciłem na zewnątrz i to zadziałało dla mnie świetnie.

Po prostu ... bądź zwinny ;-)

Schultz9999
źródło
1

Polecam zignorować Scruma. Za kilka lat pojawi się nowa moda, a ty będziesz mniej cyniczny i nadal będziesz mógł go ogarnąć całym sercem. W rzeczywistości możesz szybko zostać ekspertem. Następnie możesz zarobić dużo pieniędzy, pisząc na nim książkę i przemawiając na konferencjach.

Ponieważ wiele rzeczy ma charakter cykliczny, najprawdopodobniej ta nowa moda będzie procesem ciężkim, podobnym do RUP. To, co się wydarzyło, jest takie, że wszyscy będą postępować zgodnie z lekkimi, zwinnymi procesami, które zostaną obwinione za niepowodzenia projektu. Zatem logicznym rozwiązaniem jest to, że wymagane jest więcej planowania i projektowania z góry!

Poważnie, nie sądzę, że potrzebujesz Scruma. W scrumie nie ma nic lepszego niż inne konkurencyjne zwinne procesy. Ma też wiele głupich nazw rzeczy.

Antonio2011a
źródło
1

To świetnie, ale wydaje mi się, że to zdrowy rozsądek. Dlaczego ta potrzeba została skodyfikowana?

Scrum jest zwykle porównywany do starszych, bardziej ciężkich metod. Metodologie próbowały sprawić, by wodospad bez sprzężenia zwrotnego działał, wymuszając więcej dokumentów, więcej podpisów i więcej planowania z góry. Manifest Agile (który cytujesz) był odwróceniem tych pomysłów.

Powiedziano mi, że metodologia pomaga nam reagować na zmiany. Jakie specyficzne aspekty SCRUM pozwalają mi być tak elastycznym, że wcześniej nie osiągałem tego w moich spotkaniach ad hoc, rozmowach sześcianowych i spotkaniach dotyczących planowania programistów?

Wygląda na to, że masz już zwinną strukturę. Jeśli już dobrze reagujesz na zmiany, to oczywiście nie potrzebujesz pomocy. Niektóre procesy stają się tak ukryte w procedurze, że usunięcie błędu wymaga pełnej analizy i fazy projektowania funkcjonalnego i nie może wejść do projektu najwcześniej w przyszłym roku.

Wyjaśniają potrzebę posiadania działającej dostawy co dwa tygodnie lub sprintu. W moim konkretnym projekcie nie ma „klienta”, oprogramowanie nie zostanie ukończone przez rok lub dłużej, a tymczasem prawdopodobnie będę co miesiąc demo kierownictwa wyższego kierownictwa. Skąd więc wyraźna potrzeba dostarczenia produktu co drugi tydzień?

Oryginalny Scrum zaleca miesięczne sprinty. W skracaniu sprintu panuje paskudny trend w kierunku zwinnego machismo. („Tak, cóż, nasze sprinty są tylko jeden dzień ...”) Klient / Klient jest tym, kto ma uprawnienia do stwierdzenia, że ​​projekt jest gotowy do realizacji lub potrzebuje więcej pracy. Jeśli co miesiąc przeprowadzasz demo do wyższej kadry kierowniczej, prawdopodobnie jest to twój klient i prawdopodobnie już jesteś bardzo blisko Scruma.

Na podstawie opisu tego, co robi twój zespół, Scrum prawdopodobnie nie różni się zbytnio. Możesz uzyskać pewną wartość ze standaryzacji, ponieważ łatwiej będzie wyjaśnić osobom postronnym, co się dzieje, jeśli użyjesz terminów Scrum. Scrum może być również używany jako tarcza; na przykład Scrum nakazuje, aby zespół podejmował decyzje techniczne - wskazanie tej zasady może być dobrym sposobem na uzyskanie wartości technicznej, która w przeciwnym razie byłaby trudna do sprzedaży (na przykład programowanie w parach).

Scrum to w zasadzie interfejs, który może wdrożyć twój zespół. Jeśli tak, masz dobry pomysł na komunikację z osobami spoza zespołu, a oni mają dobry pomysł na komunikację z tobą. Tylko Ty możesz wiedzieć, czy Twój zespół tego potrzebuje.

Sean McMillan
źródło
0

Nie używamy Scruma w pracy. Używamy metodologii opartej na Agile i Lean, która pod wieloma względami jest podobna. Użyłem tego procesu w zespołach różnej wielkości od 3-5 osób, w tym ołowiu. Chociaż istnieją różnice, myślę, że możesz pomóc ci dowiedzieć się, czy Scrum jest przydatny w twojej sytuacji.

Dokonywanie metodyki

Ujawniamy nasz proces, ponieważ przeglądamy go przy każdym podsumowaniu / przeglądzie sprintu. Częścią podsumowania / przeglądu jest zidentyfikowanie praktyk, które nie działają dla nas. Omawiamy również praktyki, które naszym zdaniem będą dla nas skuteczne, a jeśli będzie wystarczająca zgoda, wypróbujemy ją. Nie bylibyśmy w stanie tego zrobić bez skodyfikowania naszej metodologii.

Wyloguj się

To jest koń roboczy dla naszego procesu. To gwarantuje, że to, co piszemy, jest potrzebne. Kiedy otrzymujemy określoną funkcję, idziemy do naszego klienta. Klient jest kimkolwiek, kto użyje tego, co piszesz. W niektórych przypadkach musisz przesłać klienta do osoby, która reprezentuje klienta (np. Zarządzanie produktem). To są nasze kroki i dopóki ostatni krok nie zostanie zakończony, funkcja nie zostanie wykonana.

  • Uzyskaj tę funkcję z tablicy, modułu śledzącego itp.
  • Przed napisaniem czegokolwiek porozmawiaj z klientem i dowiedz się, czego szuka.
  • Zaimplementuj tę funkcję.
  • Pokaż klientowi działającą funkcję w jej ostatecznej formie Poproś klienta o podpisanie się po zakończeniu tej funkcji.

Plastry pionowe

Cały nasz rozwój wykonujemy w pionowych plasterkach. Obsługuje to możliwość wypisania się z ukończoną funkcją, a także z tych innych powodów.

  • Amortyzuje problemy z integracją, wprowadzając je do każdej funkcji. Pomaga wyeliminować czas kryzysu na końcu projektu.
  • Pozwala nam łatwo wycinać funkcje, ponieważ eliminujemy wiele zależności krzyżowych.
  • Pozwala nam odciąć rozwój, jeśli potrzebujemy zmienić kierunek.
  • Możemy wykonywać wersje iteracyjne , zapewniając klientowi wcześniejszą funkcjonalność.

Akceptacja TDD

Wykorzystujemy ramy testów jednostkowych do akceptacji tdd. Daje nam to wiele korzyści.

  • Duża restrukturyzacja nie kosztuje dużo czasu na powtórne testowanie.
  • Zapewniamy funkcjonalność klienta.
  • Zajmujemy się integracją kodu.
  • Wspieraj praktykę rozwoju Vertical Slice.

Kompilacja jest zawsze zwalniana

Po każdym naciśnięciu kod powinien być zwalnialny. Nawet jeśli funkcja jest niekompletna, nic nie powinno być zepsute. Wszystkie testy powinny zostać uruchomione, a wszystkie poprzednie funkcje powinny być obecne. To naprawdę rozszerzenie naszego rozwoju pionowego wycinka. Jako taki ma wiele takich samych korzyści.

  • Pozwala nam łatwo wycinać funkcje, ponieważ eliminujemy wiele zależności krzyżowych.
  • Pozwala nam odciąć rozwój, jeśli potrzebujemy zmienić kierunek.
  • Możemy wykonywać wersje iteracyjne , zapewniając klientowi wcześniejszą funkcjonalność.

Ciągła integracja

Każde wypychanie generuje kompilację za pośrednictwem naszego serwera kompilacji CI. Serwer kompilacji sprawdza kod, uruchamia cały zestaw testów, taguje kod i pakuje go do wdrożenia. Wzmacnia naszą zasadę, że kompilacja jest zawsze możliwa do wydania.

Oszacowanie punktów dla kart

Każdy błąd, funkcja i zadanie staje się „kartą”. Karta jest najmniejszą logiczną jednostką pracy, która przynosi pewne korzyści klientom. Wskazujemy je zgodnie z naszą skalą. Wszelkie, które przekraczają naszą maksymalną wartość punktową lub ulegają dalszemu rozkładowi. Stwierdziliśmy, że im większa wartość punktowa, tym większe odchylenie może nastąpić w czasie do ukończenia, a tym samym dalsze rozkładanie dużych kart. Jeśli karta ma wystarczającą dwuznaczność, zostaje zaokrąglona w górę do następnej wartości punktowej na skali. Każda karta musi zostać podpisana, aby można ją było uznać za kompletną. Prawidłowe oszacowanie wspiera naszą zdolność do obliczania prędkości.

Prędkość

Mamy tygodniowe sprinty. W każdy piątek planujemy pracę i ustalamy jej priorytety na następny tydzień. W oparciu o naszą szybkość mamy dobre wyobrażenie, ile „pracy” możemy wykonać w ciągu tygodnia. Nasza prędkość jest średnią i medianą wszystkich punktów ukończonych w ciągu tygodnia. Wzrosty odchyleń standardowych są analizowane pod kątem złych oszacowań (które zawsze starają się poprawić) lub zwiększonych zakłóceń (o których rozmawiam z kierownikiem). Prędkości można również użyć do oszacowania dokładnej daty zakończenia projektu, ale tylko wtedy, gdy jest to jedyny projekt nad którym pracuje.

Stopniowe doskonalenie i projektowanie

Mamy również zasadę pozostawiania kodu w co najmniej trochę lepszym stanie niż sposób jego znalezienia. Zmodyfikuj / przeprojektuj kod na początku karty. Celem jest uwzględnienie wzrostu organicznego, który może występować wraz ze stopniowym rozwojem. Dokonujemy również refaktoryzacji na końcu według normy.

W przeważającej części są to zasady, których przestrzegamy i dlaczego je przestrzegamy.

dietbuddha
źródło
0

Wydaje mi się, że jesteś w bardzo doświadczonym, dobrze funkcjonującym zespole. Gratulacje, Scrum / Agile zasadniczo formalizuje to, co twój zespół intuicyjnie przez cały czas.

Myślę, że zaletą (całej) firmy może być przyjęcie Scruma jako „wspólnej płaszczyzny”, nie pomiędzy członkami zespołu programistów, ale między zespołem programistów a całym działem biznesowym .

Podczas gdy Sprinty Scrumowe są rozgrywane czasowo, zespoły mogą wybierać pomiędzy zaleceniami od dwóch tygodni do 1 miesiąca. Wszelkie mniej i byłoby zbyt wiele recenzji i retrospekcji, a wszystko to może utrudnić firmie zmianę kierunku w ciągu roku. Wygląda na to, że znalazłeś swój ulubiony punkt na 1 miesiąc, więc naprzyj.

Masz wiele swobody w dostosowywaniu parametrów Scrum i jestem pewien, że możesz wyjaśnić swojej firmie, że nadal robisz Scrum we właściwy sposób. Jedną zaletą jest to, że jeśli spotkasz biznes w połowie drogi, jego zaangażowanie może przynieść pozytywne wsparcie.

jonathangersam
źródło