role business analysts scrum
příklady aplikací internetu věcí
Prominentní role obchodních analytiků ve SCRUM:
Obchodní analytik, který je brzy označován jako BA, hraje velmi drastickou a důležitou roli SKRUMÁŽ .
Tato osoba je spojovacím článkem mezi vlastníkem / zákazníkem produktu a technickým týmem IT. Ačkoli jsme na našem webu na BA narazili na několik tutoriálů, tento tutoriál bude nějakým způsobem jedinečný a vysvětlí vám důležitost BA ve SCRUM.
Pojďme prozkoumat !!
=> Podívejte se na VŠECHNY výukové programy obchodního analytika zde.
Co se naučíte:
- Odpovědnosti BA
- Obchodní analytik jako vlastník produktu
- Obchodní analytik jako člen týmu
- Důležitost a role obchodních analytiků v týmu SCRUM
- Proč je QA Best vhodný pro tuto práci?
- Doporučené čtení
Odpovědnosti BA
Ve Scrumu je několik rolí obchodních analytiků a existují určité povinnosti, kterých by se BA měla držet.
Několik selektivních z nich je uvedeno níže.
- Upravování nevyřízených položek produktu na základě stanovení priorit poskytnutých vlastníkem produktu.
- Analýza potřeb zákazníků a hledání řešení k jejich řešení.
- Vytváření požadavků ve formě uživatelských příběhů s příslušnými kritérii přijetí.
- Pokud v případě, že uživatelské příběhy již vytvořil vlastník produktu (s kritérii přijetí), zkontrolujte je, abyste se ujistili, že je pokryto každé obchodní pravidlo a kritéria přijetí splňují funkčnost příběhu uživatele.
- Spolupráce s vlastníkem produktu a zúčastněnými stranami na porozumění rozsahu, navrhování vylepšení požadavků atd.
- Příprava dokumentů, jako jsou drátové modely, návrhový tok, uživatelské rozhraní atd. Podle potřeby.
Kromě toho, a Obchodní analytik je důležitým účastníkem brainstormingu, když se tým setká, aby prodiskutoval nevyřízené položky sprintu. BA vede tým, pomáhá jim porozumět požadavkům a někdy musí schválit implementaci.
Úzce také spolupracuje s QA, jako je analýza pokrytí testů, konverze případů použití v reálném světě na testovací případy, poskytnutí vhledu k testování složitých funkcí atd. BA se také účastní plánovací schůzky, aby pomohla týmu v odhadech tím, že jim pomůže porozumět toku, složitosti a závislosti.
BA se musí neustále učit o novém trendu, který se na trhu děje, neustále inovovat a být informován o obchodní oblasti, pro kterou byl produkt vyroben.
Obchodní analytik jako vlastník produktu
V závislosti na zákazníkovi a společnosti se stává, že některé společnosti mají jako produktového vlastníka Business Analyst. V těchto případech je BA kontaktním bodem pro všechny dotazy. BA se poté stává prostředníkem mezi týmem a zúčastněnými stranami.
BA musí porozumět požadavkům zúčastněných stran, jejich přemýšlení o tom, jak posunout podnikání vpřed, a co (a jak) by mělo podnikání růst. Poté musí BA na základě požadavků zúčastněných stran vytvořit dokumenty, uživatelské příběhy, upřednostnit příběhy, pomoci týmu porozumět jim, odpovědět na jejich dotazy ohledně stejných atd.
Nejdůležitější je zde poznamenat, že je to vhodné, když je BA fyzicky dostupná a není geolokována do jiného časového pásma, aby se předešlo „mezeře v komunikaci“.
Pokud je BA jako u vlastníka produktu geolokována do jiného časového pásma, není možné se k němu pokaždé přiblížit a jediný způsob komunikace je e-mailem nebo chaty nebo hovory, což může mít za následek nedostatek, mezeru a dokonce občas špatná komunikace.
Podle mých zkušeností by to mělo být dodržováno, když BA sedí ve vaší kanceláři, vedle vašeho týmu, aby vaše práce nebránila a byl snadno přístupný. Z pohledu BA vlastní produkt jménem zúčastněných stran / zákazníků, činí vhodná rozhodnutí a dokonce se musí naučit nové dovednosti, které mohou zahrnovat osvojení některých technických dovedností vývoje.
Mít obchodního analytika jako vlastníka produktu je další výhodou, protože obchodní analytik produktu velmi dobře rozumí a lze vyjednat také stanovení priorit a stanovení rozsahu úkolů.
Obchodní analytik jako člen týmu
Druhou možností je mít obchodního analytika jako člena týmu, protože produktový vlastník nebude vždy k dispozici. Pokud je obchodní analytik členem týmu, pak pomáhá kolegům v přípravě nevyřízených věcí.
Mít obchodního analytika za člena týmu je výhodnější, protože technickému týmu je snadné a pohodlné komunikovat s BA za účelem vysvětlení nebo diskuse. BA také úzce spolupracuje s týmem QA pro testování, tj. Analýzu pokrytí, pokryté případy použití, jakékoli skryté požadavky nebo spolehlivost nebo účinky.
Někdy mohou být akceptační kritéria napsaná vlastníkem produktu vágní a nejasná, pak se jako člen týmu stává odpovědností BA napsat komplikovaná a dobře vysvětlená akceptační kritéria. Pokud tým potřebuje více informací, pak BA také vytvoří drátové dokumenty, dokumenty toku, atd., Aby pomohl týmu porozumět požadavkům.
U rozsáhlých projektů, kde jsou moduly distribuovány mezi týmy, je přidaná výhoda také získání BA pro více než jeden tým. Vzhledem k tomu, že BA je stejný napříč týmy, může uvažovat o interoperabilitě modulů, o tom, jak nové funkce nebo aktualizace ovlivní ostatní moduly atd.
To by tedy technickým týmům velmi pomohlo zvážit takové aspekty, jako to ne vždy zmiňují uživatelské příběhy nebo kritéria přijetí.
Důležitost a role obchodních analytiků v týmu SCRUM
Role obchodních analytiků ve SCRUM je velmi důležitá pro úspěch projektu. Jejich zapojení začíná hned od pochopení potřeby zákazníka až po ukázku Sprint. Jsou prvním kontaktním místem technického týmu pro vysvětlení. Ještě důležitější jsou v počátečních fázích nového projektu a v projektech, které jsou rozsáhlé.
Produktový vlastník nebude vždy dobrým autorem, někdy pochází z technického prostředí, a proto se stává odpovědností obchodního analytika psát příběhy, přijetí, drátové modely atd.
V mém projektu naše PO nebyla tak dobrá s dokumentací a dokonce ani napsané uživatelské příběhy nikdy nebyly více než 2-3 vložky, zatímco kritéria přijetí byla pouze vložka 1. Byl to obchodní analytik, který je upravoval, aby byly vysvětlující a podrobnější.
Dokonce se občas stalo, že naše PO napsala příběhy uživatelů, které měly 21 nebo více bodů příběhu, a proto obchodní analytik musel věnovat více času a úsilí jejich členění a upřednostnění u vlastníka produktu.
Můžete si představit, co by se stalo, kdyby neexistoval obchodní analytik a váš produktový vlastník vytvořil uživatelský příběh jako „Jako zákazník chci provádět všechny bankovní operace pro svůj účet“ s kritérii přijetí, jako jsou:
- Zákazník by měl mít možnost se přihlásit.
- Zákazník by měl být schopen provádět transakce na mém účtu.
- Zákazník by měl mít možnost stáhnout si moje historická prohlášení atd.
Podle mého názoru by nyní tento uživatelský příběh obsahoval ještě více než 34 příběhových bodů, a proto je třeba jej dále rozepisovat. Věci by se zhoršily pro technický tým, kdyby nebyly poskytnuty správné vývojové diagramy a obrazovky uživatelského rozhraní (které budou vytvořeny).
To by vedlo k neúspěšnému sprintu a následně k neúspěšnému projektu. Pokud není produktový vlastník vyškoleným / procvičeným obchodním analytikem, je třeba mít v týmu jednoho.
Proč je QA Best vhodný pro tuto práci?
QA je osoba, která ověřuje navrhované řešení problému / požadavku jeho testováním. Proto jsou obchodní analytici / zúčastněné strany / vlastníci produktů velmi dychtiví vědět o zpětné vazbě QA. Zapojení BA do testování je o něco více než ve vývoji.
Obchodní analytik úzce spolupracuje s QA při kontrole pokrytí testovacích případů, které poskytuje pohled na skryté toky nebo požadavky / efekty. Tak tento druh sdílení znalostí (BA) jim umožňuje pochopit funkčnost produktu, obchodní pravidla, očekávání zákazníků, toky, závislosti a všechno úplně.
QA vždy testuje z pohledu koncového zákazníka, který by produkt používal, a proto je šance, že zákazníkovi pomůžeme s vylepšením, vylepšení v produktu je více (ve srovnání s vývojářem). Vývojáři vyvíjejí produkt pro daný uživatelský příběh a soubor kritérií přijetí, ale ne vždy přemýšlejí o tom, jak by zákazník produkt použil .
Ve vývoji je implementace produktu, tok a pravidla dobře definována, ale testování je zcela založeno na logickém myšlení a schopnosti přemýšlet z pohledu koncových uživatelů.
QA se může ve SCRUM začít dostávat do role obchodních analytiků kvůli spoustě příležitostí, které se nabízejí v každodenní práci.
Doporučené čtení => Kariérní posun z testeru do BA
Pro QA je velmi snadné se dostat do rolí jako:
- Studujte požadavky velmi hluboce a poukazujte na mezery v kontrolních schůzkách / brainstormingových relacích atd. Pokuste se přemýšlet o lepších řešeních a diskutovat totéž s týmem a BA.
- Pozorně sledujte hovory s produktovým vlastníkem, kladte otázky a sdílejte svá zjištění. Tím se zvýší důvěra vlastníka produktu, který projeví váš zájem o produkt.
- Umístěte se mezi BA a vývojovým týmem, měli byste být kontaktním místem pro vývojáře v případě vysvětlení nebo pochybností.
- Nastavit testovací proces a neustále ho inovovat, měnit jej tak, aby poskytoval úspěšné sprinty.
- V případě produktů s efektními uživatelskými rozhraními hledejte nové trendy a navrhněte taková vylepšení.
- Pochopte produkt úplně dovnitř a ven.
- Budujte silné znalosti o svých zúčastněných stranách, jejich očekáváních a sdílejte s nimi své zkušenosti.
To také znamená, že abyste se dostali do role BA, musíte zlepšit své dovednosti. Na trhu se nachází několik kurzů, které zahrnují základní i pokročilou úroveň.
Jste BA / QA? Poukázali jsme správně na vše o vaší roli? Nebo si myslíte, že nám chybělo něco, co jedinečně předvádíte? Budeme rádi, když se nám ozvete. Neváhejte se s námi o ně podělit v sekci komentářů níže !!
=> Navštivte zde a prohlédněte si řadu Business Analyst pro všechny.
Doporučené čtení
- Scrum artefakty: Nevyřízené položky produktu, nevyřízené položky sprintu a přírůstky produktu
- Existuje nějaká hranice začátku a konce role QA ve Scrumu?
- 39 nejlepších nástrojů pro obchodní analýzu, které používají nejlepší obchodní analytici (seznam A až Z)
- Role a odpovědnosti Scrum týmu: Scrum Master a produktový vlastník
- Kariérní posun od testera k obchodnímu analytikovi - průvodce krok za krokem
- Začněte svou kariéru jako obchodní analytik: Career Avenue pro vás
- Koordinátor Cum Training Pune pro IT podporu a rozvoj podnikání
- Defekt Triaging in Scrum: How Is it Organized in a Scrum Setup