it-swarm-eu.dev

Řešení špatných / neúplných / nejasných specifikací?

Pracuji na projektu, kde náš dev tým získává specifikace z obchodní části společnosti. Jak obchodní management, tak IT management vyžadují odhady a projekce termínů, jak by měly.

Dobrá věc je, že odhady většinou dělají skuteční vývojáři, kteří dostanou potřebné funkce. Špatné je, že specifikace jsou obvykle buď příliš jednoduché (ukáže se, že vám zbylo mnoho otázek nad hlavou, protože se zdá, že spousta informací chybí) nebo příliš složitá (až do té míry, že můžete Nevidím ani to, kde by se všechno do aplikace „hodilo“). Obchodní část specifikací je častěji neúplná nebo nevědomá o tom, co lze a co nelze udělat (vzhledem k dříve implementované obchodní logice).

Dev týmu je dán asi jeden den na nový spec dát odhad a my se snažíme jasné nejistoty, obvykle setkáním s kýmkoli, kdo spec. Většinou se ukáže, že spisovatelé spec opravdu neuvažovali všechno, a to je obvykle jen když začneme navrhovat a vyvíjet, že jsme skončili v problémech, protože spousta spec vypadá, že má díry.

Jak se s tím vypořádáte? Jste velkorysí na odhady předem?

44
eagerMoose

Pokud narazíte na problémy ve fázi návrhu, máte opravdu problém?

Ujistěte se, že ti, kteří vytvářejí specifikace, nemají pocit, že musí dělat všechno dopředu. Nemohou na všechno myslet a ani my. Potřebují také vědět, že na nějakém specifickém dokumentu nemohou udělat vše, co by se stalo, a pak je s projektem hotové. Tato praxe také vede k tomu, že přidávají každou maličkost, na kterou si možná vzpomenou, protože ji mohou „potřebovat“ a pokud se na to neptají, dostanou ji někdy. Musí být k dispozici, aby znovu a znovu kontrolovali, testovali a schvalovali své požadavky.

Nesnažte se navrhnout nebo postavit celou aplikaci najednou. Jakýkoli projekt/aplikace lze rozdělit na nějaké fáze, části, moduly nebo cokoli, co chtějí nazvat. Nemusíte být agilní, pokud to není vaše věc. Začněte kusem Zabezpečení uživatelů a jděte odtud.

Udělejte si čas, abyste si s těmito lidmi sedli a zjistili, co opravdu chtějí. Byl bych rád, kdyby mi někdo dal specifikace, které mi umožnily vytvořit celý projekt najednou, ale co bych udělal pro příští rok a půl?

13
JeffO

Používám Kužel nejistoty Řekněte hlasitě vzkvétajícím hlasem

V podstatě uděláte nejlepší odhad, který můžete poskytnout informacím, které máte.
Upozorňujeme však také na to, že vzhledem k nejasnostem ve specifikacích existuje vysoká nejistota ohledně těchto odhadů (Správa bodů na místě, aby mohli číst na principu).

Jak postupujete k cíli a zpřísňujete specifikace, můžete aktualizovat svůj odhad a zpřísnit nejistotu.

20
Martin York

Ano, na odhady jsem velkorysý. Nezapomeňte Hofstadterův zákon

Hofstadterův zákon: Vždy to trvá déle, než očekáváte, i když berete v úvahu Hofstadterův zákon. Z Gödel, Escher, Bach: Věčný zlatý cop.

9
Brian Carlton

Proces, který popisujete, je ve skutečnosti docela normální. Problém je v tom, že typy podniků mají tendenci myslet na věci z hlediska „fáze požadavků“, poté „fáze návrhu“ atd. Když tým vytváří produkt, opravdu potřebujete iterativní přístup. Několik nápadů, které jsem našel, jsou:

  • Definujte hlavní cíle navrhovaných změn/nové aplikace. Jedná se o obchodní záležitosti cíle jako „snížit náklady na zpracování reklamací o 10%“ nebo „sdílet průzkum trhu od našich satelitních kanceláří, aby produkty lépe vyhovovaly potřebám našich klientů“. Pomáhá zaměřit se na otevřené požadavky na to, jaké jsou skutečné potřeby.
  • Udělejte svůj počáteční Swag (Seriously Wild-A ** Guess) pro špatné požadavky, jak jsou psány, ale dokumentujte, co vy předpokládalo, že implementace bude. Toto je zpětná vazba, kterou musí obchodní lidé (a váš klient) zlepšit a přemýšlet o těchto věcech. Spoléhají se na vás za ně.
  • Pokud máte na výběr mezi opravdu dlouhým a opravdu krátkým odhadem, vždy jděte dlouho. Pravděpodobně bude šokovat toho, kdo vás žádá o práci, což je dobrá věc. Nutí vás dva, abyste diskutovali o tom, co vlastně jsou.

