Temat: Warto przeczytać!

http://www.waterfallmanifesto.org/

Najbardziej godne uwagi są zasady:
http://www.waterfallmanifesto.org/?principles

Doskonałe ;)

Temat: Warto przeczytać!

Tomasz Stachewicz:
http://www.waterfallmanifesto.org/?principles

"Pizzas and beers.." - kupili mnie ;)

Temat: Warto przeczytać!

Tomasz Stachewicz:
http://www.waterfallmanifesto.org/

Najbardziej godne uwagi są zasady:
http://www.waterfallmanifesto.org/?principles

Doskonałe ;)

nie powinni tego propagować bo jeszcze ktoś przeczyta i uwierzy :-)

Temat: Warto przeczytać!

Michał Słociński:

nie powinni tego propagować bo jeszcze ktoś przeczyta i uwierzy :-)

Historia by wtedy zatoczyła niezłe koło i się na nim przetoczyła po własnej ironii: Waterfall jako model został po raz pierwszy przedstawiony i opisany jako proces tworzenia produktu inżynieryjnego, który nie pasuje do realiów tworzenia software'u.

Temat: Warto przeczytać!

.Ten post został edytowany przez Autora dnia 04.08.16 o godzinie 20:46

Temat: Warto przeczytać!

Myślę, że Waterfall żyje i ma się dobrze :/ (w sensie teoretycznym, czyli wyobrażeniu zarządu)

Patrz jeden z bardziej "poważanych" certyfikatów, czyli PMI. Jeśli też prześledzi się oferty dla managerów, to często pojawia się "znajomość metodologii(sic!) lekkich" - ale zaraz po informacjach, że PMBOK to podstawa :|

Temat: Warto przeczytać!

Filip Balicki:
Myślę, że Waterfall żyje i ma się dobrze :/ (w sensie teoretycznym, czyli wyobrażeniu zarządu)

Przede wszystkim, nikt nie mówi, że waterfall nie ma sensu i jest z natury zły. Dla projektów o dużym ryzyku (wojsko, medycyna, finanse) czy o jasnych, oczywistych i niezmiennych wynikach (np. migracja an nową platformę z releasem dopiero po pełnej migracji) czasem lepiej wykorzystać waterfall.

Inną sprawą jest uprawianie Scrum BUT i Agile na zasadzie taniego tuningu samochodów (zaczynamy od naklejek).
Często w korporacjach pomija się "buy in" ze strony higher management i działu finansów. Potem się słyszy: od jutra jesteśmy Agile. A po chwili: kiedy dostanę pełny business case dla nowego projektu z jasnymi milestones pełną dokumentacją architektury?

Temat: Warto przeczytać!

Filip Balicki:
Myślę, że Waterfall żyje i ma się dobrze :/ (w sensie teoretycznym, czyli wyobrażeniu zarządu)

Patrz jeden z bardziej "poważanych" certyfikatów, czyli PMI. Jeśli też prześledzi się oferty dla managerów, to często pojawia się "znajomość metodologii(sic!) lekkich" - ale zaraz po informacjach, że PMBOK to podstawa :|

Filipie,
Możemy sobie chwilę poteoretyzować, bo wiadomo, że umiemy :)

Chyba błędnym założeniem jest: pmbok == waterfall. Chłopaki z PMI trochę dorośli i wprowadzili w wersji czwartej iteracje ;) Może każda z nich stać się oczywiście takim małym wodospadem, ale nikt nigdy nie powiedział, że wszystkie 42 procesy muszą być wykorzystywane. Nikt jeszcze nikomu nie zabronił skalować PMBOKa w dół.. upraszczać jedne procesy i zapominać o innych.

