Jak zacząć ze SCRUM w istniejącym projekcie

[CyberBoB]

Czy ktoś posiada doświadczenie we wdrożeniu SCRUM-a do istniejącego już projektu? Sprawa wygląda następująco:
1. Projekt prowadzony od ponad roku w metodyce wielkiego BUM i robimy co nam aktualnie wpadnie do głowy + łatanie bugów
2. Brak jakichkolwiek testów.
3. Brak doświadczenia zespołu w metodykach zwinnych - myśli, że jest agile bo nie ma żadnego projektu :)
4. Nie można sobie pozwolić na zaprzestanie prac na powiedzmy 2 miesiące żeby np. napisać podstawowe testy.
5. Zakładamy bardziej komfortową sytuację - obecny PM ma świadomość zmian jaką niesie ze sobą SCRUM - więcej władzy w rękach zespołu, pozwala zespołowi uczyć się na własnych błędach etc. etc. - to o czym mówił Kuba na przedostatnim spotkaniu.

Od czego zacząć ? Jak wykonać to, aby w jak najmniejszym stopniu wstrzymywać dalszy development produktu. Będę wdzięczny za Wasze przemyślenia / doświadczenia w tej kwestii.

[Marek Kirejczyk]

Ja bym zrobił tak:

Krok 1: Sprinty, stand-upy, planowanie, retrospekcje etc

Krok 2: Rozpoczęcie pisania testów do istenijącego kodu (dobrze zrobić code dojo lub kilka, żeby zespół podszkolił się w TDD)

Krok 3: Pisanie testów do starego kodu przy okazji refactoringów i bigfixów

Krok 4: Stopniowe pokrywanie testami legacy kodu (np kilka pkt na sprint) -> na początek bym zrobił tylko wysoko poziomowe akceptacyjne czy integracyjne w zależności od technologi i możliwości zespołu. 

Plan do zrealizowania w 3-4 sprinty (1-2 miesiące czasu).

Można też gdzieś po drodze Kanbana wcisnąć ;)

2012/4/12 CyberBoB <mateusz....@gmail.com>

--
Marek Kirejczyk
marek.k...@gmail.com

[Krzysztof Jelski]

W dniu 12 kwietnia 2012 22:39 użytkownik CyberBoB <mateusz....@gmail.com> napisał:

3. Brak doświadczenia zespołu w metodykach zwinnych - myśli, że jest agile bo nie ma żadnego projektu :)

Warto zaadresować ten punkt na samym początku transformacji. Dać szansę zdobycia wiedzy, o co chodzi, gdzie chcemy dojść i dlaczego.
Program minimum dla wszystkich: obejrzeć filmik "The Scrum Framework in 10 minutes" ze strony [1] (albo przygotuj się i zrób to samo po polsku). Lepiej: przeczytać Scrum Guide [2]. Jest wersja polska, 18 stron. Do rozważenia szkolenie lub coaching przez kogoś z zewnątrz.

[1] http://www.coachingagileteams.com/what-is-agile/
[2] http://www.scrum.org/scrumguides/

[Michal Margiel]

Cześć,

1-2 miesiące brzmi dla mnie dość ekstremalnie dla mnie ale wszystko zależy od zespołu. Jeśli ludzie są  gotowi na zmiany, chcą być zwinni i testować swój kod to super. Jeśli zaś są opory to ja bym podszedł do tematu jeszcze mniejszymi kroczkami. Może najpierw stendupy i tablicę z zadaniami. Potem można to co zrobiliśmy zaprezentować wspólnie naszym sponsorom. 

Wyszło? super.. nazwijmy to sprintem. Nie wyszło.. popróbujmy jeszcze. Na koniec przydało by się jakieś spotkanie podsumowujące nasze zmiany.

Chociaż z drugiej strony czasami warto zacząć właśnie od retrospekcji i sprawdzić co w boli ludzi w zespole.

Co do testów  to ja bym jednak rozpoczął pisanie testów do nowego kodu, przed otestowaniem istniejącego .

Co z tego, że napiszemy kilka testów do starego kodu, skoro wciąż będzie powstawały setki linii kodu bez testów.

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Marek Kirejczyk]

Michał: ops, w pkt 2 chodziło mi o testy do nowego kodu pomyłka, dzięki za zuważenie.

2012/4/12 Michal Margiel <michal....@gmail.com>

Co do testów  to ja bym jednak rozpoczął pisanie testów do nowego kodu, przed otestowaniem istniejącego .

Krok 2: Rozpoczęcie pisania testów do istenijącego kodu (dobrze zrobić code dojo lub kilka, żeby zespół podszkolił się w TDD)

