Jakie ramy lub metodologię poleciłbyś zespołowi Data Science?
Jestem Scrum Master'em dla zespołu składającego się głównie z Data Scientists i niektórych Software Engineers oraz Product Owner.
Nasza organizacja zdecydowała, że wszystkie zespoły pracują w dwutygodniowych sprintach z wykorzystaniem Scruma. Osobiście nie wierzę, że to działa. Framework Scrum tak naprawdę nie działa dla nas z następujących powodów:
- Bardzo trudno to oszacować, ponieważ poziom niewiadomych jest ogromny. Na przykład, jeśli miałbyś zaległości w realizacji eksperymentu, wynik mógłby i zwykle jest bardzo zróżnicowany. Wynik eksperymentu dosłownie napędza twoją pracę na nadchodzące dni.
- Nawet jeśli uda ci się zmusić zespół do rozbicia się na historie, istnieje ogromna liczba zależności między historiami. To bardziej przypomina schemat blokowy lub drzewo decyzyjne, a następnie mapę historii.
- PO i SM nie są naukowcami od danych, naprawdę nie można pomóc przy treści opowiadań.
- Z powyższych powodów zobowiązanie do sprintu prawie nigdy się nie kończy.
- Zespół nie komunikuje się w ten sam sposób, co inżynierowie. Potrzebują dużo czasu, aby omówić i postawić hipotezę (tj. Nie do tego służył Scrum), przynajmniej takie jest moje doświadczenie.
- Planowanie spotkań staje się nieporęczne ze względu na nieznany charakter pracy.
Jakie ramy lub metodologię poleciłbyś zespołowi Data Science?
Odpowiedzi
Warto rozróżnić, czym jest Scrum (zgodnie z definicją zawartą w Przewodniku po Scrumie ), a tym, co jest ze Scrumem powszechnie kojarzone.
Na przykład punkty fabularne, historie, szacowanie, szybkość itp. Nie są częścią Przewodnika po Scrumie.
Zespół nie komunikuje się w ten sam sposób, co inżynierowie. Potrzebują dużo czasu, aby omówić i postawić hipotezę (tj. Nie do tego służył Scrum), przynajmniej takie jest moje doświadczenie.
Ponownie, w Przewodniku po Scrumie nie ma nic, co mówi, że nie spędzasz dużo czasu na dyskusjach i hipotezach. Mówisz raczej o konwencjach Scruma niż o tym, co faktycznie mówi framework.
Pracowałem z zespołami data science, które korzystały z frameworka Scrum i spędzili mnóstwo czasu na omawianiu swojej pracy.
Planowanie spotkań staje się nieporęczne ze względu na nieznany charakter pracy.
W takim razie proponuję spędzać więcej czasu na synchronizację, a mniej na planowanie. Wartością frameworka takiego jak Scrum jest pomoc zespołowi we współpracy w sposób bardziej oparty na współpracy, wspierając się w razie potrzeby.
Aby odpowiedzieć na Twoje pytanie, zarówno Scrum, jak i Kanban mogą współpracować z zespołami analityków danych. Wybór frameworka zwykle sprowadza się do typów osobowości członków zespołu, charakteru organizacji i rodzaju domeny, w której pracujesz.
Spekuluję, ale podejrzewam, że problem polega na tym, że zespół narzuca im podejście, a nie kontroluje sposób, w jaki pracują. Retrospektywy oraz cykl inspekcji i adaptacji w Scrumie mają na celu umożliwienie zespołowi dostrojenia sposobu pracy, dopóki nie znajdzie odpowiedniego podejścia.
Kanban, tj. Zarządzany przepływ, a nie sprinty ograniczone czasowo, ma duży sens w badaniach i odkrywaniu dokładnie z powodów, o których wspomniałeś. Być może nadal możesz tworzyć wskaźniki i raporty o stanie, aby Twój zespół był odpowiedzialny przed kierownictwem, ale chodzi o to, aby skupić się na ustalaniu priorytetów i zrównoważonej realizacji, a nie na szacowaniu i iteracji. Powinno być możliwe uzasadnienie tego, jeśli możesz udokumentować rodzaj wspomnianych problemów.
Pracuj także nad zapewnieniem wydajnego potoku ciągłej integracji. Pod warunkiem, że możesz wypuszczać tak często, jak potrzeba, wtedy wszyscy wygrywają, jeśli nie muszą stawiać wszystkich swoich oczekiwań na jeden lub dwa tygodnie.
Jeśli jest dużo „hipotez” i spotkań bez ustalonych ram czasowych - chodzi raczej o to, że zakres prac nie jest jeszcze jasno sprecyzowany. Gdy zakres jest cementowany i przygotowywany jest harmonogram, ale pojawiają się nowe wymagania lub zmieniają się lub spotkania są opóźnione - przystępujemy do pracy tylko nad już uzgodnionym zakresem, podkreślając opóźnienia dla Klienta z opcjami kompromisu, jeśli chce on pozbawić priorytetów jedna funkcja na korzyść drugiej.
Możesz wypróbować ramy SAFe (https://www.scaledagileframework.com/# i https://www.guru99.com/scaled-agile-framework.html) - mogę to podkreślić poza tym, o czym wspomnieli wcześniej inni respondenci. Spośród wielu prelegentów na profesjonalnych konferencjach organizowanych w Rosji, ten schemat był wielokrotnie podkreślany jako używany w `` laboratorium '' (terminem tym określa się średni lub duży zespół, skupiony na rozwoju produktu w nieznanym dotąd obszarze jak my). Epicka -> Funkcja -> Przepływ historii użytkownika. Jak wspomniałeś, „Twój PO nie jest ekspertem w danej dziedzinie” i że istnieje „ogromna liczba zależności między historiami. To bardziej przypomina schemat blokowy lub drzewo decyzyjne, a potem mapę opowieści '', uznałem SAFe za potencjalnie odpowiedni do użycia, ponieważ ma właścicieli funkcji i funkcji, którzy stają się osobiście odpowiedzialni za wartość E2E, a ludzie, na których polegają, są ekspertami w tej dziedzinie obszar i może zapewnić wartość biznesową + kod.
Rozkład w SAFe jest następujący: Epicki -> Architektoniczny pod-epos (następnie podział na Cechę (y), które są podzielone na Historie, które z kolei są podzielone na Zadania) oraz Pod-epos biznesowy (następnie rozbicie na Cechę ( s), które są dzielone na historie, które z kolei są dzielone na zadania).
Moje osobiste doświadczenie (analityk biznesowy w dużym projekcie korporacyjnym, w którym na jednej z jego faz zastosowaliśmy podejście oparte na funkcjach SAFe, aby skupić się na dostarczaniu wartości biznesowej dla kilku, ale tematów zawierających wiele scenariuszy). Feature jest własnością analityka biznesowego, na który składnik produktu ma największy wpływ (inaczej „właściciel firmy” - odpowiedzialny za E2E, a konkretnie za wartość biznesową) oraz kierownik ds. Deweloperów (inaczej „właściciel techniczny” - koordynuje rozwój wszystkich historii, tj. E2E w ramach funkcji). Tymczasem „właściciel firmy” jest zależny od wyników wdrożenia, których właścicielem jest „właściciel techniczny”, „biznes” jest i tak najważniejszy,kiedy ostatecznie demonstruje to Klientowi (zewnętrznemu lub wewnętrznemu ogólnemu Właścicielowi Produktu - tak jak w Twoim przypadku) i zbiera informacje zwrotne.Business Stories w ramach Feature , każda z nich jest własnością analityka biznesowego (odpowiedzialnego za konkretny scenariusz, tj. Funkcjonalność według dekompozycji cech). Po opisaniu historii biznesowych i pojawieniu się widocznego E2E lub jego stałej części - organizowane jest rozpoczęcie dla Właściciela / Zespołu Historii Technicznej. Historie techniczne w ramach funkcji, każdy z nich jest własnością dev leadera (odpowiedzialnego za konkretny scenariusz, tj. funkcjonalność zgodnie z dekompozycją cech) - w celu uproszczenia raportowania, DEV Team odwzorował Cechę techniczną -> Historie techniczne, zachowując linki do ID Business Story (mówiąc o JIRA). Po wdrożeniu historii technicznych i pojawieniu się widocznego E2E lub jego stałej części - organizowane jest DEMO dla Właściciela / zespołu Business Story. Nie wyróżniłem Epics, ponieważ w tym podejściu „funkcja” była terminem bardziej odpowiednim. W skrócie: ZALETY: osobiste zaangażowanie i osobista odpowiedzialność. MINUSY: koszty ogólne pilnowania zadań technicznych dla nietechnicznego „właściciela firmy”.