Temat: Scrum a duże projekty

Witam, nie jestem specjalista od Scrum-a, i znam tylko ogólne zasady działania tej metodyki. Zastanawia mnie kwestia dopasowanie Scrum-a do duzych projaktow IT. Zgodnie z moja wiedza scrum opiera sie na 30 dniowych iteracjach po ktorych ma nastapic oddanie gotowego produktu.

Interesuje mnie rozwiazanie sytuacji kiedy mamy przed soba duży, wieloetapowy(ale te etapy sa równoległe) i złożony problem i chcemy użyć scruma. Co jesli w zwiazku z dostepnymi zasobami sama analiza+projektowanie zajmuje wiecej niz 30 dni?
Uczestnicze teraz w projakcie gdzie pm 'obciął' czas na analize i to strasznie msci sie na programistach ktorzy pracuja jako testerzy/projaktenci/programisci i scigaja sie z deadlinem.
Co z projaktami gdzie zrobienie jak na moje standardt 'szybiego builda'(30 dni) mści sie później?
Pozdrawiam.maciej sowinski edytował(a) ten post dnia 06.03.08 o godzinie 13:15

Temat: Scrum a duże projekty

Wydaje mi sie, ze podstawowymi aspektami jakie towarzysza pracy ze SCRUM'em sa:
- adaptowalnosc,
- swiadomosc tego co sie zaplanowalo na danego sprinta,
- bliska wspolpraca z odbiorcami (klientem)

Adaptowalnosc: czyli dostosowanie sie do aktualnie panujacej sytuacji. Iteracje nie koniecznie musza byc 30-dniowe... nie musimy sie tego ortodoksyjnie trzymac.

Swiadomosc tego co sie zaplanowalo: PM nie moze (a przynajmniej nie powinien) tak sobie po prostu obciac czasu na jakas faze projektu. Jesli tak uczynil to znaczy, ze nie trzymacie sie metodologii SCRUM, ktora zaklada ze ZESPOL ocenia czy jest w stanie podjac sie zadan zalozonych przez haromonogram i dostarczyc je na zakonczenie danego sprinta. Chodzi o to zeby plan i sytuacja jak najbardziej odpowiadala stanowi faktycznemu a nie jakims fikcyjnym wyliczeniom. Kazdy czlonek zespolu musi byc na tyle odpowiedzialny zeby powiedziec np. 'tak ja jestem w stanie zrobic przez te 30 dni tyle a tyle'. Jesli PM tego nie slucha to jest zlym PM'em.

Bliska wspopraca z klientem: Jako, ze wg SCRUM'a nie mamy na poczatku scisle zdefinowanego ksztaltu koncowego produktu, dobrze jest blisko wspolpracowac z odbiorca po to zeby produkt z kazdym etapem ewoluowal zgodnie z zyczeniami klienta co pozwoli, na ostateczne, wieksze jego zadowolenie niz gdybysmy odcieli go od projektu i postawili przed gotowym produktem - do ktorego i tak zglosi mnostwo zmian.

Wazna sprawa i warta podkreslenia jest to ze aby skorzystac z dobrodziejstw SCRUM'a trzeba wdrozyc wszystki jego skladowe a nie tylko te ktore akurat PM'owi odpowiadaja. Innymi slowy jesli PM nie liczy sie ze zdaniem zespolu i zaczyna produkowac fikcyjne plany to cale zastosowanie SCRUM'a mozna, za przeproszeniem, o kant dupy rozbic :)

Pozdrawiam

Temat: Scrum a duże projekty

Witam

Scrum jak najbardziej sprawdza się w dużych projektach. Jeśli chodzi o długości sprintów to tak jak to napisał kolega wyżej jest to elastyczna sprawa. Ważne jednak, żeby z góry ustalić, że ten konkretny sprint będzie trwał tyle a tyle.

Jeśli programiści nie wyrabiają się z pracą to znaczy, że sprint został źle zaplanowany, nie skonsultowany z zespołem lub po prostu trzeba go będzie przedłużyć o tydzień lub dwa. Może warto pomyśleć o dołożeniu kolejnego developera do projektu lub przesunięciu niektórych ticketów do kolejnego sprintu? Proponuję szczerą rozmowę z klientem...

