Un libero professionista può usare uno sviluppo agile?

... Oltre alla programmazione di coppie, certo. ; -)

Scherzi a parte, anch'io sono un libero professionista e uso le tecniche agili il più possibile. Funziona molto bene per me. Faccio un enorme uso di TDD,

Nessuno usa mai il 100% di XP o Scrum, ma tutti ne usano alcune parti, cercando di adottare quanto più funzioni per loro. Secondo me, più ne adotterai, meglio sarà.

La cosa che mi manca di più è la programmazione di coppie. Il modo in cui lo hai superato è

1. Vai a molte riunioni di gruppi di utenti.
2. Trova un paio di persone che tu rispetto come sviluppatori.
3. Chiedi loro di incontrarti per un caffè o qualcosa da scrivere codice. Dare loro parte del tuo salario orario ogni tanto se lo senti necessario o semplicemente rispondere in natura a lavorando sul loro codice.
4. Partecipa o crea un Hack Club come questo: link .

Ecco alcune risorse che uso:

• Extreme Programming -un online guida rapida, ma completa attraverso XP.
• Un'ottima panoramica di Scrum .
• Libro fantastico e breve . Perfetto per te!

Quindi direi che ci sono tre "punti fantastici" principali per usare Agile come libero professionista:

1. Per clienti più grandi, lavora / fattura in iterazioni. Alla fine dell'iterazione il cliente può continuare a lavorare sul progetto o terminare il progetto (cioè: ha raggiunto il suo obiettivo). So (dall'esperienza) che non posso stimare bene più di qualche settimana, e il pay-iteration mantiene il flusso di cassa. Non è divertente essere al 6 ° mese di un progetto di 3 mesi, e aspettare per finire il progetto in modo da poter bil ...

2. Agile significa che il cambiamento accade. Ho fatto un sacco di progetti di offerte fisse (che pensi di poter fare con waterfall) che mi hanno fatto perdere denaro, a causa di una richiesta del cliente nel bel mezzo del ciclo. Il cambiamento accade: il cliente può decriorizzare un ticket per fare in modo che altri lavori possano essere fatti più velocemente, o forse hai forcastato male e non hai ottenuto quanto hai sperato.

3. Buoni strumenti di collaborazione con i clienti. La mia stima standard (per qualcosa di più piccolo di un valore iterativo di lavoro) è in realtà una serie di passaggi di sviluppo comportamentale derivati dalle aspettative del cliente. Invio questo al cliente e dico "È corretto?". Si assicura che tutti siano sulla stessa pagina.

4. La cosa più semplice che potrebbe funzionare. È qualcosa da tenere a mente mentre lavori: non aver paura di tornare dal cliente e dire "Sarebbe molto più semplice (o più potente, o qualsiasi altra cosa) se lo facessimo in questo modo ... "

5. Scrum è importante. Mi piace mandare via email ai miei clienti ogni giorno che lavoro sul loro progetto. Questo è come la mia mischia per loro: "su cosa ho lavorato oggi", "cosa / quando lavorerò al loro progetto successivo?", "C'è qualcosa nella mia strada?", E "Nel complesso, come va il progresso ? "

6. Anche lo sviluppo basato su test è davvero utile, anche come singolo programmatore. Le mie "stime con storie di BDD in loro" mi aiutano ad alimentare questo processo.

Un ottimo modo per iniziare il tuo viaggio Agile è impostare il tuo flusso di lavoro usando un sistema KANBAN.

Abbiamo semplicemente 3 swimlanes:

1. I nostri TO-DO o backlog
2. Su cosa stiamo lavorando o IN CORSO
3. Cose che completiamo o FATTO.

Questo semplice flusso di lavoro Agile è un ottimo modo per iniziare.

In termini di codifica, consiglierei di utilizzare lo sviluppo basato sui test (TDD). Nel nostro articolo abbiamo incluso molti link interessanti che descrivono TDD, ma li coperemo di nuovo qui:

Per ulteriori informazioni, consulta le seguenti risorse:

• AgileData.org - Una grande risorsa per lo sviluppo basato su Test.
• JamesShore.com - Un'altra grande ripartizione per TDD
• Net Tuts - Una divertente introduzione al TDD che mi piace!
• Artima - Intervista a Martin Fowler
• Games From Within - Un buon caso di studio di TDD
• DaniWeb - Introduzione a TDD per gli sviluppatori
• Mark Levison - Articolo su TDD

Dato che sei un individuo, è meglio che ti avvicini alle metodologie agili come qualcosa che ti aiuta a risolvere ciò che funziona meglio per tu . Sono lì per aiutarti a raggiungere quell'altopiano "non c'è un cucchiaio", ma come esattamente ciò che accadrà dipende interamente da te e ciò che ti verrà in mente si sovrapporrà notevolmente con alcune metodologie a vari livelli, eppure sarà qualcosa di completamente tuo.

