it-swarm-eu.dev

Jak reagovat, když budete požádáni o odhad?

My, jako programátoři, se neustále ptáme „Jak dlouho to bude trvat“?

A víte, situace je téměř vždy taková:

  • Požadavky jsou nejasné. Nikdo neprovedl hloubkovou analýzu všech důsledků.
  • Nová funkce pravděpodobně poruší některé předpoklady, které jste ve svém kódu provedli, a okamžitě začnete přemýšlet o všech věcech, které byste mohli muset změnit.
  • Z minulých úkolů musíte udělat něco jiného a budete muset přijít s odhadem, který vezme tuto práci v úvahu.
  • Definice „hotového“ je pravděpodobně nejasná: Kdy se to stane? „Hotovo“ jako v právě dokončeném kódování nebo „hotovo“ jako v „uživatelé jej používají“?
  • Bez ohledu na to, jak jste si vědomi všech těchto věcí, někdy vám díky "programátorské hrdosti" dáte/přijmete kratší časy, než jste původně předpokládali. Zvlášť když cítíte tlak termínů a očekávání vedení.

Mnoho z nich jsou organizační nebo kulturní problémy, které nejsou jednoduché a snadno řešitelné, ale nakonec je skutečností, že jste požádáni o odhad a očekávají, že dáte rozumnou odpověď. Je to součást vaší práce. Nemůžete jednoduše říci: Nevím.

Výsledkem je, že vždycky dávám odhady, které si později uvědomím, že nemohu splnit. Stalo se to bezpočet časů a vždy slibuji, že se to už nestane. Ale to ano.

Jaký je váš osobní postup pro rozhodování a odhad? Jaké techniky jste považovali za užitečné?

665
Sergio Acosta

Od Pragmatický programátor: Od Journeymana k Mistrovi :

Co říci, když budete požádáni o odhad

Říkáte: "Vrátím se k vám."

Téměř vždy získáte lepší výsledky, pokud zpomalíte proces a strávíte nějaký čas procházením kroky popsanými v této části. Odhady uvedené v kávovaru se (stejně jako káva) vrátí, aby vás pronásledovaly.

V sekci autoři doporučují následující postup:

  • Určete přesnost, kterou potřebujete. Na základě doby trvání můžete odhad odhadnout s různou přesností. Říká se, že „5 až 6 měsíců“ je jiné než „150 dní“. Pokud trochu vklouznete do 7. měsíce, jste stále docela přesní. Ale pokud sklouznete do 180. nebo 210. dne, ne tolik.
  • Ujistěte se, že rozumíte tomu, co je požadováno. Určete rozsah problému.
  • Modelování systému. Modelem může být mentální model, diagramy nebo existující datové záznamy. Rozložte tento model a sestavte odhady ze součástí. Ke každé hodnotě přiřaďte hodnoty a rozsahy chyb (+/-).
  • Vypočítejte odhad na základě vašeho modelu.
  • Sledujte své odhady. Zaznamenejte si informace o problému, který odhadujete, o vašem odhadu a skutečných hodnotách.
  • Dalším bodem, který lze do odhadu zahrnout, jsou vývoj a dokumentace požadavků nebo změn specifikací požadavků, vytváření nebo aktualizace návrhových dokumentů a specifikací, testování (jednotka, integrace a přijímání), vytváření nebo aktualizace uživatelských příruček nebo README se změnami. Pokud spolupracují 2 nebo více lidí, dochází k režii komunikace (telefonní hovory, e-maily, schůzky) a slučování zdrojového kódu. Pokud se jedná o dlouhý úkol, při výběru data doručení si vezměte v úvahu věci jako jiná práce, volno (dovolená, dovolená, nemocný čas), schůzky a další režijní úkoly.
395
Thomas Owens

Odhad softwaru je nejobtížnějším jediným úkolem v softwarovém inženýrství - těsnou sekundou jsou požadavky.

Existuje mnoho taktik pro jejich vytváření, vše založené na získání dobrých požadavků jako první. Ale když jsou vaše záda u zdi a oni vám odmítnou dát lepší podrobnosti, Fake It:

  1. Podívejte se na požadavky, které máte.
  2. Udělejte předpoklady k vyplnění mezer na základě svého nejlepšího odhadu toho, co chtějí
  3. Zapištevšechnyvaše předpoklady
  4. Nechte je sedět, číst a souhlasit s vašimi předpoklady (nebo, pokud budete mít štěstí, nechte je, aby se vzdali a dali vám skutečné požadavky).
  5. Nyní máte podrobné požadavky, které můžete odhadnout.

