it-swarm-eu.dev

Agilní pro sólového vývojáře

Jak by někdo implementoval koncepty agilních procesů jako samostatný vývojář? Agile se zdá být užitečný pro získání aplikací vyvíjených rychleji, ale také se zdá být velmi orientovaný na tým ...

136
kelleystar
  • Prováděním testem řízeného vývoje
  • Vývojem v malých sprintech
  • Díky velkému kontaktu se zákazníkem

Vzpomínám si, jak jsem četl tezi o Cowboy Development, která je v podstatě Agilní pro sólové vývojáře, ale nepamatuji si, kde jsem ji našla.

66

Kromě odpovědi od klez (všechny dobré návrhy) bych navrhl následující:

  • Zachování nevyřízeného produkt
    Backlog produktu je v podstatě seznam všech položek, které chcete v tomto stadiu dokončit.
  • Zachování burndown sprintu a burndown produkt
    Sprint burndown začíná seznamem všech úkolů, které jste se rozhodli dokončit v tomto sprintu (podmnožina nevyřízených produktů, které mají být dokončeny během stanoveného časového období - např. 2 týdny), spolu s odhadem vyžadovaná práce. Když označíte věci, označíte je jako hotové; čímž se sníží (nebo vypálí) zbývající práce pro tento sprint.
    Podobně produkt burndown sleduje zbývající práci pro celý nevyřízený produkt
  • Přijetí konceptů relativního odhadu a rychlosti
    Relativní odhad je technika odhadu, která používá ostatní úkoly (nebo příběhy) jako vodítko. Pokud například víte, že úkol A je jednodušší než úkol B a přibližně dvakrát tak složitý než úkol C, zajistíte, aby „body“ pro úkol A byly ve vztahu k těmto očekáváním správné.
    Důraz není kladen na správné odhadnutí požadované práce, ale na udržení konzistentních odhadů.
    Rychlost je měřítkem toho, kolik „bodů“ získáte ve sprintu. Pokud váš relativní odhad zajišťuje konzistenci, lze pomocí této rychlosti odhadnout, jaké úkoly budete pravděpodobně v nadcházejících sprintech provádět. Mějte však na paměti, že tato rychlost by měla být neustále revidována.
39
Damovisa
  • Omezení probíhající práce (kromě časového boxu). I když používáte iterační metodu (na rozdíl od Kanbanu), řekněme, že vaše rychlost je 8 bodů na iteraci. Nezačněte pracovat na všech 8 najednou. Omezení WIP buď počtem příběhů nebo bodů příběhu je v pořádku.
  • Mějte automatizované akceptační testy pro všechny své uživatelské příběhy. Automatizujte co nejvíce obecně.
  • Chybí na straně toho, že uživatelské příběhy jsou příliš malé. Obecně platí, že poměr největší a nejmenší příběh 3: 1 . Pokud v Scrumu podceňujete příběh a ukáže se, že je příliš velký, může ho mnohonásobní vývojáři rojit, aby se dostali zpět na trať. Ale nemáš dost lidí.
  • Pokud byste v kontextu pravidelných týmů váhali, zda oddělit bodec od uživatelského příběhu - v kontextu sólo nebo malého týmu, bodec bez váhání udělejte. To pomáhá udržovat příběhy menší a předvídatelnější.
  • Retrospektivy jsou obecně důležité v agility, takže Kanban (to by byl osobní Kanban) zde získává extra body, protože jeho retrospektivní proces je více zaměřen na data. Je těžké hrát Triple Nickels, když nemáte dost lidí.

Tyto věci se pravděpodobně týkají situací sólo i malého týmu (2 nebo 3 vývojáři).

PŘIDÁNO: Někdy poté, co jsem napsal tuto odpověď, jsem našel tuto konferenci a byl jsem velmi ohromen: Osobní Kanban: Optimalizace individuálního kodér

21
azheglov
  • Buď pracujte na dobře definovaných sprintech, nebo záměrně volte přístup Kanban. V Kanbanu náhodou nekončí
  • Chyby první, druhý funkce.
  • Stále se zaměřte na nadhodnocení hodnoty vs. (YAGNI nad pozlacením)
  • Retrospektivy jsou stejně cenné. A stejně důležité je provádět změny procesů v malých kouscích. Nerozhodujte se, že dnes začnete používat TDD, Mock a IoC v jednom záběru, pokud opravdu nemáte žádné externí funkce pro poskytování bankomatů. Přiveďte jeden po druhém.

Nakonec definuji Agile opravdu jako „dělat to, co má smysl pro váš tým a zákazníka, a nedodržovat staré postupy, protože vypadaly, jako by fungovaly v minulosti“.

9
MIA

Agilní pracuje stejně dobře pro jednotlivce, jako pro týmy. Jde o nalezení procesu, který vám vyhovuje, a umožní vám přizpůsobit se měnícím se okolnostem, jakmile váš projekt již začal. Jedná se také o pravidelné poskytování hodnot zákazníkům, bez ohledu na to, zda je software skutečně „hotový“.

Agilní procesy jsou vysoce iterativní. Práce se provádí v krátkých TimeBoxech/sprintech/cyklech/iteracích. Některé konstrukční práce mohou být vyžadovány předem, ale lze je refaktorizovat, když se dozvíte více o tom, co je třeba systém udělat. Testování jednotek je páteří téměř všech agilních vývojových metod, což vám dává indikaci o tom, zda váš software funguje, a zda přidání/změny vašeho softwaru naruší stávající kódovou základnu.

Pokud dodržujete BDD/TDD, dovolte, aby se vaše požadavky změnily s větrem a podle toho můžete upravit priority funkcí, pokud sestavujete celý systém a často provádíte všechny testy, a pokud dodáte pracovní kód na konci každého sprintu , už jsi Agilní.

3
S.Robins

Wow. Pokusil bych se udržet přítele na háku, kterému bych mohl zavolat, když jsem měl potíže - a mluvit problémem s kódováním. Víš, co tím myslím ... jen akt hlasitého vysvětlení problému přináší řešení mysli 90% času.

1
codeyoung