Wydaje się, że byłoby sporym nadużyciem, gdyby ktoś zatrudniając na stanowisko kierownika projektów, wymagał tylko bardzo dobrej znajomości Scruma. O ile ten wspomniany framework prawdopodobnie sprawdzi się bardzo dobrze w wielu projektach IT, to ciągle pozostaje frameworkiem, i to w dodatku takim, który raczej opisuje proces wytwarzania oprogramowania, niż proces zarządzania projektem. A jednak, wydaje się, że nie wolno zapominać o kilku ważnych kwestiach o których Scrum milczy (lub mówi na tyle mało, że aż niektórzy tego nie zauważają). I tak, warto pochylić się np. nad zarządzaniem ryzykiem, zarządzaniem kontraktami, czy choćby nad jakością. I oczywiście zdaje sobie sprawę, że szczególnie jakość właśnie wpisana jest nieomalże domyślnie w proces Scrumowy, a i ryzyko niweluje się w sposób może i drastyczny, pokazując funkcjonalności klientowi raz na dwa tygodnie (oraz podpisując kontrakt T&M). To jednak PMBOK wspomina jak ta jakość powinna być mierzona, i co to jest rejestr ryzyka. I wiem, że jakość powinna być mierzona satysfakcją klienta, jednak dostępność klienta lub nawet jego fizyczne istnienie nie zawsze jest zapewnione, a przecież proces wytwórczy trzeba ciągle doskonalić.

Gdzieś tam pojawia się potrzeba rozróżnienia w projekcie rol PM'a i SM'a. Może obydwie role spełniać jedna osoba.. ale nie wolno zapominać, że to ciągle są dwie różne role.

No i sorry za off topic. Tak przyjemnie się temat zaczął ;)

Temat: Warto przeczytać!

Nie no - co to za zabawa? I Krystian i Michał słusznie się wypowiedzieli i mam problem by nawet o coś zahaczyć polemikę ;)

Trochę uprościłem założenie PMBOK == waterfall, ale nadal uważam, że jednak blizej chłopakom do metodyk ciężkich, chociaż miło, że jakoś do nich dociera to, że da się inaczej ;)

Jeszcze słowo do Krystiana - ostatnio miałem okazję spotkać się z wojownikami Scrum (jeśli ktoś się chociaż zająknie, że istnieją obszary gdzie metodyki klasyczne mogą się sprawdzić - walczą) - byłbyś ich wrogiem numer jeden ;) Natomiast ja osobiście zgadzam się z Tobą w 100%.

Mamy worek z narzędziami i wybieramy co akurat teraz jest przydatne i to jest ok :)
Ja na ten przykład ostatnio bardziej "przytulam się" do Kanbana - i też już udało mi się usłyszeć, że to taki maskowany waterfall i "ZŁOOO"

Temat: Warto przeczytać!

Filip Balicki:
Jeszcze słowo do Krystiana - ostatnio miałem okazję spotkać się z wojownikami Scrum (jeśli ktoś się chociaż zająknie, że istnieją obszary gdzie metodyki klasyczne mogą się sprawdzić - walczą) - byłbyś ich wrogiem numer jeden ;) Natomiast ja osobiście zgadzam się z Tobą w 100%.

Mamy worek z narzędziami i wybieramy co akurat teraz jest przydatne i to jest ok :)
Ja na ten przykład ostatnio bardziej "przytulam się" do Kanbana - i też już udało mi się usłyszeć, że to taki maskowany waterfall i "ZŁOOO"

A Ci wojownicy podają jakieś argumenty czy każdy ma korzystać ze Scrum "bo tak!"? :) Scrum nie jest srebrną kulą i ma być zabawą. Nie można się dobrze bawić na siłę.
„Powiedz mi, a zapomnę, pokaż mi a zapamiętam. Zaangażuj mnie a zrozumiem”
Konfucjusz

Ostatnio słyszałem o bardzo ładnie maskowanym Waterfallu. Chłopaki robią juz 3ci Sprint Zero, żeby dostarczyć dokumentację do business case. Mnie uczyli, że 0 w numeracji występuje tylko raz. I każdy Sprint musi dostarczyć potentially shippable product.

Temat: Warto przeczytać!

