Sprint Review to nie demo!

utwor­zone przez | Lut 11, 2018 | Blog, Scrum­pe­dia | 0 komen­tarzy

It’s the feed­back cycle that tends to real­ly make devel­op­ment go fast” — Jeff Suther­land

Sprint Review czy demo? A co za różni­ca? W wielu orga­ni­za­c­jach spo­tykam się, z tym, że Sprint Review nazy­wany jest demo. Częs­to wyni­ka to, z tego, że ludzie nie widzą różni­cy pomiędzy tymi dwoma określe­ni­a­mi. Czy na pewno nie widzisz różni­cy pomiędzy Przegląd Sprintu a demo?

Nawet, kiedy Zespoły Scru­mowe mają w ostat­ni dzień Sprintu zaplanowanie Sprint Review, to i tak zapy­tani o to, co się dzieje pod­czas tego spotka­nia mówią, że trze­ba zro­bić demo.

Kole­jne pyta­nia pozosta­ją już bez odpowiedzi. Po co to demo? Dla kogo? Moż­na się dowiedzieć, że Sprint Review to ten moment kiedy Prod­uct Own­er oglą­da co zro­bił Zespół Devel­op­er­s­ki i odbiera Sprint. To bard­zo ciekawy pomysł. A co jeśli odrzu­ci Sprint?
Czy Sprint może się nie udać? Zostawmy odpowiedź na to pytanie na kole­jnego pos­ta.

Moż­na też spotkać się z tym, że Przegląd Sprintu to takie miłe spotkanie, na którym wszyscy klaszczą a na koniec wjeżdża piz­za, a przy­na­jm­niej dają ciast­ka :-)

Jeśli skupimy się tylko na pokaza­niu demo, czyli tego co nam poszło dobrze w Sprin­cie, czy to wywoła dyskus­je, wąt­pli­woś­ci? Czy nastąpi tutaj pęt­la sprawdź i dos­to­suj (inspect & adapt)? No i najważniejsze pytanie czy cel Sprint Review zostanie osiąg­nię­ty?

Mam nadzieję, że moje wyjaśnie­nie poniżej rozwieje wszelkie wąt­pli­woś­ci i poz­woli zrozu­mieć, że słowa mają znacze­nie.

Po co w Scrum mamy Sprint Review?

Przyjrzyjmy się zagad­nie­niu od samego początku. Jaki cel do osiąg­nię­cia kry­je się za Sprint Review? Zajrzyjmy do Scrum Guide.

Przegląd Sprintu to spotkanie orga­ni­zowane na zakończe­nie Sprintu w celu przeprowadzenia inspekcji Przy­ros­tu i, jeśli zajdzie taka potrze­ba, dos­tosowa­nia Back­logu Pro­duk­tu. Pod­czas Przeglą­du Sprintu Zespół Scru­mowy i intere­sar­iusze współpracu­ją w zakre­sie tego, co zostało ukońc­zone w Sprin­cie. Na tej pod­staw­ie oraz na pod­staw­ie zmi­an wprowad­zonych do Back­logu Pro­duk­tu w trak­cie Sprintu, uczest­ni­cy spotka­nia wspól­nie rozważa­ją, co mogło­by być wyko­nane w następ­nej kole­jnoś­ci, aby zwięk­szyć dostar­czaną wartość.”

Zobacz co o Sprint Review mówi Jeff Suther­land, współtwór­ca Scrum.

Przez cały Sprint chronil­iśmy Zespół Devel­op­er­s­ki przed wpły­wa­mi z zewnątrz i zmi­ana­mi zakre­su Sprintu. Prod­uct Own­er był jedynym stykiem ze światem zewnętrznym. Sprint Review to jest ten moment, kiedy osobom spoza Zespołu Scrum mówimy, chodź i zobacz co zro­bil­iśmy. Oczy­wiś­cie kiedy pokazu­je­my kole­jny Przy­rost Pro­duk­tu zada­je­my pytanie “I co o tym sądzisz?”. Prze­cież, tym ma się różnić Agile Soft­ware Devel­op­ment od water­fall, że dostar­cza­my mniejsze funkcjon­al­noś­ci i częs­to pytamy o feed­back.

