Co widziałeś, że poszło nie tak podczas wprowadzania SCRUM?

Jaki był pojedynczy punkt awarii, kiedy Twoja firma zdecydowała się zastąpić obecne procesy SCRUM?

Czy możesz podać mi przykłady rzeczy, które naprawdę poszły źle, gdy firma próbowała wprowadzić SCRUM? Chciałbym usłyszeć twoje anegdoty, coś, czego sam doświadczyłeś, wielką porażkę , którą zobaczyłeś, ale która nie mogła zapobiec.

Słyszę wiele obaw związanych z brakującą dokumentacją dotyczącą decyzji dotyczących szczegółów implementacji oraz rozmiarów opowieści i poziomu szczegółowości opowieści.

Największym problemem jest nieporozumienie. Typowe awarie to:

• Tylko zespół zajmuje się Scrumem, ale reszta firmy (w tym sprzedaż, zarządzanie, HR) wciąż myśli po staremu. Przykłady:

  Bardzo ważna jest ciągła interakcja z klientem i jego zaangażowanie.

  Dział HR musi zrozumieć, że wydajność zespołu jest ważniejsza niż wydajność poszczególnych osób. KPI musi się do tego zmienić.

  Definicja funkcji jest procesem ciągłym. Definicja projektu będzie ewoluować podczas opracowywania na podstawie opinii klientów. Z powodu tego terminu projektu wymagany zestaw funkcji budżetu lub wyników może ulec zmianie (po zatwierdzeniu przez interesariusza).

  Zmiana jest częścią tego procesu.

  Szacowanie jest procesem ciągłym, którego nie można powiedzieć na początku projektu, że w ciągu 5 miesięcy zostaną wykonane wszystkie funkcje (wiele z nich nieznanych na początku).

  Zespół jest upoważniony do podejmowania decyzji. Zespół zobowiązuje się do ilości funkcji dostarczonych podczas następnego sprintu. Tego nie można żądać ani nakazać.

  Sprint to bezpieczna strefa dla drużyny. Gdy zespół zaangażuje się w określone historie użytkowników, zobowiązania nie można modyfikować poza zespołem.

  Część starej struktury organizacyjnej nie ma sensu przy przenoszeniu się do Scruma. Scrum definiuje trzy role: mistrz Scrum, właściciel produktu, zespół. Istnieją inne role, ale te trzy zwykle wystarczają do dostarczenia aplikacji. Nie ma sensu mieć mistrza Scrum, lidera zespołu, właściciela produktu i jednego lub więcej kierowników projektu. Kierownik projektu i lider zespołu są zbędnymi rolami w Scrumie.

• Facet, któremu przypisano rolę mistrza Scrum, nie robi mistrza Scrum. Scrum Master rozwiązuje przeszkody. Wszystko, co przeszkadza zespołowi, jest przeszkodą, którą należy rozwiązać jak najszybciej. Najczęstszym niepowodzeniem jest przypisanie tej roli programistom bez wcześniejszego doświadczenia ze Scrumem. Ta rola częściowo zastępuje zwykłego kierownika projektu, ale Scrum Master nie ma władzy nad zespołem, a Scrum Master nie wymaga implementacji żadnych funkcji. Scrum master chroni zespół nawet przed właścicielem produktu z nieosiągalnymi wymaganiami.