Je to, jako by moje matka zvykla vyhrožovat, když jsem byla malá. "Pospěšte si a vyzvedněte si nějaké oblečení, neboBuduvyzvedněte je pro vás!"

172
Fishtoaster

Udělal jsem vývoj pro chlapa, který byl velmi neoblomný, když chtěl přesné odhady. Usadili jsme se, což fungovalo velmi dobře, bylo toto:

  • Fakturoval jsem za celou dobu, kterou jsem strávil odhadováním. Přibližně 20-25% z toho, co jsem fakturoval, dosáhlo.
  • Provedl jsem velmi podrobné zkoumání úkolů. Žádné střílení z kyčle. Šel jsem do kódu a zjistil, jaké řádky je třeba změnit, jaké další části programu to ovlivní, kolik testování musím udělat, abych zajistil, že věci stále fungují. Odhadl bych každý kus v jednotkách .1 hodin (6 minut).
  • Poslal jsem mu svůj odhad pro každý úkol spolu s podrobným rozpisem.

20-25% fakturace zní jako hodně.

Ale požádal mě, abych změnil XYZ, myslel si, že to bude trvat asi 2 hodiny. Za 1 hodinu podrobného odhadu bych zjistil, že to bude trvat 8,5 hodiny. Rozhodl se tedy, zda to stojí za 8,5 hodiny platu. Pokud ne, pak ušetřil 7,5 hodiny nad tím, co by ho stálo, kdybych to udělal bez odhadu.

A pokud chce dělal chtít investovat 8,5 hodiny, podrobnou prací, kterou jsem provedl pro odhad, byla práce, kterou bych stejně musel udělat.

Zjistil jsem, že touto metodou jsem byl schopen přivést většinu úkolů včas nebo dokonce brzy, aniž bych musel těžce přeceňovat. Vzhledem k tomu, že čas byl tak nepatrně rozdělen, mohl jsem brzy vědět, jestli jsem uklouzl. Pokud narazím na zátarasy, abych po 3 hodinách mohl říct, že můj 8,5hodinový úkol bude trvat 12, mohl bych s ním o tom mluvit dříve, než uplyne více času, aby mohl znovu posoudit a vytrhnout tuto funkci, pokud se zajímal o náklady .

Byl to nikl a stmívání? Ne, podíval jsem se na to, když jsem mu dovolil použít své peníze tam, kde viděl největší přínos. A byl jsem rád, že jsem získal zkušenosti s odhadováním, které jsem byl vždycky hrozný.

145
Kyralessa

Během schůzek, na nichž dostáváme velmi široké a obsáhlé představy o tom, co by chtěli dělat, se často žádáme o „odhad odhadů“. Vždycky říkám: "Pokud chcete odpověď dnes, je to rok a milion dolarů. Pokud byste mi chtěli dát mnohem více podrobností a nějaký čas je zkontrolovat, pak vám mohu tato čísla pro vás upřesnit."

Téměř vždy pochopí.

65
Walter

Záleží na tom, k čemu je odhad.

Pro počáteční odhad na vysoké úrovni pro obchodní případ jsou klíčové věci:

  1. Rychlost. Ať už používáte jakoukoli metodu, musí být rychlá. Celá věc je, že zúčastněné strany si nejsou jisty, zda to stojí za to udělat projekt - proto potřebují čísla pro obchodní případ. Pokud by obchodní případ byl solidní, nepotřebovali by vaše odhady. Převážná část těchto projektů nepůjde, takže je důležité, aby při odhadování nebylo vynaloženo příliš mnoho úsilí.
  2. Dejte rozsah. Ať je to široké. Neměli jste čas analyzovat požadavky, workshop se zúčastněnými stranami, ověřovat předpoklady. Široká škála říká příjemci odhadu „Softwarové projekty jsou přirozeně složité a riskantní - pokud chcete správný odhad, musíte mi poskytnout více podrobností a více času“. Problém s udáním jediného čísla nebo úzkého rozmezí je v tom, že vás dostane do rohu stanovením očekávání před provedením jakékoli skutečné analýzy.

Najdu nejlepší techniku ​​pro výběr srovnatelného projektu, který se „cítí“ stejně. „Feel“ je zcela subjektivní - ale s tímto druhem odhadu mi moje zkušenost říká, že nenajdete objektivní měření. Pak poskytněte širokou škálu. Četl jsem některé knihy, které říkají, že rozsah od -50% do + 100% je dobrý, ale záleží na mnoha faktorech.

