Agilní myšlení versus agilní mechanismy

https://flic.kr/p/bkcj5q

Opakovaně zjišťuji, že softwarové týmy se příliš zaměřují na mechanismy a ztrácí ze zřetele základní princip. To platí zejména o agilních metodikách. Metody, jako je Scrum, mají tolik mechanismů, že ti nové agilní úplně ztratí. Původně jsem to napsal jako e-mail svému týmu, abych objasnil, jaký je můj názor na Agile, ale poslal jsem ji nyní tolika lidem, že když vezmu radu Scotta Hanselmana, přeměním to v blogový příspěvek.

Považuji se za trochu kvalifikovaného, ​​abych poskytl tento vhled. Jsem agilní praktikující z dob, kdy se Agilní vývoj týkal pomocí šroubováku - rozebrat vlastní kabiny a vytvořit otevřený plán sezení!

Na začátku své kariéry jsem pracoval s lékařskou softwarovou společností. Vytvořili jsme stolní software pro prohlížení obrázků, který byl nainstalován na Doktorově stolním počítači v nemocnicích. Proces nasazení zahrnoval cestování s CD do jiného města a instalaci stolních počítačů a obrazových serverů. Byli jsme podrobeni schválení FDA, takže jsme museli stavět podle specifikací, které prošly schválením FDA. To vytvořilo ideální prostředí pro metodiku vodopádů shora dolů. Všechny specifikace byly zapsány, schváleny, podepsány a my jsme stavěli pouze na tyto specifikace a tyto specifikace. Teprve když dev tým začal cestovat s instalačním týmem a pozorováním lékařů používali náš software, jsme si uvědomili, že to dokážeme mnohem lépe, pouze pokud budeme moci se zákazníkem hovořit dříve v cyklu. Zakódovali jsme přesné specifikace a dodali něco, co nebylo tak užitečné, jak by to mohlo být. Tento obrázek ukazuje některé z mých zkušeností.

Jak se vývoj softwaru může zhoršit z https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Kolem tentokrát můj tým slyšel o něčem zvaném Agilní manifest a praxi zvané Extrémní programování. Vzhledem k tomu, že byl podepsán průmyslovými veterány, jejichž knihy jsme aktivně četli, lidé jako Martin Fowler a Kent Beck propůjčili praxi hodně legitimity. Můj tým pěti rozebral naše kabiny, vytáhl našeho PM (zástupce pro našeho zákazníka), aby se posadil vedle nás, postavil desku s indexovými kartami a odešel do práce, když jsme šli, tvořili XP. Měli jsme týdenní cyklus plánování a ukázek, spoustu párování a diskuse. Asi 15 let jsem pracoval v různých iteracích a variacích tohoto, v různých společnostech. Zdálo se, že jeden tým nedodržel vůbec žádnou metodiku, ale bylo to proto, že všichni členové týmu byli z agilního prostředí, iterace a spolupráce byly jejich výchozím stavem provozu a nepotřebovali vynucený proces.

Takže je Agile o plánech otevřených podlaží nebo hodně mluví? Pokud máte stand-up a retros, můžete tvrdit, že jste agilní? Kam se vejde Scrum nebo TDD? Lidé se často dostávají do specifik procesu - Scrum nebo Kanban? Dva týdny nebo jeden týden sprintu? Pokud nemáte péči o nevyřízené položky, jste opravdu agilní? Poté, co jsem vyrostl v aktivním rozvoji pomocí agilních metod, s dalšími vývojáři, kteří se stejnou měrou angažují, vyvíjejí a přizpůsobují, mi poskytl dobrý přehled a tento příspěvek má identifikovat základní principy.

Být agilní dokáže rychle uspokojit potřeby zákazníků. Znamená to, že píšeme kód rychleji? Ani náhodou. Nemůžeme porazit zákony fyziky a vybudování solidní multifunkční aplikace vyžaduje čas.

Musíme udělat

  1. Identifikujte základní obchodní problémy, které chceme vyřešit pomocí kódu
  2. Poskytněte rychle teoretické řešení a otestujte hypotézu
  3. Iterujte a přizpůsobujte se měnícím se potřebám, nebo se naučíme více
  4. Udělejte to ve spolupráci se zákazníkem zapojenou částí týmu