Jeśli zaś chodzi o produkt jako efekt sprintu - tutaj nie chodzi o serwis jako całość, ale raczej o zbiór ustalonych wcześniej z klientem funkcjonalności.

W razie pytań o scruma w praktyce zapraszam do kontaktu mailowego. Służę pomocą i doświadczeniem :)

Pozdrawiam,
piotr@aenima.pl

Temat: Scrum a duże projekty

Dobra, skoro już zostałem zaproszony do grupy, to się udzielę ;)

Z mojego własnego skromnego doświadczenia przy robieniu sporego projektu w Scrumie mam kilka luźnych wniosków.

1. Layout NAJPIERW. Trzeba to twardo wymusić na kliencie, jako że layout definiuje (doprecyzowuje) funkcjonalność od strony użytkownika końcowego, a więc także user experience. Póki nie ma layoutu, nie ma możliwości wyobrażenia sobie jak tak naprawdę ma wyglądać "flow" pracy z aplikacją, więc programiści swoje (wizje implementują), klient swoje (sobie wyobraża), a grafik swoje (zaprojektuje).

2. W dużych projektach często mamy sytuację taką, że trzeba zrobić małe badanie czy poszukiwanie możliwych rozwiązań danego problemu - nazwijmy to dalej "research". Wyniki tak zrobionego researchu, z jasną listą możliwych rozwiązań, trzeba potem przedstawić klientowi (mam na myśli product ownera), dostać od niego decyzję (którą z propozycji wybiera) i zaimplementować.
Otóż, nie powinno się researchu oraz implementacji wciskać w jeden sprint. Właśnie z powodu istnienia w tej pętli ośrodka decyzyjnego, nad którym nie mamy żadnej kontroli - product ownera - i który może (czasem nawet powinien) podejmować decyzję dłużej, niż planowany czas sprintu. Czyli research w sprincie X, natomiast implementacja rozwiązania w sprincie Y, który będzie pierwszym sprintem rozpoczętym po podjęciu decyzji.

3. Programistów demoralizuje i irytuje brak jasno zdefiniowanych rzeczy do zrobienia. To akurat zauważyłem w poprzedniej firmie, gdzie o Scrumie nikt nie słyszał. W każdym razie podczas każdego ze sprintów powinna być pula zadań "to be done" (czy też "can have"), do której programiści mogą sięgnąć w przypadku braku zadań do robienia z aktualnego springu. Zarówno w przypadku braku krótkotrwałego (coś "się mieli" i do tego czasu programista nie może w "tym" grzebać), jak i długotrwałego (zadania ze sprintu zostały skończone mocno przed czasem).
Fajny patent zastosował w naszym sporym projekcie Piotrek - pula "to be done" zawiera nierzadko zadania, które i tak pojawią się w przyszłych sprintach, już jako "normalne" (must/should have). Dzięki temu wiemy, że wykonywane zadania autentycznie dodają wartości aplikacji i nie są jakimiś wziętymi z powietrza zabójcami czasu ;)

Temat: Scrum a duże projekty

Zgodnie z moja wiedza scrum opiera sie na 30 dniowych iteracjach po ktorych ma nastapic oddanie gotowego produktu.

Jeżeli SCRUM opierałby się na projektach, które robi się od a do z w 30 dni to raczej nigdy byśmy o nim nie usłyszeli ;-). Z tego co wiem, sprint nie kończy się oddaniem "gotowego produktu" w tradycyjnym tego słowa znaczeniu, tylko wytworzeniu określonej wartości dodanej w obszarze biznesu klienta, nawet jeżeli będzie to bardzo mały zakres. W tym znaczeniu "gotowym produktem" moga być np dwa nowe okienka dialogowe do wprowadzania danych których klient bardzo potrzebuje.Michał Orzechowski edytował(a) ten post dnia 22.05.08 o godzinie 17:56