--
Marek Kirejczyk
marek.k...@gmail.com

[Tomek Wykowski]

Hej,
3gr ode mnie:
1. Nie napisales nic o woli zespołu, jedynie o ich wiedzy. Ja bym zaczął od tego, żeby zespół poczuł po co to robić. Bo jak nie ma potrzeby to i nie ma woli, nie ma woli, nie ma zmiany. Tutaj wdl. mnie nic nie zastąpi dobrego szkolenia. Dla całego zespołu. Macie w Wawie kilku trenerów, z tego co pamiętam ktoś ostatnio prowadzil Scruma wieczorową porą. Jak są ograniczenia budżetowe to sam im powiedz - przede wszystkim "po co", potem dopiero "jak".
Ostatnio pojawiło się tłumaczenie na polski "Agile Samuraj" - podobno dość dobre. Leży u mnie na półce backlogowej z high priority. Może ktoś z grupy już to ma (było do kupienia na 33rd Degree).
2. Teraz Plan Marka. Jedynie 1-2 mce brzmia dość optymistyczne. Raczej 1-2 kwartały
3. Jeżeli ludzie są nowi to nie wprowadzaj Kanbana, dopóki nie poczują się pewnie z nowymi praktykami Scrum/XP.
Tomek

[Marek Kirejczyk]

1-2 miesiące na wprowadzenie zespołu w podstawowe praktyki, potem inspect i adapt :)

2012/4/13 Tomek Wykowski <twyk...@gmail.com>

--
Marek Kirejczyk
marek.k...@gmail.com

[Paweł Siergiejuk]

Hej

Z mojego doświadczenia to sprawa wygląda tak:

1 - na początek trzeba wszystkich w zespole uświadomić czym tak naprawdę jest SCRUM. Ja polecam obejrzeć wspólnie http://www.youtube.com/user/OpenViewVenture/videos?query=scrum i przedyskutować wszystkie wątpliwości razem. Jak już wszyscy będą wiedzieli z czym to się je i jakie są plusy to będzie mniejszy opór z wdrożeniem, możliwe że ludzie sami będą tego chcieli.

2 - wyznaczenie roli w projekcie. Znajdź osobę której najbardziej zależy na jakości i ma najlepsze układy w teamie i zrób z niego Scrum Mastera. Musi wiedzieć dużo o SCRUMie i wiedzieć kiedy powiedzieć STOP nie idziemy w tym kierunku bo to niezgodnie z SCRUMem. 

3 - następnie powoli agilowo wdrażamy SCRUMA, jeden krok na raz:

• SCRUM Meeting - koniecznie krótkie, aby ludzie nie uważali że tracą przez to czas.
• Sprint - określcie jakiej długości sprinty będą dla was najlepsze (w zależności od częstości zmian wymagań)
• User story
• Planowania 
• Retrospekcje 
• Testowanie 
• UnitTesty
• Pair Programming
• Dema
• TDD
• Tablice
• Wykresy

Niekoniecznie w tej kolejności.

Na początku ludzie się wahali ale chcieli spróbować i teraz nie wyobrażają sobie robienia wszystkiego w inny sposób. Wszyscy są bardzo zadowoleni i chwalą sobie SCRUM.

Odnośnie testów i czy to ma być 2 miesiące czy kwartały to raczej kwartały szczególnie gdy chcesz dopisywać testy do całości kodu który już powstał. My przyjęliśmy taką metodykę, że testy piszemy tylko do nowego kodu. Stary kod, jeśli jest krytyczny to piszemy zautomatyzowane testy funkcjonalne i akceptacyjne i przy okazji refacoringu dopisujemy UnitTesty. 

Pozdrawiam

Paweł Siergiejuk 

[Łukasz Lipka]

Ostatnio pojawiło się tłumaczenie na polski "Agile Samuraj" - podobno dość dobre. Leży u mnie na półce backlogowej z high priority. Może ktoś z grupy już to ma (było do kupienia na 33rd Degree).

Jeśli zespół faktycznie nie ma pojęcia o metodykach zwinnych to ta pozycja jest naprawdę dobra na początek, zwięzła i z humorem :)

2. Teraz Plan Marka. Jedynie 1-2 mce brzmia dość optymistyczne. Raczej 1-2 kwartały

dokładnie w 2 miesiące to zespół poczuje lub nie, że taka praca faktycznie przynosi korzyści dla nich. Z tego co widzę to ludzie średnio do zaadoptowania jakiejś metodyki zwinnej potrzebują koło 6 miesięcy.

3. Jeżeli ludzie są nowi to nie wprowadzaj Kanbana, dopóki nie poczują się pewnie z nowymi praktykami Scrum/XP.

