it-swarm-eu.dev

Nejlepší metodika rozvoje pro jednu osobu?

Hodně času trávím prací na projektech, ve kterých jsem jediným vývojářem, projektovým manažerem, návrhářem, osobou QT (Ano, já vím ... Špatně!), A někdy jsem i klientem.

Vyzkoušel jsem téměř všechno pro plánování projektů a řízení sebe sama, od prostého sezení a pracovního freestylu až po dokončení projektu, jakkoli to trvá dlouho, až po verzi scrum pro jednu osobu, ve které jsem se se sebou konal setkání o pokroku v průběhu jednoho - muž vypaluje každé ráno graf (ne srandu).

Pro ty z vás, kteří tráví mnoho času sami, jaký je nejlepší způsob, jak se uspořádat, řídit velké (pro jednu osobu) projekty a udržovat produktivitu na nejvyšší možné úrovni?

77
Eli

Vedení jasného seznamu vašich cílů je zásadní. Převzetí vlastního projektu je snadné. Užitečný je také přístup TDD „je hotovo, když to funguje“. To vám brání stát se perfekcionistou.

Jedna věc, která mi opravdu pomáhá, je představit si, co by v dané situaci řekl jiný inženýr nebo projektový manažer. Často jsem schopen se „zahanbit“ ze špatného kódu, nebo se dostat zpět na trať, pokud plán sklouzává.

29
Jon B

Tady to máš ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP se pěkně zmenšuje, protože je optimální pro malé soustředěné týmy ..

  • Můžete vytvořit tabulku požadavků na funkce, upřednostnit je a vybrat tu nejlepší.
  • definovat kritéria přijatelnosti (jak to vypadá) a kódovat je do spustitelného testu
  • Dále definujte inženýrské úkoly, které musíte splnit
  • Napište jednotkové testy, dělejte vždy nejjednodušší věc (YAGNI) a refaktor. Cílem je absolvovat vnější akceptační test
  • Časové pole každé relace. Pro efektivní správu času byste se také mohli podívat na Pomodoro technika .
  • Chcete-li vytvořit instalaci nebo zip vašeho softwaru, použijte řízení verzí a nastavení serveru CI/dávkového souboru
  • Ukázka často. Nasměrujte zpětnou vazbu do původní tabulky a změňte prioritu

Jediná věc, kterou jste nemohli udělat v týmu jednoho, je PairProgramming.

23
Gishu

Pokud pracujete samostatně. Zde jsou rady:

  1. Dělejte co nejméně práce na nízké úrovni. Používejte tolik knihovny a nástrojů, kolik jen můžete, včetně věcí, o kterých si myslíte, že můžete snadno kódovat (nedělejte to, prostě použijte knihovnu).
  2. Použijte přístup shora dolů. Kódujte pouze věci, které opravdu potřebujete.
  3. Když vidíte problém v abstraktním termínu, hledejte na google a použijte výzkumné články od akademické obce, které již byly prokázány. Musíte pouze kódovat jejich algoritmus.
  4. Navrhněte svůj systém tak, abyste mohli věci co nejvíce volně měnit. (včetně kopírování a vkládání kódu odtud sem). Účelem je ušetřit čas, když si uvědomíte, že jste udělali chybu. Pokuste se minimalizovat množství práce, kterou musíte zahodit, když uděláte chybu. Část kódu, kterou je třeba zahodit (namísto kopírovat-vložit odtamtud) je ekvivalent času, který jste ztratili při psaní tohoto kódu.
  5. Mnoho automatizovaných testů umožňuje pravidelné regresní testy pokaždé, když provedete změnu
  6. Oddělte odpovědnosti za svůj design (tj. Snižte propojení). Dělat věci co nejvíce modulární
  7. K ladění použijte debugger a k nalezení vady použijte binární vyhledávání.
  8. Neustále upravte svůj kód, abyste snížili (explicitní) propojení a expozici veřejným metodám (implicitní propojení).
  9. Fakt nic. To je tady jen pro případ, že můžu přijít s něčím novým: P
