Czy w Scrumie zadania takie jak konfiguracja środowiska programistycznego i rozwój zdolności powinny być zarządzane jako podzadania w ramach rzeczywistych historii użytkowników?

23

Czasami w projektach musimy spędzać czas na zadaniach takich jak:

  1. badanie alternatywnych ram i narzędzi
  2. poznanie ram i narzędzi wybranych do projektu
  3. konfigurowanie serwerów i infrastruktury projektu (kontrola wersji, środowiska kompilacji, bazy danych itp.)

Jeśli korzystamy z historii użytkowników, to gdzie powinna przebiegać cała ta praca?

Jedną z opcji jest uczynienie ich wszystkimi częścią historii pierwszego użytkownika (np. Stworzenie strony głównej aplikacji). Inną opcją jest wykonanie kolca dla tych zadań. Trzecią opcją jest włączenie zadania do problemu / przeszkody (np. Środowisko programistyczne jeszcze nie wybrane), a nie historii użytkownika.

Asim Ghaffar
źródło
zmieniłem nieco pytanie, aby było bardziej przejrzyste .. pytanie ma teraz jako podzadania w rzeczywistych historiach użytkowników zamiast jako historie
Asim Ghaffar,

Odpowiedzi:

12

W ciągu ostatniego roku dużo myśleliśmy o tym problemie.

Chociaż zgadzam się, że podstawowe ramy powinny istnieć przed rozpoczęciem projektu, w praktyce mogą one stanowić część samego projektu. Musisz więc jakoś sobie poradzić.

Podczas gdy łączenie konfiguracji projektu z historiami użytkowników może mieć sens, czasami zdecydowaliśmy się na proste zadania, które można dodać do rejestru produktów i uzyskać taką samą uwagę jak historie użytkowników. Wiemy, że te zadania techniczne są czasem konieczne, ale w każdym razie muszą być uzasadnione. Jeśli zespół uzna, że ​​są absolutnie niezbędne do osiągnięcia określonego celu, będzie częścią sprintu.

Trudno powiedzieć, co jest dla Ciebie najlepsze, więc eksperymentuj ! Spike może na razie wystarczyć, ale myślę, że później napotkasz ten sam problem, więc planuj z wyprzedzeniem. Wykonuj zadania zastępcze dla takich działań. Aby oddzielić zadania od opowieści drugiej, szybko je porównam na podstawie mojego doświadczenia z nimi.

Zadanie: zadanie jest koniecznością techniczną. Mogą to być rzeczy związane z zarządzaniem konfiguracją lub ogólną konfiguracją projektu, takie jak konfigurowanie repozytorium zatwierdzeń lub dodanie najgorętszego narzędzia do przeglądania kodu, jakie kiedykolwiek widziałeś w procesie programowania. Zadania należy brać pod uwagę przy planowaniu, podobnie jak historia użytkownika. Jeśli zespół może przekonać właściciela produktu, że posiadanie najnowszego i najlepszego narzędzia do sprawdzania kodu zwiększa wydajność i usprawnia komunikację w zespole poprzez wyeliminowanie długotrwałych sesji programowania par lub osobistych recenzji kodu, wówczas zwróci uwagę właściciela produktu.

Historie : Koncentrując się wyłącznie na perspektywie biznesowej, historie zawsze mają widoczną wartość dla klienta. Jakość wewnętrzna idzie w parze z tworzeniem wartości biznesowej.

Przypisujemy nawet punkty historii do zadań, a czasem pracujemy z nimi tak samo, jak w przypadku historii.

Na koniec wybrałbym to rozwiązanie w twoim przypadku (które może być również zastosowane ogólnie):

  1. Oddziel „konfigurację” i rzeczy techniczne do zadań (rzeczy, które nie generują bezpośrednio wartości biznesowej dla właściciela produktu).
  2. Być może zrób skok przed konfiguracją projektu, aby zainstalować najważniejsze narzędzia (SCM, narzędzia programistyczne, definiowanie procesów, standardy kodowania itp.)
  3. Zaakceptuj, że zadania te pojawiają się w trakcie trwania projektu i zaplanuj to, tworząc osobny „rodzaj” działań innych niż historie.