Podrobný odhad na nízké úrovni:

  1. Potřebujete základní linii. Pokud základní linie není stabilní, odhad nemá smysl.
  2. Nejlepší je zdola nahoru. Získejte podrobný rozpis práce, odhadněte jednotlivé komponenty a poté je rozbalte do většího počtu. Považuji zde plánování pokeru za skvělou techniku.
  3. Podmíněnost dokumentu. Jasně uveďte, kde jsou přidány případné případy (pokud existují). Je přidán do každé řádkové položky? Nebo k celému odhadu? Nebo ke konkrétním rizikům? Nebo není žádný?
  4. Uveďte své předpoklady. Ověřte co nejvíce v daném časovém rámci.
  5. Výslovně uveďte, co je v odhadu zahrnuto a vyloučeno. Je například zahrnuta recenze? Jsou zahrnuta technická zpoždění?
55
darreljnz

Nějaká rada z temné stránky od toho, kdo se tvrdě naučil.

Požadavky jsou nejasné. Nikdo neprovedl hloubkovou analýzu všech důsledků.

V tuto chvíli nedělejte odhad. Člověk neodhaduje, kolik vojáků je potřeba k vítězství v bitvě, aniž by tušil počet nepřátel. Odhad je proveden po skautingu. To je, pokud jste již s tímto nepřítelem bojovali.

Nová funkce pravděpodobně poruší některé předpoklady, které jste ve svém kódu provedli, a okamžitě začnete přemýšlet o všech věcech, které byste mohli muset změnit.

Pokud jste očekávali, že ostatní budou mít odborné znalosti v této oblasti, je vaší odpovědností.

Z minulých úkolů musíte udělat něco jiného a budete muset přijít s odhadem, který vezme tuto práci v úvahu.

Stejně jako výše, i pro neočekávanou práci, kterou vytvoří kamarád týmu přátel vedle vás, s téměř neexistujícím testovacím postupem, který způsobí, že se váš kód rozzáří, což nelze předem dokonale předvídat. Je to předpověď počasí.

Definice „hotového“ je pravděpodobně nejasná: Kdy se to stane? „Hotovo“ jako v právě dokončeném kódování nebo „hotovo“ jako v „uživatelé jej používají“?

Pochopte zde požadavek koncového uživatele, přemýšlejte jako uživatel. Nedělejte to, co vaši kolegové dělají, pokud odhadnou, že něco bude „uděláno“ jen proto, že některé základní funkce s pracovním postupem v barebone, které žádný uživatel nemůže tolerovat, je to, co považují za „hotovo“. Přemýšlejte o tom z uživatelského hlediska, protože to je vše, pro koho odhad provedete, tomu obvykle porozumí. Odhadujte na úplné požadavky na koncové uživatele, nikoli na technické požadavky barebone. A uvědomte si, že vaši klienti, kteří požadují odhady, budou naprosto nepřesní ohledně toho, jak oni dělají Word a rozumějí technickým aspektům toho, co říkáte.

Bez ohledu na to, jak jste si vědomi všech těchto věcí, někdy vám díky "programátorské hrdosti" dáte/přijmete kratší časy, než jste původně předpokládali. Zvlášť když cítíte tlak termínů a očekávání vedení.

Nedělej to! Zníte jako sebep motivovaný tvrdý dělník a možná ten, kdo se dá snadno donucovat.

Problém je v tomto: řekněme, že vy a Joe jste provedli odhady času pro stejný úkol (ale mezi dvěma samostatnými zaměstnanci, kteří nevěděli o obou odhadech najednou). Odhadujete statečně, „jeden týden“. Je v pořádku, myslíte si, že budete pracovat více než 100 hodin týdně, nezaplacené přesčasy. Teď máš zpoždění o tři dny.

Mezitím Joe odhaduje 5 měsíců. Myslíš si, že je to směšné, myslíš si, že to dokážeš za týden. Kolik Joe pracuje? 10 hodin týdně? ... kromě toho, že skončí včas přesně za 5 měsíců.

Hádejte, kdo je vnímán jako podvodník? Správně, vy. Joe vypadá jako skvělý dělník, teď se vám zdá nespolehlivý. Nezáleží na tom tolik, že jste dosáhli ještě lepšího výsledku za ~ 7% času, který Joe zabral. Záleží na tom, že jste byli 3 dny volna z týdenního odhadu.

Nikdy se nemýlte na straně přísnějšího odhadu. Err na straně odhadu uvolnění. Ve vaší společnosti je dobré jméno a nebude to založeno na délce vašich odhadů téměř stejně jako na přesnosti vašich odhadů. Je snadné být přesný s odhadem, který je příliš dlouhý, stačí získat více času na řešení problému a jeho lepší řešení. Odhad, který je příliš krátký, neponechává vůbec žádný dýchací prostor, buď se s ním zoufale setkáte, nebo jste zašroubovaný.

28
user204677

"Dva týdny!"

Vážně. Můj první odhad je vždy dva týdny. Protože mám nějaký bizarní mentální blok, který mě nutí myslet na to, že všechno zní jako dva týdny.

Snažím se to obejít, pokusit se opravdu myslet si o tom, jak dlouho si myslím, že něco bude trvat, pokusím se identifikovat všechna potenciální problémová místa a kousky, které vypadají příliš černě, abych mohl přesně odhadnout. A zkuste si uvědomit, že pokud je moje odpověď „Dva týdny!“, Pravděpodobně jsem tak neučinil.

Skoro každý dobrý manažer, kterého jsem se naučil rozpoznat „Dva týdny!“ jako odpověď, která vyžaduje mírné slovní pasák-facku v reakci.

18
BlairHippo

Existuje položka v blog , která popisuje, jak uchovávat záznamy o tom, jak přesné byly vaše předchozí odhady, a poté, když někomu řeknete „bude to dva týdny“, můžete se podívat na předchozí historii a uvidíte, jak dlouho to vlastně trvalo naposledy, když jste řekl: „budou to dva týdny“.

Nezkoušel jsem to sám, ale rád bych viděl, jak přesné jsou moje odhady.

17
Richard

Závisí to na organizaci a způsobu použití odhadů.

Pokud je odhad pouze poskytnout obecnou představu o tom, kdy bude připraven, mohu obecně udělat rychlý odhad na základě svých zkušeností. Často zahrnuji jakoukoli nejistotu nebo možné variace s odhadem spolu s tím, jak mohou změny ovlivnit jiné oblasti systému a rozsah požadovaných regresních testů.

Pokud je odhad použit pro cokoli smluvního nebo ve scénáři, kde je vyžadováno přesnější načasování, udělám úplné rozpis práce. To je více práce a vyžaduje důkladnější přemýšlení o designu a změnách systému, ale je mnohem přesnější, zejména u větších kusů práce.

V obou případech je klíčová pokračující komunikace. Pokud narazíte na něco neočekávaného, ​​oznamte to v té době místo čekání do termínu. Pokud požadavky nejsou jasné, ujistěte se, že dokumentujete své porozumění a funkčnost, kterou plánujete splnit. To je také užitečné pro všechny předpoklady, které provedete. A pokud jde o konkurenční priority, když jedna část práce narazí na druhou, bude jasné, jak to ovlivní plán.

11
g .

Odhady za co? Malé úkoly nebo kompletní řešení.

Ten druhý zřídka dělám, ale pak jen hádám, přidám trochu, nechám manažera přidat trochu a udělá to z řady, s malou notou vedle toho uvede, že výše je hádání.

Malé úkoly - Plánování poker Zjistil jsem, že fungují opravdu dobře (není dokonalý, některé úkoly 1pt zabraly mnohem déle a některé úkoly 5pt trvalo minuty, ale nakonec se to všechno projeví).

9
mlk

Představte rozsah na základě toho, co dnes víte. Použijte Kužel nejistoty a zadejte rozsah kolem vašich počátečních odhadů.

Každý týden vypočítat, kolik zbývá udělat, přehodnotit na základě toho, co víte. Jakmile budete mít dostatek velikosti vzorku toho, kolik práce prochází každý týden, poskytněte 90% interval spolehlivosti toho, co zbývá, aby vám poskytl (obvykle) stále se zužující časové období v průběhu projektu a množství zbývající práce (doufejme, že ) se zmenší.

7
Paddyslacker

Sebevědomě. Nemohu říct, kolikrát jsem dokončil úvodní schůzku s klientem tím, že jsem nedal profesionalitu při odhadování. I když vyfukujete čísla ze vzduchu, ujistěte se, že máte vždy nějaký odhad. To znamená, že buďte opatrní, abyste se neodhadli do díry. Různé věci vyžadují různé množství času, úsilí a zdrojů, aby se daly dohromady. Zde je dobrý způsob, jak to udělat:

Them: Kolik to bude stát?

Me: Záleží na tom, co chcete, abych udělal. Obecně začínám tento druh projektu kolem $ X.

7
Moshe

Odhadování se někdy stává pro vás a váš tým obrovskou výzvou, zejména když hovoříme o odhadu softwarového projektu.

Jakmile jsme se rozhodli podělit se o své zkušenosti a znalosti o procesu odhadování softwaru a definovat čtyři různé typy odhadů :

  • míček
  • odhad služby
  • odhad funkce
  • složený odhad

Tyto typy jsou samozřejmě odlišné. Ballpark je to, čemu se často říká „guesstimate“. Takže je to přibližné číslo nebo rozmezí, které poskytuje obecnou představu o nákladech a které může potenciálnímu subjektu pomoci při rozhodování, zda by chtěli pokračovat v diskusi.

Na začátku projektu klienti zpravidla potřebují postavu s míčem. A naše doporučení je: diskuse o projektu a poskytování údajů o počtu parků by měly být jen kroky k přijetí složeného odhadu (což je flexibilní, lze využít odhad komponentního typu pro celý vývojový proces. Není třeba znovu odhadovat od nuly, pokud chcete přidat, odebrat nebo nahradit funkce, služby atd.).

Každý by měl mít na paměti rizika spojená s vývojem softwaru, který odhaduje: podceňování, nadhodnocování, scénář celkového epického selhání atd.

Více si můžete přečíst na našem blogu!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Doufám, že vám tyto informace pomohou!

6
Olha

Vždycky nakonec dávám odhady, které si později uvědomím, že nemohu splnit. Stalo se to bezpočet časů a vždy slibuji, že se to už nestane.

Zní to, jako by vás žádali o závazek, ne o odhad. To jsou různé věci, ale pokud dokážete spolehlivě spravovat závazky, opravdu to pomůže vaší důvěryhodnosti a kariéře.

Několik rad na základě mých ~ 10 let zkušeností:

  • Vždy uveďte rozsah (tj. Dolní a horní mez). Tím se sdělí vaše úroveň nejistoty
  • Pokud máte velmi velkou nejistotu, požádejte o odklad (např. 1 den na provedení analýzy a poté zadejte přísnější rozsah)
  • Pokud je úkol příliš velký, rozdělte jej a poskytněte rozsah pro každý kus
5
jamesfmackenzie

Nejprve, kdyby mi byl přidělen nějaký úkol, rozdělil bych to na dílčí úkoly. Odhadoval bych čas pro jednotlivé dílčí úkoly a pravděpodobně u dílčích úkolů bych mohl najít problematickou oblast, a proto bych mohl předpovědět, jak dlouho to bude do určité míry.

Ale přesto by všechno plánování pomohlo jen do určité míry. Přesné problémy najdete, až když začnete kódovat

4
Gopi

Pokud pro stejného šéfa nebo klienta děláte mnoho projektů, můžete se pokusit odhadnout v širokých úsecích složitosti namísto týdnů nebo měsíců, případně ve velikostech trička. Identifikujte několik minulých projektů a přiřaďte jim velikosti S, M, L, XL.

A pak se zeptejte sami sebe: jaký projekt zní podobně svým rozsahem? A pak místo odpovědi s „2 měsíci“ můžete odpovědět „zní mi jako L“ (nebo ať se ukáže vaše kalibrace pro projekt).

To je docela snadné pochopit a je také zřejmé, že v těchto odhadech existuje spousta nejistoty.

Poté, když se změní požadavky, můžete říci „tato změna způsobí, že to zní více jako XL“.

1
moritz

Trochu pozdě, ale když jsem byl v armádě, dostali jsme pokyny, abychom použili PERT ke stanovení odhadů. Vyžaduje to určité zkušenosti ve vašem oboru a úkol, který máte po ruce. Překvapivě přesné bylo určení určeného času dokončení při údržbě a opravách elektronických zařízení (složitá rádia a satelitní komunikační zařízení), kde může být během běžného provozu chybné nebo nalezeno jakékoli množství věcí a je třeba je opravit. Odhady byly důležité, protože jiné jednotky mohou být nefunkční, dokud nedostanou zpět své komunikační zařízení. Ten, který jsem použil, je tento Bezplatná online kalkulačka PERT

0
xtreampb