SCRUM do projektow utrzymaniowych

[Krzysztof Kwiatkowski]

Hej,


Zastanawiam sie czy jest sens "go agile" w moim projekcie. Moze odrazu przyblize projekt zeby zrozumiec dobrze sytuacje.

Team 7dmiu osob implementuje server aplikacji, ktory rowiniez jest frameworkiem dla tych aplikacji. Poniwaz liczba aplikacji jest dosyc spora (ok 40 aplikacji pracujacych z 3 ma roznymi versjami tego servera), ilosc zglaszanych bledow jest dosyc spora (srednio 10 bledow dziennie). Co dosyc wazne, bledy maja zawsze najwyzszy priorytet, wiec musza byc naprawiane odrazu. Sredni czas spedzony nad jednym bledem waha sie w granicach 1 dzien do 1 tydzien dla jednej osoby.
Zeby troche zmieniejszyc ilosc pracy z tymi bugami, wyznaczona jest jedna osoba ktora wstepnie sprawdza gdzie jest 'root cause' bledu i albo naprawia buga albo wysyla do osoby ktora jest w danym temacie specjalista.
Oczywiscie oprocz tych bugow, team implementuje dodatkowe funkcjonalnosci.

Myslicie ze SCRUM zadziala w takim teamie? Macie moze jakies doswiadczenia? Mysle ze ludzie w Sabre i Google moga miec podobne projekty, wiec bylbym wdzieczny za opinie owych jesli czytaja ta grupe :)

Pozdrawiam
Krzysiek

[bartek]

Cześć,
z tego co piszesz, to w najlepszym przypadku (rozwiązanie błędu
zajmuje 1 dzień 1 osobie, zespół liczy 7 osób), to codziennie do bug-
logu trafiają 3 nierozwiązane babole?

czy może czegoś nie rozumiem ?

pzdr
bartek

On 15 Paź, 17:17, Krzysztof Kwiatkowski

[krzysiek.kwiatkowski]

Chyba rzeczywiscie troche przesadzilem z iloscia, ale na
usprawiedliwienie dodam ze ciezko to oszacowac. Bledow jest troche mniej
faktycznie i w duzej czesci bledy wynikaja ze zlej konfiguracji, a nie z
bledow w kodzie (wtedy blad odsylany jest do osob odpowiedzialnych za
konfiguracje).

To co chcialem podkreslic to, fakt ze ciezko oszacowac. Sa dni ze
faktycznie po tygodniu pracy zostaje 5 bledow do naprawienia i sa tez
takie ze jedna osoba wystarczy zeby obsluzyc wszystkie requesty w ciagu
dnia.

Pozdrawiam
Krzysiek

[Marcin Niebudek]

Pytanie podstawowe brzmi jakie problemy chciałbyś rozwiązać? Co chciałbyś zmienić w bieżącym procesie?

Pozdrowienia,
Marcin

2009/10/15 krzysiek.kwiatkowski <krzysiek.k...@gmail.com>

[Bartek Kobyłecki]

Dokładnie tak jak pisze Marcin. Mogę jeszcze podpowiedzieć, że najlepiej byłoby poprzedzić odpowiedź na pytanie 'co chciałbyś zmienić' pytaniami 'dlaczego właśnie to'. Pomocne może być: Cause-effect diagrams: a pragmatic way of doing root-cause analysis

bartek

http://www.linkedin.com/pub/bartek-kobylecki/0/502/534
http://www.goldenline.pl/bartosz-kobylecki

2009/10/15 Marcin Niebudek <dina...@gmail.com>

[krzysiek.kwiatkowski]

Moj cel to szybsze realeasy nastepnych wersji softu i lepsza ich jakosc.
Chcialbym tez przyspieszyc development - dlatego scrum, poniewaz:
1. w scrumie wszystko jest bardziej transparentne widac jak szybko team
radzi sobie z problemami
2. problemy sa rozwiazywane szybciej

Dzieki za linka. Przyszlo mi tez do glowy jedno pytanie - wiecie moze
gdzie moge znalezc jakies informacje na temat "W jakich projektach NIE
stosowac scrum'a"

Krzysiek