malta
źródło
Więc to, co nazywacie ZADANIEM, jest w zasadzie elementem pracy, takim jak historia użytkownika lub błąd? .. To nie jest ZADANIE, jak w zadaniach w historiach użytkowników, np. W kodzie, testowaniu, wdrażaniu itp.
Asim Ghaffar
2
Tak, aby uzyskać rozróżnienie między tymi, które nazywamy podzadaniami opowieści „Działania”.
malte
To, co nazywacie Zadaniem, jest w zasadzie problemem według MSF dla Agile 5.0
Asim Ghaffar
Jeśli odwołujesz się do tego opisu tutaj: msdn.microsoft.com/en-us/library/dd997897.aspx - Możesz nazwać to problemem tak, jak tam został opisany, myślę, że byłoby to odpowiednie. To sprawiłoby, że byłaby to twoja opcja numer 3
malte
2
Punkt 3 „Zaakceptuj, że zadania te pojawiają się w trakcie trwania projektu” jest szczególnie ważny. Agile Unified Process ma świetny obraz, który to pokazuje: i.stack.imgur.com/CUVFI.jpg . Zauważ, że dyscyplina „środowiskowa” nigdy tak naprawdę nie znika. Zauważ też, że większość prac związanych ze środowiskiem jest z góry. Więc jeśli nagle zauważysz, że wykonujesz wiele prac środowiskowych w późniejszej fazie, być może coś pójdzie nie tak.
Michael
4

Rób wszystko, co ma sens w twojej firmie. Nigdy nie pozwól, aby to, co robią inni ludzie, było przeszkodą dla zdrowego rozsądku.

Ale powiem, że wszystkie te zadania brzmią jak coś, co powinno się wydarzyć na długo przed rozpoczęciem rozwoju. Zastanawiam się więc, czy Scrum jest w ogóle odpowiedni do tych zadań. Trwają prace konserwacyjne i takie w zakresie kontroli źródła i baz danych, ale nie należy ich planować, powinny to być rzeczy, które się zdarzają i wpływają na twoją prędkość.

Będą chwile, kiedy będziesz musiał wybrać framework lub cokolwiek innego podczas projektu, ale kiedy powiem, że mam na myśli framework taki jak nHibernate, a nie framework taki jak .NET. W takich przypadkach badania powinny zostać wzbogacone i zabezpieczone czasowo, nie mówiąc już o dość krótkich. Spróbuj zarządzać nim tak, jakby programista był chory przez kilka dni.

Transfer wiedzy to kolejny ciągły proces, którym należy zarządzać poza ogólną prędkością rozwoju.

pdr
źródło
kiedy powiedziałem ramę .. to było jak powinniśmy iść na JSF lub Spring .. lub kiedy powiedziałem narzędzie .. to było tak, jakbyśmy poszli na Jboss lub Glassfish ..
Asim Ghaffar
1
Nie wiem, co masz na myśli mówiąc „na długo przed rozpoczęciem programowania” .. kiedy projekt się rozpoczyna, nie powinien zaczynać 1 od razu jak najszybciej, np. W ciągu 2 tygodni od daty rozpoczęcia projektu ... aw sprincie 1 jest prawdziwe kodowanie.
Asim Ghaffar
1
@AsimGhaffar: Nie sądzę, że powinno, nie. Jeśli zaczniesz kodować, zanim jeszcze podejmiesz decyzję, jak wybrać serwer aplikacji, podejmiesz przynajmniej jedną decyzję, która wymaga przepisania większości tego kodu. I nie wyobrażam sobie rozpoczęcia projektu bez skonfigurowanej kontroli źródła. Mam na myśli ok, jeśli masz wokół siebie programistów, znajdź dla nich coś produktywnego, na przykład prototypy. Ale nie angażuj się w projekt, dopóki nie podejmiesz kluczowych decyzji.
pdr
„nie powinien biec sprintem 1 rozpocząć jak najszybciej, np. w ciągu 2 tygodni od daty rozpoczęcia projektu”. Poprawny. Oznacza to, że Twoje środowisko jest skonfigurowane i gotowe do pracy. Masz już umiejętności korzystania z narzędzi, tworzenia kompilacji i wdrożeń. Jeśli nie masz wprawy w tych sprawach, a środowisko nie jest skonfigurowane, to nie jesteś gotowy, aby rozpocząć.
S.Lott
@ S.Lott hmm Myślałem, że wymagane są umiejętności W ZADANIU PRACY, tj. Podczas pracy nad projektem i nie ma żadnych wymagań dotyczących narzędzi do nauki dla sprintu 1.
Asim Ghaffar
2

Istnieje nazwa podejmowania jak największej liczby decyzji projektowych przed „oficjalnym” rozpoczęciem projektu. To się nazywa wodospad. Nie ma nic złego w opowiadaniach użytkowników, takich jak: „Jako programista muszę wybrać platformę, więc mamy punkt wyjścia dla strony internetowej”. Jeśli jest zbyt duża, aby zmieścić się w iteracji, spróbuj rozbić ją w stylu: „Jako programista muszę wdrożyć podstawową stronę główną w Drupal, abyśmy wiedzieli, czy pasuje ona do naszych potrzeb”.

Karl Bielefeldt
źródło
1

