2010-02-01 11 views
25

In cerca di lavoro al momento, vedo molti luoghi che richiedono esperienza Agile, ma finché non avrò un lavoro con una squadra che utilizza Agile, sospetto che non avrò mai l'esperienza.Una persona può adottare tecniche Agile?

È possibile adottare metodologie Agile con una sola persona?

sorta di rispondere alla mia domanda, non c'è domande simili a: -

(. Credo che dovrei arrivare meglio a cercare)

+0

Non ha senso fare agile per una persona. Lo scopo per l'agile è quello di irradiare la comunicazione. –

+2

@jpartogi Non sono d'accordo con il tuo primo reclamo né con la tua comprensione di Agile. Entrambi i punti non sono veri. –

+3

I post di lavoro sono posizionati in modo flessibile in base a requisiti o preferenze? Forse hai bisogno di mostrare la volontà di usare agile e dimostrare alcuni studi autonomi sull'argomento. – JeffO

risposta

11

Sembra che tu stia arrivando da un punto di vista dell'esperienza lavorativa; se stai cercando di costruire un'esperienza rilevante per farti un lavoro su un progetto agile, probabilmente penserei un po 'più lateralmente.

In primo luogo potresti lavorare con altri, magari in un progetto open source? Questa sarebbe una buona opportunità per provare metodi agili con altri che potrebbero avere più esperienza.

In secondo luogo, è possibile utilizzare alcune delle tecniche o degli strumenti comuni, anche se è solo per imparare come funzionano gli strumenti, ad es. è possibile configurare un server di integrazione continua per eseguire build e unit test al momento del check-in del codice. Se stai lavorando da solo, non otterrai molto in termini di produttività, ma acquisirai alcune abilità e avresti qualcosa di rilevante da dire ai futuri datori di lavoro che indicherebbe che sei impegnato in uno stile agile.

+0

Contrassegnerò questo come accettato, dal momento che riprendi l'aspetto dell'esperienza lavorativa e fornisci consigli pratici su come dimostrarlo ai potenziali datori di lavoro –

+0

Mentre l'open source potrebbe essere un modo per acquisire esperienza, grazie alla sua natura distribuita e raramente incontro le persone faccia a faccia, non so quanto sarebbe efficace rispetto all'esperienza commerciale di lavorare in un ufficio dove è più facile collaborare e condividere idee con i colleghi. –

+0

@greg Sicuro. Le cose come la mischia o la programmazione delle coppie non funzioneranno, ma altri aspetti potrebbero ad es. nessuna ragione per non fare TDD o CI. Non sono sicuro se siano strettamente sotto la definizione di "agile", ma penso che ci sia un'esperienza utile da avere lì. –

3

Alcuni aspetti si può fare da solo: viene in mente un backlog di prodotti e l'uso di una bacheca di attività. Guarda cosa sta facendo il secretGeek.

Naturalmente alcuni non possono: pair programming, mischie ecc ...

+0

Nice: posso utilizzare la lavagna del mio ufficio a casa piuttosto che usare il pezzo di A3 che suggerisce. –

+0

+1 per il collegamento se ho avuto voti a sinistra ... :) –

1

Sicuramente. Agile è molto flessibile in termini di quante persone sono coinvolte. Alcune metodologie, come Scrum, si concentrano principalmente sul fare il più possibile in un tempo limitato, come due settimane (sprint). Ciò include qualunque cosa tu voglia. Se la tua squadra richiede il QA, allora questo è parte di esso. Da solitario, decidi cosa vuoi includere.

Dopo lo scrum sprint, guardi cosa avresti potuto fare diversamente per ottenere di più, e passare al prossimo.

Alcune altre metodologie si concentrano maggiormente sull'ottenere funzioni eseguite in ogni iterazione, ad esempio tre piccole funzionalità sviluppate, testate e refactored.

Come potete vedere, ci sono molti modi per applicare agile a qualsiasi progetto. Tu decidi quali aspetti vuoi. Sebbene ovviamente una parte integrale stia facendo le cose con piccoli incrementi.

+0

Immagino che questo porti a una domanda successiva quindi - Come faccio a dimostrare ad un potenziale datore di lavoro che adotto tali pratiche quando lo faccio da solo? –

+1

Spiega come funziona il tuo sistema e come ti ha aiutato a svolgere il compito. –

11

Controllare PXP o Personal Extreme Programming.

