Używałem SCRUM w trzech różnych projektach w ciągu ostatnich czterech lat. Jedną z zalet SCRUM wydaje się być jego elastyczność i zdolność adaptacji, np. Do zmieniających się wymagań klienta. Kolejną zaletą jest to, że kierownictwo może łatwo śledzić postęp projektu.
Elastyczność SCRUM może być zaletą na przykład podczas wdrażania aplikacji internetowej, gdzie wymagania zmieniają się bardzo szybko, a klienci naprawdę rozumieją, czego chcą, po tym, jak zobaczyli prototyp.
Z drugiej strony istnieją inne rodzaje projektów oprogramowania (np. w lotnictwie przemysłu), gdzie wymagania są dość stałe: dostajesz dokument specyfikacji wymagań i musisz wrócić sześć miesięcy później z działającym oprogramowaniem i pełną dokumentacją. W przypadku tego rodzaju projektów wątpię, czy potrzebna jest elastyczność oferowana przez SCRUM (w sensie że nie musisz budować prototypów i pokazywać ich klientowi, aby uzyskać informacje zwrotne na temat wymagań): potrzebujesz raczej bardzo ustrukturyzowanego i systematycznego podejścia, które jest prawdopodobnie powtarzane w kółko dla każdego projektu, pozostawiając niewiele miejsca na niespodziankę.
Czy SCRUM jest uważany przez swoich zwolenników za metodologię tworzenia oprogramowania ogólnego przeznaczenia, czy też jest uważany za szczególnie dostosowany do określonych kategorii projektów lub obszarów zastosowań?
Na przykład ostatnio przeglądałem witrynę firmy produkującej oprogramowanie dla przemysłu lotniczego i zauważyłem, że używa ona modelu V. Czy zwolennik SCRUM powiedziałby, że SCRUM jest mniej odpowiedni dla tego rodzaju projektów, czy raczej zasugerowałby, że ta firma powinna spróbować przejść na SCRUM?
Uwaga że nie pytam o opinię czytelników tego forum, ale chcę wiedzieć, jaka jest ugruntowana opinia wśród autorów SCRUM: czy SCRUM jest uważany za uniwersalny, czy raczej odpowiedni dla niektórych zajęć tylko projektów? W tych ostatnich przypadkach, jakiego rodzaju projekty?
Komentarze
- Zobacz stackoverflow.com / questions / 596916 / when-should-you-not-scrum i eweek.com/c/a/IT-Management/…
- Że ” otrzymujesz dokument specyfikacji wymagań i musisz wrócić sześć miesięcy później z działającym oprogramowaniem ” to mit. Nawet jeśli tworzysz coś w rodzaju kompilatora dla formalnie zdefiniowanego języka (gdzie wymagania funkcjonalne wydają się być naprawdę jasne i naprawione), musisz zdecydować i ustalić priorytety rzeczy do zaimplementowania, istnieją niefunkcjonalne wymagania do omówienia z użytkownikiem i masz kilka stopni swobody, ponieważ trzeba zdecydować, jak rozwiązać pewne problemy. Dlatego podejście zwinne ma sens nawet w tego typu projektach.
- ” Dlatego podejście zwinne ma sens nawet w tego rodzaju projektach. „: Chociaż zwinne mogą być bardziej elastyczne, inne metody też są elastyczne. Być może inne metody są wystarczająco elastyczne, a zwinne jest zbyt elastyczne dla niektórych projektów. Tu tylko burza mózgów.
- ” Że ” otrzymujesz dokument specyfikacji wymagań i musisz wrócić sześć miesięcy później z działającym oprogramowaniem ” to mit. „: Nie ' nie sądzę . Chociaż możesz szybko zmienić etykietę przycisku na stronie internetowej, ponieważ klienci zmienili zdanie po obejrzeniu go, nie możesz tak łatwo zmienić krytycznej części oprogramowania awionicznego, które kontroluje ruchomą część samolotu. Być może potrzebne będą późne zmiany, ale zastanawiam się, czy metoda zwinna jest właściwym sposobem zarządzania nimi, czy też potrzebujesz bardziej złożonej iteracji innej metody (np. Modelu V).
Odpowiedź
SCRUM to metodologia ogólnego przeznaczenia, która może dobrze działać w przypadku większości projektów i wielkości zespołów, ale jest mniej przydatna dla dużych zespołów, które zajmują się bardzo dużymi projektowanie. Sama liczba osób zaangażowanych w niektóre projekty sprawia, że każda zwinna metodologia jest niezwykle trudna lub prawie niemożliwa, ponieważ do utrzymania porządku wymagana jest bardziej sztywna struktura. Przemysł lotniczy jest dobrym przykładem branży, w której zazwyczaj są duże projekty, w których podejście zwinne nie zawsze jest możliwe.
Komentarze
- Czy istnieje jakiekolwiek informacje, kiedy projekt jest uważany za zbyt duży, aby można go było wykonać w SCRUM? Rozważmy np. 18-miesięczny projekt dla zespołu 15-osobowego: czy taki zespół zyska na SCRUM, czy też pasowałby inny model, taki jak model V Powodem, dla którego pytam, jest to, że w ciągu 18 miesięcy wymagania i implementacja mają wystarczająco dużo czasu, aby dojrzeć i ustabilizować się i być może elastyczność zapewniana przez SCRUM nie jest tak naprawdę potrzebna.Raczej odpowiednie jest podejście bardziej średnio- i długoterminowe. Czy jest jakaś literatura na ten temat?
- Czas projektu @Giorgio nie ma znaczenia ', ale wystarczy 15 osób, abyś skorzystał z wielu scrumów grup, ale nadal jest w zarządzalnym zakresie dla SCRUM. kiedy zarządzanie komunikacją staje się dla Twojego zespołu pracą na pełny etat, czas zacząć przyglądać się modelowi V
- Mówisz poważnie? Wcześniej używaliśmy modelu V i przeszliśmy na SCRUM. Właściwie mamy wrażenie, że ' zwolniliśmy się właśnie z tego powodu: za dużo księgowości.
- @Giorgio, który byłby prawdziwy dla każdego przełącznika, jesteś na początku będzie wolniejszy, ponieważ nowy, tak jak Pierre 303, powiedział, że po kilku sprintach uzyskujesz lepszy pomysł.
- @Giorgio – to ' jest prawdą, wiele ” metodologii zwinnych ” jest cięższych niż ciężkie procesy, które ' są uważane zamienić! Oczywiście oznacza to, że ' się mylą – agile ma być lekki i wolny, a osobom postronnym wydaje się chaotyczny. Oznacza to, że Twój zespół musi być bardzo zorganizowany i zdyscyplinowany, ale to ' to generalnie korzyść. Zamiast tego wypróbuj Crystal od Alistaira Cockburna (jednego z założycieli Agile).
Odpowiedź
Dowolny rodzaj projektu ! Sprawdza się dobrze zarówno w dużych, jak i małych projektach.
Ludzie używali go do planowania ślubów, przeprowadzek itp. Nie dotyczy to tylko projektów związanych z oprogramowaniem.
Jestem głęboko przekonany, że istnieje wiele operacji biznesowych, które mogłyby skorzystać na podejściu podobnym do Scruma.
Komentarze
- Czy podzielasz się własną opinią autorów, którzy skodyfikowali i promowali SCRUM?
- Tak – powiedział niedawno Cheryl Hammond ( blog.bsktcase.com ), konsultantka ALM z Northwest Cadence podczas wykładu zatytułowanego ” Dzień mistrzów Scrum w życiu: nowy program Visual Studio „. Możesz go obejrzeć tutaj: msevents.microsoft.com/CUI/…
Odpowiedź
Zwróć uwagę, że Scrum nie jest metodologią, ale szkieletem.
Scrum będzie działał najlepiej w c Ross-funkcjonalny zespół z 5 do 9 programistów pracujących nad średni do dużego projekt wielkości (od 4 miesięcy do wielu lat). Jeśli Twój projekt jest większy, możesz go skalować za pomocą Scrum of Scrum .
Nie będę tutaj omawiał kwestii wielofunkcyjnych, ale tutaj co oficjalny przewodnik po Scrumie mówi o wielkości zespołu:
Optymalny rozwój Wielkość zespołu jest wystarczająco mała, aby zachować zwinność i wystarczająco dużą, aby wykonać znaczącą pracę. Mniej niż trzech członków zespołu deweloperskiego zmniejsza interakcję i skutkuje mniejszym wzrostem produktywności. Mniejsze Zespoły Deweloperskie mogą napotkać ograniczenia umiejętności podczas Sprintu, przez co Zespół Deweloperski nie będzie w stanie dostarczyć potencjalnie możliwego do wydania Przyrostu. Posiadanie więcej niż dziewięciu członków wymaga zbyt dużej koordynacji. Duże zespoły programistyczne generują zbyt dużą złożoność, aby można było zarządzać procesem empirycznym. Role Właściciela Produktu i Scrum Mastera nie są uwzględniane w tej liczbie, chyba że wykonują oni również pracę z Backlogu Sprintu
Sprint trwa około miesiąca.
Sprinty są ograniczone do jednego miesiąca kalendarzowego. Gdy horyzont Sprintu jest zbyt długi, definicja tego, co jest budowane, może się zmienić, może wzrosnąć złożoność i wzrosnąć ryzyko. Sprinty zapewniają przewidywalność, zapewniając kontrolę i dostosowanie postępów do celu przynajmniej co miesiąc kalendarzowy. Sprinty ograniczają również ryzyko do jednego miesiąca kalendarzowego kosztów.
Myślę, że nie ma sensu używać struktury opartej na iteracyjnym procesie z mniejszymi projektami niż 4 miesiące. 4 miesiące = 4 sprinty. Musisz również wziąć pod uwagę, że po 3 sprintach uzyskasz dokładniejszą prędkość .
To powiedziawszy Osobiście używam ograniczonej wersji Scruma do mniejszych projektów, ale tak naprawdę nie można tego nazwać Scrumem. W tym konkretnym przypadku korzystasz z podstawowych zasad Scruma we własnej implementacji frameworka.
Odpowiedź
na początek traktuj SCRUM jako tylko jeden zestaw wskazówek dotyczących wdrażania zwinnych praktyk. Nigdy nie myśl o tym jako o „świętej księdze” opisującej, jak wykonywać projekty. Na przykład w przypadku wielu projektów, w których wymagany jest stały przepływ zadań, Kanbam jest bardziej odpowiedni.
Projekty zwinne zazwyczaj kończą się niepowodzeniem tam, gdzie robisz projekty wymagające stałej daty zakończenia lub stałego kosztu. Chociaż nadal możesz wykonywać te projekty przy użyciu metod zwinnych, musisz wszystko zaplanować z góry, aby określenie, czy prawdopodobne jest, że trafisz w cel, nie jest zwykłym zwinnym sposobem – w zwinnym masz tendencję do kontynuowania pracy, dopóki nie zabraknie Ci rzeczy do zrobienia lub nie zabraknie Ci czasu. ponieważ wymagania i tak zmieniają się w trakcie projektu.
Komentarze
- Sposób, w jaki działamy zwinnie w naszym zespole, polega na tym, aby klient nadał priorytet historiom (od najważniejszych do najmniej ważnych), oceniamy historie użytkowników za pomocą kart pokerowych i planujemy tyle historii, ile możemy wdrożyć do ostatecznego terminu. Jeśli okaże się, że jesteśmy szybsi, planujemy więcej historii, zgodnie z tym, co będzie następne na liście priorytetów.
- Przeczytałem Twoją odpowiedź ponownie po kilku miesiącach i jest naprawdę pouczająca. +1