Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Witam,

Jestem właśnie na etapie wdrażania się w SCRUM. Przeczytalem pozycję Ken'a Schwaber'a, ogarnolem troche treści z netu, ale prawde mówiąc pozostało jeszcze kilka niewyjaśnionych kwesti ktore chciałbym ogarnąć od strony praktycznej.

Ktoś mi kiedyś napisał na grupie "estimating software", gdzie poruszyliśmy temat wdrażania SCRUM w firmie, że jest to tylko framework i uwypukla nieprawidłowości przy realizacji produktu.

Jednakże stosowanie tej medodyki wiąże sie z przestrzeganiem ról i zasad.

Chciałbym poruszyć kilka kwesti.

ScrumMaster kontroluje prawidlowy proces SCRUM. Usowa przeszkody i reaguje kiedy trzeba. Jednakże jak rzeczywiście wygląda praca ScrumMastera?

ProductOwner, reprezentuje stronę klienta oraz osob finansujących projekt. Rozumiem, że to on kontaktuje się bezpośrednio z tymi stronami w celu rozpoznania potrzeb jakie ma spełniać oprogramowanie.
Czy ProductOwner w rzeczywistości może reprezentować stronę firmy developerskiej pełniąc po części rolę "zbieracza wymagań" który do skutku rozpoznaje potrzeby klienta?

SCRUM neguje/zaciera hierarhie szczebli w zespole poprzez wzajemną współpracę wszystkich biorących udział w realizacji. A co z hierarhia w zespole i np rolą architekta, ktory jako najbardziej doświadczona osoba w zespole, projektuje architekture i kontroluje proces technologiczny?

Jak w rzeczywistości wygląda retrospekcja?

Inspekcja i adaptacja:
Scrum definiuje znaczenie momentu "skończone" w rozumieniu, że dana funkcjonalność została zakończona czyli, przetestowana i wpełni działająca, kod jest jasny i czytelny, poddany refaktoryzacji. Programista nie może zacząć nowej funkcjonalności dopuki aktualnie tworzona nie przejdzie w stan "zakończone".
Kiedy przeprowadzana jest inspekcja? Kto przeprowadza inspekcję? Jeżeli np. leader zespolu, to, czy w tym momencie programmer idzie na kawe;)? Czy np inspekcja przeprowadzana jest wspolnie z programistą? Jak naprawdę wygląda ten proces w rzeczywistości?

Zapraszam do dyskusji

PozdrawiamRoman Piekarski edytował(a) ten post dnia 13.10.09 o godzinie 06:40

konto usunięte

Temat: Wkręcam się:D

Jedyne o czym mogę się wypowiedzieć, to część "programistyczna". Otóż teoretycznie Scrum i metodologie z rodziny Agile nie "detronizują" (na przykład) architektów i nie rozwalają hierarchii w zespole, ale w praktyce prowadzą do
- zrównania zespołu pod względem kompetencji, gdzie "starszeństwo" oznacza po prostu osobę, z którą konsultuje się decyzje (na przykład kiedy mówimy o architekcie projektu)
- zredukowania do minimum etapu projektowania, celem realizacji projektu w małych fragmentach -- czyli mikrofunkcjonalność (ułamek większej funkcjonalności), jej (mikro)projekt, realizacja, testy (TDD/BDD proponuje je pisać jeszcze przed realizacją, zamiast mikroprojektu), spłukać i powtórzyć

Znaczy, jeśli architekt jest przyzwyczajony do siedzenia dwa tygodnie w swoim gabinecie i rozmawiania wyłącznie z analitykiem oraz, po tych dwóch tygodniach, podania zespołowi gotowego projektu całej (albo dużej części) architektury systemu i potem miesiąca wolnego, to jego pracę Scrum/Agile najbardziej przeformatują.

Możesz się więc spodziewać największego oporu ze strony architekta właśnie (bardzo mocna zmiana metodologii pracy, której był przecież uczony i przyzwyczajany).

Polecam googlnąć "agile architects ivory tower" i poczytać razem z resztą zespołu, włączając w to (a zwłaszcza z!) architekta oraz przedyskutować na spokojnie jak zmieni się flow informacji i pracy w związku z wprowadzeniem Scruma.