Dato che stai cercando di trovare la tua strada facendo cose per migliorare la tua efficacia generale, ecco alcuni suggerimenti che possono aiutarti almeno a non commettere gli stessi errori che ho fatto io:

Rinuncia a tutte le soluzioni software rivolte esclusivamente a metodologie agili, il più a lungo possibile.

Il fatto che siano più adatti per facilitare la collaborazione tra team è fuori questione. Resisti alla tentazione. Non ti inscatoli in un modo di fare le cose e poi speri che adottarlo funzionerà per il meglio. Non è così, ti frustra. Prima trovi il tuo modo di fare le cose e poi cerca una soluzione software adatta. Ho finito con l'utilizzo di lavagne bianche (iniziate con una, ma ora ne ho due nella mia stanza) per tracciare / sviluppare storie e la Tecnica di Pomodoro | Da fare oggi elenco per tracciare i miei compiti di sviluppo e è friginesco 2011. Attenersi alle nozioni di base fino a quando non otterremo alcune interfacce come quelle di Iron Man 2 o le macchine volanti.

Riflessione, riflessione, riflessione

Questo è quello che ho capito essere l'unica parte più importante di qualsiasi metodologia per un individuo. Si tratta di sviluppare questo flusso di lavoro che ti offre una visione olistica del tuo progetto in modo da poter tenere traccia di ciò che deve essere fatto e quando è facilmente gestibile e dove le decisioni sbagliate sono raramente fatte e si distinguono per essere rapidamente modificate prima che causino danni ... ma non puoi semplicemente prenderlo dallo scaffale. Inizia da qualche parte, ovunque. Ti infili per tutto il tempo che funziona. Investire nel tracciare il bene, il male e il così-così. Migliora le tue ipotesi, quindi aggiusta il modo in cui fai le cose di conseguenza. Questo è l'unico modo per migliorare.

Furget sulle scadenze, concentrati sulla velocità con cui fai le cose

Probabilmente ero come il prossimo quando ho iniziato, inseguendo le date. Grafici del burnout? Pensavo a loro come a un modo per visualizzare il mio percorso di sviluppo contro le scadenze. È una performance, non un modello di stima. Il tempo è lì per misurare la tua efficacia riflettendo sul lavoro che hai svolto entro un certo lasso di tempo, non solo un qualche stupido valore per rappresentare la distanza prima di ostacolare le scadenze. La realtà è che le cose vengono fatte quando è fatta e la metodologia deve tener conto di ciò.

Devia di conseguenza

Alla fine, chi dice che devi usare le storie degli utenti o qualsiasi cosa di cui siamo a conoscenza? Non pensare in questo modo. Se sei più a tuo agio nel pensare in termini di funzionalità, sfidare in ogni modo la comunità di sviluppo globale e farlo a modo tuo, perché fare le cose è tutto ciò che conta alla fine della giornata. Se ti senti come se stessi facendo qualcosa di sbagliato, congratulazioni - hai appena concluso che è ora di passare a qualcos'altro. Riguarda ciò che è, non il come.

Risponderei "come si desidera migliorare il modo in cui si sviluppa il software?". Per il tuo modello di business, quali sono i maggiori problemi che hai riscontrato utilizzando la metodologia waterfall?

Il tuo obiettivo è uno sviluppo più veloce, un codice più robusto, un maggiore riutilizzo, l'incontro / adattamento ai requisiti in continua evoluzione ecc.? Esistono diverse metodologie per superare diversi problemi.

Ovviamente l'adozione di una metodologia di progettazione diversa da Waterfall può essere molto utile per gestire efficacemente il ciclo di vita di un progetto in base ai requisiti aziendali. Per uno sviluppo agile ci sono un gran numero di risorse online. Vorrei esaminare AUP (Agile Unified Process) che incorpora TDD (Test Driven Development). Questo può essere estremamente utile quando si costruiscono / gestiscono grandi sistemi scalabili.

Non esiste una metodologia "taglia unica" e questa è la ragione principale del vasto numero di approcci diversi. Vorrei iniziare a pensare a dove ti senti attualmente i colli di bottiglia nel tuo processo di sviluppo e poi provare ad adottare una nuova metodologia per superare questo problema.

Ad esempio, spesso non riesci a rispettare le scadenze? Le nuove funzionalità introducono un gran numero di bug? I nuovi requisiti provocano importanti interventi di riqualificazione? L'azienda richiede la presentazione di sistemi di lavoro regolari? Controlla: Agile , Iterativo e Agile Intro .