• Facet przypisany Rola właściciela produktu nie jest właścicielem produktu. Właściciel produktu ponosi odpowiedzialność finansową za produkt. Jest to bardzo konkretna i kluczowa rola do sukcesu. Rola ma coś wspólnego z analitycznym, kierownikiem projektu i kierownikiem produktu. Właściciel produktu zbiera i utrzymuje wymagania (zwykle w formie historii użytkowników). Do jego obowiązków należy przekazywanie informacji zespołowi i określanie priorytetów historii użytkowników. Powinien być na miejscu z zespołem, ponieważ współpraca między PO a zespołem jest ciągła.
• Zmieniam nazwę procesu na Scrum, ale pozostawiam większość procesu tak, jak było to po staremu. Najczęstszym scenariuszem jest przejście z wodospadu na Scrum, a najbardziej znaczącą zmianą jest to, że nie wykonujesz już analiz i dokumentacji, a mówisz, że to Ty Scrum.
• W wymaganiach / historiach użytkowników brakuje definicji ukończenia - bardzo często. Jeśli nie masz definicji ukończenia (kryteria akceptacji), nie możesz zakładać złożoności historii użytkownika podczas planowania sprintu. Jeśli nie masz ich podczas sprintu, nie możesz oznaczyć historii użytkownika jako ukończonej, ponieważ nie możesz jej zweryfikować.
• Jakość jest uważana za opcjonalną. Jakość w Scrum jest obywatelem pierwszej klasy. Możemy powiedzieć, że każde kryterium akceptacji powinno być objęte automatycznym testem kompleksowym. Gdy zaczniesz obniżać jakość i dodawać niesprawdzone funkcje, tracisz kontrolę nad produktem, ponieważ funkcje uznane za gotowe mogą przestać działać w dowolnym momencie z powodu regresji.
• Rezultatem sprintu powinien być przyrost dostawy (= działający i przetestowany) do produktu.

Edytować:

Dodaję ważną notatkę. Przy zastosowaniu zwinnego podejścia głównym celem jest jak najszybsze dostarczenie klientowi najwyższej wartości biznesowej. Ale klient (reprezentowany przez właściciela produktu) opisuje, jaka jest wartość biznesowa. Więc ogólnie nie jest prawdą, że nie masz analizy ani dokumentacji podczas korzystania ze Scruma. Jeśli klient zażąda analizy lub dokumentacji i oznaczy go jako wartość biznesową (na przykład z powodu dużego projektu lub długoterminowego projektu, który powinien zostać ulepszony w ciągu najbliższych kilku lat), również go utworzysz. Najbardziej podstawowym podejściem jest uwzględnienie analizy i dokumentacji w kryteriach akceptacji historii użytkowników. Analiza w takim przypadku jest udokumentowaną komunikacją z właścicielem produktu w jakiś znormalizowany sposób.

Największym problemem, jaki zauważyłem przez ponad 10 lat doświadczenia i scrum, jest to, że zespoły, które nie są jeszcze „zwinne”, decydują się na „elastyczność w kwestii zwinności” i zaczynają dostosowywać je, upuszczając pewne części itp. Bez jasne zrozumienie tego, co robi każda część i dlaczego tam jest.

Widziałem, że zespoły odnoszą większe sukcesy w scrumie, gdy na początku robią rzeczy według książki, niż zespoły, które zmieniają to, czego jeszcze nie „dostają”.

Wtedy dostajesz takie rzeczy, jak „pierwszy sprint, spełnimy wszystkie wymagania. Drugi sprint cały projekt itp., Ostatni sprint wszystkie testy”. Znany również jako wodospad. Lub nawet proste rzeczy, takie jak „i tak usiądźmy, co jest z tym pojedynczym biznesem?”.

Coś wspólnego z Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

Największym problemem jest zawsze wpisowe. Jeśli jakikolwiek zespół lub kluczowe osoby nie dokonały zakupu (zarządzanie projektami, kontrola jakości, rozwój itp.), Wówczas porażka jest prawie zapewniona.

Kolejnym powiązanym problemem jest uświadomienie wszystkim zaangażowanym, czym jest Scrum, a co nie.

Widziałem środowiska, w których zarządzanie projektami rzeczywiście wzięło to za szansę, aby przyjść bezpośrednio do programistów ze zmianami i oczekiwać, że zostanie to zrobione jutro, ponieważ korzystamy z nowego, wspaniałego procesu. Każdy, kto był w takiej sytuacji lub w innych nieudanych próbach wdrożenia Scruma i ma gorzki smak w ustach. Ci ludzie czasem też będą próbować usunąć projekt.