Bartek Kobyłecki wrote:
> Dokładnie tak jak pisze Marcin. Mogę jeszcze podpowiedzieć, że
> najlepiej byłoby poprzedzić odpowiedź na pytanie 'co chciałbyś
> zmienić' pytaniami 'dlaczego właśnie to'. Pomocne może być:
> Cause-effect diagrams: a pragmatic way of doing root-cause analysis

> <http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf>

>
> bartek
>
> http://www.linkedin.com/pub/bartek-kobylecki/0/502/534
> http://www.goldenline.pl/bartosz-kobylecki
>
>
> 2009/10/15 Marcin Niebudek <dina...@gmail.com

> <mailto:dina...@gmail.com>>

>
> Pytanie podstawowe brzmi jakie problemy chciałbyś rozwiązać? Co
> chciałbyś zmienić w bieżącym procesie?
>
> Pozdrowienia,
> Marcin
>
> 2009/10/15 krzysiek.kwiatkowski <krzysiek.k...@gmail.com

> <mailto:krzysiek.k...@gmail.com>>

[Michał Ostruszka]

Hej,

Może to Ci trochę pomoże. Jakiś czas temu na grupie też o coś podobnego pytałem
http://groups.google.pl/group/polish-agile-user-group/browse_thread/thread/ef329a2a8e1b7f52?hl=pl

zdrv, Michał.

2009/10/15 krzysiek.kwiatkowski <krzysiek.k...@gmail.com>

--
Michał Ostruszka
http://www.michalostruszka.pl

[Bartek Kobyłecki]

2009/10/15 Michał Ostruszka <michal.o...@gmail.com>

Hej,

Może to Ci trochę pomoże. Jakiś czas temu na grupie też o coś podobnego pytałem
http://groups.google.pl/group/polish-agile-user-group/browse_thread/thread/ef329a2a8e1b7f52?hl=pl

Przydługi wątek, ale na końcu 2 ciekawe linki. 

zdrv, Michał.

2009/10/15 krzysiek.kwiatkowski <krzysiek.k...@gmail.com>

Moj cel to szybsze realeasy nastepnych wersji softu i lepsza ich jakosc.
Chcialbym tez przyspieszyc development - dlatego scrum, poniewaz:
1. w scrumie wszystko jest bardziej transparentne widac jak szybko team
radzi sobie z problemami
2. problemy sa rozwiazywane szybciej

Tak sobie dumam o możliwych opcjach. Uzależniłem je od proporcji czasu jaki poświeca się na naprawę błędów vs realizację wymagań.

1) 50% nowe funkcjonalności, 50% bugfixy. 2 teamy: 5 osobowy do nowych tematów (scrum), 2 osobowy do bugfixów (kanban). Co iterację członkowie zespołów wymieniają się.

Potencjalna zaleta: aplikacje mogą być rozwijane (separacja bugów od nowych wymagań)
Potencjalna wada: problem z integracją (ile, jakie strumienie, kiedy releasy etc)

2) 80% bugfixy, 20% nowych funkcjonalności: 1 team + kanban

Potencjalna zaleta: minimalizacja czasu przestojów
Potencjalna wada: znalezienie czasu na realizację nowych funkcjonalności

3) 80% nowych funkcjonalności 20% bugfixy: 1 team + scrum

Nie chciałbym żeby powyższe punkty były odbierane jako konkretne przepisy. Raczej chodzi mi o pokazanie w jakim kierunku można iść rozwiązując problem projektów utrzymaniowych.

szacuneczek,
bartek

 

[Michał Ostruszka]

2009/10/16 Bartek Kobyłecki <b.kob...@gmail.com>

2009/10/15 Michał Ostruszka <michal.o...@gmail.com>

Hej,

Może to Ci trochę pomoże. Jakiś czas temu na grupie też o coś podobnego pytałem
http://groups.google.pl/group/polish-agile-user-group/browse_thread/thread/ef329a2a8e1b7f52?hl=pl

Przydługi wątek, ale na końcu 2 ciekawe linki.

Trochę zeszło na tematy testowania, ale końcówka całkiem do rzeczy.
 

zdrv, Michał.

2009/10/15 krzysiek.kwiatkowski <krzysiek.k...@gmail.com>