Pamatujte, že váš první odhad nemůže být přesný. Zakládejte své odhady na rozumných interpretacích požadovaných požadavků a dokumentujte své předpoklady/interpretace. Z důvodu otvorů, které jste objevili, bude existovat více odvozených požadavků. To je normální.

6
Berin Loritsch

Být velkorysý na odhady může znít dobře, ale jaký problém to vyřeší? Nebude to zlepšovat specifikace, nebude to usnadňovat plánování. Říká to „nemůže být mnohem horší než X“, na rozdíl od toho, že říká „může to být Y“. Pravda je, že nevíte. Zjistěte, co můžete.

Pokud obchodní analytici potřebují zapojit vývojáře dříve, řekněte jim to. Písemná zpráva není opravdu nejlepší způsob komunikace. Pokud můžete mít vývojářskou pomoc při shromažďování počátečních požadavků a obchodního analytika, který vám pomůže s vývojem a testováním, budou vaše výsledky lepší.

Právě jsem četl kužel nejistoty; jsou to dobré věci, ale je snadné to špatně pochopit. Vedení se může podívat na první obrázek a říci: „ok, máme obchodní požadavky, takže váš odhad by měl být s 50% přesností podle vašeho kužele. Řekni mi. To nepomůže.

Analogie auta: někdo se vás zeptá, kolik stojí auto, a dá vám papír s jeho požadavky. Papír říká, že by měl vážit kolem 1200 kg, mít čtyři kola a alespoň dvě dveře, ale možná čtyři, pokud by měla sedět čtyři lidé, a dobré světlomety jsou opravdu důležité. Barva by měla být šedá (ale je možná i černá?).

Můžete říci 25 $, a pokud se později ukáže, že chce zbrusu nový Range Rover, jste v pořádku. To neznamená, že by bylo korektnější nebo užitečnější říci, že to stojí 100 000 $. Může jen potřebovat použitý (promiň, pre-vlastněný) Prius. Pokud nemáte čas zjistit, který z nich, nikdy nevíte.

3
Jaap

Většinou se ukáže, že spisovatelé spec opravdu neuvažovali všechno, a to je obvykle jen když začneme navrhovat a vyvíjet, že jsme skončili v problémech, protože spousta spec vypadá, že má díry.

Použití většiny je nesprávné.

Není možné, aby spisovatelé specifikací přemýšleli všechno. Doba. Kdyby si mysleli všechno, věděli by, kolik řádků kódu napsat a které řádky kódu byly správné.

Vzhledem k tomu, že specifikace musí být nesprávná, není s tím co dělat.

Problémem je problém .

Jak obchodní management, tak IT management vyžadují odhady a projekce termínů, jak by měly.

Možná ne. Celkové odhady a termíny nejsou nejužitečnějšími věcmi.

Od této doby se vyvíjí agilní metody.

Jde o to. Všechny odhady založené na specifikacích musí obsahovat chyby. Mají jen štěstí. Polovina času, odhad je mnohem méně a polovina času, kdy je odhad daleko. Toto je logický důsledek pokusu předpovídat budoucnost s neúplnými informacemi.

Protože se to musí stát, neměli byste skončit v potížích , když se mýlíte. Musíte se mýlit. A musíte se neustále a náhodně mýlit. Jinak si popletete čísla.

2
S.Lott

Měli byste vysvětlit řízení, že s neurčitými specifikacemi je nízká míra důvěry v odhad. tj. odhadujete, že se může lišit o 30% nebo 40% nebo 50% nebo co si myslíte. Pokud se tedy něco odhaduje na 2 dny, je to vlastně rozmezí od 2 do 3 dnů.
Poté vytvořte registr vydání projektů (může být na wiki nebo Jira atd.). Vytvořte všechny své otázky jako problémy a nechte firmu odpovědět na vaši otázku. Dokud problém zůstává nevyřešený, zůstává odhad nejistý. Pokud je to možné, požádejte obchodního analytika, aby to usnadnil a vytvořil lepší požadavky. Nechte svůj testovací tým zkontrolovat specifikace, protože musí vytvářet testovací případy proti specifikacím. Jejich zapojení může často vést k psaní lepších specifikací. Hlášení denně/týdně vedení, kolik nevyřešených problémů máte. Čím více bude vyřešeno, tím lepší budou vaše odhady. Vždy uvádějte metriky managementu jako čísla, díky nimž je objektivně přemýšlí a také vás postaví na silnou půdu.
Také v závislosti na velikosti projektu věnujte 1-4 týdny fázi návrhu řešení, ve které vymažete hlavní problémy (požadavky i technické). Mít mnoho workshopů s malými a středními podniky a pokusit se jim porozumět a následně vysvětlit své názory, abyste dospěli k závěru. Až pochopíte hlavní případy použití a vaše odhady dosáhnou přibližně 80% jistoty, měli byste pokračovat ve vytváření fáze.