Innym problemem, który widziałem, są spotkania na stojąco. Zawsze dostaniesz faceta, który chce usiąść podczas spotkania na stoisku… „Mam złe plecy” czy coś w tym rodzaju. Zawsze wydaje się, że to ten sam facet, który nie ma pojęcia, jaki jest cel tego pojedynku, i nie chce zamykać się na temat polityki ani tego, co zrobił w ten weekend. Odkryłem, że spotkania stand up są kluczem do skutecznej komunikacji. Ważne jest, aby nikt nie zatruwał tych spotkań.

Próbując wykonać całą analizę kodu, który rozwijaliśmy w tym samym sprincie, faktycznie go kodowaliśmy.

Niedawno przenieśliśmy się do scrum i szczerze mówiąc, kierownictwo, które to zarządzało, traktowało każdy scrum jako 2-tygodniowy proces wodospadu. Nastąpiło takie przestrzeganie zasad scrum, które samo w sobie stało się procesem!

To jest problem, który uważam, wszystkie zwinne metodologie powinny polegać na elastyczności, aby działać efektywnie tak, jak to działa. Nie sposób, który jest zakazany przez procesy. Na przykład mieliśmy 2-tygodniowe scrumy, a zespół powiedział, że 2 tygodnie nie są wystarczające, aby wykonać dobrą pracę (nie z przestojami spowodowanymi przez koniec demo scrum i wstępnej oceny wymagań), więc chcieli przejść do 3 tydzień. Shock horror! Kierownictwo odmówiło, ponieważ zdecydowali, że 2 tygodnie na scrum są idealne i zostało to udokumentowane w procedurach jakości.

Scrum jest najmniej zwinną z metod zwinnych, i być może dlatego jest tak popularny - łatwiej go sprzedać starej gwardii. powinieneś usunąć rzeczy, które ci się nie podobają, ale nie sądzę, żeby tak się stało. Radzę wybrać bardziej elastyczną, mniej opartą na regułach i dodać reguły, których potrzebujesz. Wolę Crystal z tego powodu.

Ostatecznie pamiętaj tylko na wpół arseny zwinny manifest .

Największym problemem jest to, że również twój klient musi zaakceptować proces SCRUM i stać się zwinny. Większość klientów chce to usłyszeć na początku projektu:

• Ile to będzie kosztować
• Jak to będzie wyglądać
• Kiedy to będzie zrobione

Brzmi rozsądnie, ale jest absolutnie niezgodny ze zwinnym. Musisz wyjaśnić swojemu klientowi, dlaczego jest zwinny dla niego zamiast wodospadu.

Podczas mojej pierwszej wizyty w SCRUM mieliśmy dwa duże problemy:

1) Tak naprawdę nie mieliśmy właściciela produktu. Nasz szef musiał zagrać tę rolę, ponieważ nikt, kto powinien być właścicielem produktu, nie zgodziłby się na to. Ten rodzaj przygniatania rzeczy, ponieważ nie zawsze tak naprawdę zna odpowiedzi.

2) Mieliśmy złe podejście do rozliczania komponentów zewnętrznych. Nasze pierwsze sprinty obejmowały uruchomienie w pełni zautomatyzowanych testów i wielokrotnie napotkaliśmy problemy z automatyzacją używanych symulatorów. Jakoś nigdy nie udało nam się lepiej zrozumieć, że tak się stanie.

Głównym problemem, przed którym stoję w moim projekcie, jest to, że zbieranie wymagań ma miejsce po tym, jak oszacowaliśmy na kolejny sprint. Szacujemy na podstawie kryteriów akceptacji. Podczas zbierania wymagań stwierdzamy, że precyzyjnie dostrojony prąd przemienny jest znacznie większy, więc zadanie wstępnie oszacowane na 8 godzin wynosi teraz naprawdę 24 godziny! Czy mogę zmienić zaległości sprintu i skorygować prognozy i zmniejszyć moje historie? Nie proszę pana! Zwinne wymagania, że ​​nie można zmienić zaległości sprintu! Tak mówi mój TL. Więc nie powinienem też kodować zgodnie z oryginalnymi kryteriami akceptacji, dla których oszacowałem czas na 8 godzin! Pan Bóg! Nie! Nie możesz tego zrobić! To nie byłoby Zwinne, prawda!