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.
Odpowiedzi:
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.
źródło
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.
źródło
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:
itp.
Możesz zauważyć, że wszystkie powyższe funkcje głównie powodują dwie rzeczy:
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ś.
ź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. 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
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).
źródło
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 ;-)
źródło
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.
źródło
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.
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.
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.
źródło
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.
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.
Akceptacja TDD
Wykorzystujemy ramy testów jednostkowych do akceptacji tdd. Daje nam to wiele korzyści.
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.
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.
źródło
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.
źródło