Come fai a sapere quando interrompere l'aggiunta di funzionalità?

Qualche tempo fa ho scritto uno script Python molto piccolo che controlla periodicamente un feed XML per nuove voci e avvisa l'utente di nuove voci quando presenti. Ho scritto questo per me stesso, quindi era essenzialmente un programma basato su console che chiunque avrebbe potuto usare con un'interfaccia console avrebbe potuto usare.

Dopo un po 'ho deciso che poteva essere più utile per altre persone e ho iniziato a riordinare, disinfettare gli input, rimuovere i bug. Mi è venuto in mente che, poiché avevo scritto la sceneggiatura, sapevo come usarla in modo efficiente, accurato, ecc. Altri no, quindi ho iniziato ad aggiungere una GUI. Questo è iniziato come un semplice menu, per poi essere esteso a una GUI più completa con un'interfaccia e un menu di opzioni. Ho quindi aggiunto le preferenze dell'utente memorizzato e anche l'archiviazione per i feed XML precedentemente cercati per accelerare le ricerche ripetute.

Ho aggiunto la registrazione per aiutare il debug dell'applicazione in caso di problemi, ho portato l'applicazione all'ultima base di codice Python stabile disponibile per la mia piattaforma prescelta e funzionalità di dialogo migliorate.

Ho corretto un bug e commentato chiaramente il mio codice, eppure ho ancora cose che penso possano essere fatte per migliorare l'app prima di renderla disponibile per i tester alfa. È molto lontano dal mio copione originale di 20-30 righe. Ciò che mi aspettavo impiegherebbe solo un'ora o due per passare dalla dimostrazione del concetto a un programma di utilizzo accettabile che ha richiesto 10-20 volte. (Sono ancora un noob, e le cose mi richiedono molto tempo, ma comunque ....)

Come fai a sapere quando smettere di aggiungere / modificare / riparare oggetti e lasciare che il tuo bambino striscia fuori all'aperto?

Quando raggiungi la scadenza.

Se non hai una scadenza, questo è il tuo problema ...

Ecco come lavoro:

1. Aggiungo nuove funzionalità / bug nel mio backlog di prodotto.
2. Dò la priorità all'intero arretrato di prodotto sul valore aziendale e stimato (l'ultimo è facoltativo in caso di progetto personale).
3. Assegno il tempo di lavoro a me stesso. La data di uscita è la fine di quel tempo.
4. Comincio con il primo nella lista. Lavoro su un film alla volta. Per essere completata, una funzione deve essere davvero completa, compresa la documentazione (al termine di una funzione, posso potenzialmente spedire il prodotto).
5. Prendo il prossimo fino a quando il mio tempo assegnato è consumato.
6. Se il tempo è sprecato durante la creazione di una funzione, la scarto temporaneamente.
7. Quando il tempo allocato viene consumato, prendo l'ultima build e ne rilascia una versione.
8. Ripeto il processo dal punto 1.

Effettuare un SRS quindi codificare in base ai requisiti. Quando hai raggiunto tutti gli obiettivi menzionati nell'SRS è il momento di interrompere e testare il tuo prodotto.

A breve termine, quando hai qualcosa che funziona in modo affidabile e non si blocca. Anche se non fa tutto ciò che potrebbe fare se ci lavorassi indefinitamente. La spedizione come dice il proverbio è una caratteristica . L'affidabilità e il set di funzionalità limitate ti danno l'opportunità di testare le funzionalità di base da parte di persone reali nel mondo reale, che troveranno cose che non hai mai pensato che possano spezzare il tuo codice in modi che non ti passerebbero mai per la testa. Meno funzioni hai, a questo punto, più facile sarà risolvere questi primi problemi. Poiché la funzionalità principale funziona in modo più affidabile, puoi iniziare a implementare le altre cose "belle da avere" con la consapevolezza che il tuo codice centrale e più importante funziona ancora bene.

A lungo termine: dopo aver completato e documentato il sistema di plug-in che consentirà ai vostri utenti (e ovviamente a voi) di implementare nuove funzionalità rapidamente e facilmente se ne avete bisogno. Dovrebbe essere l'ultima funzione che devi aggiungere, dopo che sono tutti plug-in.

Quando sei sicuro della stabilità del tuo software, richiedi un rilascio, anche se ci possono essere funzionalità in sospeso. La stabilità è più importante delle caratteristiche. Ottieni il feedback, incorporalo con le funzionalità esistenti e decidi cosa deve essere consegnato dopo e quando!

Puoi sempre curare un progetto nei secoli dei secoli.

Una regola molto buona è quella di non aggiungere mai cose che non si trovano in un caso d'uso approvato. Questo ti assicura di non finire con molte cose che sarebbe bello avere, ma che nessuno usa. L'approvazione garantisce che altri oltre a te concordino sul fatto che ciò sia necessario nel tuo progetto.

Dipende dal motivo per cui stai aggiungendo funzionalità. I proprietari del progetto lo stanno chiedendo? gli utenti? QA? Programmatori?

• Aggiungi le funzionalità che devi.
• Passa al setaccio le funzionalità che sono importanti.
• Ignora le funzionalità che è bello avere.

Concentrati sullo scopo del programma e focalizza il suo scopo. Le richieste di funzionalità che estendono il suo scopo dovrebbero essere messe in discussione accuratamente prima che diventi un coltellino svizzero.

Non smetto più di aggiungere funzionalità. Cerco solo di far uscire l'app appena possibile e di scrivere file txt se necessario. Quindi posso decidere quando fermarmi e quando lavorare su qualcosa di diverso

Aiuta anche il fatto che mi piace fare il minimo possibile per fare qualcosa (senza ricorrere all'hacking).

Ti consiglierei timebox it. Datti una settimana per dire. Crea un elenco di lavori da completare durante quella settimana e assicurati che se hai una funzione che non riesci a completare, puoi ritirarla.

Alla fine della settimana rilascialo. Rilasciare presto, rilasciare spesso.

Quando hai qualcosa di affidabile e utile, rilascia. Non devi smettere di aggiungere funzionalità, ma se qualcuno utilizza ciò che hai pubblicato, avrai un'idea molto migliore di quali funzionalità sono richieste. Attualmente, stai indovinando.