Michał Porzożyński:
to ciągle pozostaje frameworkiem, i to w dodatku takim, który raczej opisuje proces wytwarzania oprogramowania, niż proces zarządzania projektem.

O tym bardzo często zapominają nowi fani. Bardzo ładne stwierdzenie.

I wiem, że jakość powinna być mierzona satysfakcją klienta, jednak dostępność klienta lub nawet jego fizyczne istnienie nie zawsze jest zapewnione, a przecież proces wytwórczy trzeba ciągle doskonalić.

Nie tylko satysfakcją, pare standardów można dorzucić. W przypadku fizycznego braku klienta, czy niskiej dostępnosci mamy takie narzędzia jak Persony i User Proxy.

Gdzieś tam pojawia się potrzeba rozróżnienia w projekcie rol PM'a i SM'a. Może obydwie role spełniać jedna osoba.. ale nie wolno zapominać, że to ciągle są dwie różne role.

Oj, to jest chyba najgorsze, co można sobie zrobić startując ze Scrumem. PM nadal decyduje ile co zajmie i kto ma jakiego taska zrobić. Nie mówię, że ta konfiguracja nie ma praw działać, ale już kilka razy widziałem i słyszałem o tym samym błędzie.

- "Co robicie na Daily Scrum?"
- "No wiesz... ScrumMaster przydziela zadania ..."
- "Yyyyy... Wait a minute. A kto jest Waszym SM?"
- "Nasz PM"
- "Ok, to wyjaśnia" :)

Temat: Warto przeczytać!

Krystian K.:

Ostatnio słyszałem o bardzo ładnie maskowanym Waterfallu. Chłopaki robią juz 3ci Sprint Zero, żeby dostarczyć dokumentację do business case. Mnie uczyli, że 0 w numeracji występuje tylko raz. I każdy Sprint musi dostarczyć potentially shippable product.

Generalnie tak - ale w życiu różnie bywa. Nie chcę oczywiście nikogo usprawiedliwiać, ale wiem z własnego doświadczenia że niekiedy zgranie wszystkiego zgodnie z iteracjami jest trudne.

Przykład, a w zasadzie dwa przykłady z mojego własnego doświadczenia:

Zespół zajmujący się globalizacją oprogramowania jest zespołem globalnym i opiekuje się 20 produktami. Na dodatek siedzi 4.000 km z dala od nas. Dystans w szczebelkach managersko-organizacyjnych naszego teamu od ich teamu - podobny :-) Produkt którym ja się opiekuję jest pierwszym który przechodzi waterfall -> scrum. Pozostałe 19 leci dalej po staremu - wiadomo, siła inercji w korporacji, nie da się wszystkiego przestawic w tym samym momencie.

Różne produkty mają różne cykle wydawania nowych wersji (pół roczne, roczne, dwuletnie), do tego wchodzi konieczność zgrania wydawania nowych wersji z procesem mainteinance starszych wesji.

To powoduje że daty GA są dość sztywno ustalone i zsynchronizowane z wieloma innymi trybikami w całym procesie.

No i teraz okazuje się że team zajmujący się lokalizacją i globalizacją ma czas dla naszego produktu dokładnie od 1 maja do 20 majau. Przez pozostałe 11,5 miesiąca zajmują się innymi produktami. Nie ma mowy o tym żeby pracowali z nami po trochu w każdej iteracji - zbyt duża zmiana ich trybu pracy i zaburzenie pracy nad pozostałymi 19 produktami.

Czyli nie jest możliwe faktyczne zakończenie każdej iteracji z "potentially shippable" product.

Dokładnie ten sam problem z współpracującym teamem który zajmuje się testowaniem wydajności oprogramowania.

Takie realia - niestety migracja procesów szczególnie w większych firmach jest trudna i często długotrwała.

Dlatego nie dziwią mnie ogłoszenia gdzie stawiane są wymagania dot. znajomości klasycznych metodyk PMowych jak i metodyk zwinnych. Zwyczajnie niekiedy osoba odpowiedzialna za projekt musi być w stanie odnaleźć się w różnych realiach i spojrzeć na swój projekt w kontekście wielu innych wydarzeń mających miejsce w organizacji, ocenić ryzyko, zarządzać zależnościami i kontraktami, itp itd.