http://portal.acm.org/citation.cfm?id=1593127

Sintesi dalla carta:

Personal Extreme Programming (PXP) è un processo di sviluppo software per una squadra sola persona . Si basa sui valori di Extreme Programming (XP) , ad esempio semplicità, comunicazione, feedback e coraggio. Funziona con mantenendo gli aspetti importanti di XP e perfezionando i valori in modo che siano disponibili in una situazione di programmatore solo . PXP può ancora essere raffinato e migliorato. È nella tradizione dei professionisti XP di variare XP a comprendere qualsiasi cosa funzioni. Speriamo nello che PXP erediti anche queste pragmatiche radici . Rinunciare ai principi XP la programmazione come coppia non è necessariamente una tragedia. Siamo ancora a credere che seguire XP in modo rigoroso sia un modo più efficace per perseguire i progetti di più persone .Ma siamo anche nello convinti che molte delle pratiche e dei metodi di XP possono essere applicati a lavoro individuale . L'approccio PXP cerca di bilanciare tra il "troppo pesante" e le metodologie "troppo chiare" . PXP inietterà la giusta quantità di rigore per la situazione senza sovraccaricare la squadra con burocrazia inutile.

programmazione
+0

Se non riesci a vedere la carta. Prova a cercare su Google il termine. La programmazione delle coppie è annullata in modo nativo, ma tutto il resto funziona. Lo sto usando su un progetto ora. – Finglas

+0

Concetto interessante: c'è un modo per vedere effettivamente la carta senza avere un login membro ACM? –

+0

La tabella di confronto è molto più grande di quanto ricordassi, quindi pubblicherò il riassunto. – Finglas

3

Coppia sarebbe stato difficile in questo modo :)

Controlliamo Agile Principles:

  • Gli individui e le interazioni oltre processi e gli strumenti
  • software di lavoro su una documentazione completa
  • la collaborazione dei clienti corso di negoziazione del contratto
  • Rispondere al cambiamento sopra seguendo un piano

Si può fare tutte queste cose, anche mentre si lavora su da solo qualche progetto personale. Puoi usare anche GTD mentre lavori da solo, puoi sviluppare il tuo prodotto attraverso iterazioni, puoi adottare timeboxing, puoi chiedere ad alcuni familiari o amici di fare test di usabilità con te (e questo funziona davvero bene).

In conclusione, è possibile ottenere davvero un sacco di esperienze agili da solo. Vi consiglio vivamente di leggere prima alcuni libri, in quanto alcuni dei principi possono essere facilmente interpretati erroneamente.

2

Mentre alcune pratiche agili sono direttamente rivolte a più di un team di persone, sono solo pratiche, sono solo un mezzo, non un fine. Voglio dire, Agile è non su come fare la programmazione di coppia, riunioni in piedi, ecc. Agile è circa massimizzando il valore del cliente riducendo al minimo i rifiuti per fornire il ROI più ottimale. Agile è orientato al business, le pratiche sono solo un modo per raggiungere questo obiettivo in un determinato contesto. Quindi, tornando alla domanda iniziale, è sicuramente possibile adottare pratiche Agile (che hanno senso nel proprio contesto) per massimizzare il valore erogato: pianificazione continua, limitazione del work in progress, cultura stop-the-line, time boxing, alta qualità, solo un numero sufficiente di specifiche, documentazione appena sufficiente, documentazione, ecc. ecc.

+0

+1 Tutti sembrano concentrarsi su Pair Programming, ma come si fa notare questo non è il tutto e finisce con Agile - anzi, l'argomento principale per PP sembrava essere quello di aiutare la condivisione della conoscenza dove è ostacolata da una mancanza di documentazione altrove. –

+0

La programmazione delle coppie deriva più da XP (che è più prescrittivo) che da Agile/Scrum. –

+0

Agile! = Scrum, Agile è solo un termine generico per molti metodi, Scrum e XP sono alcuni di loro. E mentre Pair Programming è una delle pratiche XP (che cattura molte pratiche ** come un set indivisibile **), XP non ha l'esclusività di Pair Programming, è possibile utilizzarlo al di fuori di XP. –

6

Sì - è possibile fare molte agili pratiche come individuo.

