it-swarm-eu.dev

Je agilní přístup příliš vhodnou omluvou pro kovboje

Věřím, že agilní přístup je nejlepší pro projekty, kde jsou požadavky nejasné a je zapotřebí hodně interakce, aby se pomohlo utvářet nápady koncových uživatelů.

Nicméně ... Ve své profesionální práci se stále dostávám ke společnostem, kde se používá „agilní“ přístup jako omluva, pokud jde o proč nebylo vynaloženo úsilí na přední design;, když jsou požadavky dobře pochopeny.

Nemohu si pomoct, ale pomyslím si, že kdyby se agilní přístup nenacházel, seděl bych tady se specifikací na vysoké úrovni v Nice a nemusel jsem každý druhý den opakovat stejnou obrazovku a funkčnost, když se něco jiného vynoří. a tak na to nemyslel.

Jsou výhody agilních metodik opravdu dost na to, aby vyvážily omluvu za to, že je chromý, že dává technickým vedoucím kovboje?

Aktualizace: Ironicky jsem nyní certifikovaným Scrum Masterem. Jeden z příspěvků prezentovaných na kurzu Scrum poznamenal, že nejlepší vývojový proces byl ten, kde byl jediný odborník nebo guru, který dělal rozhodnutí o návrhu, ale který má zjevné slabiny. Scrum přesouvá odpovědnost za produkci kvalitního softwaru na „tým“, což znamená, že nestandardní tým se může dostat pryč s vyfukováním špaget, které se, jak se domnívám, neliší od ostatních agilních a neagresivních vývojových procesů.

73
sipwiz

I'm Glad it has a name

Věřím, že pokud používáte agilní vývoj jako omluvu pro programování v kovbojském stylu, pak opravdu nesledujete agilní vývoj. Kovboji budou vždy kovboji, bez ohledu na to, jaký proces jim dáte.

87
Dean Harding

Za agilní praktiky není agilní více než BDUF. Problém spočívá v disciplíně nebo její nedostatečnosti při uplatňování praktik. Účelem postupů BDUF je identifikovat směr projektu a předem určit rizika. Účelem agilních praktik je udržovat stav vývoje dostatečně pružný, aby rychle změnil směr. Agilní projekt by mohl připravit velmi podrobné uživatelské příběhy, aby si tým byl vědom budoucích směrů a stále si vybral pouze 2 nebo 3 iterace, aby se plně implementoval. Problém zůstává stejný bez ohledu na použitou metodologii: správa nechává kovboje běžet amuck.

[BDUF: Velký design vpředu]

20
Huperniketes

Agilní, jako cokoli, lze použít k pokrytí špatného chování nebo k pokusu vyřešit problém, o kterém si tým myslí, že za ně není zodpovědný.

Kouzlo v některých Agilních metodikách, jako je Scrum, je, že poskytnou velké zviditelnění problémů v organizaci. Včetně problémů v týmu!

Poté budete mít příležitost je vyřešit, jakmile se objeví.

Pokud problém spočívá na kovboji, bude to po první iteraci velmi viditelné. Pokud je problém někde jinde, uvidíte to také velmi brzy.

13
user2567

Kupodivu, z „agilních“ projektů, do kterých jsem se zapojil, se zdá, že je spíše jako výmluva managementu přeskočit fázi shromažďování požadavků než kovbojská touha jednoduše začít kódovat. Moje projekty byly nesmírně frustrující, protože nemáme mají žádní koncoví uživatelé, se kterými by bylo možné komunikovat. Místo toho máme ředitele, který mluví s prodejem, aby zjistil, co si zákazníci myslí, pak zavolá schůzku a popisuje ji manažerům, kteří pak začínají přiřazovat úkoly vývojářům. Na „dobrém“ projektu bychom mohli mít prezentaci PP), na kterou se však můžeme odkazovat, ale obvykle ukončujeme utrácení denních schůzek scrum s otázkou, jak má některá funkce fungovat, a manažer si otázky zapíše a ptá se ředitele. Je to obrovská ztráta času - ale je to „agilní“!

12
TMN