Moj cel to szybsze realeasy nastepnych wersji softu i lepsza ich jakosc.
Chcialbym tez przyspieszyc development - dlatego scrum, poniewaz:
1. w scrumie wszystko jest bardziej transparentne widac jak szybko team
radzi sobie z problemami
2. problemy sa rozwiazywane szybciej

Tak sobie dumam o możliwych opcjach. Uzależniłem je od proporcji czasu jaki poświeca się na naprawę błędów vs realizację wymagań.

1) 50% nowe funkcjonalności, 50% bugfixy. 2 teamy: 5 osobowy do nowych tematów (scrum), 2 osobowy do bugfixów (kanban). Co iterację członkowie zespołów wymieniają się.

Potencjalna zaleta: aplikacje mogą być rozwijane (separacja bugów od nowych wymagań)
Potencjalna wada: problem z integracją (ile, jakie strumienie, kiedy releasy etc)

2) 80% bugfixy, 20% nowych funkcjonalności: 1 team + kanban

Potencjalna zaleta: minimalizacja czasu przestojów
Potencjalna wada: znalezienie czasu na realizację nowych funkcjonalności

3) 80% nowych funkcjonalności 20% bugfixy: 1 team + scrum

Nie chciałbym żeby powyższe punkty były odbierane jako konkretne przepisy. Raczej chodzi mi o pokazanie w jakim kierunku można iść rozwiązując problem projektów utrzymaniowych.

Pytanie też, jak z nowymi funkcjonalnościami. Czy jest tam na tyle pracy, żeby robić do tego osobny zespół kosztem potencjalnych problemów z rozjechaniem kodu między fixami i mainem.
A może lepiej planowac iteracje na nowe funkcjonalności z odpowiednim buforem który w razie potrzeby zostanie zapchany fixami. Jeśli po jakimś czasie jesteś w stanie jakkolwiek ocenić ilość fixów ktore mogą się przydarzyć to może to być rozsądne podejście.
Wtedy fixy tak naprawdę bardzo nie zakłócają pracy nad nowymi rzeczami (w kontekście całej iteracji), ponieważ czas na nie został z góry przewidziany. Dodatkowo masz kontrolę i obraz tego jak te nowe funkcjonalności idą (+masz obraz bugfixingu w danej iteracji).

[bartek]

Generalnie nie zastanawiaj się zbyt długo. Wybierz jakieś podejście,
działaj i MIERZ - zobacz ile czasu faktycznie poświęcacie na błędy, a
ile na rozwój. Żeby to zrobić nie koniecznie musisz adoptować SCRUM by
the book (aczkolwiek na początek to wg mnie rozsądne podejście),
możesz wybrać pojedyncze praktyki, np. task board, daily scrum. Po 3
sprintach powinieneś znać trend. W zależności od tego podejmiesz
decyzję co do dalszych działań.

Inspect&adapt :o)

Powodzenia!
bartek

On 16 Paź, 09:24, Michał Ostruszka <michal.ostrus...@gmail.com> wrote:
> 2009/10/16 Bartek Kobyłecki <b.kobyle...@gmail.com>
>
>
>
>
>
> > 2009/10/15 Michał Ostruszka <michal.ostrus...@gmail.com>

>
> >> Hej,
>
> >> Może to Ci trochę pomoże. Jakiś czas temu na grupie też o coś podobnego
> >> pytałem
>

> >>http://groups.google.pl/group/polish-agile-user-group/browse_thread/t...

>
> > Przydługi wątek, ale na końcu 2 ciekawe linki.
>
> > Trochę zeszło na tematy testowania, ale końcówka całkiem do rzeczy.
>
> > zdrv, Michał.
>

> >> 2009/10/15 krzysiek.kwiatkowski <krzysiek.kwiatkow...@gmail.com>

> >>> > 2009/10/15 Marcin Niebudek <dinad...@gmail.com
> >>> > <mailto:dinad...@gmail.com>>

>
> >>> > Pytanie podstawowe brzmi jakie problemy chciałbyś rozwiązać? Co
> >>> > chciałbyś zmienić w bieżącym procesie?
>
> >>> > Pozdrowienia,
> >>> > Marcin
>

> >>> > 2009/10/15 krzysiek.kwiatkowski <krzysiek.kwiatkow...@gmail.com
> >>> > <mailto:krzysiek.kwiatkow...@gmail.com>>