Se già sapete come fare queste, si può fare come un unico sviluppatore:

  • sviluppo test-driven - ottimo punto di partenza
  • refactoring
  • integrazione continua
  • fare la cosa più semplice che potrebbe funzionare (e evolverci attraverso il refactoring)
  • distribuzione automatizzata
  • riunioni di programmazione (una squadra di uno più clienti)

Le cose non si possono fare da soli:

  • coppia di programmazione
  • workshop CRC/RRC (... voi 'd dovuto parlare con voi stessi un bel po')
0

XP/TDD scala da uno a mille. La programmazione della coppia è facoltativa.

3

Recentemente ho interrotto un grande progetto. Era un progetto di software medico. Mentre ci lavoravo, ho realizzato alcuni schemi sulla programmazione da solista. Voglio condividere le mie esperienze qui:

  1. La logica di lavoro del tuo software deve sempre riflettere il mondo reale. Prendi il pesce con la canna da pesca, non con la mazza da baseball; quindi dimenticalo.
  2. Iniziare sempre a costruire dall'elemento di progetto a cui fanno riferimento tutti gli altri elementi. Questo ha senso se si pensa che come la funzione in un progetto software che viene chiamato al massimo. Potrebbe essere la modellazione del database. Sarebbe inutile se modellate il livello di accesso ai dati per primo, prima di modellare il database.
  3. Non importa cambiare i nomi delle variabili. Questa è la voce più scritta nel diario di un programmatore; quindi non c'è bisogno di vergognarsi.
  4. La metodologia cambia il mondo. Ne vale la pena. Rendi ogni singolo processo logico con una funzione o una procedura. Quando il progetto diventa enorme capirai che è il modo migliore.
  5. Se non si sta progettando un compilatore di linguaggio in assembly, non esitare ad utilizzare enormi catene di chiamate di procedure in cui si chiama un altro e che chiama un altro e così via. Utilizzare i metodi ovunque, quasi assomigliano a ogni singola entità con le classi ed essere modulari.
  6. La modularità è tutto. Imposta la modularità come obiettivo principale. Ho detto che è tutto nel frattempo?
  7. Ultima parola per iniziare il progetto. Se stai costruendo un appartamento, puoi finalmente installare l'ingresso principale. Ma quando si usa, si entra dall'edificio. Sii consapevole

Questi sono alcuni dei miei principi di progettazione che ho imparato e apprendo giorno dopo giorno.Spero di essere stato utile. Fai del tuo meglio.

+1

Alcuni dei tuoi punti sono anti-agili e/o anche atipatterns. Vale a dire 2, 4, 7. Potremmo iniziare dall'interfaccia utente e prendere in giro dati reali. Un'operazione logica/utente per lo più diventa un ampio insieme di metodi, non uno solo. In Agile, dovresti iniziare a creare dall'elemento che è di partenza per un utente. – Gangnus

0

SI.

Agile è più uno stato mentale che una semplice metodologia di sviluppo software come Cascade. Scrum è una delle metodologie agili molto popolari. Si può studiare sotto gli aspetti della mischia in dettaglio:

  1. vantaggi di Scrum/Agile su cascata
  2. Come si può creare "prodotti" migliori con Scrum/Agile
  3. Quali sono i tipi di progetti più adatti per Scrum
  4. Pro e contro di Scrum
  5. Scrum Rituali e perché sono necessari (che vantaggio fanno portano)
  6. ruoli diversi in mischie e le loro responsabilità (Scrum master, Proprietario del prodotto e team di sviluppo)

Dopo aver compreso bene il funzionamento di Scrum e i relativi vantaggi, provare a creare un progetto per animali domestici. Dovrai giocare tutti i ruoli da solo. Puoi provare a distinguere tra quale ruolo stai correntemente indossando cappelli colorati per ogni ruolo.

Esempio:

proprietario del prodotto: pensare dal punto di vista del prodotto, che dovrebbero essere le caratteristiche del prodotto e perché avrebbero dovuto essere importanti per gli utenti, ecc Quindi procedere con tutte le pratiche Scrum.

Scrum Master: Continua a controllare se stai seguendo tutti i rituali di scrum nel giusto senso e nello spirito e sei in grado di trarne benefici.

Ci saranno dei limiti, ad esempio non è possibile avere una riunione di stand-up giornaliera, ovviamente perché si è l'unica persona nel progetto. Ma se segui sopra, dovresti essere bravo a ottenere un lavoro e svolgere bene il tuo ruolo nel team.