Temat: Scrum a duże projekty

Oczywiscie miales dwa okeinka dialogowe, ktore sa juz na 100% przetestowane i dzialajace. I to wlasnie jest kwintesencja uzywania SCRUM :)

Temat: Scrum a duże projekty

Pawel Klimczyk:
Oczywiscie miales dwa okeinka dialogowe, ktore sa juz na 100% przetestowane i dzialajace. I to wlasnie jest kwintesencja uzywania SCRUM :)

1.I nie mówiłeś jak mają wyglądać w połowie roboty. Bo może jednak powinny być okrągłe albo różowe , bo przed sprintem ustaliliśmy że powinny być seledynowe w kształcie rombów.
2. I nie czekałeś na nie długo na tyle żeby chęć posiadniania okrągłych i różowych owładneła twoim umysłem. Bo zespół jest odpowiedzialny i nie przeciąga terminów.
3. Te okienka są tobie bliższe niż enigmatyczne bibloteki i moduły bo dają ci nowe wspaniałe możliwości.Otrzymujesz nowe funkcje co tydzień lub dwa a czy twój pakiet biurowy to potrafi ?
4.Możesz też oszacować korzyści w trakcie realizacji projektu a nie po jego zakończeniu. Np. że te 2 seledynowe przyspieszyły procesy w twojej firmie a te 1 turkusowe z poprzedniego to nie bardzo.
5. Zespół ma satysfakcję ze stworzonych okienek bo ma namacalne dowody że okienka które stworzył dzięki kolorowi seledynowemu i romboidalnym kształtom są po prostu najlepsze.
6. A następne będą jeszcze lepsze bo zespół po każdym sprincie udoskonala proces (podobnie jak w keizen) .Piotr T. edytował(a) ten post dnia 21.08.08 o godzinie 23:13

Temat: Scrum a duże projekty

U nas gdy zaczynaliśmy ze Scrumem, problemem okazało się ujęcie w sprincie zadania, które jest tak duże, iż potrzeba 2-3 sprintów, aby je wykonać, biorąc pod uwagę istniejące zasoby deweloperów.

Nie bardzo dało się je podzielić na pod-zadania (realizujące konkretne elementy product backlogu), które pozwoliłyby na koniec sprintu oddać działający produkt. Z drugiej strony, nie mogliśmy sobie pozwolić na sprint o innej długości ze względu na koordynację z innymi zespołami oraz umowę z klientem na przekazanie mu do testowania co miesiąc nowej wersji.

No cóż, radziliśmy sobie, jak mogliśmy :-) W pierwszym sprincie kodowało się najniższe warstwy, bez spięcia z warstwą aplikacji, a więc część pracy była wykonana, produkt na koniec sprintu był jak najbardziej działający, aczkolwiek nie posiadał jeszcze funkcjonalności, nad którą się pracowało. Kolejny sprint, to było już faktyczne udostępnienie funkcjonalności i oddanie jej klientowi.

Nie jestem pewien, czy takie postępowanie jest zgodne ze Scrumem, bo w końcu na koniec pierwszego sprinta określona funkcjonalność istniała tylko w sensie technicznym, natomiast aplikacja jeszcze jej nie wykorzystywała ;-) Co byście zrobili w takiej sytuacji?

Temat: Scrum a duże projekty

Tomasz Lisowski:
U nas gdy zaczynaliśmy ze Scrumem, problemem okazało się ujęcie w sprincie zadania, które jest tak duże, iż potrzeba 2-3 sprintów, aby je wykonać, biorąc pod uwagę istniejące zasoby deweloperów.

Nie bardzo dało się je podzielić na pod-zadania (realizujące konkretne elementy product backlogu), które pozwoliłyby na koniec sprintu oddać działający produkt.

Nie mogę sobie wyobrazić funkcjonalnośći, która byłaby tak skomplikowana, że opisanie jej języku programowania zajmuje miesiąc.

Z drugiej strony, nie mogliśmy sobie pozwolić na sprint o innej długości ze względu na koordynację z innymi zespołami oraz umowę z klientem na przekazanie mu do testowania co miesiąc nowej wersji.

