Come posso tenere traccia degli attributi di qualità sul Kanban del mio team?

Il mio team utilizza un sistema Kanban per tenere traccia dei progressi quotidiani e ha funzionato davvero bene per comprendere i progressi sulle funzionalità (acquisiti come user story). Abbiamo in gran parte permesso alla progettazione del nostro sistema di emergere mentre sviluppavamo funzionalità che hanno funzionato bene fino a poco tempo fa. Nelle ultime due settimane abbiamo avuto diverse discussioni sui compromessi dell'architettura specificamente legati agli attributi di qualità delle prestazioni e della modificabilità.

Penso che ciò che sta accadendo sia quando implementiamo funzionalità e progettiamo il sistema, prendiamo implicitamente decisioni sull'architettura ma non prendiamo in considerazione quelle decisioni in termini di requisiti di attributo di qualità noti. Sarebbe davvero fantastico se potessi tracciare / catturare / rappresentare visivamente come vengono prese queste importanti decisioni di progettazione in modo che i membri del team abbiano maggiori possibilità di non creare ulteriore tensione nell'architettura del sistema mentre viene implementata. E, naturalmente, per complicare ulteriormente le cose, le caratteristiche della nostra scheda non sono esclusivamente funzionali e talvolta nascondono complessità architettonica!

Come posso monitorare i progressi sugli attributi di qualità (o altre decisioni rilevanti dal punto di vista architettonico) visivamente sul kanban del mio team?

stiamo prendendo implicitamente decisioni sull'architettura ma non le consideriamo in termini di requisiti di attributo di qualità noti.

Penso che sia possibile visualizzarlo creando un passaggio di "revisione dell'architettura" nel flusso di lavoro. Il passaggio sarebbe rappresentato da una colonna della scheda Kanbad con il proprio limite WIP. Il limite WIP dipenderà da quanti architetti / designer devi partecipare a queste recensioni.

Il team di sviluppo è responsabile del flusso orizzontale, da sinistra a destra delle storie degli utenti. Gli architetti, nella maggior parte dei casi, toccheranno le storie solo quando si trovano nella colonna di revisione tecnico / architettonica. L'intersezione della colonna con un piano orizzontale visualizza l'incontro degli sviluppatori e degli architetti.

Uno dei team in cui lavoro ha un passaggio simile in cui esegue una revisione dello schema del database con il capo architetto dei dati. Non usano Kanban, ma se lo facessero, molto probabilmente avrebbero questa colonna sulla loro scheda.

Gli attributi di qualità noti potrebbero quindi essere rappresentati come:

• la definizione di done per la fase di revisione dell'architettura.
• test di accettazione intorno alle storie utente già fatte che rappresentano requisiti non funzionali. Quindi la definizione di done per una nuova user story includerebbe non interrompere quei test.

AGGIUNTO : Il passaggio del flusso di lavoro "Revisione dell'architettura" può essere sospetto di un problema chiamato tragedia dei beni comuni . Ecco un ottimo post sul blog su come la visualizzazione Kanban può aiutare ad affrontarlo e le possibili soluzioni.

Ci sono davvero due parti in questa domanda. Una parte è: come facciamo a sapere quando l'architettura viene modificata. La seconda parte è: come facciamo a sapere che l'architettura è ancora buona.

Per questa prima parte: come fai a sapere quando l'architettura viene modificata?

L'obiettivo qui è prendere qualcosa che è stato fatto implicitamente e renderlo esplicito

• Il suggerimento di Alexei è un'opzione. Crea una colonna alla lavagna per la revisione dell'architettura. Quindi sposta una carta lì se richiederà decisioni architettoniche
• Un'altra opzione è quella di creare una politica esplicita su come gestirla: "Se abbiamo bisogno di cambiare architettura, allora dobbiamo accoppiarci con qualcun altro" è un esempio di una di queste politiche. In un progetto, avevamo una politica secondo la quale le modifiche al codice di alcuni moduli specializzati dovevano essere eseguite abbinando persone specifiche. Quando qualcuno voleva cambiare codice lì, chiamavano una coppia e si univano. Il resto del lavoro è stato fatto da solo. Puoi fare qualcosa di simile con l'architettura.

