Un libero professionista può usare uno sviluppo agile?

Voglio migliorare il modo in cui sviluppo software. Voglio sviluppare più velocemente e un ottimo codice! Oggi uso il metodo waterfall come libero professionista, scrivendo materiale web (siti, sistemi, ecc.). Esiste un modo per utilizzare lo sviluppo agile (XP, SCRUM, ecc.) Che funziona in questo modo? Non so nulla dello sviluppo agile, da dove dovrei iniziare? Grazie mille.

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

Seriamente, sono anche un libero professionista e uso tecniche agili il più possibile. Funziona molto bene per me. Faccio enorme uso di TDD,

Nessuno ovunque usa il 100% di XP o Scrum, ma tutti ne usano parti, cercando di adottare quanto funziona per loro. Secondo me, più ne adotti, meglio sei.

La cosa che mi manca di più è la programmazione in coppia. Il modo in cui lo superi è

1. Vai a molte riunioni del gruppo di utenti.
2. Trova un paio di persone che rispetti come sviluppatori.
3. Chiedi loro di incontrarti davanti a un caffè o qualcosa per scrivere il codice. Fornisci loro una parte del tuo stipendio orario di tanto in tanto se ritieni che sia necessario o semplicemente rispondi in natura a lavorare sul loro codice.
4. Partecipa o crea un Hack Club come questo: http://www.DallasHackClub.org .

Ecco alcune risorse che utilizzo:

• Programmazione estrema : una guida online rapida ma completa su XP.
• Un'ottima panoramica di Scrum .
• Libro fantastico e breve . Perfetto per te!

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

1. Per clienti più grandi, lavorare / fatturare nelle iterazioni. Al termine dell'iterazione il cliente può continuare a lavorare al progetto o terminare il progetto (ovvero: ha raggiunto il suo obiettivo). So (per esperienza) che non riesco a stimare bene più di qualche settimana, e il pay-per-iteration mantiene anche il flusso di cassa in arrivo. Non è divertente essere al 6 ° mese di un progetto di 3 mesi e aspettare per terminare il progetto in modo da poter bil ...

2. Agile significa che il cambiamento accade. Ho fatto un sacco di progetti a offerta fissa (che pensi di poter fare con la cascata) che mi hanno perso soldi, a causa di una richiesta del cliente nel mezzo del ciclo. Il cambiamento accade: il cliente può depriorizzare un biglietto per fare qualche altro lavoro più velocemente, o forse ti sei procurato un errore e non hai fatto tanto quanto speravi.

