Qual è una buona metodologia per un piccolo progetto per 2 persone? [chiuso]

Non esiste una metodologia perfetta che si adatti a tutti i team di per sé - qualsiasi metodo valido valga la pena riconoscere che deve essere adattato alle situazioni e ai bisogni specifici di ciascun team e progetto.

Quindi solo

1. scegli ciò che ti sembra utile dalle metodologie Agile (o simili),
2. inizia a usarlo,
3. guarda come funziona per te e
4. miglioralo man mano.

Per progetti di dimensioni così ridotte, potresti non aver bisogno di molta pianificazione. Tuttavia, ritengo che sia ancora necessario (tra gli altri)

• gestisci i requisiti,
• attività di stima,
• monitora i progressi e
• verifica che i requisiti siano soddisfatti.

Queste sono almeno alcune delle cose che IMHO anche il più semplice processo di sviluppo dovrebbe essere in grado di gestire a un certo livello. Naturalmente, se entrambi avete esperienza nel dominio (o nei domini), sapete molto bene cosa state facendo e non avete bisogno di comunicare strettamente con la direzione, gli sponsor, ecc., Potreste essere felici con un processo minimale che vi consente "fallo e basta". Altrimenti, meno queste condizioni sono vere, più il processo è probabilmente necessario.

Sono d'accordo con @ Péter Török sceglierne uno e massaggiarlo.

Tuttavia, se dovessi suggerire di massaggiare, sceglierei qualcosa dal mondo degli "ale", poiché naturalmente ha pezzi più piccoli di lavoro che potrebbero corrispondere meglio a una settimana lavorativa di 20-40 ore rispetto a una metodologia a cascata che richiede periodi più lunghi di costante sviluppo per raggiungere un progresso formale.

TDD potrebbe anche essere un buon supplemento di implementazione, specialmente se il tuo 20-40hr è in realtà solo più set di 2-4 ore al giorno con una spinta nel fine settimana. Può davvero aiutare a favorire il progresso (e ricordare a cosa stavi lavorando ... il test che si interrompe attualmente)

Sto utilizzando la metodologia Lean per il mio progetto per l'anno scorso a una donna; in particolare i sette principi Lean identificati da Tom e Mary Poppendieck in Lean Software Development: An Agile Toolkit per i responsabili dello sviluppo software (2003)

1. Elimina rifiuti
2. Qualità di costruzione in
3. Crea conoscenza
4. Rimanda l'impegno
5. Consegna veloce
6. Rispetta le persone
7. Ottimizza l'intero

Dalla mia lettura sull'argomento, l'approccio Lean alla gestione del progetto e all'ingegneria del software è a volte confuso con l'approccio Agile, ma dove la metodologia Agile si rivolge principalmente a un flusso di lavoro che si adatta rapidamente ai cambiamenti, Lean lo fa ulteriormente eliminando punti a valore aggiunto all'interno del processo e si concentra su un processo iterativo ancora più snello (non esitate a non essere d'accordo con la mia comprensione della metodologia Lean e Agile qui)

suggerito lettura utile: Hibbs, Curt, Steve Jewett e Mike Sullivan. (2009). L'arte dello sviluppo del software snello; Un approccio pratico e incrementale. Media O'Reilly

Ecco un paio di opzioni:

1. La programmazione accoppiata sembra funzionare molto bene in queste situazioni. Avendo attraversato più progetti con un partner di progetto, è difficile comunicare ciò che hai fatto dopo aver appena finito un punto di osservazione, ma è importante quando l'altra persona ha in programma di sincronizzarsi con i tuoi cambiamenti al mattino. Potresti voler provare TDD insieme alla programmazione Pair.

2. Delineare il progetto in più moduli (relativamente) indipendenti e programmare via. Lavora insieme mentre fai l'integrazione per evitare che una persona scarichi la metà del codice dell'altro:)

3. Naturalmente, metodi agili come la mischia funzionano ancora bene in questo contesto.