Quanto ben definito dovrebbe essere un prodotto software prima di iniziare a codificare?

13

Volevo sapere quanto bene le persone generalmente definiscono un prodotto software prima di iniziare effettivamente a codificare e quanto bene ha funzionato per loro? Mi riferisco alla definizione di casi d'uso, analisi del rischio, disegno di diagrammi di classe, ecc.

So che è una buona idea avere un'idea abbastanza precisa di quale sarà il prodotto finale per poter evitare rischi in futuro, ma è anche importante non definire un prodotto così bene che è difficile adattarsi al cambiamento.

Altre domande più specifiche sarebbero probabilmente:

  1. Quale percentuale del tempo di un progetto viene normalmente spesa nelle fasi di pianificazione prima dello sviluppo?

  2. Hai determinati criteri misurabili che cerchi di soddisfare prima di iniziare a scrivere il codice o è più una questione di budello?

  3. Descrivi tutte le classi prima di iniziare a scrivere il codice, o si sta tentando principalmente di creare un design dinamico fin dall'inizio aspettando che le cose cambino?

Qualsiasi esperienza che desideri condividere sarebbe fantastica!

    
posta drewag 15.04.2011 - 04:27
fonte

6 risposte

10

La risposta letterale a "quanto è ben definito?" è

Ben definito abbastanza da poter iniziare.

Ben definito abbastanza da poter identificare uno scopo iniziale del lavoro (per un concetto iniziale). Questo è sufficiente per identificare i cambiamenti che inevitabilmente si verificheranno.

Ben definito abbastanza da poter dare la priorità agli sprint.

I am referring to defining use cases,

Sempre utile. Ma non tutti . Devi dare la priorità e coprire prima i casi d'uso importanti. Altri casi d'uso saranno trattati nelle versioni successive. Alcuni casi d'uso avranno una priorità così bassa che non verranno mai eseguiti.

analyzing risk,

Generalmente una perdita di tempo.

drawing class diagrams, etc.

Se aiuta.

What percentage of a project's time is normally spent in the planning stages before development?

Varia molto. Compra un buon libro, come Software Engineering Economics per ottenere numeri "autorevoli".

Do you have certain measurable criteria you try to meet before starting to code or is more of a gut thing?

"misurabile". È quasi impossibile da definire.

"gut". Cattiva politica.

Il problema è "hai capito cosa stai facendo?"

Non è una cosa istintiva. È una domanda Sì / No.

Non è "misurabile" poiché è solo una domanda si / no.

E, inoltre, devi dare la priorità. Non fai tutto. Quanto basta per gestire i primi sprint.

Do you diagram all classes before beginning to code, or is it mostly trying to create a dynamic design from the beginning expecting that things will change?

Non puoi sapere tutto in anticipo.

Non provare.

    
risposta data 15.04.2011 - 04:56
fonte
2

Se il tuo cliente aderisce attivamente al progetto come membro del team di progetto, che è disponibile per gli sviluppatori per domande e prendere decisioni rapide sulla funzionalità. Quindi la specifica potrebbe essere meno dettagliata.

Se il tuo cliente è lontano e non è disponibile per il feedback in un lungo periodo di tempo, le tue specifiche dovrebbero essere molto dettagliate.

Nella nostra azienda creiamo storie di utenti e giochiamo a Pianificazione del poker con gli sviluppatori del progetto. Questo ci dà una buona indicazione delle ore da spendere per un utente.

    
risposta data 15.04.2011 - 07:43
fonte
2

Quanto è ben definito il progetto deve essere sufficiente per iniziare e sapere dove si dirigerà per le prossime due settimane.

Come Scrum Master, vorrei semplicemente dire che è necessario definire le funzioni lorde del prodotto in un foglio Excel o altrove, solo per tenere traccia delle proprie funzionalità. Rendendoli User Story aiuta molto a pensare a quali funzionalità hai bisogno in seguito. Quindi, assegna loro la priorità: La caratteristica più importante o imperativa nella parte superiore e la meno importante nella parte inferiore.

Dopo aver elencato alcune delle funzionalità più importanti, seleziona le funzionalità che ritieni di poter sviluppare portare allo stato di Fatto dopo un periodo di due settimane o un mese se preferisci. Quindi esplora la funzione selezionata in modo da poter iniziare la codifica in pochi.

Durante la codifica, penserai sicuramente ad altri elementi da sviluppare per portare le tue funzionalità selezionate in uno stato Fatto. Fatto significa che non hai più nulla da fare, cioè test, codifica, assemblaggio, la documentazione è fatta!