Dwa linki na początek, najlepiej poczytać właśnie w tej kolejności:
http://www.infoq.com/news/2008/01/agile-architect
http://www.agilemodeling.com/essays/agileArchitecture.htm

Na resztę Twoich pytań prawdopodobnie doskonale odpowiedzą większe materiały pisemne o Scrumie (zwłaszcza jak wyglądać może/powinna retrospekcja itd.).Tomasz Stachewicz edytował(a) ten post dnia 13.10.09 o godzinie 08:42
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Dzieki za namiary! Materialy zapowiadaja sie calkiem niezle. Napewno dzisiaj do nich siade.
Tomasz Stachewicz:
Dwa linki na początek, najlepiej poczytać właśnie w tej kolejności:
http://www.infoq.com/news/2008/01/agile-architect
http://www.agilemodeling.com/essays/agileArchitecture.htm
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Roman Piekarski:

ScrumMaster kontroluje prawidlowy proces SCRUM. Usowa przeszkody i reaguje kiedy trzeba. Jednakże jak rzeczywiście wygląda praca ScrumMastera?

Scrum Master załatwia wszystko co jest potrzebne, zeby team mógł wydajnie pracować. Oznacza to organizowanie takich prostych rzeczy jak pisaki i karteczki po bardziej skomplikowane typu pilnowanie Project Managera, żeby jak najszybciej podjął jakąś decyzję.

ProductOwner, reprezentuje stronę klienta oraz osob finansujących projekt. Rozumiem, że to on kontaktuje się bezpośrednio z tymi stronami w celu rozpoznania potrzeb jakie ma spełniać oprogramowanie.

Jeżeli oprogramowanie jest tworzone dla klienta zewnętrznego to jest tak jak napisałeś.
Czy ProductOwner w rzeczywistości może reprezentować stronę firmy developerskiej pełniąc po części rolę "zbieracza wymagań" który do skutku rozpoznaje potrzeby klienta?

Tak. W tym wypadku Product Ownerem jest sales albo Account Manager. On dogaduje z klientem, czego klient oczekuje, jeżeli nie ma możliwości ustalania tego bezpośrednio z klientem. PO jest angażowany w Planning Meeting i zajmuje się Product Backlogiem. PO definiuje kiedy Story jest DONE i akceptuje lub nie Sprint.
SCRUM neguje/zaciera hierarhie szczebli w zespole poprzez wzajemną współpracę wszystkich biorących udział w realizacji. A co z hierarhia w zespole i np rolą architekta, ktory jako najbardziej doświadczona osoba w zespole, projektuje architekture i kontroluje proces technologiczny?

Poprzednik dobrze to opisał :)
Jak w rzeczywistości wygląda retrospekcja?

Są rózne metody przeprowadzania retrospekcji. Ogólnie chodzi o to, żeby team określił negatywne i pozytywne aspekty minionego Sprintu i wybrał max 3 action pointy do nastepnego Sprintu. Za action pointy, a dokładnie ich wdrożenie odpowiedzialny jest Scrum Master.

Inspekcja i adaptacja:
Scrum definiuje znaczenie momentu "skończone" w rozumieniu, że dana funkcjonalność została zakończona czyli, przetestowana i wpełni działająca, kod jest jasny i czytelny, poddany refaktoryzacji. Programista nie może zacząć nowej funkcjonalności dopuki aktualnie tworzona nie przejdzie w stan "zakończone".
Kiedy przeprowadzana jest inspekcja? Kto przeprowadza inspekcję?

Jeżeli Ci chodzi o "inscpect and addapt" to to pojęcie odnosi się do całego procesu i inspect odbywa się na Sprint Retrospective meeting a addapt w kolejnym Sprincie. Team ma lepiej estymować, lepiej wykonywać swoje zadania w każdej kolejnej iteracji i eliminować problemy.
Jeżeli np. leader zespolu, to, czy w tym momencie programmer idzie na kawe;)? Czy np inspekcja przeprowadzana jest wspolnie z programistą? Jak naprawdę wygląda ten proces w rzeczywistości?

Tutaj chodzi Ci o Code Review. Code Review może byc prowadzony pomiędzy 2 developerami lub developer + lead/architekt. To zależy od Twojej organizacji i są do tego narzędzia.
Określ sobie Definition of DONE i standardy jakich trzeba się trzymać. Wtedy Review jest łatwiejsze.
Cały workflow wygląda mniej więcej tak:

Development->Code Review->Testing->DONE
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Krystian K.:
Roman Piekarski:

ScrumMaster kontroluje prawidlowy proces SCRUM. Usowa przeszkody i reaguje kiedy trzeba. Jednakże jak rzeczywiście wygląda praca ScrumMastera?

Scrum Master załatwia wszystko co jest potrzebne, zeby team mógł wydajnie pracować. Oznacza to organizowanie takich prostych rzeczy jak pisaki i karteczki po bardziej skomplikowane typu pilnowanie Project Managera, żeby jak najszybciej podjął jakąś decyzję.

No własnie, Project Manager. Jak sie tak patrzy na SCRUM i role jakie on przewiduje to PM jest jak by wyeliminowany. Rola PM zawsze bylo planowanie i przydzielanie zadan, czesciowy kontakt z klientem a teraz zespol przejmuje zadania na siebie gdzie tak naprawde komunikacja bardziej toczy sie zespol<->klient. Gdzie w takim razie jest rola PM w tym wszystkim? Czesc rzeczy bierze na siebie zespol a czesc PO.
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Roman Piekarski:
>

No własnie, Project Manager. Jak sie tak patrzy na SCRUM i role jakie on przewiduje to PM jest jak by wyeliminowany. Rola PM zawsze bylo planowanie i przydzielanie zadan, czesciowy kontakt z klientem a teraz zespol przejmuje zadania na siebie gdzie tak naprawde komunikacja bardziej toczy sie zespol<->klient. Gdzie w takim razie jest rola PM w tym wszystkim? Czesc rzeczy bierze na siebie zespol a czesc PO.

PO reprezentuje klienta i jest jest wyrocznią w sprawach "jak to ma wyglądać". PM nadal jest potrzebny, żeby zatwierdzać budżet, załatwiać zasoby, kontraktorów, wypełniać arkusze w Excelu ;) itd. Zmienia się to, że PM nie pokazuje palcem kto ma co robić i nikt nie pyta PM o to jak to zrobić, bo komunikacja jest skrócona. PM też nie mówi kiedy,co i jak ma być zrobione, bo to team sam bierze za to odpowiedzialność.
Agile stawia przed PM cięzkie zadanie, bo musi brać na siebie odpowiedzialność za projekt przed stakeholders i "odwalać brudną robotę", a z drugiej strony musi zaufać teamowi i polegać na tym, że team potrafi sam się zorganizować i poczuwa się do odpowiedzialności.

Mam nadzieję, że nie zakręciłem za bardzo ;)
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Krystian K.:
Mam nadzieję, że nie zakręciłem za bardzo ;)

Gra:) Dzieki:D

konto usunięte

Temat: Wkręcam się:D

Generalnie Scrum umniejsza rolę PMa, w stopniu pozwalającym na scrummasterowanie w większej ilości projektów lub obcięcie niepotrzebnego etatu ;)
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Eeee... PM nie jest najlepszym kandydatem na Scrum Mastera, bo ma tendencje do wprowadzania swojej kontroli, narzucania zdania co do rozwiązań i estymat oraz wskazywania palcem co kto ma robic na Daily Scrums. Widziałem to już kilka razy. Wtedy to nie jest Scrum, tylko nowa nazwa starego z większą ilością meetingów i nowym raportem (burn down).
Paweł S.

Paweł S. Grupa PM, PRINCE2(R)
approved trainer,
Project Manager -
...

Temat: Wkręcam się:D

Krystian K.:
Roman Piekarski:
>

No własnie, Project Manager. Jak sie tak patrzy na SCRUM i role jakie on przewiduje to PM jest jak by wyeliminowany. Rola PM zawsze bylo planowanie i przydzielanie zadan, czesciowy kontakt z klientem a teraz zespol przejmuje zadania na siebie gdzie tak naprawde komunikacja bardziej toczy sie zespol<->klient. Gdzie w takim razie jest rola PM w tym wszystkim? Czesc rzeczy bierze na siebie zespol a czesc PO.