17
InformedA

Recenze kódu.

Jsou to zvláště užitečné, protože kód vysvětlíte někomu, kdo na stejném projektu nepracoval, takže nebudou mít žádné z vašich předpokladů o tom, jak by měl fungovat.

Budou mít také další výhodu sdílení znalostí kolem společnosti, takže když někdo jiný musí na projektu pracovat (kvůli lidem, kteří jsou zaměstnáni jinde, nemocní, rezignovali nebo byli propuštěni), nebude muset začít od nuly .

13
ChrisF

Posouval jsem svou vlastní verzi agility, která se opírá o příběhy, těžkou interakci se zákazníky, častá vydání a vývoj zaměřený na testy. Používám wiki ke sledování příběhů, zapojuji zákazníka do co největšího možného rozsahu do jejich psaní a nechávám zákazníky, aby se mnou spolupracovali na stanovení priorit a organizování do vydání. K řízení návrhu a implementaci používám TDD. Zřídil jsem server QA, kde si zákazník může vyzkoušet častá vydání (někdy denně, když se vyvíjejí nové funkce), abych rychle získal zpětnou vazbu. Zřídka jdu více než 3 iterace bez vydání QA. Zákazník se rozhodne, kdy má verze QA dostatek funkcí k uvedení do provozu - a pokud již není nutné vyvíjet další funkce ze seznamu.

7
tvanfosson

V mé společnosti naše skupina pracuje na stejném projektu, ale na relativně nezávislých dílech. Jedna věc, kterou tady hodně děláme, je, když se něco, co děláte, zdá být trochu složitější, nebo jste na rozcestí s více než jedním způsobem, jak něco implementovat, popadnete někoho jiného a dříve o výhodách a nevýhodách diskutujete pokračujete. Pokud počkáte, až si myslíte, že váš kód je dokončen, aby provedl kontrolu, obvykle jste již investovali příliš mnoho času na zvážení hlavních architektonických změn, i když určitě je v revizi kódu odhaleno mnoho vad.

Také si uvědomuji, že Test Driven Development je v poslední době trochu buzzword nasycený, ale může to být velká pomoc pro sólové vývojáře, protože poskytuje kontrolu kvality za běhu, a když je obtížné napsat testy, víte, že pravděpodobně potřebujete nějakou restrukturalizaci své kód. Rovněž pomáhá pozdějším správcům, aby náhodně nezlomili kód v obtížně detekovatelných způsobech.

7
Karl Bielefeldt

Navrhuji vám následující:

  1. Testem řízený vývoj
  2. Eavy použití "TODO: poznámka zde" ve vašem kódu, když uvidíte něco, co nejste schopni udělat okamžitě, a vrátit se k nim, když budete mít čas místo toho zůstat na facebooku čeká na svého klienta zavolat zpět
  3. Napište svůj kód, protože váš klient jej koupí při pohledu na kód nejen na výsledek, představte si svého klienta jako předsedu pro kontrolu kódu.
  4. Vyplňte kód tvrzení
4
Gaetano Mendola

přál bych si, abych řekl, že jsem byl schopen praktikovat to, co hlásám 100% času, ale BDD se zdá být dobrým přístupem pro vaši situaci:

Zde je odkaz s více informacemi: http://en.wikipedia.org/wiki/Behavior_driven_development

3
Levi Rosol

filozofie: XP/TDD + GTD

obecný přehled:

  • rozhovor zúčastněných stran
  • makety obrazovky, průchody, prototypy papíru (podle potřeby)
  • brainstorming funkcí/příběhů (se zúčastněnými stranami a bez nich)
  • brainstorming v testovacím případě (se zúčastněnými stranami a bez nich)
  • celková doba přeměny designu/architektury (podle potřeby)
  • iterační plánování (se zúčastněnými stranami)
  • iterace
  • přezkoumání procesu, školení, plánování údržby atd. (podle potřeby)
