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


13

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

So che è una buona idea avere una buona idea di ciò che il prodotto finale sarà in grado di evitare rischi in futuro, ma è anche importante non definire un prodotto così bene che è difficile adattarsi modificare.

Altre domande più specifiche sarebbero probabilmente:

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

  2. Hai alcuni criteri misurabili che provi a soddisfare prima di iniziare a scrivere codice o è più una cosa di budello?

  3. Diagrammi tutte le classi prima di iniziare a scrivere il codice o sta cercando principalmente di creare un design dinamico dall'inizio aspettandosi che le cose cambino?

Qualsiasi esperienza che vorresti condividere sarebbe fantastica!

Risposte:


10

La risposta letterale a "quanto ben definito?" è

Ben definito abbastanza da poter iniziare.

Ben definito abbastanza da poter identificare un ambito di lavoro iniziale (per un concetto iniziale). Questo è appena sufficiente per aiutare a identificare i cambiamenti che inevitabilmente accadranno.

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

Mi riferisco alla definizione di casi d'uso,

Sempre utile. Ma non tutto . 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.

analisi del rischio,

Generalmente una perdita di tempo.

disegno di diagrammi di classe, ecc.

Se aiuta

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

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

Hai alcuni criteri misurabili che provi a soddisfare prima di iniziare a scrivere codice o è più una cosa di budello?

"misurabile". È quasi impossibile da definire.

"intestino". Cattiva politica.

Il problema è "capisci cosa stai facendo?"

Non è una cosa di budello. È una domanda sì / no.

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

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

Diagrammi tutte le classi prima di iniziare a scrivere il codice o sta cercando principalmente di creare un design dinamico dall'inizio aspettandosi che le cose cambino?

Non puoi sapere tutto in anticipo.

Non provarci


personalmente trovo che passare troppo tempo a scrivere diagrammi di classe sia una perdita di tempo poiché il modello e il codice con esso cambiano comunque dopo l'inizio.
AndersK,

Sono d'accordo che non puoi sapere tutto in anticipo, ma un buon documento di progettazione ti aiuterà almeno a identificare l'ambito e le caratteristiche quando si verificano.
Tim Post

@Tim Post: buon suggerimento. Questo è un modo per definire il "quanto ben definito" nella domanda. "Ti aiuterà a identificare l'ambito e il creep delle funzionalità". Non molto di più, vero?
S. Lott,

@Tim Post: "identifica ambito" è fuorviante. Implica che ci sia una certa conoscenza di "ambito" disponibile all'inizio del progetto, il che non è vero. L'ambito cambierà durante il ciclo di vita del progetto man mano che le esigenze aziendali cambiano, perché nessun mercato è statico.
Rein Henrichs,

@Rein Henrichs: ho leggermente modificato la risposta per incorporare il tuo punto. Abbastanza definizione dell'ambito per iniziare. Sono tentato di aggiungere "e non di più".
S.Lott

2

Se il cliente si unisce attivamente al progetto come membro del team di progetto, che è disponibile per gli sviluppatori per domande e prendere decisioni rapide sulla funzionalità. Quindi le specifiche potrebbero essere meno dettagliate.

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

Nella nostra azienda creiamo storie utente e giochiamo a Planning Poker con gli sviluppatori del progetto. Questo ci dà una chiara indicazione delle ore da trascorrere in una user story.


Un "rappresentante del cliente" (il ruolo che stai suggerendo per il cliente) è il ruolo più vitale in tutto il team. Se il tuo team non è in grado di ottenere risposte su domande relative a prodotti e aziende, come devono prendere la decisione giusta?
Rein Henrichs,

Questo è un ottimo punto, grazie! Non ho considerato come il coinvolgimento del cliente potesse cambiare così drasticamente ciò che funziona meglio per un determinato progetto. Sicuramente qualcosa che dovrei tenere a mente. Inoltre, non avevo mai sentito parlare di "Planning Poker" e sembra che sarebbe davvero prezioso.
Drewag,

2

Quanto ben definito deve essere il progetto è abbastanza buono per iniziare e sapere dove andrai nelle prossime due settimane.

Come Scrum Master, direi semplicemente che devi definire le funzionalità lorde del tuo prodotto in un foglio Excel o altrove, solo per tenere traccia delle tue funzionalità. Renderli User Stories aiuta molto a pensare a quale funzionalità è necessaria dopo. Quindi, assegnale le priorità: la caratteristica più importante o imperativa verso l'alto e il minimo verso il basso.

Dopo aver elencato alcune delle funzionalità più importanti, seleziona le funzionalità che ritieni possano essere sviluppate e porta allo stato di Fine dopo un periodo di due settimane o, se preferisci, un periodo di un mese. Quindi, esplodi queste funzionalità selezionate in modo da poter iniziare a scrivere in pochi.

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

In qualsiasi momento l'elenco delle funzionalità selezionate può espandersi, purché si raggiunga l'obiettivo, vale a dire che si è in grado di sviluppare tutto ciò che si è detto durante un determinato periodo.

