Come evito il creep delle funzionalità su un progetto solista?

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

1. Scrivi le funzionalità in basso e attribuisci loro una valutazione che rifletta quanto vuoi lavorare su di esso e quanto pensi che avvantaggerà l'utente (potrebbe essere possibile coinvolgere gli utenti effettivi per questo). Quindi scrivili in questo ordine.
2. Prima di effettuare il check-in / spingere una funzione, assicurati di avere una build stabile e distribuibile (considera strongmente un sistema di CI per facilitare ciò).

In questo modo, puoi semplicemente rilasciare un rilascio dopo ogni funzione se vuoi ... o aspettare un rollup che offra il valore che vuoi che una versione abbia.

Nota:

• Una funzionalità 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 next ma mai ora . Ciò significa che quando si passa da ora a quella successiva, si avrà l'opportunità di tagliare una build di rilascio, se lo si desidera.

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

In modo più approfondito, la risposta si riduce a ciò che fa cadere una nuova funzionalità nel Creep Bin? Se supponiamo che le funzionalità che si insinuano siano quelle che vengono aggiunte a un progetto nonostante il fatto che la loro funzionalità sia solo tangente all'uso previsto del progetto e che le caratteristiche striscianti siano utili, non superflue, la risposta è di spostarle in modo separato 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 stabilisci una scadenza. Stimare le caratteristiche e tagliare abbastanza per rendere la scadenza. Se ci sono parti interessate coinvolte diverse da te, fagli scegliere ciò che conta di più per loro.

Una buona panoramica sulla programmazione può essere trovata su Joel on Software:

link

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

In genere, uno sviluppatore aggiunge funzionalità. Questo a sua volta ispira più idee. Quindi vengono aggiunte ulteriori funzionalità. Cioè, 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 a cui vuoi entrare è smettere di pensare in termini di versione / versione come progetto "finito". Piuttosto, considera lo sviluppo come un processo a lungo termine. Pensa alle versioni come traguardi lungo il percorso verso ciò che un giorno spererai che il programma sia. Quindi, una versione / versione è solo un'istantanea di dove ti trovi nel processo a lungo termine ... un'istantanea che è stata completata e testata.

Quello che puoi fare, dal punto di vista pratico, è sederti e provare la tua prossima versione. Non deve essere terribilmente accurato. Annota i 3-5 nuovi principali pezzi di 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 della scheda grafica ) Lavora su quelle. Se trovi altre idee, va bene ... basta prendere appunti e implementarle nella seguente versione. Quando ricevi 3-5 elementi, la tua versione è pronta per la versione beta.

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

Riepilogo:

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

Utilizza un sistema di controllo della versione in cui è economico creare un ramo per qualche idea e tenerlo fuori dal tuo percorso di rilascio. Ad esempio in git , puoi "creep up" un'idea e poi git stash via. Più tardi puoi rivedere questi documenti e selezionarli in qualsiasi ordine sembra interessante.

Per funzionalità più grandi, crea un ramo reale (in modo da poter eseguire più commit). Caso in questione: quando volevo aggiungere supporto generazionale al garbage collector, ho creato una filiale. I cestini catturano molto bene le piccole cose che distraggono. Le grandi funzionalità possono essere avviate come arresti, quindi trasformarle in rami e infine unirle quando sono pronte.

Con le barre e i rami, puoi fare un bilancio delle tue idee, dare la priorità a loro e stabilire uno scopo per le versioni del tuo progetto solista, proprio come un progetto di team gestito.

Guarda, quando hai un'idea, deve andare da qualche parte , e il migliore è code : il repository. Le caratteristiche striscianti sono meglio che dimenticare le buone idee. Ma ovviamente, se tutte le funzionalità si insinuano nella stessa linea principale, manterrà il rilascio ritardato, a meno che non si tagli in modo disordinato le versioni piene di materiale scaduto che gli utenti devono essere avvertiti di non usare.