2
Steven A. Lowe

Jsem ve velmi podobné lodi. Snažím se co nejvíce dodržovat agilní principy (jak jim rozumím). Pravděpodobně nedělám věci „správně“, ale měl jsem velký úspěch na svých projektech tím, že jsem se snažil dodržovat agilní principy. Vyžaduje to obrovské množství disciplíny, protože neexistuje žádný tým, který by zajistil, abyste nezačali jen používat zkratky.

2
John Kraft

Zjistil jsem, že pomocí nástrojů pro formátování kódu, jako je ReSharper, zajistíme, že alespoň vizuálně bude kód snadno vyzvednut pro další vývojáře.

Pokud jde o skutečné metodiky, je pro jednoho vývojáře obtížné držet se jakéhokoli konkrétního. Jsem konzultant, který obecně pracuje sám a pro mě i pro klienta je pro mě nejsnadnější použít agilní proces. Obvykle se snažím přimět své klienty, aby přímo zadali své požadavky do nástroje, jako je Trac (nebo budu jejich jménem). To nejen pomáhá ostatním vývojářům identifikovat účel kódu, ale také sami 3 měsíce po sobě!

2
bryanatkinson

Jakákoli vhodná metodologie pomůže - bez ohledu na počet lidí v projektu. Vyberte si jeden po druhém a podívejte se, jak můžete použít a mapovat svou doménu, a změřit jejich úspěchy.

Možná zajímavější je zeptat se, jaké metodiky nevyhodit, protože na projektu pracuje pouze 1 osoba.

A klíčovým, který mi vyniká, je Řízení zdrojů (Ano, to je nástroj, ale je to součást vašeho pracovního postupu, tedy také proces). Lidé by mohli být v pokušení dát tento průchod, protože „nemusí podporovat více lidí, kteří upravují kód najednou“.

Ironicky jsem zjistil, že distribuční řešení pro správu verzí, jako je GIT, je pro jednotlivce lepší, než něco jako SVN.

1
Stephen Bailey

Pokud je to zahozený kód, mohl by být s metodikou trochu uvolněný-goosey, ale cokoli důležitého a řekl bych, že způsob, jak s ním zacházet jako týmový projekt s jednou osobou, je velmi pěkný a disciplinovaný.

Napište kód pro příštího chlapce, který si přečte, ne vy ... být k němu milý. Dokonce i kód „zahodit“ zůstane navždy.

0
Nick

Myslím si, že recenze kódu jsou dobrým začátkem, ale líbí se mi, když jsou neformální a zábavné, jako když dělám párové recenze kódu nebo párové programování, abychom vyřešili určitý problém/problém nebo nějaké vylepšení (např. Změna staršího kódu tak, aby splňoval nové standardy kódování) ). Občas jsou dvě sady očí lepší než jedna a je to také zábavné, mám pocit, že sdílení a diskuse se jeví otevřenější. Mohli byste mít také rádi formální/neformální oběd a diskutovat o zasedáních, abyste hovořili o tom, co jste udělali jednotlivě nebo jako skupina, např. zmínit se o novém vzoru, který jste použili, nebo o nových technologiích, jak byl problém vyřešen?

0
MalsR

Agilní

funkce, příběhy a testovací případy jsou mnohem poučnější než formálnější dokumentace a sada pracovních testů je lepší při demonstraci, jak něco použít nebo jak něco funguje, než jakéhokoli množství mrtvých stromů

Je také snazší předat práci mezi iteracemi.

0
Steven A. Lowe

Jako konzultant můj já bych navrhl, abyste si našli způsob, jak vždy existovat alespoň dva vývojáři v jakémkoli úkolu.

Souhlasím s tím, aby byl agilní, a nechal jsem agilní stopu příběhů a testů, které mohou ostatní následovat, ale nevěřím, že ani žádný jiný proces nebo metodologie přilepí, zatímco lidé pracují samostatně.

0
Apalala