it-swarm-eu.dev

Jsou dráty vhodné pro dokumentaci požadavků?

Lidé v oblasti designu, vývoje a testování momentálně vedou rozhovory o požadavcích.

Součástí rozhovoru je účel a použití drátových modelů. Náš analytik změn je rozhodně proti používání drátových modelů jako součásti požadavků na vývoj nebo testování. Mají být použity pro „doplňující informace“ pouze v nezbytných případech - „pro přehlednost“.

Zkrátka: použijte písemné požadavky, nikoli vizuální.

Měl by být drátový model používán jako součást procesu shromažďování požadavků a dokumentace?

Pracovali jste někdy v týmu, kde byly drátové modely primárními požadavky na vývoj a/nebo testování?

Edit: Mám předsudky ve prospěch použití wireframes jako formální dokumentace požadavků. Strávil jsem pár let v prostředí, kde to bylo the jediná forma požadavků na dokumentaci - vývoj nezačal, dokud se vlastníci produktu (agilní nastavení) neodhlásili na drátových modelech. V tomto nastavení velmi efektivní.

13
gef05

Myslím, že riskujete požadavky vs debata o designu zde. Drátové kostky jsou docela důležité, ale myslím, že záleží na tom, jak je konceptualizujete. Toto je můj vlastní názor, ale podle mých zkušeností jsou podporovány docela standardními průmyslovými procesy.

  • Požadavky by se obecně měly psát pouze proto, že popisujete, co řešení musí udělat. Měly by být dostatečně podrobné, aby jasně popsaly všechny kroky, které musí být provedeny, a měly by být rozděleny do logických kbelíků v závislosti na typu produktu, pro který jsou určeny.
  • Dráty jsou součástí procesu návrhu, protože popisují, jak se řešení musí chovat, aby splnilo požadavky. Někdy budete možná muset vyvinout mentální mapu nebo uzlový diagram, nebo nakreslit něco, aby klientovi jasněji popsal jeho požadavky, ale to není účelem drátového modelu.
  • V projektech, kde někdo načrtl, jak by aplikace měla proudit a/nebo postavit drátěné rámečky (které v podstatě začínají umisťovat prvky do uživatelského rozhraní), předem, vždy ovlivní proces návrhu a IMHO obvykle skončí podstatnou změnou nebo úplně vyhodí.

Požadavky jsou obvykle (ne vždy) napsány obchodním analytikem nebo PM a nikoli návrhářem zaměřeným na uživatele.) Někdy se tyto role překrývají a lidé mohou dělat obojí dobře, ale tam, kde jsou rozlišené, drátové snímky jako součást požadavků obvykle podle mých zkušeností nefungují. Z nutnosti přicházejí později, když se klient odhlásí o tom, co produkt musí udělat, nikoli o tom, jak by to měl udělat.

12
jameswanless

Používám Storyboards v aplikaci PowerPoint v polopřímé věrnosti. Zjistil jsem, že písemná dokumentace má zásadní nedostatky.

  1. Lidé nedokážou citově reagovat na interaktivitu tím, že si to představí z textu. Nemůžete napsat odstavec o tom, jak něco bude fungovat a přimět lidi, aby rozuměli nuanci návrhu interakce. Je to jako psát: „Grafický design bude krásný pomocí hodně fialové“. Co to znamená? Jak to můžete definovat, aniž byste to ukázali?

  2. Jazyk je na hovno . Osobně mám méně argumentů než v e-mailu. E-mail (textová komunikace) má příliš mnoho šancí na nesprávnou interpretaci. Když jste spolu a díváte se na něco vizuálního, věci se zjemňují. Navíc mnoho inženýrů, o kterých vím, není angličtina jako mluvčí prvního jazyka. Text je často nesprávně interpretován.

  3. Nemůžete testovat text . Můžete otestovat scénář a postavit jej před lidi, abyste dostali reakce. Text tak nefunguje.

CAVEAT: Všechny společnosti mají zvláštnosti a zvláštní okolnosti. Musíte najít, co pro vás funguje. Jen nenechte lidi říkat něco, o čem víte, že je špatné. Pokud musíte, udělejte obojí a tajně dejte scénáře technikům.

