W naszej firmie mamy pracę zespołu na 3 różnych projektów w tym samym czasie, w którym zazwyczaj tylko jedna lub dwie osoby biorą udział w każdym projekcie. Prace projektowe często wiąże się opanowanie nowych technologii i rozwiązywania lub błędów, zarówno prowadzące do zadań, które są bardzo trudne do oszacowania. W tej sytuacji zarząd nadal upiera się przy użyciu SCRUM i nie pozwala na przydzielenie bufor bezpieczeństwa na koniec sprintu do nieoczekiwanych sytuacjach. Spotkanie stand-up dzieje się dla całego zespołu, choć prawie każdy pracuje na niepowiązanych elementów oprogramowania lub różnych projektów oprogramowania razem.
Zastanawiałem się, czy ktoś nie widziałem SCRUM działa dobrze dla projektu za pomocą jednego dewelopera i zadań rozmytych, i jak się działa proces dobrze?
Jak oszacować zadania, które polegały badania / mastering nowe technologie (wiąże się to z uczenia się nowych języków programowania, platformy i narzędzia programistyczne)?
Czy ktoś udało się przekonać zarządzania nie używać SCRUM dla poszczególnych projektów, a jeśli tak, to jakie argumenty były najbardziej skuteczne?
Dzięki!
Odpowiedzi:
Wyszukaj „Personal Scrum” ... Widziałem kilka lub trzech postów na blogu osób, które to robią. Full Scrum ma pewne pojęcia, które nie przełożą się idealnie na zespoły jednoosobowe. (Moje doświadczenie - pewna „masa krytyczna” około 4 osób wydaje się sprawiać, że praca zespołowa działa dobrze).
http://blog.jgpruitt.com/tag/personal-scrum/ na przykład.
Ale takie rzeczy estymacji zadań, prędkości i sprinty ograniczonych czasowo, podczas którego zadanie-lista jest „chroniona” pracy dobrze nawet na 1.
źródło
Oczywiście nie. Twoje codzienne młyny byłyby bardzo krótkie i niesamowicie nudne!
Można cherry-pick bity myślisz by pomóc chociaż, karty sensu choć nie trzeba wypełniać je więc w pełni; sensowne jest też zatrzymywanie się po określonym czasie, aby sprawdzić postępy. Ale jeśli robisz to, sprawdź Kanban, kryształ i wszystkie inne metody Agile zbyt dla bitów, które ci pomóc.
źródło
Nie, nie możesz zrobić scrum bez zespołu. Zespół określa SCRUM jest „cross-funkcjonalny grupa ludzi odpowiedzialnych za zarządzanie się rozwijać produkt”, który jest ważną rolę w SCRUM.
Według http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf
Jednak nadal można być zwinny, i może korzystać z innych cech SCRUM jak utrzymanie produktu / sprint backlog oraz planowania i pracy pod sprinty / iteracji, przeglądanie i uzyskiwanie informacji zwrotnych od wszystkich zainteresowanych stron i ponownego planowania i tak dalej. Proszę przeczytać więcej o scrumie, ponieważ jest to znacznie więcej, jak opisano tutaj.
źródło
Pracuję w podobnym sklepie. Jak zauważyli inni tutaj, to, co opisujesz, może być zwinne, ale nie scrum. Dodałbym również, że to, czy logi i sprinty mają sens, zależy od tego, czy jest to nowa praca, konserwacja i bieżące wsparcie. Jeśli były, to podejście wodospad byłoby bardziej sensowne dla zespołu jednoosobowego. Jeśli nie, to z perspektywy PM, co robią, wydaje się być dobrym podejściem, jeśli mają wiele projektów w portfelu.
Entuzjastów Agile, sama wzmianka o użyciu wodospad jest świętokradztwem. Ale ludzie muszą zachować zdrowy rozsądek.
Podam przykład z niedawnego projektu kopalni. I prowadził zespół 3 programistów na agresywną 5 miesięcy czasu, aby zaprojektować dwie główne strony internetowe. Mieliśmy codzienne spotkania stand-up. Ale był to projekt wodospad, ponieważ był mały zespół, ograniczony cykl życia, a twórcy byli wszyscy wykonawcy krótkoterminowe zaangażowane do projektu tylko do momentu uruchomienia. Projekt następnie bardzo tradycyjny cykl życia wodospad. Absolutnie nic złego. Z wyjątkiem zrobiliśmy pracę w „agile” sposób, mieliśmy spotkania stand-up i trzymaliśmy agile rozwoju najlepszych praktyk. Nasz mały zespół został zwolniony z cotygodniowych spotkań planistycznych sprint większego zespołu. Dlaczego? Ponieważ nie mieliśmy tygodniowe wdrożeń. A nasz zespół nie zależą ani wpływać na pracę wykonywana przez inny zespół. W rzeczywistości, pracowaliśmy niemal autonomicznie. Po stronach internetowych uruchomiła, my wtedy przesiedli się do błyskotliwy sposób na bieżące utrzymanie i wsparcie. Pozostali programiści pracują obecnie w innym miejscu. Wszystkie ulepszenia są planowane zgodnie z okresowymi wdrożeń.
Chodzi o to, że lepiej jest użyć procesów największy sens do wielkości, złożoności i dojrzałości każdego projektu. Jeśli robisz wiele badań, to jest trudne do oszacowanie przez najbliższe pięć miesięcy, tak zwinny jest chyba lepszym rozwiązaniem niż wodospadu.
Częścią problemu jest to, że niektórzy ludzie wydają się myśleć, że być w stanie planować kolejne pięć sprinty z wyprzedzeniem. przedtem był przypadek ze mną. Nie należy planuje więcej niż dwa sprinty, bo jeśli to jesteś pokonując cały cel posiadania sprinty. Sprint ma być zobowiązanie do dostarczenia realistycznego ilość ulepszeń w ciągu określonego czasu. Nie powinny zobowiązać się do czegoś nie jesteś pewien. Planowanie Sprint jest ze swej natury planowania krótkoterminowego, ale to rodzaj punktu. Jeśli masz harmonogram długoterminowej, a potem myśleć o łamanie rzeczy na mniejsze rezultatów. Lub utworzenie punktów kontrolnych na podstawie spotkań, gdzie jesteś w SDLC.
Planowanie sprintu ma być realistycznym zobowiązaniem co do tego, co zostanie ukończone w określonym czasie. Jeśli okaże się, że planowanie nie uwzględnia nieznanych zmiennych, być może powinieneś zacząć podawać zakresy lub prognozy pesymistyczne. Lub inny sugerował, punkty użycie historia. Sprinty również nie powinny być rezerwowane całkowicie, aby umożliwić poślizg i inne ważne zadania, które się pojawią.
źródło
W twoim zespole nie powinna być tylko jedna osoba i wątpię, że tak naprawdę jest. „Zespół” w SCRUM to nie tylko programiści. Czy jesteś przedstawicielem klienta, scrum master, programistą itp.? Czy naprawdę jesteś jedyną osobą, która robi coś związanego z tym produktem, podejmuje decyzje lub próbuje go sprzedać?
Co do oceny badań, robisz to jako historię. Zrobić jakąś historię specjalnie dla „Badania XXX” i dać punkty historia dla niego (pamiętaj, nie jesteś szacowania czasu tutaj, ale trudności). Należy również być w stanie dość odpowiednio oszacować trudności w realizacji niektórych funkcji, nawet jeśli trzeba badań technologii. Czasami ten ostatni fakt po prostu zamienia historię w „maksymalną trudność”.
Nie, naprawdę nie powinno być spotkanie ze wszystkimi deweloperami jak twój standup. Powinno być spotkanie z zespołem , który znowu jest nie tylko programiści.
Powodzenia. Hope you guys dostać to zorientowali się.
źródło
Zakładając, że masz właściciela produktu oraz mistrza scrum (jeśli nie, to jej nie scrum), scrum może pracować dla jednej drużyny człowieka. artefakty Scrum (zaległości, burddown wykresów) będą wykorzystywane tak jak są one wykorzystywane w zespole multi-ludzi. Teraz o spotkaniach:
Daily Standups: Codzienny standup służyłby do aktualizacji wszystkich, tj. Właściciela produktu, scrum master lub każdego innego zainteresowanego postępem. Scrum master wykorzysta te spotkania, aby dowiedzieć się o wszelkich przeszkodach. W razie potrzeby właściciel produktu może pomóc w ponownym sprawdzeniu zakresu.
Sprint Review: Na końcu każdego sprintu byś przekazanie przyrost oprogramowania pracuje do właściciela produktu lub klienta. Jeśli celem sprintu było nauczenie się „czegoś”, pokażesz PoC, który może być wykorzystywany przez kierownictwo (tj. Ogólnie klienta dla PoC).
źródło