Vše ostatní, co děláme, je učinit 2 a 3 výše méně bolestivými - abychom věděli, zda splňujeme potřebu co nejdříve, a pokud nebudeme schopni rychle se změnit. Pokud jste se rozhodli stavět (vs koupit), píšete vlastní software. To znamená, že má specializované požadavky a prostředí.

Zviditelnění něčeho, i když se jedná o malou podmnožinu funkčnosti, co nejdříve před zákazníkem nám umožňuje rychlejší zpětnou vazbu. Z tohoto důvodu se vždy zasazuji o to, abych se zaměřil na stavbu malého plátku, end-to-end a na to, abych se dostal až k produkci. Řekněme, že vytváříte stránku pro své agenty podpory, aby viděli všechna data o zákazníkovi. Namísto toho, abyste strávili spoustu času zkoumáním zdrojů dat pro celou stránku a zapisováním všech API jako první, zkuste získat na stránce celou sadu dat až do produkce. Budete moci uplatnit své integrační a implementační mechanismy, můžete začít získávat zpětnou vazbu v rámci uživatelského rozhraní, jak tato stránka zapadá se zbytkem vaší aplikace atd. Tyto věci se snáze upravují, když máte malé množství kódu, na rozdíl od do doby, kdy jste vytvořili celý rámec API.

Zde jsou některé z dalších mechanismů, které jsou nezbytné pro pohyblivost

Sprinty: Vývoj v časově ohraničených cyklech, umožňuje nám kontrolovat a přizpůsobovat se a v pravidelných intervalech začleňovat nová data, abychom zajistili, že stále pracujeme na příslušných funkcích. Software je odpovědnost. Měli bychom budovat jen to, co potřebujeme, a být schopni přidat to, co je potřeba, když je to potřeba. Proto je důležité pravidelně se dívat na to, co jsme dosud vybudovali a kam jdeme dál. To vede k druhému bodu.

Vzhledem k tomu, že plánujeme neustále vyhodnocovat a měnit, měl by být náš software snadno změněn. Co když po spuštění aplikace zákazníkem chtěli, aby se některá data zobrazovala jinak, než bylo původně navrženo? Mohli bychom to udělat, aniž bychom se dotkli všeho ostatního na stránce? Nebo potřebujeme zavolat jiné API, abychom získali data - mohli bychom to bezpečně změnit? Zde přicházejí osvědčené postupy a mechanismy rozvoje

Testování jednotek: Máme automatické testování na různých úrovních, takže existuje bezpečnostní síť pro změny. Je také důležité mít na paměti, co testy jednotek skutečně testují. Jednotkové testy by měly testovat logiku. Pokud použijete výše uvedený příklad, použití jiného rozhraní API pro získání dat by v ideálním případě nemělo vyžadovat žádnou změnu testů jednotek pro naše rozhraní API, které poskytuje data v uživatelském rozhraní. Existují jednotkové testy, které vám dávají jistotu, že změníte kód, což vám dává svobodu psaní pouze toho, co nyní potřebujete, a odpočinku později, stejně jako vy můžete vytvořit 100% metriku pokrytí.

CI / CD: To nám umožňuje zkrátit vzdálenost mezi odevzdáním a doručením. To je zásadní pro obratnost. Když jsou odstraněny překážky rozmístění a můžeme tlačit na drobné změny ve výrobě, riziko ze změn je výrazně sníženo. Pokud je nasazení únavné, je méně časté. Méně časté rozmístění vytlačí tunu změny ven, dotkne se velké plochy, a proto je rizikovější. Pokud se dozvíte více o tom, proč je výkon dodávek softwaru důležitý a jaké metriky je použít k jeho optimalizaci, velmi doporučuji tuto knihu Nicole Forsgrenové.

Rozdělení obav: Volně spojená architektura je nezbytná pro software, který lze snadno změnit. Zmenšuje povrchovou plochu změny. Mikroslužby a kontejnery jsou některé z mechanismů používaných k oddělování zájmů. Při vytváření API, komponent a aplikací je důležité si to pamatovat a mít na paměti oddělení problémů.

Pamatuj si
Dobrý kód lze snadno změnit

Lepší kód lze snadno vymazat

Nejlepší kód je ten, který nebyl napsán vůbec

Je nezbytné, aby se bity, které vytvoříte, co nejdříve setkaly se skutečným světem, abyste věděli, jak musí vaše nové bity vypadat, a neztrácejte čas zbytečnými bity.