Nebudu říkat, že jsem fanouškem vodopádu, protože se také zabývám stále frustrujícím rozsahem, ale vždy jsem viděl Agilní jako ústupek problému, ne účinný způsob, jak proti němu bojovat. Dobrý design s časným opakovaným testováním a spoustou prototypů papíru se zdá být mnohem účinnější.

7
Morgan Herlocker

Vidím obranu Agile Development, která říká, že není zodpovědná za selhání způsobená kovboji. Úspěch s Agile vyžaduje pečlivost a inteligenci.

To se zdá rozumné, pokud použijete stejnou úlevu na jiné metodiky. Pokud nemůžete vinit Agile za selhání projektu způsobená kovboji, nemůžete vinit neagresivní metodiky za selhání projektu způsobená kovboji.

Můžeme se tedy dohadovat o tom, zda existuje souvislost (nikoli příčinná souvislost!) Mezi Agile a kovboji. Domnívám se, že existují pouze neoficiální důkazy. Je to vnímáno jako dobrý způsob, jak se obejít s kovbojskými praktikami, aniž by byl odhalen vedením?

Samozřejmě, pokud přijmeme, že kovboji nemusí být rovnoměrně rozptýleny v rámci metodik, a uznáváme, že kovbojové podkopávají úspěšné použití procesu, velmi obtížně jsme otestovali, zda je proces úspěšný. Tvrzení, že jeden proces je lepší (v kontextu), se blíží nezpochybnitelnému. To je jeden z problémů, který mě nutí zahanbovat hlavu o své profesi - nedostatek vědeckého opory mnoha tvrzení.

(Mimochodem, nesnáším volat alternativu (y) k Agilnímu „vodopádu“, protože vodopádové procesy se zdají být slámy, které každý útočí, ale jen velmi málo lidí ve skutečnosti použilo bez jakékoli iterace.)

6
Oddthinking

Agilní je v pořádku, pokud pracuje pro váš tým.

Příliš mnoho z nich to prodává jako způsob, jak přeměnit špatný tým na dobrý tým, a tak to prostě nefunguje. Nemůžete brát špatné lidi a použít postup, který jim náhle pomůže.

Mám rád mnoho nápadů, které stojí za agilností, ale selhání, které vidím znovu a znovu, je to, že manažeři tlačí přísnou sadu „agilních procesů“, která letí tváří v tvář celé koncepci agility, že týmy by měly být samy sebe -organizace.

Co se týče „kovbojů“, zjistil jsem, že pro všechny agilní týmy, které jsem byl, procesy slouží k tomu, aby je zpomalily více, než aby je nechaly divočiny. Nikdy jsem nezažil situaci, kdy by agilní sloužil povolení „cowboy coder“.

U dobrých týmů to vypadá dobře (opět se zdá, že většina procesů funguje dobře, když máte dobrý tým, vtipné, jak to funguje, že?).

U ostatních týmů podle mých zkušeností nikdy špatným lidem nepomohlo lépe, ale někdy slouží k zabodnutí produktivních lidí.

Celkově si myslím, že je důležité vybudovat dobrý tým, říct jim, co potřebujete, a pak se dostat z cesty. Nemyslím si, že použití nějakého řetězce buzzwords pravděpodobně vyřeší problém špatného týmu.

(Pokud jste na to přišli výše, nejsem ani fanouškem "Capitol-A Agile". Na druhou stranu si nemyslím, že by to povzbudilo i kovboje.)

5
TM.

Agilní, když se to dělá správně, by mělo mít za následek reining v „kovbojských“ technických vedeních a „hrdinských“ programátorech. Pokud tento efekt nepozorujete, může to být známkou toho, že v agilní implementaci chybí něco důležitého.

Chci dodat, že „Agilní“ je opravdu rozhraní (používám zde objektově orientovanou metaforu) a nemůžete jej vytvořit. Pokud je vaše konkrétní implementace XP , pak se musíte řídit spoustou technických praktik se spoustou disciplíny, což ponechává malý prostor pro programování kovboje. Další možností je, že týmová práce dobře organizovaného týmu Scrum bude udržovat na uzdě.

3
azheglov

Cowboy kodéry také inklinují psát kód, který není příliš testovatelný, a oni nemají rádi psaní testů. Myslím, že to, že každý dělá TDD, může pomoci panovat v kovbojském postoji a přimět vývojáře přemýšlet o architektuře o něco více. Žádná metodologie není samozřejmě dokonalá.