6
Glen Lipka

Moje frustrace jako BA spočívá v nejasnosti mezi „požadavky“, které jsou testovatelnými jednotkami, a „designem“, které, když byly vytvořeny jako součást požadavků, BECOME požadavky. Když se podnik odhlásí na drátovém modelu s nízkým nebo vysokým výkonem, učinily to vizuálním požadavkem. Nyní píšu testovací skripty, aby se zajistilo, že drátový model generuje přesně tak, jak je to znázorněno na obrázku. Mluvte o granularitě !! Požadavky by se měly týkat FUNKCE aplikace, nikoli vizuálního designu, pokud návrh nemá legitimní obchodní potřebu - například ADA, marketingové standardy nebo identifikovaná zvýšení produktivity.

Podnikání a vývojáři se častěji než ne spoléhají na vizuální řešení, protože bez něj nemohou koncipovat svůj konečný produkt. Je to rozdíl mezi čtením knihy a sledováním videa těchto požadavků. Je to kluzký svah sňatku s designem a podnikání začíná diktovat „jak“ by tento design měl fungovat (uložit tlačítka, chybová hlášení, sběr dat, navigaci atd.) Stejně jako vývojáři by neměli diktovat UX, ani by neměli podnikání, pokud nejsou v podnikání UX a designu, a pak bych se divil, proč sami nepíšou kód.

Velké zasténání je často shromažďováno a požadavky na dokumenty rychlejší, takže může začít vývoj, který vyvolává otázku, proč je vůbec napsat? Pokud vývojáři nemohou číst požadavky a začít strukturovat vývoj bez návrhu, pak se zdá pravděpodobné, že se nestarají o přepracování dat a přepracování návrhu je mnohem nepříjemnější změnit. Být agnostický pro shromažďování požadavků znamená otevřenou příležitost pro agnostický design - design není vázán na platformu a je to omezení. Vytváříte-li proces odhlášení na drátových modelech, nastavujete firmu tak, aby akceptovala to, co jim chcete dát, namísto toho, aby jim dala to, co potřebují. Pak proces skončí o pěkných obrázcích a ne o funkci aplikace.

Defenitly ... Myslím, že je nezbytné, aby váš tým uživatelského rozhraní měl drátový model, aby viděl všechny různé interakce, které potřebujete zobrazit na projektu.

Někteří lidé říkají, že by mělo stačit mít písemný popis projektu, ale někdy nemůžete získat celý obraz proyecta pouhými slovy.

Zejména u dynamických drátových modelů je pro designéra snadnější mít například představu o tom, co by menu mělo dělat.

Je také skvělé pracovat s klienty, protože mají jasnou představu o tom, co váš tým plánuje pro svůj projekt naprogramovat.

To vám ušetří spoustu času na programovací straně věci a UI interakce pro mě dobrý drátový model je grafické znázornění dobrého písemného dokumentu.

V mé mysli není pochyb o hodnotě dobrého, podrobného a interaktivního drátového modelu.

1

Drátové modely nejsou dokumentací požadavků. Dokumenty požadavků nejsou drátové. Oba však záleží a vzájemně se ovlivňují.

Zjistil jsem, že spolu fungují nejlépe společně. Jinými slovy, oba se vyvíjejí společně (na rozdíl od toho, co bylo dokončeno před tím, než začalo druhé).

Zmíníte, že jako požadavky v agilním prostředí používáte drátové snímky. Myslím, že to je pravděpodobně výjimka. V ideálním případě by všechno bylo provedeno v agilním prostředí.

V tomto scénáři jsou drátěné rámečky skutečně ubrousky. Jsou interním dokumentem, který komunikuje myšlenku, aby se mohla okamžitě postavit.

Skvělé na Agile je to, že (IMHO), když se to udělá správně, výrazně snižuje potřebu dokumentace obecně a svým způsobem tuto konkrétní otázku méně relevantní.

1
DA01