Czyli jakiej długości był Sprint? Przecież nie trzeba robić releasu do klienta po zakończeniu sprintu. Wystarczy, że jest to potencjalnie gotowy do deploymnetu produkt.

No cóż, radziliśmy sobie, jak mogliśmy :-) W pierwszym sprincie kodowało się najniższe warstwy, bez spięcia z warstwą aplikacji, a więc część pracy była wykonana, produkt na koniec sprintu był jak najbardziej działający, aczkolwiek nie posiadał jeszcze funkcjonalności, nad którą się pracowało. Kolejny sprint, to było już faktyczne udostępnienie funkcjonalności i oddanie jej klientowi.

Proponowałbym w pierwszym sprincie wykonać część funkcjonalności w najniższych warstwach + prowizoryczny interfejs, ponieważ na Review Meeting jest demo i coś trzeba pokazać. Może to być prezentacja, że dane są odczytywane/zapisywane do bazy danych lub komunikacja z aplikacją z poziomu lini poleceń. W drugi sprincie dostarczyłbym reszte funkcji z właściwym interfejsem.

Oczywiście nie znając bardziej szczegółowego opisu sytuacji trudno jest proponować odpowiednie rozwiązania.

Temat: Scrum a duże projekty

Krystian K.:

Tomasz Lisowski:
U nas gdy zaczynaliśmy ze Scrumem, problemem okazało się ujęcie w sprincie zadania, które jest tak duże, iż potrzeba 2-3 sprintów, aby je wykonać, biorąc pod uwagę istniejące zasoby deweloperów.

Nie bardzo dało się je podzielić na pod-zadania (realizujące konkretne elementy product backlogu), które pozwoliłyby na koniec sprintu oddać działający produkt.

Nie mogę sobie wyobrazić funkcjonalnośći, która byłaby tak skomplikowana, że opisanie jej języku programowania zajmuje miesiąc.

Mieliśmy np. implementację wsparcia dla fontów TrueType. W ramach jednego ze sprintów zaplanowaliśmy rezygnację ze specyficznego formatu plików, który nie wspierał fontów TrueType i zastąpienie go obrazem w formacie EMF. Szybko się okazało, że macki sięgają głęboko w system i konsekwencje są widoczne w wielu miejscach. Trzeba było to robić dłużej: od sterowników generujących wyjście na różne urządzenia (dla zaimplementowania formatu EMF) począwszy, do wsparcia w języku komend obsługujących nowy format, zapewnienie migracji starego formatu na nowy, itp. W zasadzie okazało się to pod-projektem samym w sobie ...

Z drugiej strony, nie mogliśmy sobie pozwolić na sprint o innej długości ze względu na koordynację z innymi zespołami oraz umowę z klientem na przekazanie mu do testowania co miesiąc nowej wersji.

Czyli jakiej długości był Sprint? Przecież nie trzeba robić releasu do klienta po zakończeniu sprintu. Wystarczy, że jest to potencjalnie gotowy do deploymnetu produkt.

Umowa z klientem przewidywała comiesięczne dostawy kolejnej wersji do testowania. Zgadzało się to z miesięcznym terminem sprintów. Poza tym, poszczególne zespoły musiały być gotowe pod koniec miesiąca, a więc czas trwania sprintów dla poszczególnych zespołów musiał być taki sam.

No cóż, radziliśmy sobie, jak mogliśmy :-) W pierwszym sprincie kodowało się najniższe warstwy, bez spięcia z warstwą aplikacji, a więc część pracy była wykonana, produkt na koniec sprintu był jak najbardziej działający, aczkolwiek nie posiadał jeszcze funkcjonalności, nad którą się pracowało. Kolejny sprint, to było już faktyczne udostępnienie funkcjonalności i oddanie jej klientowi.

Proponowałbym w pierwszym sprincie wykonać część funkcjonalności w najniższych warstwach + prowizoryczny interfejs, ponieważ na Review Meeting jest demo i coś trzeba pokazać. Może to być prezentacja, że dane są odczytywane/zapisywane do bazy danych lub komunikacja z aplikacją z poziomu lini poleceń. W drugi sprincie dostarczyłbym reszte funkcji z właściwym interfejsem.

