02.09.2010

Jak na demo?

Demonstrace zákazníkovi je jednou z klíčových praktik iterativně inkrementálních přístupů. Cílem je získat zpětnou vazbu a postupně budovat důvěru se zákazníkem, že opravdu doručujeme potřebné rysy aplikace. Tento post shrnuje několik tipů, jak na efektivní demonstraci zákazníkovi.

Demonstrace zákazníkovi (dále jen demo) je součást procesu hodnocení sprintu/ iterace/projektu (viz například naše šablona). Na konci každé iterace/projektu bychom měli provádět několik aktivit:

  • srovnání aktuálního a očekávaného (plánovaného) výstupu iterace,
  • analýza metrik a trendů,
  • analýza rizik a kontrola akcí, které jsme provedli za účelem snížení rizik,
  • sběr/revize změn (interní i externí),
  • revize odhadů zbývajících položek/scénářů k dokončení,
  • revize plánů (projektový, iterační, program) a způsobu práce,
  • sběr ponaučení (demo, retrospektiva, denní meetingy, způsob práce).

Demo je jednou z těchto aktivit. Víme, že každá iterace by měla produkovat hmatatelný výstup ve formě spustitelné a demonstrovatelné části aplikace, právě demo je kontrolním bodem, kde se my i zákazník učíme, diskutujeme a dostáváme zpětnou vazbu. Stručně řečeno se jedná o předvedení implementované a otestované funkčnosti, která byla cílem daného sprintu/iterace. Cíle dema jsou tedy následující:

  • získat zpětnou vazba – korigovat směr vývoje, upřesnění našich představ i představ zákazníka, vyjasnění si potřeb a pojmů,
  • budování důvěry – něco doručujeme, nejedná se o „tajný“ vývoj, kdy se zákazníkem moc nekomunikujeme a na konci doručíme něco, co zákazník nechtěl.

Tipy pro demo

  1. Demo by mělo být řízeno scénáři, které jsme implementovali, resp. testovacími scénáři – demonstrace probíhá podle nich (aby měl meeting formu a cíl) a je řízena vývojovým týmem.
  2. Mělo by být krátké (ideálně do 30-ti minut) – jelikož se ho účastní koncoví byznys uživatelé, ale také sponzoři či vlastníci projektu a dále také z důvodu zachování koncentrace.
  3. Pokud v rámci iterace implementujeme vícero různých scénářů a je třeba více různých uživatelů nebo by demonstrace všech scénářů trvala dlouho, je vhodné provést v průběhu iterace více demonstrací, jakmile je scénář implementován a otestován.
  4. Tým je odpovědný za přípravu dema a prostředí (připojení, aplikace zprovozněna na testovacím/demonstračním prostředí, připravené scénáře, …) a za jeho prezentaci. Pokud prezentace týmem podle scénářů nestačí, pak je možné předat kontrolu zákazníkovi, resp. koncovým uživatelům.
  5. Před vlastní demonstrací projeďte všechny zamýšlené scénáře, abyste si ověřili, že všechny fungují a při kompletaci, nasazení či opravách nebyla zanesena chyba.
  6. V pozvánce na demonstraci a při vlastním zahájení shrňte: Co bude prezentováno? Jaký je přínos pro zákazníka (z pohledu byznysu)? Jaké funkcionality budete prezentovat (v názvech scénářů, resp. testovacích scénářů).
  7. Zapisujte komentáře zákazníka jako součást hodnocení iterace (opět viz například naše šablona).
  8. Nahrejte si demo pro pozdější rekapitulaci – nemusíte pochytit vše (zvlášť v případě cizí řeči) nebo naopak se budete chtít přesvědčit, že zákazník opravdu zmínil to, co jste zachytili v poznámkách.

Ne všechny demonstrace musí být za účasti zákazníka. Jeho roli může převzít konzultant či analytik, kteří znají potřeby zákazníka a jeho způsob práce (připravují požadavky se zákazníkem, znají danou byznys doménu). Někdy může zaskočit i projektový manažer nebo architekt, ale jejich pohled může demo ubírat jinou stranou (architekt se může zaměřit na technické aspekty; manažer na stav plnění úkolů, i když tyto nebyly pro zákazníka velkým přínosem).

Demonstrace ne-GUI funkčností

Díky komplexnosti dnešních systémů není možné všechny úkoly demonstrovat s pomocí GUI. Samostatnou kapitolou je demonstrace funkcionalit, které nejsou přímo na front-end straně, nelze je přímo demonstrovat, jedná se typicky o integrace, databázové transakce, bakche, back-end úkoly apod. Podle typu funkčnosti může demonstrace v tomto případě probíhat následovně:

  • ukázka změněných stavů v systému/zapsaných logů po provedení transakce/přenesených dat architektovi řešení na straně zákazníka či vývojového týmu,
  • prezentace výstupů testovacích scénářů (v tomto případě jistě automatických).

Typy pro demo v distribuovaném prostředí

Distribuované prostředí má svoje specifikace. Zákazník a tým jsou většinou umístěni v jiné zemi, často i na jiném kontinentu, proto schůzka na jednom místě je téměř nereálná (rozhodně v případě krátkých iterací). V tomto případě je vhodné provádět následující:

  1. Vzdálená demonstrace: samozřejmostí je použití sdílené plochy, kde je pro obě strany možné mít kontrolu nad prezentovanou funkčností, k dispozici jsou různé nástroje, přes virtuální stroje či sdílené meetingy (Webex, MS Live meeting).
  2. Nahrávání: pokud používáte některé z výše zmíněných nástrojů, potom je dobré demonstraci nahrávat (například Live meeting to umožňuje), jak už bylo diskutováno výše.

Doufám, že tyto základní rady vám pomohou k úspěšným demonstracím a tím i k úspěšnému doručení toho, co si zákazník opravdu přál (a aniž by to na začátku projektu věděl ;)) za dohodnutou cenu a čas.

Máte k tomu co říct?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *