it-swarm-eu.dev

Získání neprogramátorů pochopit vývojový proces

Při zahájení projektu pro společnost, která není primárně programovací společností, je jedním z očekávání, že na konci je hotový produkt bez jakýchkoli chyb a okamžitě provede vše potřebné. To je však zřídka případ.

Jaké jsou způsoby, jak řídit očekávání a vysvětlit neprogramátorům, jak se vývoj softwaru liší od jiných typů vývoje produktů?

66
user8

Téměř všichni s počítačem se v dnešní době setkali s pojmem „chyby“, takže tam můžete začít. „Jaký je ten nejnepříjemnější způsob, jak na vás aplikace někdy selhala? Vynásobte to deseti a budete mít zkušenosti našich uživatelů, pokud nebudeme věnovat dostatek prostředků na testování a údržbu.“

A nepodceňujte hodnotu navázání dobrého pracovního vztahu s neprogramátory. Pokud dokážete, že váš úsudek může být důvěryhodný, vezmou vás vážně, když vydáte poplach, že X bude velkolepě selhat, pokud neuděláte Yto, i když úplně nerozumí vašemu uvažování.

34
BlairHippo

Jedním z přístupů, který jsem považoval za úspěšný, je tento:

Všichni víme, že počítač dělá pouze a přesně to, co je řečeno.

Programování je způsob, jakým řekneme počítači nyní co děláme, co dělat později.

To znamená, že způsob, jakým se vaše chování chová nyní, je způsoben kombinovanými úmysly každého, kdo napsal jakýkoli kód, který běží na vašem počítači. Když vezmete v úvahu složitost operačního systému, ovladačů, programovacího prostředí, knihoven atd., Je snadné vidět, že ve většině systémů musí být zapojeno více než 20 tisíc lidí a že jich může být více než 100 tisíc.

Kód napsaný každou osobou odráží jejich vlastní pochopení, motivaci, záměr a schopnost. Vzhledem k tomu, že bezchybné fungování systému vyžaduje, aby všechny kódu napsaného těmito 20k lidmi interagovalo bez chyb - že všechny kódu musí souhlasit s významem a interpretací kódu požadované chování, není překvapující skutečnost, že máme chyby, ale že jich máme tak málo.

28
Bevan

IMO, zjistil jsem, že transparentnost, kterou nabízejí agilní procesy (např. Scrum, Crystal atd.), Vede k tomu, že vývoj funguje průměrnému zúčastněnému, dlouhou cestu.

12
Brandon

Vysvětlení metaforou je netěsná abstrakce, ale zde jsou některé nápady, které pro mě často pracují:

Všimněte si, že žádné z těchto vysvětlení neomlouvá nedbalá práce.

Počítačový program považujte za stroj, kde každá proměnná je pohyblivou součástí. Díky tomu je i triviální program stroj složený ze stovek pohyblivých částí.

Když to selže, opírám se o skutečnost, že ačkoli je matematicky možné dokázat, že program nemá žádné chyby, vyžaduje to obrovské množství času a nestojí za námahu.

Nakonec se ptám, jestli se Intel a Microsoft nedokážou vyhnout chybám, jak od nás očekávají?

3
KevDog

Tradičním způsobem, jak to říci, je trojúhelník řízení projektů: tři konkurenční kritéria, která se týkají rozsahu, nákladů a harmonogramu; obvykle vyjádřeno jako „levný, rychlý, dobrý - vyberte dva“.

Na konci procesu návrhu, vývoje a nasazení je naprosto rozumné očekávání, že produkt je bez konstrukčních vad a pracuje se specifikovanou funkčností. Stejné očekávání je naprosto nepřiměřené s ohledem na projekt, proces nebo profesi.

Co profesionál založený na vědách, tvrdý nebo měkký, neprochází procesem zkoumání, formování nepřesných a nepřesných konceptualizací, sledováním méně než optimálních (nebo prostě zjevně nesprávných) taktik, objevováním toho, co funguje pomocí pokusů a omylů, a opakováním proces znovu a znovu, dokud nedojde zdroje nebo dokud nebude dosaženo dostatečné úrovně výkonu?

Žádný proces není nikdy bez závad, i když se může asymptoticky přiblížit k vyšší úrovni kvality.

To platí o lékařské profesi, kde taktika často zahrnuje hádání a protokoly, a hodně z činnosti je v podstatě ladění většinou wetware stroje. Platí to o stavebnictví a architektuře, kde musí být aplikace nových inženýrských materiálů ověřeny v terénu a po letech provozu mohou náhle selhat i přes přísné dodržování standardů. Platí to pro automobilový průmysl, kde věk a změny provozních podmínek obvykle ovlivňují výkonnost až do okamžiku poruchy, a to bez zavinění použitých inženýrských nebo opravárenských služeb. Vývoj softwaru se ne zásadně liší od těchto profesí v takových ohledech, má jen větší část svého zaměření zapojeného do vymýšlení nových, účelných strojů.

2
jerseyboy

Odpověděl jsem na podobnou otázku podrobněji , ale podstata je: „Programování je jako stavba továrny nebo montážní linky.“

2
Huperniketes

Můžete to porovnat s něčím, co vidí, a pokud je to možné, používat každý den.

Například automobil. Automobily začínaly s mnohem méně rafinovanými a spolehlivými zařízeními, než jaké máme dnes. Zatímco auta byla vyrobena více než 100 let, ale software asi o polovinu tak dlouho. Auta jsou k dispozici se značným přizpůsobením, některé jsou zahrnuty v ceně (jako je výběr barvy), jiné jako velikost motoru, typ převodovky, kolo/pneumatika, úroveň výbavy jsou významnými řidiči nákladů.

Existuje mnoho ovladačů funkcí, kvality a nákladů pro automobily a pro software. Pak můžete diskutovat o tom, jak softwarová technologie, dostupnost odborných znalostí, možná i tam, kde je postavena, bude mít velký rozdíl. Správně vývojové cykly (například roční modely s malými změnami, změny karoserie/motoru/platformy přibližně každé tři roky) jsou poháněny kombinací potřeb zákazníků a komplexním procesem návrhu. Některé produkty začínají vypadat maličko a neohrabaně (vymyslet Honda Accord), ale každý rok se vylepšují, dokud nejsou hodnoceny nejlépe.

Auta mají stahování (často mnohem nákladnější než aktualizace softwaru) a postupná vylepšení ve formě provádění změn v jejich seznamech dílů (opravy chyb v opravách) a často potřebují dlouhodobou podporu (zpětná/dopředná kompatibilita). Velká část nákladů na vaše auto přijde poté, co ji odvezete domů. Velká část nákladů na software přichází po vydání prvního produktu, když aktualizujete a upgradujete zákazníky.

V některých případech můžete odkazovat na známé produkty, které zahrnují software nebo jiné softwarové produkty. Například telefony mají cyklus vydání a aktualizace a metody přidávání funkcí po počátečním prodeji, aby se zvýšily příjmy. Telefony jsou skvělým příkladem kompatibility dopředu/dozadu. Příliš mnoho a lidé nevyhodí ten starý, aby si koupili nový. Příliš málo a zákazníci zoufale potřebují telefon, který nenávidí dříve, než bude smlouva uzavřena.

Produkty jako Windows, Microsoft Office, webové prohlížeče a webové stránky jsou software, který lze použít v diskusích. Byly aktualizovány v ročních nebo tříletých cyklech, ale mohou mít častěji automatické aktualizace. Mají chyby a bezpečnostní díry, které ovlivňují zákazníky v různé míře, ale jsou součástí krajiny i přes naše nejlepší úsilí. Zákazníci mohou získat opravy zdarma, ale obvykle platí za vylepšení, často jako balíček, někdy jako samostatný modul nebo prostřednictvím licenčního klíče.

Přední výrobci v oboru, jako jsou Microsoft, Apple, Google a Amazon, dodávají uživatelům relativně levné zákazníky. Mají však obrovské náklady, které těmto produktům umožnily. Jejich zkušenosti ukazují, že software je drahý, ale cenný a ziskový. Často kompromitují mezi kvalitou, mají všechny funkce, které chtějí, a dostat se na trhy, když je načasování správné. Ne každý produkt, který vyrábějí, je úspěšný, a někdy přeměňují psy na vítěze přejmenováním, vylepšením marketingu a prodeje nebo snížením ztrát a využitím toho, co se naučili v pozdějších produktech.

0
DeveloperDon

Pokud máte nějaké zkušenosti s vývojem softwaru hi-rel, jako je řízení jaderného reaktoru, komunikace v hlubokém vesmíru nebo lékařská implantační zařízení (atd.), Můžete vysvětlit, jak se struktura nákladů a dodacích lhůt pro tuto úroveň správy náplastí a QA může být o více než to, co si typické firmy mohou dovolit pro své softwarové projekty.

0
hotpaw2

Možná je zkuste projít jednotlivě nebo v malých skupinách ideálně, použijte případy softwaru, který musíte vyvinout. Při popisu případů použití identifikujte body v případě, že by se mohly vyskytnout různé věci (neočekávané, ale nikoli nepřiměřené případy). Začněte je vyjmenovávat, žádejte o objasnění a ilustrujte všechna rozhodnutí a pokyny, které je třeba učinit nebo se vypořádat, a kompromisy, které se při tom činí. Pokračujte, dokud nejsou pahýl a nemohou vám odpovědět. Nechte je pochopit, že to, co s nimi nyní děláte, je přesně to, co děláte celý den, pravděpodobně sami, pravděpodobně mnohem méně jasným směrem, a to jak při rozhodování o kurzu, tak při psaní kódu, pro stovky či tisíce používat případy, které může nebo nemusí být stanoveny kýmkoli. A když existuje případ, o kterém jste si nemysleli, nemůžete zaručit, co program udělá. Možná to dělá "správnou" věc, možná na vědomí. A to je chyba. A proto psaní softwaru vyžaduje čas. Čím méně času máte, tím méně případů jste měli možnost zvážit a vyhovět, a tím pravděpodobnější je, že program nebude dělat „správnou“ věc za neznámých okolností.

0
huntmaster

Náklady a čas.

Čas

Nastavte očekávání, že byste X doručili v čase Y. Nebude mít nic víc, nic méně. Pak jim řekněte, co bude mít příští verze v kolik hodin. Nejprve by mohli být překvapeni, když věří, že stavba X zabere Y množství času - zde vysvětlíte čas a složitost vytváření softwaru. Pokud nejsou překvapeni, buď jste odhadli velmi méně času, nebo věděli lépe, než si myslíte o budování softwaru.

Cena

Toto je z knihy Steve McConnel's Code Compete (citace z paměti, takže promiňte, kdybych to nemohl sdělit se stejným účinkem) - Je snadné pro zákazníky požádat o nové funkce. Jako produktový manažer byste neměli říkat, co zákazník požaduje. Měli byste odhadnout, kolik úsilí a nákladů je zapotřebí k vytvoření této nové funkce. Pomalu pochopí, že nová funkce opravdu nestojí za peníze/čas nebo že je ani nemusí. Nenavrhuji, abyste použili tuto zbraň k vystrašení, ale používejte ji upřímně a mohlo by to pomoci při řízení místa domů.

0
Sundeep