Intere­sar­iusze powin­ni powiedzieć nam jak odbier­a­ją kole­jną wer­sję, którą zbu­dował Zespół Devel­op­er­s­ki, przedysku­tować co jest potrzeb­ne w kole­jnych Sprint­ach. Intere­sar­iusze częs­to przynoszą również infor­ma­c­je, które mogą wpłynąć na ksz­tałt Pro­duk­tu i pracę Zespołu. Może­my tutaj dowiedzieć się rzeczy, które bezpośred­nio wpłyną na wygląd Prod­uct Back­log. Czy to Prod­uct Own­er zmieni kole­jność na Prod­uct Back­log, czy edy­tu­je­my Prod­uct Back­log Item. Dos­tosowanie następu­je właśnie ter­az. Sprawdza­my Przy­rost Pro­duk­tu i dos­tosowu­je­my Prod­uct Back­log — Inspect & Adapt.

Co się dzieje podczas Sprint Review?

Pier­wszym krok­iem jest przed­staw­ie­nie przez Prod­uct Own­era jaki był cel Sprintu i co fak­ty­cznie udało się osiągnąć a czego nie.
Zespół dewelop­er­s­ki omaw­ia jak prze­b­ie­gała pra­ca w Sprin­cie, jakie prob­le­my napotkał pod­czas Sprintu i jak zostały rozwiązane. Jeśli nadal mamy nierozwiązane imped­i­men­ty, to dobrze, żeby Intere­sar­iusze byli tego świado­mi.
Sama demon­strac­ja, bez wnikli­wej dyskusji nie daje żad­nej wartoś­ci i może dawać fałszy­wy obraz, ponieważ sku­pi­amy się tylko na tej częś­ci pra­cy, która się powiodła a nie na Celu, który fak­ty­cznie był do osiąg­nię­cia w Sprin­cie.

Dopiero po tych krokach następu­je część, w której Zespół Dewelop­er­s­ki pokazu­je demo – czyli dzi­ała­ją­cy Przy­rost Pro­duk­tu, który jest ukońc­zony. To czy prezen­tować także nieukońc­zone funkcjon­al­noś­ci, to inna dyskus­ja. Demon­strac­ja pro­duk­tu to tylko pretekst do wywoła­nia dyskusji na tem­at tego, co właśnie zbu­dowal­iśmy, nowych pomysłach i ewen­tu­al­nych zmi­anach, które chcielibyśmy wprowadz­ić w przyszłoś­ci. Na tej pod­staw­ie Zespół Scrum razem z intere­sar­iusza­mi omaw­ia co budować w dal­szej kole­jnoś­ci i jak. Dzię­ki czemu Przegląd Sprintu dostar­cza wartoś­ciowego wkładu na Planowanie Sprintu.

Pod­czas Przeglą­du Sprintu powin­na paść też jas­na odpowiedź na pytanie “Jak nam idzie?”. Czyli Prod­uct Own­er powinien pokazać aktu­al­ną roadmapę, plany wydań, pokazać jak ten Sprint wpłynął na datę lub zakres kole­jnego wyda­nia. Jeśli Prod­uct Own­er pod­jął decyzję o wdroże­niu na pro­dukcję, to ter­az jest właś­ci­wy moment, żeby poin­for­mować Intere­sar­iuszy kiedy mogą spodziewać się nowej wer­sji.

Podsumowanie

Pod­sumowu­jąc, najważniejszym ele­mentem Sprint Review jest dogłęb­na dyskus­ja i współpra­ca pomiędzy Scrum Team a Intere­sar­iusza­mi.

Demo Przy­ros­tu jest istotne w kon­tekś­cie wywoła­nia dyskusji, ale jest to tylko jeden z kroków Sprint Review i sam w sobie nie przynosi wartoś­ci. Tak więc jeśli nazy­wasz Sprint Review demo, sugeru­ję przes­tać.

Fun­da­men­tal­nym celem Sprint Review jest sprawdze­nie i dos­tosowanie Back­logu Pro­duk­tu poprzez zebranie feed­backu i infor­ma­cji w dyskusji z intere­sar­iusza­mi.