Oczywiście nie znając bardziej szczegółowego opisu sytuacji trudno jest proponować odpowiednie rozwiązania.

Dużo z tego, co proponujesz zależy od tego, na ile elastyczny jest klient. W moim przypadku było z tym raczej trudno - stąd problemy. Product backlog był oczywiście uzgadniany z klientem, ale nie zawsze pozycje w nim dawały się ująć w ramach pojedynczego sprintu. Teraz będę miał możliwość dalszego "scrumowania" i mam nadzieję zobaczyć, jak to może wyglądać w innej firmie :-)

Temat: Scrum a duże projekty

Tomasz Lisowski:
No cóż, radziliśmy sobie, jak mogliśmy :-) W pierwszym sprincie kodowało się najniższe warstwy, bez spięcia z warstwą aplikacji, a więc część pracy była wykonana, produkt na koniec sprintu był jak najbardziej działający, aczkolwiek nie posiadał jeszcze funkcjonalności, nad którą się pracowało. Kolejny sprint, to było już faktyczne udostępnienie funkcjonalności i oddanie jej klientowi.

Nie jestem pewien, czy takie postępowanie jest zgodne ze Scrumem, bo w końcu na koniec pierwszego sprinta określona funkcjonalność istniała tylko w sensie technicznym, natomiast aplikacja jeszcze jej nie wykorzystywała ;-) Co byście zrobili w takiej sytuacji?

Dzielenie niepodzielnych historyjek to rzeczywiscie wyzwanie :). Gdy sie na prawde nie da, to ja zazwyczaj wolalbym zaczac od interfejsu. Tak, by moc "cos" pokazac klientowi jak najszybciej, nawet jesli tam pod spodem nie wszystko by dzialalo. Dzieki temu wiecej czasu zostaje na uporanie sie z problemami typu "tlo ma miec inny kolor". Ale na pewno nie jest to rozwiazanie idealne.

A przy okazji - wyrzucenie obslugi formatu pliku mialo tak wielka wartosc dla klienta, ze oplacalo sie mu abyscie spedzili kilka tygodni nad tym zadaniem? Gdzie znajdujecie klientow, ktorzy placa za obciecie funkcjonalnosci? ;) Troche sie drocze, rozumiem problem z obsluga TT i tak dalej, ale nie dalo sie tego jakos obejsc z korzyscia dla klienta?

Pozdrawiam,
Kuba

--
http://letni.agiletuning.pl/ - juz niedlugo w Krakowie!

Temat: Scrum a duże projekty

Jakub Dziwisz:
Dzielenie niepodzielnych historyjek to rzeczywiscie wyzwanie :). Gdy sie na prawde nie da, to ja zazwyczaj wolalbym zaczac od interfejsu. Tak, by moc "cos" pokazac klientowi jak najszybciej, nawet jesli tam pod spodem nie wszystko by dzialalo. Dzieki temu wiecej czasu zostaje na uporanie sie z problemami typu "tlo ma miec inny kolor". Ale na pewno nie jest to rozwiazanie idealne.

A przy okazji - wyrzucenie obslugi formatu pliku mialo tak wielka wartosc dla klienta, ze oplacalo sie mu abyscie spedzili kilka tygodni nad tym zadaniem? Gdzie znajdujecie klientow, ktorzy placa za obciecie funkcjonalnosci? ;) Troche sie drocze, rozumiem problem z obsluga TT i tak dalej, ale nie dalo sie tego jakos obejsc z korzyscia dla klienta?

Projekt, nad którym pracowaliśmy był jednym z tych, gdzie produkt przeznaczony dla całego rynku jest rozwijany przez pewien czas pod dyktando i zgodnie z wymaganiami dużego klienta, który dobrze płaci ;-) Z jednej strony kontrakt zobowiązywał nas do realizacji jego wymagań, a z drugiej - musieliśmy myśleć o reszcie klientów, a branża, w której działaliśmy była taka, że co klient to praktycznie nieco inne procesy, standardy, priorytety, itp. Ot, taki typowy koszmarek analityka biznesowego ;-)

Wyglądało to tak, iż w praktyce mieliśmy już gotowy design wsparcia dla TT gdy okazało się że jest taki "mały" element (plotfile - ów specyficzny format pliku), wprowadzony do systemu jakieś 20 lat temu, który nie wspiera TT, a naszemu głównemu klientowi wcale na tym specjalnie nie zależało, natomiast wsparcie dla różnych formatów plików "obrazkowych" było jak najbardziej istotne. Pozostała część klientów używała tego starego formatu plików, a więc nie mogliśmy go tak po prostu porzucić. Powstał więc pomysł, aby dodać wsparcie dla formatu EMF, którego możliwości pozwalałyby przejąć funkcjonalność starego formatu i opracować migrację starych plików do EMF. Wyglądało to super, dopóki ktoś nie dokonał niskopoziomowej analizy skutków takiej operacji ...

Aby uprzedzić pytanie pragnę nadmienić iż pomysł z dodaniem obsługi TT do plików starego formatu został odrzucony. I tak chcielibyśmy od tego formatu odejść, stopniowo chcieliśmy wyeliminować wsparcie dla natywnych fontów w systemie na korzyść TT, a tak mielibyśmy do czynienia z kolejnym pasztetem, który trzeba by było wspierać i tym trudniej byłoby wyeliminować stare technologie.

Temat: Scrum a duże projekty

Tomasz Lisowski:

Mieliśmy np. implementację wsparcia dla fontów TrueType. W ramach jednego ze sprintów zaplanowaliśmy rezygnację ze specyficznego formatu plików, który nie wspierał fontów TrueType i zastąpienie go obrazem w formacie EMF. Szybko się okazało, że macki sięgają głęboko w system i konsekwencje są widoczne w wielu miejscach. Trzeba było to robić dłużej: od sterowników generujących wyjście na różne urządzenia (dla zaimplementowania formatu EMF) począwszy, do wsparcia w języku komend obsługujących nowy format, zapewnienie migracji starego formatu na nowy, itp. W zasadzie okazało się to pod-projektem samym w sobie ...

Sam napisałeś, że były poszczególne etapy gdzie wsparcie było implementowane - jak dla mnie kazdy z tych etapów to osobne Story jeśli nie Task. Prawdopodobnie realizowaliście to kaskadowo a nie równolegle.

Umowa z klientem przewidywała comiesięczne dostawy kolejnej wersji do testowania. Zgadzało się to z miesięcznym terminem sprintów. Poza tym, poszczególne zespoły musiały być gotowe pod koniec miesiąca, a więc czas trwania sprintów dla poszczególnych zespołów musiał być taki sam.

Dlaczego nie można zrobić Sprintów 2 tygodniowych? Wówczas łatwiej odpowiadać na zmiany takie jak implementacja tej nieszczęsnej czcionki i przede wszystkim otrzymujecie cenny feedback od klienta 2x częściej, gdzie po pierwszym Sprincie nadal jesteście na tyle elastyczni, zeby wprowadzić zmiany. Jeszcze raz podkreślam zwrot "potencjalnie gotowy do deploymentu".

Nie da się niezauważyć, że to nie był/jest to zwykły Scrum, ale Scrum of Scrums (ze względu na klika zespołów pracujących nad tym samym produktem) i powinien być koordynowany przez Sprint of Sprints. Sprint of Sprints zapewni większą koordynacje w zespołach i przepływ wiedzy.

Dużo z tego, co proponujesz zależy od tego, na ile elastyczny jest klient. W moim przypadku było z tym raczej trudno - stąd problemy. Product backlog był oczywiście uzgadniany z klientem, ale nie zawsze pozycje w nim dawały się ująć w ramach pojedynczego sprintu.

No i nie muszą, bo to nie jest Sprint Backlog. Należy je wtedy robić na Sub-Stories.