PO reprezentuje klienta i jest jest wyrocznią w sprawach "jak to ma wyglądać". PM nadal jest potrzebny, żeby zatwierdzać budżet, załatwiać zasoby, kontraktorów, wypełniać arkusze w Excelu ;) itd. Zmienia się to, że PM nie pokazuje palcem kto ma co robić i nikt nie pyta PM o to jak to zrobić, bo komunikacja jest skrócona. PM też nie mówi kiedy,co i jak ma być zrobione, bo to team sam bierze za to odpowiedzialność.
Agile stawia przed PM cięzkie zadanie, bo musi brać na siebie odpowiedzialność za projekt przed stakeholders i "odwalać brudną robotę", a z drugiej strony musi zaufać teamowi i polegać na tym, że team potrafi sam się zorganizować i poczuwa się do odpowiedzialności.

Dosyć dobrze się całość sprawdza, jeśli PM potrafi tak "opakować" pakiety prac aby można je było realizować adaptacyjnie. Szczególnie ma to zastosowanie, gdy w macierzy kompromisów projektowych wartością ustaloną lub, jeszcze lepiej, optymalizowaną jest jakość. Zachowujemy wtedy taradycyjną warstwę zarządczą z zwinnym wytwarzaniem produktów. Jeszcze inaczej - można zamiast pakietów prac opakować cały etap i zastosować planowanie kroczące (rolling-wave planning)- całkiem nieźle opisane np. w PMBoK-u. Przy dobrze napisanym planie komunikacji, planie zarządzania jakością i dobrze zbudowanym zespole zarządzania projektem mamy z tyłu SCRUM-a (lub coś zbliżonego) ze wszystkim jego dobrodziejstwami a na wierzchu PMBoK-a lub PRINCE-a (trochę trudniej, ale można np. zobaczyć podejście xPRINCE) ze wszystkimi jego dobrodziejstwami.
Całość w literaturze (np. Wysocki) nazywana jest APF - Adaptive Project Framework i świetnie się sprawdza nie tylko w projektach informatycznych. Należy zaznaczyć też, że nie do wszystkich projektów się nadaje.Paweł S. edytował(a) ten post dnia 13.10.09 o godzinie 16:52
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Kolego, spokojnie. Chłopaki wdrażają SCRUM i chcą zrozumieć jak to działa w życiu codziennym. A tutaj poziom abstrakcji 9 w skali do 10. PMBok-a, PRINCE'a i innych nie ma w Agile Manifesto, ani w książkach Kena Schwabera, więc nie zawracajmy sobie tym głowy.
Paweł S.

Paweł S. Grupa PM, PRINCE2(R)
approved trainer,
Project Manager -
...

Temat: Wkręcam się:D

Właśnie piszę jak to działa w życiu codziennym :-)
Trzeba pamiętać, że projekt informatyczny to max 60-80% pisania i testowania kodu. Reszta to projekt organizacyjny. Tą częścią raczej nie da się zwinnie zarządzać.
I tu jest właśnie rola PM-a - wykorzystać SCRUM-a tam gdzie ma to sens - w sumie bardzo fajne podejście do części zastosowań, tak opakować, żeby SCRUM Masterzy robili swoje, skoordynować z resztą działań projektowych i spokojnie zając się wypełnianiem tabelek w Excelu, czyli tym, co PM lubi robić najbardziej :-)
(oczywiście jak już załatwi kwestie finansów, ryzyka, uzasadnienia biznesowego, dostępności zasobów, koordynacji z pracami innych dostawców i innych takich nudnawych kwestii).

Dobry PM nie będzie wchodził w kompetencje SCRUM Master-a - wszak nie taka jest jego rola.