1
softveda

Komunikace obvykle pomáhá, alespoň ve zdravé organizaci.

Toto není žádná stříbrná střela, ale to, co jsem se pokusil udělat (a fungovalo to v naší společnosti), je přesvědčit podnikatele, aby problém vysvětlili, spíše než navrhli řešení okamžitě. Naše požadavky na funkce tedy začínají popisem problému nebo cíle, kterého chtějí dosáhnout.

Poté se vývojář s určitými znalostmi domény snaží najít řešení, zatímco konzultuje s někým na obchodní straně věcí. Tento proces obvykle poskytuje několik alternativních řešení, doplněných odhady.

V tuto chvíli je na podnikání vybrat si jeden na základě nákladů a toho, jak kompletní je řešení. To je také to, jak byste jim mohli tuto metodu prodat, že zde mají možnosti, nejen řadu mandays, vzít ji nebo ji opustit. Samozřejmě to také vyžaduje více zdrojů na jejich straně, ale pokud máte problémy s odhady a specifikacemi, je to investice, která stojí za to.

0
biziclop

Proč byste přijímali specifikaci požadavků, která je neúplná, obsahuje protichůdné požadavky nebo je nemožná? Doporučuji, aby váš proces obsahoval způsob, jak vyhodnotit specifikaci a poslat ji zpět k opravám, než ji přijmete a uvedete jakékoli odhady.

0
oosterwal

Přesvědčte management/zákazník, že stojí za to investovat do lepších specifikací. Pokuste se zapojte lidi se znalostmi domény. Nakonec z toho budou mít všichni prospěch.

0
FabianB

Odstraňte specifikace.

Přesvědčte podnikání, aby vyzkoušelo Agile (nebo alespoň Agile-ish proces) pro projekt.

Místo toho psát specifikace

  • setkejte se s obchodníky a identifikujte funkce
  • pracovat s nimi na identifikaci minimální sady funkcí/funkcí, které by byly užitečné (i když pouze pro interní vydání)
  • kartu do práce
  • nastavit datum práce (čím méně funkcí/práce, tím snazší bude přesné odhadnutí data).
  • spolupracujte s firmami na upřednostňování práce, ujistěte se, že mají schopnost změnit názor na objednávku karet, řekněte jim, jak to ovlivňuje datum
  • každé dokončené funkce je funkční systém, který je zobrazuje, a nechat je odhlásit se na každém díle tak, jak je hotovo
  • uvolnění
  • opláchněte
  • opakovat

Zobrazeno funkce, jakmile jsou hotovi. Vydání brzy a často. Buďte transparentní a pohotoví. Zjistil jsem, že to povede k odstranění zbytečných lhůt.

pravit pro architektur

Koho je na čele, mělo by se uskutečnit úvodní setkání, které by sdělilo devs, jaká by měla být architektura. Vedení je také opravdu osoba, která by měla náležitě dbát, aby se ujistila, že jsou splněny všechny potřeby.

Pokud ve svém procesu potřebujete další kroky, než je přidat. Existuje postup, který týmu usnadní práci. Pokud něco nefunguje, změňte to. Přidejte k tomu, odeberte z něj, změňte jej tak, aby vyhovoval vašim potřebám. Chcete-li se zvláště zajímat o zabezpečení, přidejte kroky.

0
dietbuddha

Pamatujte, že pokaždé, když se změní specifikace, aby se přidala nová funkčnost nebo aby se vyjasnily otázky, je čas znovu odhadnout. Není to tak moc, že ​​náš původní odhad je špatný, vzhledem k tomu, co nám bylo řečeno, ale že netlačíme zpět a ne, když to bude k dispozici, bude to nutné, až bude k dispozici více podrobností. Kdybych byl dodavatelem stavby domu a odhadl jsem náklady na základě použití lamiante pultu a o měsíc později klient chce žulový, můžete se vsadit, že s ním budu revidovat odhad nákladů. Necháme naše klienty dostat pryč s ošuntělými požadavky a pak se nestlačíme, když se ukáže, že je mnohem více věcí, než se původně předpokládalo.

0
HLGEM