Myšlenky nalezené v knize „Prototyping: Practitioners Guide“ jsem našel jako dobrý příklad toho, jak někdy není psané MRD tak užitečné, jak bývalo, na základě myšlenky, že někdy ukazuje, je lepší než vyprávět. Specifika knih se týkají prototypování, mám pocit, že stejné nápady mohou přejít i na wireframing.

  • Prototypování je generativní: Znamená to, že během procesu prototypování (nebo wireframing) procházíte stovkami nápadů. Někteří brilantní a jiní ne tak brilantní. Méně geniální nápady však mohou být katalyzátorem pro brilantní řešení.
  • Prototypování komunikuje prostřednictvím show and tell.
  • Prototypování snižuje chybnou interpretaci. Vezměte si 60stránkový dokument s požadavky. Přineste 15 lidí do místnosti. Rozdejte to. Ať si to všichni přečtou. Nyní se jich zeptejte, co stavíte. Dostanete 15 různých odpovědí. Nyní si představte, že zkuste to samé s 200stránkovým MRD - je to ještě horší ...
  • Prototypování vytváří rychlou zpětnou vazbu, která v konečném důsledku šetří čas, úsilí, peníze a snižuje riziko.

S ohledem na toto všechno by argument proti tomu byl, někdy může být prototypování/wireframing také pro určité projekty nadměrné, takže to opravdu záleží na projektu.

1
Armando

Rozhodně ne - drátěné snímky nepatří do požadavků.

Drátové modely jsou skvělý způsob, jak:

  • Vytvořte požadavky
  • Návrh řešení požadavků

Ale dát je do požadavků je noční můra, která povede ke zmatenému, zmatenému myšlení a dokumentaci (často spojující formu a funkci).

Jedná se zejména o problém v regulovaném prostředí nebo ve smlouvách - podívejte se na tento způsob, pokud uživatelské rozhraní změní rozevírací seznam na zobrazení seznamu:

  1. Tento požadavek již není splněn a ve výchozím stavu je regulačním nebo smluvním selháním. Produkt stále funguje dobře, ale papírování je nyní zákonnou odpovědností.
  2. Dokumentace musí být přepracována při každé změně uživatelského rozhraní - to je šílené.
  3. Dříve jsem pracoval pro společnost, která byla natolik bláznivá, že jsem dala drátové modely do požadavků, ale také do odpovídajících testů! To šílenství znamenalo, že když bylo uživatelské rozhraní přepracováno novými designy a sadami nástrojů, veškerá dokumentace musela být přepracována (že ve svých odhadech projektů nezohledňovaly).

Předpokládám, že máte na mysli pouze drátové modely uživatelského rozhraní. Blokové diagramy, vývojové diagramy atd. Jsou nezbytné.

0
Mr Blah

Konečný produkt, který stavíte, je webová aplikace.

Drátěné rámy vás mohou dostat na polovinu cesty s malým úsilím, takže je rozumné používat drátěné rámy jako požadavky, pokud obsahují dostatečnou granularitu mezi kroky.

Jinak jsem zjistil, že špatně provedené drátěné snímky lze interpretovat téměř stejně snadno jako písemné požadavky.

Při dokumentování všech toků jsou však stále nezbytné písemné požadavky. Bez nich je obtížné provádět strukturované testování přijímání uživatelů a testování kvality.

0
Jung Lee

Zde věřím, že vaše požadavky se mohou stát vynalézavými - Stavební blokové diagramy a vývojový diagram.

http://www.leacock.com/deliverables/block_diagram_ex2.pdf

Zde vysvětluje postup v vývojovém diagramu, který je opět lepší než jen dokumentace. Používání drátových modelů vyžaduje čas, rozpočet na práci kolem. Ale použití blokových diagramů a vývojových diagramů je smysluplnější a pomáhá dalším vývojářům a členům týmu zapojit se do dokumentace.

Většině se lidem nelíbí prohlížení textových informací, které podle mých zkušeností skutečně nepřitahují nikoho, aby se na ně díval déle než 10 minut. Udělali jsme projekt, kterému čelíme Klientovi, kde to mělo velkou výhodu tím, že jsme drátové snímky zobrazovali paralelně s textovými daty. Lidé začali chápat, v čem se snažíme dokumentovat. Ale to vyžaduje hodně úsilí. Ideálním způsobem, jak udržet zdroje neporušené, je použití vývojových diagramů a blokových diagramů, aby bylo zajímavé.

0
inkmarble