design in processo agile

Question

design in processo agile

#1 da (4 voti)
#2 da (2 voti)

5

Recentemente ho avuto un'intervista con il team di sviluppo in un'azienda. Il team usa agile + TDD. L'esercizio del codice implementa un negozio di noleggio video che genera una dichiarazione per calcolare la tariffa di noleggio totale per ogni tipo di video (nuova versione, bambini, ecc.) Per un cliente. Il codice esistente usa l'oggetto come:

Dichiarazione per generare una dichiarazione e una commissione di calcolo in cui si trova la dichiarazione di switch grande per utilizzare enum per determinare come calcolare la commissione di noleggio
cliente detiene un elenco di noleggi
classe base film e classe derivata per ogni tipo di film (NUOVO, BAMBINI, AZIONE, ecc.)

Il codice originariamente non viene compilato poiché si presume che il proprietario sia stato colpito da un bus. Quindi ecco cosa ho fatto:

ha delineato il miglioramento rispetto al modello a oggetti per avere una migliore responsabilità per ogni classe.
usa il modello di strategia per sostituire l'istruzione switch e intrecciarli in config

Ma il team dice che è una perdita di tempo perché non c'è alcun requisito e la suite di test UAT funziona ed è l'unica linea guida a prendere decisioni di architettura. La storia di fondo è solo per ottenere funzionalità di prezzo e non dire nulla su come farlo. Quindi la discussione è incentrata sul motivo per cui dovrebbe essere trascorso del tempo sul refactoring dell'affermazione dell'interruttore.

A mio avviso, la metodologia agile non significa zero design in anticipo e tale odore di codice dovrebbe essere evitato all'inizio. Inoltre, qualsiasi suite di test unità / UAT non rileverà tale odore di codice, altrimenti sonar, i findcugs non esistono.

Qui voglio chiedere:

c'è una cosa chiamata design agile nella metodologia agile? Proprio come una documentazione agile.
come definire anticipatamente il design agile? come sapere abbastanza è abbastanza? A mio modo di vedere, l'architettura del ballpark e il contratto di dati tra i componenti dovrebbero essere definiti prima / al momento dell'avvio del progetto, non i dettagli. Ho ragione?
qualcuno può spiegare cosa sta veramente cercando il team in questo tipo di configurazione? è l'aspetto del design o l'aspetto agile?
come implementare il concetto di prodotto minimo vitale nel processo agile nel progetto del mondo reale? È necessario che ti senti imbarazzato per essere MVP?

agile mvp

posta ying 19.10.2013 - 16:03

fonte

2 risposte

Leggi altre domande sui tag agile mvp

Come conciliare OOAD e Database Design? Cancellare il bit più basso di un numero

score 4 · Answer 1

Ci sono molti approcci nel mondo reale su questo. Stai facendo una domanda molto ampia quindi la mia risposta sarà un po 'generica.

Naturalmente c'è un concetto di design in agile. Normalmente non esiste un concetto di design up-front , ma i sistemi sono progettati come si va e, naturalmente, i sistemi legacy hanno un design.
In senso stretto, dovresti fare il design minimo indispensabile che ti puoi permettere. È perfettamente possibile che un sito Web inizi con una pagina html statica ospitata da qualche parte. In effetti, molti siti lo fanno. Certo, a volte è necessario fare un po 'di lavoro in anticipo per implementare un design snello, ma dovremmo parlare di giorni di lavoro al massimo.
Questa è una domanda per la tua squadra, ma non penso sia corretto farne una domanda in anticipo. I team non hanno bisogno di nulla oltre ai computer in rete. Tutto ciò di cui una squadra ha bisogno è determinato da ciò che il team deve raggiungere.
MVP è il set minimo di cose che devi spedire per avere un valore. In genere si tratta di una "registrazione per la pagina beta". Dopodiché, la quantità minima di funzionalità che consentirà al tuo prodotto di funzionare. Vorrei sottolineare "minimo" qui: prendere il set "no-so-minimum" di funzionalità che è probabile che si presentino inizialmente, e iniziare a rimuovere tutto ciò che è possibile mantenendo il core funzionante. L'intero punto è abilitare un ciclo di feedback con i primi utenti. Un MVP deve essere una versione alfa, non una versione beta.

score 2 · Answer 2

L'aspetto importante del design in un processo agile è che deve essere eseguito entro nel processo. Una delle prime cose da produrre è un design, altrimenti non hai idea di cosa stai facendo. Ma quel progetto non dovrebbe richiedere molto tempo e dovrebbe essere un artefatto soggetto a revisione attraverso il processo agile proprio come il codice. Non dare per scontato che lo farai bene prima. Non aver paura di aggiungerlo se necessario e di rifattenerlo se è troppo complicato.

Cerca di mantenere il design su qualcosa che si adatti a una pagina (o una diapositiva) in modo che le persone possano capire dove il pezzo su cui stanno lavorando si inserisce nel quadro generale. Certo, questo non coprirà tutti i casi, ma la progettazione in primo piano per coprire tutto è non una pratica agile; questo deriva naturalmente dal principio fondante che i requisiti non sono tutti noti in anticipo (e il punto ovvio che il vero design deriva dai requisiti).

Per sapere quando hai troppo? Francamente, probabilmente hai già troppe cose. Il design di alto livello, il bit veramente utile, non dovrebbe richiedere troppo tempo e il design di basso livello è proprio quello che esce dall'arretrato. (Suggerimento: se stai pensando ad algoritmi nel design, hai già quasi certamente troppi dettagli. Beh, a meno che tu non stia facendo qualcosa di così funky che è impossibile senza quell'algoritmo specifico ...)

Ciò che è importante per il team è che ottengono qualcosa e ricontrollano il proprietario del prodotto per la successiva iterazione verso la comprensione dei requisiti. Come con tutto lo sviluppo agile. (Rispetto all'MVV, ricorda che potrebbero esserci alcune iterazioni per arrivarci, e non aver paura di non farlo sembrare buono nei primi giri, i clienti troppo spesso pensano che avere il CSS applicato significa che l'intero servizio è finito. Lo sai e so che non è vero.