Niestety świat rzeczywisty zazwyczaj nie jest tak prosty jak opisują w książkach :-)

Temat: Warto przeczytać!

Krystian K.:
- "Co robicie na Daily Scrum?"
- "No wiesz... ScrumMaster przydziela zadania ..."
- "Yyyyy... Wait a minute. A kto jest Waszym SM?"
- "Nasz PM"
- "Ok, to wyjaśnia" :)

Oraz:
— Co robicie na daily scrum?
— Nie robimy daily scrum, bo wymagania w projekcie nie zmieniają się tak często, w związku z tym PM/SM nie widzi potrzeby się spotykać z zespołem.

Temat: Warto przeczytać!

Bogdan B.:
Oraz:
— Co robicie na daily scrum?
— Nie robimy daily scrum, bo wymagania w projekcie nie zmieniają się tak często, w związku z tym PM/SM nie widzi potrzeby się spotykać z zespołem.

PO i SM nie muszą być obecni na Daily Scrum, jeżeli nie są świniami. To jest meeting dla Zespołu. Także kiepska wymówka.
ScrumMaster powinien upewnić się, że spotkanie się odbywa.

Od częstości zmian wymagań zależy długość Sprintu. Przy krótszych Sprintach jest łatwiej stawić czoło szybko zmieniającym się wymaganiom.

Temat: Warto przeczytać!

Michał Słociński:
No i teraz okazuje się że team zajmujący się lokalizacją i globalizacją ma czas dla naszego produktu dokładnie od 1 maja do 20 majau. Przez pozostałe 11,5 miesiąca zajmują się innymi produktami. Nie ma mowy o tym żeby pracowali z nami po trochu w każdej iteracji - zbyt duża zmiana ich trybu pracy i zaburzenie pracy nad pozostałymi 19 produktami.

Czyli nie jest możliwe faktyczne zakończenie każdej iteracji z "potentially shippable" product.

Sytuacja jest trudna, jednakże nie beznadziejna. Czasem w moim projekcie też mamy podobną sytuację.
Proponuje Release Planning Meeting.
Można zaplanować dostarczanie funkcjonalności w tylko jednym języku do 1go Maja pamiętając, że architektura musi być na tyle elastyczna, żeby obsłużyć więcej języków (potentially shippable product) i od 1 Maja do 20 Maja zająć się Story pod tytułem lokalizacja i globalizacja produktu, które w tym momencie dostaje od Product Ownera priority 1. Jest to nadal Agile, nie jest to 100% Scrum bo zmieniamy Team Velocity w danym momencie.
Czy od tego drugiego Teamu potrzebujecie zaangażowania czy tylko dostarczenia czegoś?

Dokładnie ten sam problem z współpracującym teamem który zajmuje się testowaniem wydajności oprogramowania.

Wydajność można wstawić w Release Sprint, albo przekazać im product z gałęzi SCM i zaplanować mniejszą ilość business value w bieżącym Sprincie + margines na bug fix przychodzący od nich i merge zmian do HEAD.

Takie realia - niestety migracja procesów szczególnie w większych firmach jest trudna i często długotrwała.

Dlatego nie dziwią mnie ogłoszenia gdzie stawiane są wymagania dot. znajomości klasycznych metodyk PMowych jak i metodyk zwinnych. Zwyczajnie niekiedy osoba odpowiedzialna za projekt musi być w stanie odnaleźć się w różnych realiach i spojrzeć na swój projekt w kontekście wielu innych wydarzeń mających miejsce w organizacji, ocenić ryzyko, zarządzać zależnościami i kontraktami, itp itd.

To tak jak z proszkiem do prania. Jak jest dobry do wszystkiego to jest dobry do niczego.
Takie oferty bardziej doświadczonym ludziom mówią Uwaga: Pole Minowe! :)

