Descriviamo una situazione tipica\u2026 Quindi si fa il planning, le review e le retrospective, ma – chiss\u00e0 perch\u00e9 – c\u2019\u00e8 una certa ritrosia nel fare demo aperte a tutti. Non \u00e8 una questione di controllo (\u201cvediamo cosa avete fatto in tutto questo tempo!\u201d), di principio (\u201cdobbiamo farla perch\u00e9 in Scrum si fa\u201d) o di forma (\u201cfacciamo la demo cos\u00ec lo Scrum Master \u00e8 contento\u201d)\u2026 Durante la demo viene illustrato l\u2019incremento di prodotto realizzato nel corso dello sprint. La finalit\u00e0 della demo \u00e8 triplice: verificare cosa va bene, capire cosa eventualmente non va bene e capitalizzare idee.<\/strong> Mi \u00e8 capitato proprio di recente. Senza la demo questo problema non sarebbe emerso.
\nIl vostro team fa Scrum, comincia ad avere una discreta conoscenza della metodologia ed \u00e8 abbastanza rigoroso nell\u2019esecuzione delle cerimonie.<\/span><\/p>\n
\nE magari vi ritrovate al penultimo giorno dell\u2019iterazione con qualcuno che chiede: \u201cma dobbiamo proprio farla la demo?\u201d.
\nS\u00ec, assolutamente s\u00ec!
\nNon a caso la Sprint Review si chiama anche Sprint Demo…<\/p>\n
\nDal mio punto di vista \u00e8 proprio un tema di sostanza.
\nPerch\u00e9 una review con una vera e propria demo estesa a tutti i potenziali interessati \u00e8, rispetto ad altre cerimonie, la migliore occasione che il team ha per interagire realmente con gli stakeholder e con tutti coloro che hanno una visione parziale del progetto.<\/p>\n
\nLa finalit\u00e0 non \u00e8 dimostrare agli altri quanto \u00e8 stato bravo il team o esporlo al pubblico biasimo se non ha portato a termine tutto quello che era stato programmato.
\nOltre all’accettazione formale delle storie da parte del Produt Owner, ci confrontiamo con il resto dell\u2019azienda per ottenere dei feedback e far emergere aspettative che sino a quel momento non hanno avuto voce.<\/p>\n
\nNon accoglieremo necessariamente tutto quanto emerge dalla platea, ma avremo raccolto un piccolo patrimonio di osservazioni che potranno rivelarsi preziose nel seguito del progetto.
\nIn alcuni casi la demo consente di portare alla luce effetti collaterali che non avevamo preso in considerazione o di cui non avevamo valutato a pieno la portata.<\/p>\n
\nIl team porta a termine un\u2019iterazione e completa una user story con un elevato valore di business nell\u2019arco delle canoniche due settimane.
\nIl manangement \u00e8 interessato a rilasciare la funzionalit\u00e0 il prima possibile.
\nNel corso della demo emerge che gli sviluppatori hanno trovato una soluzione semplice ed efficace per l\u2019implementazione, ma questa scelta produce conseguenze inattese sulle altre properties.\u00a0Qualcosa si \u00e8 perso nella comunicazione tra il Product Owner ed il team. Nulla di grave. Pu\u00f2 succedere e c\u2019\u00e8 sempre un modo per porvi rimedio.
\n<\/span>Si decide di rimandare il rilascio di un\u2019iterazione, il tempo utile per realizzare un piccolo incremento di prodotto e garantire la massima flessibilit\u00e0 a tutti gli altri gruppi di sviluppo.<\/p>\n
\nAvremmo rischiato di scoprirne le conseguenze solo in produzione. Avere tutti gli interlocutori seduti al medesimo tavolo ci ha consentito di intercettare per tempo la criticit\u00e0 e trovare la risposta pi\u00f9 adeguata.<\/p>\n