Come posso monitorare gli attributi di qualità sul Kanban del mio team?

we're implicitly making decisions about the architecture but not considering those decisions in terms of our known quality attribute requirements.

Penso che puoi visualizzarlo creando un passaggio di "revisione architettonica" nel tuo flusso di lavoro. Il passo sarebbe rappresentato da una colonna di Kanbad board con il proprio limite WIP. Il limite del WIP dipenderà dal numero di architetti / designer che devi partecipare a queste recensioni.

Il team di sviluppo è responsabile del flusso orizzontale e da sinistra a destra delle storie degli utenti. Gli architetti, nella maggior parte dei casi, toccano le storie solo quando si trovano nella colonna di revisione tecnica / architettonica. L'intersezione della colonna con una swimlane orizzontale visualizza la riunione degli sviluppatori e degli architetti.

Uno dei team in cui lavoro ha un passo simile in cui eseguono una revisione dello schema del database con l'architetto dei dati principali. Non usano Kanban, ma se lo facessero, sarebbe molto probabile avere questa colonna sulla loro bacheca.

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

• la definizione di fatto per la fase di revisione architettonica.
• test di accettazione intorno alle storie utente già fatte che rappresentano requisiti non funzionali. Quindi la definizione di fatto per una nuova user story includerebbe non rompere quei test.

AGGIUNTA : la fase del flusso di lavoro "revisione architettonica" potrebbe essere sospetta per un problema chiamato tragedia dei beni comuni . Ecco un ottimo post sul blog su come la visualizzazione Kanban può aiutaci ad affrontarlo e possibili soluzioni.

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

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

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

• Il suggerimento di Alexei è un'opzione unica. Crea una colonna sulla lavagna per la revisione dell'architettura. Quindi spostare una carta lì se richiederà decisioni architettoniche
• Un'altra opzione è creare una politica esplicita su come gestirla: "Se abbiamo bisogno di cambiare architettura, dobbiamo accoppiare con qualcun altro" è un esempio di una di queste politiche. In un progetto, avevamo una politica che le modifiche al codice di alcuni moduli specializzati dovevano essere fatte abbinando a persone specifiche. Quando qualcuno volesse cambiare il codice, avrebbe chiamato per un paio e fatto squadra. 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 e è richiesto un handoff, o la revisione sarà abbastanza dettagliata da richiedere un po 'di tempo che vuoi per tracciare alla lavagna. Quest'ultima opzione è un'opzione se solo poche schede toccano l'architettura ed è facile trovare una coppia su richiesta.

Veniamo ora alla seconda domanda: come sappiamo che l'architettura è ancora valida?

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

Ci sono anche analizzatori statici che analizzeranno il codice base e genereranno un'immagine con il grafico delle dipendenze di vari componenti. Potresti eseguirlo, fare una stampa e attaccarlo 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 permettono di fare è rendere visibili la tua architettura e il tuo design. I membri del team lo guarderanno una volta ogni tanto e commenteranno se qualcosa potrebbe essere cambiato o refactored o fatto in un modo migliore.

Ho visto anche questo problema. Prendere decisioni implicite! Se l'implicito è il problema, lo renderà il più esplicito possibile risolvere il problema? Quello che suggerisco è di modificare un po 'il processo di architettura per' iniziare a spiegare 'i pensieri impliciti che progrediscono fino a diventare decisioni. Lo scopo del passaggio aggiuntivo nel processo è far capire ai membri del team che tutti sono inclini a prendere decisioni architettoniche implicite. Questo passaggio manterrà la decisione implicita fuori dalla traccia.

Mantenere "l'esplicazione delle 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 oggetti kanban e se questo viene portato sulla scacchiera per ogni scenario di arco, non ti aiuterà a seguirlo. Suggerisco che puoi anche associarli 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 architettoniche sui team Agile. Ovviamente la cosa più responsabile per essere agili è ritardare le decisioni architettoniche fino a l'ultimo momento responsabile . Ma è probabile che l'ultimo momento responsabile possa (o debba) accadere presto.

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

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

Nei casi in cui è necessario implementare un artefatto interferente, 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 il morto delle architetture. Tutto deve essere esplicitato, sia i requisiti chiave di guida sia quelli secondari. Non è necessario implementare un requisito nella fase iniziale. Devi solo essere in grado di renderlo conto.

PS. Per requisito, intendo i requisiti architetturali a livello di sistema e non necessariamente i requisiti a livello di applicazione effimera che possono essere soddisfatti senza modifiche sostanziali all'architettura. Spero che ti aiuti.