3
Matt H

V současné době pracuji v obchodě, kde je tomu tak, kromě toho, že jde spíše o organizační kulturu než o konkrétní jednotlivé kovboje.

Organizace vždy pracovala na relativně volném „neformálním agilním“ přístupu. Neřekl bych, že je to opravdu Agilní, je to spíše „Agilní ve jménu“, ale v praxi jen obyčejná neexistující metodologie. Různé týmy fungují odlišně, ale protože celková organizační kultura nemá zavedenou žádnou jinou metodiku než velmi uvolněný proces „Agile in name only“ - je to celkově relativně kovbojské a chaotické - zejména při integraci (a je toho hodně) ).

Morální příběh je - Ano, to se stává. Kdybych v tuto chvíli hledal práci, byl bych s tím velmi opatrný. Pokud obchod prohlašuje, že je Agilní - položil bych v rozhovoru několik docela náročných otázek, abych zajistil, že bude skutečně následováno více než jen nesprávné pojmenování Agile.

3
Bobby Tables

Zjistil jsem, že uživatelé nám mohou poskytnout zpětnou vazbu, pouze pokud mají aplikaci, kterou mohou použít, obrazovky, na které mohou zadávat data. Teprve pak skutečně rozumí tomu, co jsme se snažili říci v dokumentech s požadavky (které klienti podepisují, ale každý má svou vlastní verzi významu). Pokud se nejedná o agilní vývoj, bude to projekt vodopádu, který překračuje rozpočet, ale aplikace se změní, jakmile jej doručíte. Vaše první verze není ničím jiným než prototypem pro uživatele, aby diskutovali o tom, jaké požadavky by měly být. Raději to říkám agilní než přes rozpočet.

2
Veronica Buitron

Myslím, že je to pravda, v některých prostředích se Agile používá jako omluva pro žádnou disciplínu. Skutečným problémem je, že jsme ztratili ze zřetele důvod, proč máme nějakou metodologii. Osobně mám pocit, že metodika je architektonickým problémem v tom smyslu, že architektura systému by měla řešit nefunkční atributy kvality. Metodika by se měla zabývat některými stejnými atributy (udržovatelnost, produktivita rozvoje, přenos znalostí, et al.)

Považování metodiky za kontrolu atributů procesu znamená několik věcí: 1) bez metrik nemůžeme porovnat účinnost jedné metodologie s jinou, 2) je třeba učinit aktivní rozhodnutí o tom, jaké atributy jsou důležité (dodací doba vs kód kvalita vs. přenos znalostí).

Aniž bychom měli jak metriky, tak hmatatelný cíl, jednoduše jsme si vybrali metodologii jako naše „kouzelné peří“, že pokud se budeme držet napjaté, budeme schopni dodat software.

Nyní mluvčí o agilnosti, XP, Scrumu atd. Mluví o křehkosti této konkrétní kategorie metodik. Argument je: proč použít metodiku, kterou může sabotovat jeden jedinec postrádající disciplínu, aby dodržoval všechna pravidla? Otázka je platná; to je však příznak, nikoli příčina. Pokud je definována, testována a včasná zpětná vazba přesná a smysluplná (to je těžká část) sady procesních metrik, myslím, že objevíme, že konkrétní metodologie nemá s úspěchem co do činění. (Neočekávaně jsem viděl úspěšné projekty využívající nesčetné množství metodik a dvakrát tolik metod selhalo při použití stejných metodik)

Jaké jsou tedy metriky? Liší se od projektu k projektu, týmu k týmu a čas od času. Užitečné, když je rozvrh doručení důležitý, ten, který jsem osobně použil, je dovednost a kvalita odhadu. Většina vývojářů dokáže přesně odhadnout úkoly, které jsou týdenní nebo kratší. Jedním z přístupů je tedy rozdělit projekt na úkoly jeden týdenní vývojář a sledovat, kdo provedl odhad. Jak projekt pokračuje, mohou změnit své odhady. Po dokončení úkolu, pokud je jeho vypnutí o více než 10% (1/2 denně), zacházíme s tím stejně jako s chybou - identifikujeme, proč byl odhad vypnut (tj. Nebyla zohledněna databázová tabulka), identifikujte nápravná akce (tj. zapojte do odhadu DBA) a poté pokračujte. Pomocí těchto informací můžeme vytvořit metriky, jako je například počet odhadovaných chyb týdně, počet chyb na vývojáře, počet chyb na KLOC, počet chyb na vývojáře-KLOC atd. Zveřejnění těchto čísel na týmové wiki poskytuje vážný sociální tlak a z manažerského hlediska můžete po několika týdnech vygenerovat prediktivní model následných vývojových týdnů.