Niestety świat rzeczywisty zazwyczaj nie jest tak prosty jak opisują w książkach :-)

Nie szukajmy winnych i wymówek. Każdy wie jaki jest świat, życie itd. :)
Jeżeli jesteś wyposażony w narzędzia i wiedzę, jesteś w stanie odpowiednio zareagować.
Mechanik bierze 50 centów za śrubkę a 99,50 za to, że wie gdzie ją wkręcić.

Książki mają ograniczoną pojemność, więc opisuje się najprostsze przypadki i najczęstsze problemy. Książka ma przekazać sposób myślenia i zaszczepić idee. To nie są diagramy usuwania usterek. Coś takiego można stworzyć dla niezmiennego produktu jak np. Volvo S60 MY2005. Specyfiki projektu i dynamiki Teamu nie da się w ten sposób uchwycić. Za dużo zmiennych.
Scrum też jest tylko frameworkiem i nie podaje gotowych rozwiązań.Krystian K. edytował(a) ten post dnia 15.04.10 o godzinie 21:17

Temat: Warto przeczytać!

Krystian K.:

Michał Słociński:
No i teraz okazuje się że team zajmujący się lokalizacją i globalizacją ma czas dla naszego produktu dokładnie od 1 maja do 20 majau. Przez pozostałe 11,5 miesiąca zajmują się innymi produktami. Nie ma mowy o tym żeby pracowali z nami po trochu w każdej iteracji - zbyt duża zmiana ich trybu pracy i zaburzenie pracy nad pozostałymi 19 produktami.

Czyli nie jest możliwe faktyczne zakończenie każdej iteracji z "potentially shippable" product.

Sytuacja jest trudna, jednakże nie beznadziejna. Czasem w moim projekcie też mamy podobną sytuację.
Proponuje Release Planning Meeting.
Można zaplanować dostarczanie funkcjonalności w tylko jednym języku do 1go Maja pamiętając, że architektura musi być na tyle elastyczna, żeby obsłużyć więcej języków (potentially shippable product) i od 1 Maja do 20 Maja zająć się Story pod tytułem lokalizacja i globalizacja produktu, które w tym momencie dostaje od Product Ownera priority 1. Jest to nadal Agile, nie jest to 100% Scrum bo zmieniamy Team Velocity w danym momencie.
Czy od tego drugiego Teamu potrzebujecie zaangażowania czy tylko dostarczenia czegoś?

Oczywiście, tak właśnie robimy - to chyba dość naturalne podejście do rzeczy

na szczęście takie podejście nie powoduje zbyt wielkiego ryzyka ... zazwyczaj ... większe problemy mogą wystąpić w zasadzie głównie przy organizacji UI gdy musi być ono czytane "od prawej do lewej", ale przy tym akurat kilka prostych zasad pozwala uniknąć problemów

Dokładnie ten sam problem z współpracującym teamem który zajmuje się testowaniem wydajności oprogramowania.

Wydajność można wstawić w Release Sprint, albo przekazać im product z gałęzi SCM i zaplanować mniejszą ilość business value w bieżącym Sprincie + margines na bug fix przychodzący od nich i merge zmian do HEAD.

No i właśnie z takim "release sprint" jest największy problem - zauważ że niekiedy poprawki związane z wydajnoscią / stabilnością wymagają więcej pracy, powodując tym samym konieczność zastosowania większych zmian w user stories które zostały zaimplementowane X iteracji temu.

Niestety w takiej sytuacji brak automatyzacji testów funkcjonalnych jest w stanie "położyć" projekt. Dodatkowo staramy profilować wydajność aplikacji we własnym zakresie bez czekania na ostateczne testy.

Takie realia - niestety migracja procesów szczególnie w większych firmach jest trudna i często długotrwała.