3. Buoni strumenti di collaborazione con i clienti. La mia stima standard (per qualcosa di più piccolo del valore di un'iterazione) è in realtà una serie di fasi di sviluppo guidato dal comportamento derivate dalle aspettative del cliente. Mando 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 qualunque cosa) se lo facessimo in questo modo ... "

5. Scrum è importante. Mi piace inviare ai miei clienti un'e-mail ogni giorno che lavoro sul loro progetto. Questo è come la mia mischia per loro: "su cosa ho lavorato oggi", "cosa / quando lavorerò al loro prossimo progetto?", "C'è qualcosa sulla mia strada?", E "Complessivamente, come vanno i progressi ?"

6. Anche lo sviluppo guidato dai test è davvero utile, anche come singolo programmatore. Le mie "stime con storie BDD in esse" mi aiutano a alimentare questo processo.

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

Abbiamo semplicemente 3 swimlanes:

1. I nostri impegni o arretrati
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 test-driven (TDD). Nel nostro articolo abbiamo incluso molti ottimi collegamenti che descrivono TDD, ma li ricoperemo qui:

Per ulteriori informazioni, consulta le seguenti risorse:

• AgileData.org - Una grande risorsa per lo sviluppo guidato dai test.
• JamesShore.com - Un'altra grande rottura 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 sul TDD
• DaniWeb - Introduzione a TDD per sviluppatori
• Mark Levison - Articolo su TDD

Dal momento che sei un individuo, è meglio che approcci metodologie agili come qualcosa che è lì per aiutarti a capire cosa funziona meglio per te . Sono lì per aiutarti a raggiungere quell'altopiano "non c'è cucchiaio", ma come esattamente ciò che accadrà dipende interamente da te e ciò che ti viene in mente alla fine si sovrapporrà notevolmente con alcune metodologie su vari livelli, eppure sarà qualcosa di completamente tuo.

Dal momento che stai cercando di trovare il tuo modo di fare le cose per migliorare la tua efficacia complessiva, ecco alcuni suggerimenti che possono aiutarti almeno a non fare gli stessi errori che ho fatto:

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

Il fatto che siano più adatti a facilitare la collaborazione in team è un altro punto. Resisti alla tentazione. Non ti inscatoli in un modo di fare le cose e poi speri di adottarlo funzionerà per il meglio. Non ti frustra. Prima trovi il tuo modo di fare le cose e poi cerchi una soluzione software adatta. Ho finito con l'uso di lavagne (iniziata con una, ma ora ne ho due nella mia stanza) per tenere traccia / sviluppare storie e la tecnica Pomodoro | La lista delle cose da fare oggi per tenere traccia delle mie attività di sviluppo ed è la novità del 2011. Attenersi alle basi fino a quando non avremo alcune interfacce come quelle di Iron Man 2 o delle macchine volanti che iniziano ad apparire.

Riflessione, riflessione, riflessione

Questo è ciò che ho capito essere la 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 in un modo che è facilmente gestibile e in cui le decisioni sbagliate vengono prese raramente e si distinguono in modo che possano essere rapidamente modificate prima che causino danni ... ma non puoi semplicemente prenderlo dallo scaffale. Inizia da qualche parte, ovunque. Rimani con esso per tutto il tempo in cui funziona. Investi nel tracciare il buono, il brutto e così via. Migliora i tuoi presupposti, quindi regola il modo in cui fai le cose di conseguenza. Questo è l'unico modo per migliorare.

Furget sulle scadenze, concentrati su quanto velocemente fai le cose

Probabilmente ero come il ragazzo successivo quando ho iniziato, a caccia di date. Grafici di burnout? Li consideravo un modo per visualizzare il mio percorso di sviluppo rispetto alle scadenze. È una performance, non un modello di stima. Il tempo è lì per misurare la tua efficacia riflettendo sul lavoro svolto in un determinato intervallo di tempo, non solo un valore stupido per rappresentare la distanza prima di impedire le scadenze. La realtà è che le cose vengono fatte quando sono fatte e la tua metodologia dovrebbe tenerne conto.

Deviare di conseguenza

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

Risponderei "come vuoi migliorare il modo in cui sviluppi il software?". Per il tuo modello di business, quali sono i maggiori problemi che hai riscontrato utilizzando la metodologia a cascata?

Il tuo obiettivo è uno sviluppo più rapido, un codice più solido, un maggiore riutilizzo, il rispetto / l'adattamento ai mutevoli requisiti, ecc.? Esistono diverse metodologie per superare problemi diversi.

Naturalmente l'adozione di una metodologia di progettazione diversa da Waterfall può essere molto utile nella gestione efficace del ciclo di vita di un progetto in base alle esigenze aziendali. Per lo sviluppo agile ci sono un gran numero di risorse online. Vorrei esaminare AUP (Agile Unified Process) che incorpora TDD (Test Driven Development). Ciò può essere estremamente utile durante la creazione / gestione di grandi sistemi scalabili.

Non esiste una metodologia "unica per tutti" e questa è la ragione principale del vasto numero di approcci diversi. Vorrei iniziare a pensare a dove ritieni che siano i colli di bottiglia nel tuo processo di sviluppo e quindi provare ad adottare una nuova metodologia per ovviare a questo.

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