Teraz będę miał możliwość dalszego "scrumowania" i mam nadzieję zobaczyć, jak to może wyglądać w innej firmie :-)

Powodzenia.

Temat: Scrum a duże projekty

Krystian K.:

Tomasz Lisowski:

Umowa z klientem przewidywała comiesięczne dostawy kolejnej wersji do testowania. Zgadzało się to z miesięcznym terminem sprintów. Poza tym, poszczególne zespoły musiały być gotowe pod koniec miesiąca, a więc czas trwania sprintów dla poszczególnych zespołów musiał być taki sam.

Dlaczego nie można zrobić Sprintów 2 tygodniowych? Wówczas łatwiej odpowiadać na zmiany takie jak implementacja tej nieszczęsnej czcionki i przede wszystkim otrzymujecie cenny feedback od klienta 2x częściej, gdzie po pierwszym Sprincie nadal jesteście na tyle elastyczni, zeby wprowadzić zmiany. Jeszcze raz podkreślam zwrot "potencjalnie gotowy do deploymentu".

Jasne, byłoby to z pewnością z korzyścią dla projektu. Aczkolwiek jak rozumiesz możliwość otrzymania feedbacku od klienta w momencie gdy nie jest w stanie on jeszcze przetestować rozwiązania, bo produkt jest tylko potencjalnie gotowy do deploymentu, natomiast funkcjonalność jeszcze nie działa ... Chyba, że masz na myśli samą ocenę, czy prototyp GUI się klientowi podoba czy nie, bo poza tym niewiele jeszcze mógłby zobaczyć ...

Kontakt z klientem był co miesiąc, po otrzymaniu od nas kolejnej wersji wykonanej w danym sprincie. Ewentualne kontakty z klientem w trakcie sprintu w zasadzie ograniczały się do komentarzy do wersji, którą otrzymał w poprzednim sprincie (co w pilnych przypadkach mogło niestety spowodować zmianę priorytetów czy pozycji w Sprint backlogu) lub do wymiany technicznych uwag z ekspertami klienta w zakresie szczegółów rozwiązań realizowanych w danym sprincie.

Nie da się niezauważyć, że to nie był/jest to zwykły Scrum, ale Scrum of Scrums (ze względu na klika zespołów pracujących nad tym samym produktem) i powinien być koordynowany przez Sprint of Sprints. Sprint of Sprints zapewni większą koordynacje w zespołach i przepływ wiedzy.

Dobry pomysł. U nas było coś, co szumnie nazywali Mission Control :-) Tam dyskutowało się na bieżąco ryzyka, problemy, zależności między zespołami, itp.

Mam wrażenie, że nie do końca wtedy wyszliśmy jeszcze z RUP-a, a raczkowaliśmy jeszcze w Scrumie :-)

Teraz będę miał możliwość dalszego "scrumowania" i mam nadzieję zobaczyć, jak to może wyglądać w innej firmie :-)

Powodzenia.

Dzięki :-)Tomasz Lisowski edytował(a) ten post dnia 03.06.09 o godzinie 08:41

Temat: Scrum a duże projekty

Tomasz Lisowski:

Chyba, że masz na myśli samą ocenę, czy prototyp GUI się klientowi podoba czy nie, bo poza tym niewiele jeszcze mógłby zobaczyć ...

Tak, to miałem na myśli, czasem prototyp GUI czy mała prezentacja działania może wyjaśnić dużo i dużo doprecyzować. Z reguły klient chce zupełnie coś innego niż opisał ;) Oczywiście nie zawsze specyfika projektu pozwala na nie-techniczną rozmowę z klientem. Czasem niedojrzały klient/product owner powie Ci tylko, że prototyp jest brzydki. Wtedy można spróbować porozmiawiać z przedstawicielem klienta\salesem, który komunikuje sie zwykle z klientem i może ma dobre wyczucie o co klientowi chodzi. Ogólnie zawsze jest lepiej sprawdzić rozwiązanie przed zakończeniem prac, bo wtedy właśnie jeszcze można je zmienić.