Dlatego nie dziwią mnie ogłoszenia gdzie stawiane są wymagania dot. znajomości klasycznych metodyk PMowych jak i metodyk zwinnych. Zwyczajnie niekiedy osoba odpowiedzialna za projekt musi być w stanie odnaleźć się w różnych realiach i spojrzeć na swój projekt w kontekście wielu innych wydarzeń mających miejsce w organizacji, ocenić ryzyko, zarządzać zależnościami i kontraktami, itp itd.

To tak jak z proszkiem do prania. Jak jest dobry do wszystkiego to jest dobry do niczego.
Takie oferty bardziej doświadczonym ludziom mówią Uwaga: Pole Minowe! :)

ha, a ja bym raczej powiedział że taka oferta mówi bardziej doświadczonym ludziom o tym że organizacja:
a) przymierza się do przejścia na agile
b) jest w fazie przejściowej waterfall -> agile
c) zaadaptowała podejście hybrydowe, które wg. mnie może się świetnie sprawdzać przy pewnych typach projektów

implementacja "czystego scrum'a" jest generalnie tym trudniejsza im większa jest organizacja oraz im dłużej tkwiła w procesach waterfallowych

często wszyscy mają dobre chęci, ale poprostu realia powodują że migracja pewnych procesów:
a) musi trochę potrwać i nie da się pstryknąć palcami i wszystkiego zmienić ot tak
b) jest z jakichś względów nieopłacalna, dlatego niektóre procesy działają dalej "po staremu"

to wszystko powoduje że projekt prowadzony jest "hybrydowo", a managerowie uwielbiają wtedy używać stwierdzenia "best of both worlds" jakkolwiek by ono było prawdziwe ;-)

w takich przypadkach doświadczenie w klasycznych procesach oraz metodykach lekkich jest zdecydowanie zalecane

osobom zainteresowanym tematyką migracji procesów na agile wewn. organizacji bądź właśnie stojącym przed takim wyzwaniem gorąco polecam książkę M. Cohna "Succeeding with Agile: Software Development Using Scrum": http://www.amazon.co.uk/Succeeding-Agile-Development-A...

Temat: Warto przeczytać!

Michał Słociński:

Niestety w takiej sytuacji brak automatyzacji testów funkcjonalnych jest w stanie "położyć" projekt. Dodatkowo staramy profilować wydajność aplikacji we własnym zakresie bez czekania na ostateczne testy.

To jest jedna z podstawowych zasad Agile, ile się da powinno być zautomatyzowane. Testy regresyjne powinny iść z automatu w Continuous Integration.

c) zaadaptowała podejście hybrydowe, które wg. mnie może się świetnie sprawdzać przy pewnych typach projektów

>

Hybrydy można robić w metodach Agile np. Scrum i Kanban. Nie można robić hybrydy Agile z Waterfallem, bo ludzie z obu światów będą pokrzywdzeni i będą czuli, że nie ma kontroli nad systemem. Jedni chcą wymagań spisanych w formie "System shall ..." i z góry określonych milestone. Druga grupa chce User Stories i zacząć kodować.

implementacja "czystego scrum'a" jest generalnie tym trudniejsza im większa jest organizacja oraz im dłużej tkwiła w procesach waterfallowych

Ja bym powiedział, że trudność wzrasta odwrotnie proporcjonalnie do zaangażowania menadżerów wyższego szczebla i zaangażowania Teamu. Każdy w organizacji musi zrozumieć dlaczego chcemy przejść na Agile i co się z tym wiąże.
Scrum jest w brew pozorem trudny i sprawia, że problemy organizacje stają się wyraźne i zaczynają mocno dokuczać. I w tym momencie pojawiają się 2 wyjścia: zmienić organizację, albo założyć knebel na Scrum. W drugim przypadku tworzy sie dziwna hybryda Agile-Waterfall, lub jak to Ken Schwaber nazwał Scrum BUT. "We are using Scrum BUT ..."

często wszyscy mają dobre chęci, ale poprostu realia powodują