dokładnie najlepiej na początek stosować jedną metodykę, która jest dobrze opisana i ludzie mogą sobie gdzieś poszukać dla czego to robią i jak to mają robić, bo tak będzie chaos :)

Pozdrowienia

Łukasz

W dniu 13 kwietnia 2012 07:59 użytkownik Marek Kirejczyk <marek.k...@gmail.com> napisał:

Michał: ops, w pkt 2 chodziło mi o testy do nowego kodu pomyłka, dzięki za zuważenie.

2012/4/12 Michal Margiel <michal....@gmail.com>

Co do testów  to ja bym jednak rozpoczął pisanie testów do nowego kodu, przed otestowaniem istniejącego .

Krok 2: Rozpoczęcie pisania testów do istenijącego kodu (dobrze zrobić code dojo lub kilka, żeby zespół podszkolił się w TDD)

--
Marek Kirejczyk
marek.k...@gmail.com

--
Pozdrowienia
Łukasz Lipka
http://lukaszlipka.blogspot.com/

[CyberBoB]

Dzięki za konstruktywne wskazówki. Jeżeli uda się przekonać osoby decyzyjne dam znać z efektów.

[Paweł Polewicz]

Hej

Z tego co piszesz, wnioskuję, że macie tak na prawdę trzy problemy:
1. brak metodyki
2. brak testów
3. brak czasu (czyli pewnie duże ciśnienie ze strony PM, żeby było gotowe *już*)

W związku z brakiem metodyki myślisz jak by tu wdrożyć scruma, a
koledzy już wcześniej sugerowali Ci Kanbana i ja również to zrobię.
Pojęcie Agile nie jest jednoznaczne ze SCRUMem. Jest wiele metodyk
agile, a scrum jest najlepiej rozreklamowany, co nie znaczy że jest to
najlepsze rozwiązanie dla Twojego zespołu.

Moim zdaniem, z tego co napisałeś, wynika, że w Twoim zespole będzie
ciężko wdrożyć scruma. Nie macie doświadczenia w lekkich metodykach
ani w unittestach i developerzy mają bardzo dużo wolności (każdy robi
to, co uważa za stosowne - to ma nawet nazwę, Cowboy Coding :) )...
Scrum wymaga dużo dyscypliny i zabrania ludziom decydowania o tym co
mają robić i kiedy (jest plan sprintu i koniec). Wy nie macie również
specjalnie czasu na szkolenia, wielogodzinne planowania i
retrospekcje, nie możecie wyjąć osoby do rysowania burndownów i dbania
o różne inne rzeczy, których wymaga scrum. A scrum da Wam różne
rzeczy, których tak naprawdę nie potrzebujecie.

Zróbcie sobie wspólnie z PM listę zadań, które robicie i tych które
macie do zrobienia w ciągu najbliższych kilku dni (jako pretekstu
możesz użyć majowych okresów międzyświątecznych ;) ). Zadanie nie może
być dłuższe niż jeden osobodzień. Następnie posortujcie tę listę tak,
żeby na dole listy były rzeczy, którymi z punktu widzenia PM
powinniście się zająć prędzej niż tymi na górze. Zacznijcie robić
zadania od dołu, z tym że ilość rzeczy, które robicie jednocześnie
musi być równa liczbie developerów, tzn jeden developer może robić
tylko jedno zadanie jednocześnie. Kiedy zostanie zakończone jakieś
zadanie, oznaczamy je innym kolorem na liście i rozpoczynamy następne
wzięte z dołu listy. Rozpoczętego zadania nie wolno przerywać, chyba,
że będzie zewnętrzna przeszkoda, wtedy je trzeba oznaczyć jako
zawieszone i wziąć następne.
I to właśnie było szkolenie z Kanbana. Możesz czuć się certyfikowany.

Powinno być tak:
- PM zadowolony, bo ma *jednokolumnowego* excela za pomocą, którego
kontroluje nad czym pracuje zespół. W każdej chwili (póki zadanie nie
zostanie rozpoczęte), może zmienić priorytety.
- zespół zadowolony, bo każdy robi sobie spokojnie zadanie i nie wisi
nad nim 5 innych

Nie pisałeś, że macie problemy z komunikacją w zespole, więc nie piszę
o standupach. Ktoś już chyba pisał.

Inspirująca prezentacja Scruma, którą Ken Schwaber przeprowadził dla
google: http://www.youtube.com/watch?v=IyNPeTn8fpo
Polecam aby przyswoić idee scruma, parę fajnych pomysłów oraz chwyty
marketingowe.

Pozdrawiam
Paweł