Probabilmente andresti con il primo, se molte carte richiedono una revisione, o se l'architetto non fa parte del team ed è richiesto un handoff, o la recensione sarà abbastanza dettagliata da richiedere del tempo su cui vuoi tracciare il bordo. Quest'ultima è un'opzione se solo poche carte toccano l'architettura ed è facile trovarne una coppia su richiesta.

Veniamo ora alla seconda domanda: come facciamo a sapere che l'architettura è ancora buona?

Sono un grande fan della visualizzazione. È possibile avere un grafico sulla lavagna con note di post-it che descrivono i componenti e l'architettura.

Esistono anche analizzatori statici che analizzeranno la base di codice e genereranno un'immagine con un grafico delle dipendenze di vari componenti. Potresti eseguirlo, prendere una stampa e incollarlo su un muro una volta alla settimana. Forse le ultime due stampe potrebbero essere sul muro, quindi puoi vedere se qualcosa è cambiato nell'ultima settimana.

Ciò che ti consentono di fare è rendere visibili la tua architettura e il tuo design. I membri del team lo guarderanno di tanto in tanto e commenteranno se qualcosa potrebbe essere cambiato, riformulato o fatto in un modo migliore.

Ho visto anche questo problema. Processo decisionale implicito! Se l'implicito è il problema, rendendolo il più esplicito possibile risolverà il problema? Quello che suggerisco è di modificare leggermente il processo di architettura per "iniziare a spiegare" i pensieri impliciti che progrediscono per diventare decisioni. Lo scopo della fase aggiuntiva del processo è far capire ai membri del team che tutti sono inclini a prendere decisioni architettoniche implicite. Questo passaggio manterrà la decisione implicita fuori pista.

Mantenere "esplicitare decisioni implicite" come parte di kanban per ciascuno degli scenari potrebbe essere d'aiuto.

Quello che sto per suggerire potrebbe essere ingombrante. Ma se il processo è mappato su un insieme di elementi kanban e se questo è portato alla lavagna per ogni scenario di arco, non ti aiuterà a rintracciarlo. Suggerisco che puoi anche mapparli al modello di scenario in sei parti e improvvisare la scheda kanban per accogliere i risultati, i QA possono essere monitorati.

Vikram.

È uno dei rischi di ritardare le decisioni sull'architettura dei team Agile. Ovviamente la cosa più responsabile per essere agili è ritardare le decisioni architettoniche fino all'ultimo momento responsabile . Ma è probabile che l' ultimo momento responsabile possa (o debba) accadere presto.

Una cosa che aiuta è di delineare chiaramente in anticipo i requisiti di guida chiave; cose che sai chiaramente che devi avere (ma non devi necessariamente implementare in questo momento). La tua architettura in evoluzione (che cerca di essere minimalista e flessibile) dovrebbe accogliere il supporto esistente o futuro per tali requisiti.

Ancora più importante, tuttavia, la tua architettura in evoluzione NON DEVE implementare artefatti che ostacolano (o possono ottenere) il modo di supportare tali requisiti di guida chiave, anche se tali artefatti sono pensati per risolvere i requisiti attuali. Possiamo riferirci a artefatti come artefatti interferenti , artefatti che forniscono un valore reale (poiché implementano una soluzione ai requisiti esistenti) ma la cui presenza rende difficile / costoso implementare un futuro requisito chiave di guida.

Nei casi in cui è necessario implementare un artefatto che interferisce, il tuo compito sarebbe quello di pianificare la sua rimozione ad un certo punto (in modo da poter implementare il requisito di guida chiave che viene interferito).

Ovviamente questo è tutto esoterico senza un contesto reale e tangibile (come un vero progetto). Ma più o meno il tuo modello di processo di sviluppo e la tua architettura in evoluzione devono tenere conto di queste considerazioni.

I requisiti impliciti sono morti per le architetture. Tutto deve essere reso esplicito, sia i requisiti di guida chiave che quelli accessori. Non è necessario implementare un requisito all'inizio. Devi solo essere in grado di renderlo conto.

PS. Per requisito intendo i requisiti architetturali a livello di sistema e non necessariamente i requisiti effimeri a livello di applicazione che possono essere soddisfatti senza modifiche sostanziali all'architettura. Spero che sia d'aiuto.