A tak BTW P2 i PMBoK oraz tych kilka technik, o których wspomniałem to żadna abstrakcja a własnie samo życie :-)Paweł S. edytował(a) ten post dnia 13.10.09 o godzinie 22:55
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Nie twierdzę, że PMBoK i cała reszta nie ma w Scrumie żadnego zastosowania. Po prostu zdaję sobie sprawę z tego, że jak każda technologia Scrum ma swoje poziomy wdrożenia w organizacji i na razie starajmy się odpowiadać prosto na proste pytania, rozwiązywać problemy. A jak już zacznie to wszystko "żyć własnym życiem", to można uporządkować procesy i wkoczyć na następny level.

Co do dobrego PM-a, to jakby to powiedzieć... PM w tej chwili powinien być liderem a nie managerem i raczej PMem z wyboru, z poczucia, a nie drogą awansu przez zasiedzenie. I póki co, ciężko takich spotkać na projekcie.

konto usunięte

Temat: Wkręcam się:D

Paweł S.:
Właśnie piszę jak to działa w życiu codziennym :-)

Każdy ma inne życie codzienne.
Programiści będą twierdzili, że sukces projektu programistycznego zależy od programistów (ich kompetencji i im nieprzeszkadzania). Cała reszta będzie twierdziła, że sukces zależy od nich i tego, jak organizują programistom pracę. Ot, każdy chce podkreślić swoją niezbędność ;)
Dobry PM nie będzie wchodził w kompetencje SCRUM Master-a - wszak nie taka jest jego rola.

Znaczy można go wylać? ;)
Bo w tym momencie nie widzę potrzeby PMa, jeśli ktoś inny ma być Scrum Masterem?
EDIT: Disregard, doczytałem post Krystiana.Tomasz Stachewicz edytował(a) ten post dnia 14.10.09 o godzinie 09:54
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Jak idzie?
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Krystian K.:
Jak idzie?

Hej!

Powiem szczeze, ze wszystko idzie w dobrą stroną. Niestety nie jesteśmy w stanie narazie wdrożyć scrum zgodnie z całą teorią. Nic jednak nie jest stracone. Wiedza którą zasięgnołem rowniez dzieki duskusjom tutaj uwypuklila mi tak naprawde wszystkie mankamenty i niedociagniecia jakie sa w zespole. Podsumowujac, zapoznajac sie ze scrum spojzalem na aktualny stan sytuacji w zespole z zupelnie innej perspektywy.

Wdrażamy pewne zmiany i dyskutujemy. Staramy się usprawnić różne procesy podczas wytwarzania samego oprogramowania. Wszystko malymi kroczkami, ale od początku wspólnie razem z zespołem. Najważniejsze jest to, że zaczynamy coraz bardziej współpracować ze sobą oraz wspólnie zwracać uwagę jeden na drugiego przy tym nad czym pracujemy.

Pozdrawiam
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Myślę, że wprowadzenie iteracji i pair programming mogło by pomoc.
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Krystian K.:
Myślę, że wprowadzenie iteracji i pair programming mogło by pomoc.

Pair programing stosujemy w niektorych przypadkach, powiem ze sprawdza sie. Daje naprawde ciekawe rezultaty. Praca jest bardziej agresywna i daje ciekawe efekty a ile przyjemnosci.
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wkręcam się:D

Roman Piekarski:

Pair programing stosujemy w niektorych przypadkach, powiem ze sprawdza sie. Daje naprawde ciekawe rezultaty. Praca jest bardziej agresywna i daje ciekawe efekty a ile przyjemnosci.

A pair testing? Tester + Developer przechodzą przez aplikację, czy JUnity. Technika "show me" jest bardzo skuteczna, jeżeli chcecie być bardziej Agile.
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: Wkręcam się:D

Krystian K.:
Roman Piekarski:

Pair programing stosujemy w niektorych przypadkach, powiem ze sprawdza sie. Daje naprawde ciekawe rezultaty. Praca jest bardziej agresywna i daje ciekawe efekty a ile przyjemnosci.

A pair testing? Tester + Developer przechodzą przez aplikację, czy JUnity. Technika "show me" jest bardzo skuteczna, jeżeli chcecie być bardziej Agile.

Jestesmy w fazie wdrazania się w techniki unit testow. Pair testing tylko w momentach, gdy pewien problem stanowi o core aplikacji.

Następna dyskusja:

Czego architektura korporac...




Wyślij zaproszenie do