No a co? To je, když přijdou metodiky - pokud máte prediktivní model, který nesplňuje vlastnosti procesu, můžete se rozhodnout přidat nebo odebrat některý aspekt metodologie a zjistit, jak to ovlivní váš model. Je pravda, že nikdo nechce hrát s vývojovým procesem ze strachu z neúspěchu, ale již selháváme trvale vysokou a předvídatelnou rychlostí. Provedením jednotlivých změn a změřením výsledku můžete zjistit, že Agile je perfektní metodologie pro váš tým, ale stejně snadno byste mohli najít RUP, vodopád nebo jen hodge-podge nejlepších postupů, které by byly ideální.

Můj návrh tedy umožňuje přestat si dělat starosti s tím, co nazýváme tento proces, zavádět kontroly, které jsou relevantní pro naše cíle vývojového procesu, a experimentovat s různými technikami, které tento proces vylepšují.

2
TEC

Cowboy kodéry jsou dobré, protože se jim líbí dělat věci rychle. Často se nezajímají o problémy s velkým obrázkem ani o kvalitu kódu, a proto je „cowboy coder“ často epithet. Jejich metody zmírňují rizika nákladů na příležitost při pozdním dodání projektu.

Non cowboy coders rádi dělají svou práci bezpečným, disciplinovaným a řádným způsobem. Líbí se jim stavět to správně a jednou to budovat. Je známo, že navždy shromažďují informace, zvažují co-ifs, produkují velké dokumenty, které nikdo nečte, a doručují systémy pozdě nebo velmi pozdě. Jejich metody se snaží zmírnit rizika nekvalitního softwaru.

Brilantnost agilních metodik spočívá v tom, že využívají silné stránky obou typů kodérů tím, že nutí krátké časově omezené pracovní iterace, které žádají kodéry, aby rychle produkovali malé vysoce kvalitní práce. A každá iterace zmírňuje jak riziko nákladů na opožděné doručení, tak i riziko nekvalitního softwaru.

1
Jay Godse

Je zábavné, jak si o sobě nikdo nepovažuje cowboyoví kodéry. Sázím se, že mnoho plakátů je nebo bylo jedno;)

1
user5206

Seděl bych tady se specifikací na vysoké úrovni v Nice a nemusel jsem každý druhý den opakovat stejnou obrazovku a funkčnost, jako by se něco jiného vynořilo a tak na to ani nenapadlo.

Zdá se, že se to shoduje se zkušenostmi mého kolegy z projektu „agilního“, na kterém je (nikdy jsem na jednom sám nebyl): je požádán, aby napsal část kódu nějaké specifikaci, pak stejně jako dokončil testování a je připraven přejít na nový požadavek, který vyžaduje, aby jej změnil a znovu vyzkoušel. Považuje to za frustrující.

Nejsem poblázněný hbitý, mám podezření, že tým se nedaří agilně - ale jak říkáte, termín „agilní“ může kovboji někdy použít k tomu, aby přesvědčil špičaté vedení, že napůl pečený design je spíše pozitivní než negativní .

1
Tony Andrews

Důvod, proč agilní staví velmi malý důraz na přední design/specifikace, není jen proto, že se mohou požadavky změnit. Hlubší důvod je, že i když jsou požadavky stabilní, specifikace bývají:

  • nesprávně - nezachycují požadavky.

  • nekonzistentní - prošpikované rozpory, protože obsahují dostatek informací, aby je spisovatel/čtenář nemohl zachytit.

  • oddělený - nezahrnují hodnotnou zpětnou vazbu z běžícího (i když degenerovaného) systému.

0
Itay