In breve, niente deve essere perfetto. Inserisci alcune idee, condividi con i tuoi compagni e vedi se ciò che è scritto ha senso per soddisfare i requisiti di prodotto richiesti. Se è così, allora sei dentro! Per chiarire, andrò con un semplice prodotto di gestione dei clienti. Ciò che è 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 nel nostro sistema, è abbastanza importante fare la massima priorità (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 dei 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 già illustra abbastanza funzionalità per essere in grado di iniziare a sviluppare l'applicazione. Se i tuoi programmatori hanno bisogno di ulteriori istruzioni, allora forse uno sviluppatore che è a suo agio con i diagrammi di classe può progettare la classe del Cliente e le sue proprietà e metodi! Ma per quanto mi riguarda, con questi pochi che ho scritto, avrei abbastanza per iniziare. Alcune funzionalità possono essere aggiunte o modificate lungo il percorso. L'importante è concentrarsi su ciò che hai detto che sarebbe stato fatto. Nel nostro esempio, è la questione della gestione dei clienti. Non abbiamo bisogno di preoccuparci dell'autenticazione dell'utente a partire da ora. Questo arriverà più avanti nel prossimo Sprint.

Spero che questo possa essere d'aiuto! =)


Grazie mille! È stato bello vederlo in uno scenario così specifico. Sento che questo è un buon quadro per avere qualcosa che sia almeno in qualche modo misurabile pertinente a ciò che si definisce sul prodotto complessivo, ma sottolineando i sotto-aspetti e un approccio orientato alle caratteristiche. Questo approccio sarà sicuramente importante quando inizierò nuovi progetti in futuro!
Drewag,

Prego! Sono contento che il mio granello di sale possa aiutarti! =) È importante non definire funzionalità troppo approfondite, poiché i requisiti del prodotto possono cambiare lungo il percorso perché il cliente, quando vedrà ciò che hai fatto finora, potrebbe avere altre idee o modifiche da apportare a ciò che hai Fatto. Dovrai adattare il prodotto di conseguenza in modo che soddisfi i nuovi requisiti. Quindi, se hai stabilito tutto in una volta all'inizio del progetto, immagina la perdita di lavoro che ciò può causare! Forse avrai lavorato ore solo per buttarlo via e ricominciare da zero. Let it evolve =)
Will Marcouiller,

1

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

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

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

Cavolo, a volte non so nemmeno come farlo bene fino a quando non ho sbagliato. Lo costruisco una volta, lo demolisco e lo faccio di nuovo, ora che so come. A questo punto posso disegnare una roadmap piuttosto dettagliata e ricominciare.


Grazie per aver condiviso la tua esperienza. Sembra andare d'accordo con il consenso sul fatto che l'importante sia che tu, come sviluppatore, ti senti abbastanza a tuo agio per iniziare. Naturalmente scoprirai cose che cambieresti se dovessi farlo di nuovo, altrimenti passerai troppo tempo a pianificare. Conosco la sensazione di voler fare una riscrittura completa non appena un prodotto è finito, ed è una specie di ciò che sto cercando di evitare;) (almeno in misura ragionevole).
Drewag,

1

Quale lingua e metodologia stai usando?

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

La metodologia delle cascate (in particolare quando il progetto iniziale è realizzabile) richiederà un lavoro più diretto che agile (anche se non si desidera trascurare la pianificazione precoce nei metodi agili). Avere un buon set di test automatizzati rende più sicuro cambiare cose più grandi, e quindi ti permette di cavartela con meno lavoro iniziale.

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


Grazie per la prospettiva. Non avevo considerato come il linguaggio e la piattaforma potessero influenzare le migliori pratiche in termini di gestione dei progetti. Mi capita di parlare principalmente di Objective-C, UIKit e AppKit. Comunque lavoro anche in molti altri linguaggi (C, C ++, C #, Java, Python, ecc.). Ciò significa che dovrei stare attento a non dare per scontato che un determinato metodo sia il migliore per tutti i progetti, dovrei adattare la mia base metodologica sulla piattaforma e sulla lingua di destinazione (e forse scegliere una lingua in base a quella se ho una scelta).
Drewag,

1

Due termini utili qui sono MVP (Minimo prodotto praticabile) e MMF (Minimo caratteristica negoziabile). Un MMF è la versione più piccola di una funzionalità che offre valore aziendale. Un MVP è il minor numero di MMF utilizzabili come prodotto. Quando si avvia un progetto, la cosa migliore da fare è identificare MMF e MVP e iniziare da lì.

Rilasciare il prodotto non appena è possibile, quindi continuare a migliorarlo in modo incrementale.


Questa è una terminologia davvero eccezionale, grazie! Questa è di gran lunga la cosa migliore qui per trovare qualcosa di misurabile. Ovviamente non è perfetto, ma sembra che sarà ragionevolmente facile decidere se una funzionalità è commercializzabile e / o aggiunge valore al prodotto.
Drewag,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.