Jedną z opcji jest uczynienie ich wszystkimi częścią historii pierwszego użytkownika, np. Stworzenie strony głównej aplikacji.

Łamie „historię użytkownika” jako koncepcję. Jaki użytkownik jest w to zamieszany? Żaden. To jest praca, którą powinieneś już wykonać.

Inną opcją jest wykonanie do tego piku.

Nie jest zły.

Trzecią opcją jest uczynienie zadania częścią problemu (np. Nie wybrano jeszcze środowiska programistycznego), a nie historii użytkownika.

Mniej więcej tak samo jak skok, jeśli chodzi o planowanie i koszty ogólne.

Konfiguracja nie jest historią użytkownika.

Właśnie to powinieneś mieć na swoim miejscu, zanim jeszcze zaczniesz ten projekt.

Naprawdę nie możesz rozpocząć projektu, dopóki nie skonfigurujesz frameworka / narzędzia i serwerów i nie będziesz gotowy.

Jestem świadom, że wiele organizacji nie istnieją naprawdę dopiero po podpisaniu umowy. Jestem też świadomy, że wiele organizacji nie wybierają technologię dopiero po podpisaniu umowy. To wszystko są nieefektywne rzeczy, które są poza historiami użytkowników.

S.Lott
źródło
problem nie jest taki sam jak Spike. Pomyśl o problemie jako o elemencie pracy zaplanowanym w normalnym sprincie, ale nie ma punktów historii. Przykład problemu: SVN nie jest wybrany. Pożyczam słowo problem od MSF dla Agile 5.0
Asim Ghaffar
„problem nie jest tym samym skokiem”. Jeśli chodzi o definicje słów, masz rację. Ale kiedy myślisz o zaplanowaniu dodatkowej pracy przed sprintem 1, nie ma znaczenia, czy nazwiesz to problemem, czy skokiem. Wybierz jedno. Rzuć monetą. Heads.
S.Lott,
Znów miałem na myśli kwestię planowania obok historii w Sprint 1 - nie wcześniej niż w Sprint 1. Więc dla Sprint 1 powiedzmy, że wybieramy 2 historie użytkowników i 1 problem. Brak punktów historii do wydania. Spike rzeczywiście nastąpi przed sprintem 1 ..
Asim Ghaffar,
Skok lub problem nie ma znaczenia. To cała praca, która nie jest częścią historii użytkownika. To wszystko, co należy wykonać przed pierwszym sprintem. Możesz to nazwać skokiem lub problemem, niezależnie od tego, co cię uszczęśliwia. Ale to nie jest historia użytkownika.
S.Lott,
1

W pracy korzystamy z zadania przygotowania środowiska. Może to być mylące dla niektórych osób, ale zadanie, którego używamy, jest bardzo podobne do zadania z historii użytkownika. Zadanie nie należy do historii użytkownika, ale jest szacowane w godzinach i musi zostać uzgodnione przez właściciela produktu w celu ukończenia w określonym sprincie.

Używamy tego zadania również do prac architektonicznych, które nie mają „pozornej” wartości biznesowej, ale to podnosi jakość produktu, szczególnie w przypadku istniejącego produktu o dużej podstawie kodu.

Mogą one nie mieć zastosowania w twoim środowisku pracy, ale działało dobrze dla nas.

Chris Chou
źródło
0

Myślę, że łączysz dwie niezależne rzeczy. Historia użytkownika nie powinna zawierać żadnych szczegółów technicznych.

Wybór frameworka, konfigurowanie repozytoriów i serwerów oraz inne zadania powinny przejść do początkowej iteracji.

BЈовић
źródło
masz rację i nie sugeruję, aby były one zawarte w opisie historii. miałem na myśli takie zadania, jak „instalacja MySQL”, „ocena frameworka” jako część pierwszej faktycznej historii użytkownika .. tzn. jako użytkownika, którego chcę strona główna, dzięki czemu mam szybki dostęp do niezbędnych funkcji.
Asim Ghaffar
@AsimGhaffar Można to zrobić podczas pierwszej iteracji. Nie jako historia użytkownika, ponieważ użytkownicy nie muszą wiedzieć (ani nie powinni się przejmować), jaką technologię zastosowaliście, aby zaspokoić ich potrzeby.
BЈовић
0

Niedawno poszedłem na kurs Scruma i instruktor zasugerował, że należy użyć specjalnego sprintu o nazwie Sprint 0, aby rozwiązać dokładnie tego rodzaju problemy. Na kursie byli ludzie z różnym doświadczeniem w Scrumie i prawie wszyscy doświadczeni ludzie zgodzili się, mówiąc, że zrobili to samo. W niektórych przypadkach firmy wykorzystały Sprint 0 do oceny projektu i zdecydowały, czy jest to wykonalne, czy nie.