In qualsiasi momento l'elenco delle funzioni selezionate potrebbe espandersi, a patto che tu raggiunga l'obiettivo, ovvero, sei in grado di sviluppare tutto ciò che hai detto che avresti fatto durante il periodo indicato.

In breve, niente deve essere perfetto. Getta alcune idee, condividi con i tuoi compagni e verifica se ciò che è scritto ha senso per soddisfare i requisiti di prodotto richiesti. Se è così, allora sei dentro! Per chiarire, vado con un semplice prodotto di gestione clienti. Cosa è necessario?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

La tua prima bozza potrebbe essere così semplice! Quindi, possiamo vedere che la sicurezza è una parte importante del nostro sistema, è abbastanza importante da rendere la priorità assoluta (S / N)? Questo dipenderà dai requisiti che devi soddisfare. Diciamo che la gestione dei clienti è la cosa più cruciale qui. Quindi, nel prossimo Sprint, dobbiamo essere in grado di gestire i clienti in modo semplice ma accettabile. Cos'è la gestione clienti?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Questo illustra già abbastanza funzionalità per poter iniziare a sviluppare l'applicazione. Se i tuoi programmatori hanno bisogno di ulteriori istruzioni, forse uno sviluppatore che si trova a suo agio con i diagrammi delle classi può progettare la classe del cliente e le sue proprietà e metodi! Ma per quanto mi riguarda, con questi pochi che ho scritto, ne avrei abbastanza per iniziare. Alcune funzionalità possono essere aggiunte o modificate lungo il percorso. Ciò che è importante è concentrarsi su ciò che hai detto che sarebbe stato Fatto. Nel nostro esempio, è la cosa di Customer Management. Non ci dobbiamo preoccupare dell'autenticazione dell'utente come ora. Arriverà più avanti nel prossimo Sprint.

Spero che questo aiuti! =)

    
risposta data 15.04.2011 - 08:14
fonte
1

Bene, ciò che funziona per me è avere la funzionalità "abbastanza bene" specificata e l'architettura del software solo speciosamente definita.

Per iniziare a lavorare, ho bisogno di sapere a cosa sto lavorando. Non funziona per me quando capisco semplicemente le esigenze del cliente. Anche se sto scrivendo uno strumento per uso personale, disegno gli schermi, descrivo la funzionalità, cosa fa ogni pulsante, tutto. Altrimenti, trovo che non posso iniziare.

D'altra parte, ho rinunciato a capire esattamente come svilupperò il codice. Forse questa è una pratica peggiore, ma funziona per me. Potrei definire una serie di tabelle di database che creerò, ma non quali colonne sono in ciascuna di esse. Potrei pensare a quali oggetti e classi ho bisogno, ma sicuramente non disegnare diagrammi.

Diavolo, a volte non so nemmeno come farlo, se non dopo aver sbagliato. Lo costruisco una volta, lo abbatto e lo rifaccio, ora che so come. A questo punto posso disegnare una roadmap dettagliata e riavviare.

    
risposta data 15.04.2011 - 07:30
fonte
1

Quale lingua e metodologia stai utilizzando?

Alcuni linguaggi, come Java e C ++, richiedono più struttura iniziale di linguaggi come Common Lisp o Python (C ++ più di Java, perché il refactoring è più semplice in Java). Leo Brodie (penso in "Thinking Forth") ha dato due consigli su quando iniziare a programmare: prima di quanto ti senti a tuo agio con Forth, più tardi di quanto vorresti in un'altra lingua.

La metodologia della cascata (in particolare quando il progetto iniziale è un deliverable) richiederà un lavoro più immediato di quello agile (anche se non si vuole trascurare la pianificazione anticipata con metodi agili). Avere una buona serie di test automatizzati rende più sicuro cambiare cose più grandi, e quindi consente di lavorare con meno lavoro in anticipo.

Inoltre, dipende dalle persone e dalla loro familiarità con il tipo di software da creare. Ad un certo punto, quando facevo principalmente applicazioni CRUD, potevo scrivere un intero programma partendo da alcune specifiche e un pezzo di carta bianca da 3 "x 5". Non posso scrivere le cose che scrivo ora in quel modo.

    
risposta data 15.04.2011 - 16:54
fonte
1

Due termini utili qui sono MVP (Prodotto minimo vitale) e MMF (Caratteristica minima di mercato). Un MMF è la versione più piccola di una funzionalità che offre valore aziendale. Un MVP è il meno MMF possibile come prodotto. Quando si avvia un progetto, la cosa migliore da fare è identificare MMF e MVP e iniziare da lì.

Rilascia il tuo prodotto non appena è praticabile, quindi continua a migliorarlo in modo incrementale.

    
risposta data 15.04.2011 - 17:48
fonte