Nie ma czegoś takiego jak realia i "się nie da". Nie ma też "w firmie X tak już jest i się tego nie zmieni". Firmy, projekty i zespoły tworzą ludzie. Nic nie jest wykute w kamieniu. Zaangażujesz ludzi, to Ci pomogą, muszą tylko zrozumieć dlaczego mają to zrobić i widzieć, że ich koledzy też pomagają.

Patrząc rok wstecz w moim zespole postęp jaki zrobiliśmy łamie kolana. Ale samo to nie przyszło. Dużo czasu poświęciliśmy na tłumaczenie i pokazywanie opcji "biznesowi".

że migracja pewnych procesów:
a) musi trochę potrwać i nie da się pstryknąć palcami i wszystkiego zmienić ot tak
b) jest z jakichś względów nieopłacalna, dlatego niektóre procesy działają dalej "po staremu"

to wszystko powoduje że projekt prowadzony jest "hybrydowo", a

managerowie uwielbiają wtedy używać stwierdzenia "best of both worlds" jakkolwiek by ono było prawdziwe ;-)

w takich przypadkach doświadczenie w klasycznych procesach oraz metodykach lekkich jest zdecydowanie zalecane

Leki antystresowe i antydepresyjne też ;)
- "Słuchaj Stefan, dla projektu PS223 piszemy wymagania, czy User Stories, bo to hybryda i sam nie wiem?"
- "Dla PS223 używamy klasycznych wymagań. DR233 ma User Stories, a Twe2323 używa klasycznych w parzyste dni miesiąca, a w nie parzyste User Stories".

osobom zainteresowanym tematyką migracji procesów na agile wewn. organizacji bądź właśnie stojącym przed takim wyzwaniem gorąco polecam książkę M. Cohna "Succeeding with Agile: Software Development Using Scrum": http://www.amazon.co.uk/Succeeding-Agile-Development-A...

Dokładam jeszcze materiały ze strony Mike'a:
http://www.mountaingoatsoftware.com/topics/new-to-agil...

http://www.mountaingoatsoftware.com/presentations

Temat: Warto przeczytać!

Krystian K.:

Oraz:
— Co robicie na daily scrum?
— Nie robimy daily scrum, bo wymagania w projekcie nie zmieniają się tak często, w związku z tym PM/SM nie widzi potrzeby się spotykać z zespołem.

PO i SM nie muszą być obecni na Daily Scrum, jeżeli nie są świniami. To jest meeting dla Zespołu. Także kiepska wymówka.

No ja to wiem :) To przykład wypaczenia, do jakiego prowadzi brak wyedukowanego SM i błędne postrzeganie roli SM przez zespół (kierownik zespołu/projektu).

Temat: Warto przeczytać!

Krystian K.:

[cut]

PO i SM nie muszą być obecni na Daily Scrum, jeżeli nie są świniami. To jest meeting dla Zespołu. Także kiepska wymówka.
ScrumMaster powinien upewnić się, że spotkanie się odbywa.

[cut]

Zdecydoiwanie ani PO, ani SM nie muszą być obecni na DS.
Niemniej są "świniami", bo obaj/oboje/obie odpowiadają przecież własnym "bekonem" za to, co się dzieje ;)

Temat: Warto przeczytać!

Przemek T.:

Krystian K.:

[cut]

PO i SM nie muszą być obecni na Daily Scrum, jeżeli nie są świniami. To jest meeting dla Zespołu. Także kiepska wymówka.
ScrumMaster powinien upewnić się, że spotkanie się odbywa.

[cut]

Zdecydoiwanie ani PO, ani SM nie muszą być obecni na DS.
Niemniej są "świniami", bo obaj/oboje/obie odpowiadają przecież własnym "bekonem" za to, co się dzieje ;)

To zależy tylko od tego czy dostarczają coś. Po tym się określa czy to są świnie. Komunikacja z PO może się odbywać poza Daily Scrum. Na Daily Scrum Team ma sprawdzić postep prac i zareagować w przypadku problemów.

To jest jedno z pytań na Scrum Open assesment:
http://www.scrum.org/assessmentdiscussion/post/925312