Dla kogoś, kto jest nowy w metodyce Scrum, takiej jak ja, wydaje się to fantastycznym rozwiązaniem, ponieważ chroni cię przed historiami użytkowników i wszystkimi innymi aspektami normalnego sprintu, takimi jak opinie użytkowników.

Ponieważ Sprint 0 ma ten sam czas, co inne sprinty, działa jako sposób na zapewnienie, że nie poświęcisz zbyt wiele czasu na konfigurację, ponieważ zawsze można je później ulepszyć. Chodzi przede wszystkim o przejście do stanu, w którym można zacząć opracowywać produkt.

Stuart Leyland-Cole
źródło
3
Cytując Alistaira Cockburn'a , mam przeczucie, że ktoś był naciskany na jego użycie Scruma, kiedy zrobił coś, co na początku nie miało żadnej oczywistej wartości biznesowej, i wymyślił „Och, to był Sprint Zero!”. aby oddalić chłopów z kilofami od jego progu.
Asim Ghaffar
0

na temat odkrywania 2-3 alternatywnych ram / narzędzi

Czasami może się to zdarzyć, jeśli masz specjalne wymagania, musisz zrobić POC, aby wybrać najlepsze narzędzie do rozwiązania tego wymagania. Do tego właśnie służy spike, ponieważ bez wiedzy o tym, jakiego środowiska użyjesz, najprawdopodobniej nie możesz oszacować historii, a sklepu bez oszacowania nie można zaplanować i podzielić na zadania.

a następnie poznając ramy, które wybraliśmy dla projektu

Dobrze. To jest dość niebezpieczne. Kiedy klient płaci za SW, oczekuje, że jesteś profesjonalistą, który już wie, jak korzystać z jego narzędzi. Klient nie płaci za naukę lub podejście do testowania / niepowodzenia. Na deweloperach spoczywa obowiązek uczenia się nowych narzędzi w wolnym czasie lub w specjalnym przydzielonym czasie płaconym przez jego pracownika, a nie przez klienta. Wydawanie pieniędzy klientom na naukę bez informowania klienta jest nieprofesjonalne.

Jeśli naprawdę musisz użyć czegoś specjalnego (na przykład wybranego interfejsu API lub narzędzia klienta), którego nigdy wcześniej nie używałeś, musisz poinformować klienta, że ​​cena wzrośnie o czas potrzebny na nauczenie się korzystania z interfejsu API. Może klient zmieni zdanie, jeśli wzrost ceny będzie zbyt duży.

Jasne, nie mam na myśli sytuacji, w której musisz szukać jakiegoś konkretnego nowego problemu w ramach, z których korzystałeś wiele razy. Mam na myśli sytuację, w której zaczynasz używać nowego API lub frameworka bez poświęcania znacznej ilości czasu (poza projektem) na naukę.

Jeśli naruszysz to, i tak będzie to widoczne w twojej prędkości, ponieważ zapewnisz bardzo małą wartość biznesową na iterację. Jeśli klient nie zna przyczyny, najprawdopodobniej anuluje projekt.

Jest to nadal ważne w przypadku projektów wewnętrznych - musisz poinformować swojego menedżera / firmę o czasie potrzebnym na naukę nowego API lub narzędzia. Ma to zwykle bardzo złe konsekwencje, jeśli menedżer liczy się z normalną produktywnością, a produktywność jest tylko ułamkowa z powodu nowego interfejsu API, którego próbujesz się nauczyć podczas wykonywania zadań. Jest to oczywiście jeszcze gorsze, jeśli niektórzy sprzedawcy obliczyli normalną wydajność po podpisaniu umowy z klientem.

na temat konfigurowania serwerów (SVN, bazy danych itp.)

To twoja infrastruktura i koszty wewnętrzne. Po rozpoczęciu projektu oczekuje się przygotowania infrastruktury. Konfigurowanie środowiska programistycznego nie ma żadnej wartości dla klienta i nie powinno być częścią żadnych wskaźników związanych z projektem - na przykład prędkości w Scrumie. Widziałem to zaimplementowane jako specjalna iteracja przedprojektowa używana tylko do konfiguracji środowiska, stworzenia podstawowej infrastruktury itp.

Ladislav Mrnka
źródło
Zajmujemy się rozwojem produktu, a nie projektami klientów :).
Asim Ghaffar
Dobrze. W takim przypadku należy osobno śledzić czas poświęcony na naukę i infrastrukturę, aby sprawdzić, jakie masz koszty ogólne. Ukrywanie tego czasu w zadaniach spowoduje uszkodzenie widoczności procesu programowania.
Ladislav Mrnka