Come evitare lo scorrimento delle funzioni in un progetto solista?

Quindi ho un programma su cui ho lavorato nel 2011 e per tutto il 2012, ma l'ultima versione è stata nel dicembre del 2011 . Ci ho lavorato attivamente, ma il creep ha attirato la sua brutta testa e ora è pieno di tonnellate di funzionalità non finite.

La parte brutta è che mentre implemento una funzione, ne entra una nuova. Cosa posso fare per evitare il creep in futuro in modo da poter effettivamente rilasciare un rilascio in più di un anno ?

Il progetto si basa su iOS e aveva versioni intorno ad ogni aggiornamento della versione di iOS, ma l'ultimo era di nuovo con 5.1 (2011). Mi piacerebbe riuscire a riavere quel ciclo di rilascio costante, ma si è rivelato troppo difficile.

Nella mia esperienza, è più semplice se puoi avere una cadenza di sviluppo e rilascio che non interferisce con ciò che vuoi fare. Ecco come l'ho fatto:

1. Scrivi le caratteristiche e dai loro una valutazione che rifletta quanto vuoi lavorarci e quanto pensi che ne trarrà beneficio per l'utente (potrebbe essere possibile coinvolgere gli utenti reali per questo). Quindi scriverli in questo ordine.
2. Prima di effettuare il check-in / push di una funzione, assicurati di avere una build stabile e distribuibile (considera fortemente un sistema CI per facilitarla).

In questo modo, puoi semplicemente rilasciare una versione dopo ogni funzione se vuoi ... o attendere un rollup che offra il valore che desideri avere una versione.

Nota:

• Una funzione non può mai avere una priorità più alta di quella su cui stai lavorando (o può, ma non può interrompere quella su cui stai lavorando). Può venire dopo, ma mai ora . Ciò significa che quando passerai da un momento all'altro, avrai l'opportunità di tagliare una build di rilascio, se lo desideri.

La risposta è banale e spesso impossibile: rifiutare di aggiungere funzionalità aggiuntive.

Più in profondità, la risposta si riduce davvero a ciò che fa cadere una nuova funzione nel creep bin? Se assumiamo che le caratteristiche che si insinuano siano quelle che vengono aggiunte a un progetto nonostante il fatto che la loro funzionalità sia solo tangenziale per l'uso previsto del progetto e che le caratteristiche striscianti siano utili, non superflue, la risposta è spostarle per separarle , ma strumenti correlati. Usa la filosofia Unix per costruire strumenti ortogonali e incollarli insieme.

Dal punto di vista della gestione del progetto, la risposta è comparabile. Decidi quanto tempo sei disposto a dedicare alla prossima versione e fissa una scadenza. Stimare le funzionalità e tagliare abbastanza per rispettare la scadenza. Se ci sono parti interessate diverse da te, fai loro scegliere ciò che conta di più per loro.

Una buona panoramica sulla programmazione è disponibile su Joel on Software:

http://www.joelonsoftware.com/articles/fog0000000245.html

Una delle lezioni più importanti nello sviluppo è sapere quando è il momento di smettere.

Ciò che accade in genere è che uno sviluppatore aggiunge funzionalità. Ciò a sua volta ispira più idee. Quindi vengono aggiunte più funzionalità. Questo è, come hai detto, uno dei modi in cui un progetto diventa vaporware. Lo sviluppatore non vede mai il progetto come "finito", quindi non viene mai rilasciato.

L'abitudine che vuoi prendere è quella di smettere di pensare in termini di una versione / rilascio come un progetto "finito". Piuttosto, guarda allo sviluppo come un processo a lungo termine. Pensa alle pubblicazioni come pietre miliari lungo il percorso verso ciò che un giorno speri sarà il programma. Pertanto, una versione / rilascio è solo un'istantanea di dove ti trovi nel processo a lungo termine ... un'istantanea che è stata ben completata e testata.

Quello che puoi fare, sul lato pratico, è sederti e specificare la tua prossima versione. Non deve essere tremendamente accurato. Annota le 3-5 nuove principali funzionalità che ritieni essenziali per la prossima versione. ( il numero effettivo di funzionalità può variare a seconda del tipo di app, senza contare le correzioni di bug o le modifiche minori alla gui ) Lavora su quelle. Se ti vengono in mente altre idee, va bene ... prendi appunti e implementali nella seguente versione. Quando ottieni questi 3-5 articoli, la tua versione è pronta per la beta.

Quando avvio una nuova applicazione, in genere penso alla "visione" finale dell'app. Questo, per me, è quello che voglio nella versione 3 dell'app. Con quel benchmark, ho un'idea di ciò che renderà solida la versione 1 - solo le basi.

Sommario:

Ogni versione non deve essere la 'visione' finita del progetto. Solo una pietra miliare verso quella visione.

Utilizzare un sistema di controllo della versione in cui è economico creare un ramo per qualche idea e tenerlo fuori dal percorso di rilascio. Ad esempio git, puoi "insinuare" qualche idea, e poi git stashvia. Successivamente puoi rivedere queste scorte e sceglierle in qualsiasi ordine sembri interessante.

Per funzionalità più grandi, crea un vero ramo (in modo da poter eseguire più commit). Caso in questione: quando volevo aggiungere il supporto generazionale al garbage collector, ho creato un ramo. Gli stash catturano molto bene le piccole cose che distraggono. Le grandi funzionalità possono iniziare come stash, quindi trasformarsi in rami e infine fondersi quando sono pronti.

Con stash e rami, puoi fare il punto sulle tue idee, dare loro la priorità e stabilire un ambito per le versioni del tuo progetto solista, proprio come un progetto di gruppo gestito.

Guarda, quando ti viene un'idea, deve andare da qualche parte , e il migliore da qualche parte è il codice : il repository. Le caratteristiche striscianti sono meglio che dimenticare le buone idee. Ma ovviamente, se insinui tutte le tue funzionalità nella stessa linea principale, continuerà a ritardare il rilascio, a meno che non tagli le pubblicazioni disordinate piene di cose fatte a metà che gli utenti devono essere avvisati di non usare.