Principi di architettura come storie utente "non funzionali"

Question

Sto per avviare un progetto pilota nella nostra azienda per introdurre pratiche agili, compreso l'utilizzo di storie utente. Dopo aver letto due libri di Mike Cohn, Agile Estimating e Planning in particolare e User Stories Applied, ora ho un'idea più chiara su come procedere. Ho fiducia nel perfezionamento delle nostre tecniche insieme alla pratica.

Tuttavia c'è una cosa che non mi convince. In this blog post Mike Cohn definisce un tipo specifico di storie utente, che ha definito vincoli, che possono essere utilizzati per definire i cosiddetti requisiti non funzionali. Personalmente non mi piace la parola vincolo e anche l'uso del modello classico "Come ..., io voglio ..., in modo che ...".

Piuttosto cercherò rendere il cliente a scrivere, sempre sulle carte, magari con il modello di cui sopra, quelle che Nick Rozanski e Eoin Woods chiamati, nella loro fantastica libro Software Systems Architecture, principi architettonici:

"Un principio architettonico è una dichiarazione di credenza, approccio o intento che guida la definizione di un'architettura".

(si dividono anche questi principi in principi aziendali e principi tecnologici, una differenziazione penso che non dovremmo cura di.)

Quello che vorrei fare con questi principi carte è di metterli accanto al nostro backlog board board per averli sempre presenti durante la definizione delle user story e le attività di pianificazione. Vorrei anche incoraggiare i clienti e gli sviluppatori a raccoglierli e metterli accanto alla scheda di iterazione ogni volta che pensano che una carta possa essere utile come promemoria per la squadra.

Avete mai provato alcun approccio simile? Lo scoraggi per qualsiasi motivo? Hai qualche suggerimento su questo argomento?

Answer 1

Hai mai provato un approccio simile? Non ho provato qualcosa di simile, ma quando ero uno Scrum Master del mio team avevamo una linea guida e una visione architettonica (di cui tutti i team facevano parte), che abbiamo ricordato durante i vari controlli e adattamenti dei punti. di uno Sprint e anche del Progetto Scrum, come durante le Retrospettive, le riunioni di Sprint Planning e anche gli incontri del Daily Scrum. Alcuni dei modi in cui ci ricordavamo erano aggiungendo i Done Criterias per compiti che includevano un principio per seguire le linee guida architettoniche, e poteva anche essere aggiunto come una piccola nota in Backlog. Nel mio suggerimento qui sotto ho menzionato come questo è stato visto da un livello veramente alto.

Lo scoraggi per qualsiasi motivo? No per niente. Dico che il tuo suggerimento è buono e dovresti provarlo per una riunione di pianificazione. E come suggerito da Ken Schwaber e Jeff Sutherland nella loro guida Scrum, dovresti ispezionare e adattare durante i 3 punti in uno Sprint - "Ci sono tre punti per l'ispezione e l'adattamento in Scrum. Il meeting del Daily Scrum è usato per ispezionare i progressi verso il Obiettivo di Sprint e apportare adattamenti che ottimizzino il valore del giorno lavorativo successivo. Inoltre, le riunioni Sprint Review e Planning sono utilizzate per ispezionare i progressi verso l'obiettivo di rilascio e per apportare adattamenti che ottimizzino il valore del prossimo Sprint. la Sprint Retrospective viene utilizzata per rivedere il passato Sprint e determinare quali adattamenti renderanno il prossimo Sprint più produttivo, soddisfacente e divertente. "

Avete qualche suggerimento su questo argomento? È sicuro per me presumere che questo progetto 'Agile' nella tua azienda sia appena iniziato e non hai ancora una visione solida del progetto? Se sì, ti suggerirei di organizzare un seminario di pianificazione del rilascio a livello di progetto di 2 settimane. Lo scopo di questo seminario sarebbe ottenere tutte le parti interessate, le OP, le SM e i Project Manager in un'unica posizione e sviluppare una Super User Story e Vision, e il resto degli Backlogs analizzati dalla super User Story. La Super User Story sarebbe la visione ad alto livello dell'obiettivo del progetto. Se lo hai già fatto, ignora questo suggerimento, ma il mio punto di vista è che la visione di alto livello o la storia di un super utente potrebbero/dovrebbero avere una parte che menziona seguendo il principio architettonico impostato nella tua azienda.

Vantaggi di questo? Coinvolge lo stakeholder nell'aspetto architettonico e tecnico del prodotto fin dalla Super User Story, che aiuta a creare una buona comprensione della visione tra l'azienda e il lato tecnico, e non si può vivere senza l'altro.

Posso aver intenzionalmente cercato di estendere la risposta oltre l'ambito delle domande in modo da ottenere un riscontro anche sulle mie idee.

Grazie, Sid.

Answer 2

Questo è stato il tema di un discorso che ho visto nel gennaio di quest'anno alla Architect Factory. L'ho rintracciato. E 'stata la "Business Driven Architecture: l'esempio di una corrente" di Lee Ingram. Non riesco a trovare le diapositive, ma ha parlato dell'idea di principi generali che guidano il modo in cui i requisiti devono essere soddisfatti.

Aveva cose come multi-tenancy e white-labeling. Con un servizio web multi-tenant, è necessario pianificare dall'inizio per la separazione/isolamento degli utenti. Allo stesso modo, se vuoi essere in grado di etichettare in bianco il tuo servizio, molte altre cose devono essere configurabili (stile, etichette, ecc.). Entrambi influenzano quasi ogni storia.

Answer 3

Consiglio vivamente Jeff Patton's presentation on user story mapping.

Egli non solo chiarisce la composizione di ciò che esattamente storie scopo servono (o come si vorrebbe chiamarli), così come il modo di costruire relazioni o le dipendenze tra le storie, e come trattare con loro.

Answer 4

lo sto facendo nel modo che hai descritto. Ho dei vincoli definiti sulle carte (altro colore). I vincoli non sono scritti nel formato User story, ma come semplice frase:

• Il sistema supporterà l'utilizzo massimo di 30 utenti.
• Le importazioni devono essere eseguite ogni giorno.
• Tutti i filtri e i risultati di ricerca devono essere sulla stessa pagina.

Se il cliente ha alcuni requisiti speciali che non sono direttamente di un singolo utente ma hanno un effetto più ampio, li scrivo come vincoli. Questi vincoli non sono stimati e non fanno parte del backlog del prodotto. Li usiamo per ricordare alcuni requisiti di implementazione per storie di utenti reali.

Answer 5

Questa idea generale di "principi" (o vincoli) sembra buona. Ho visto cosa succede quando le cose che dovrebbero veramente essere in questa classe - ad esempio "il sistema deve raggiungere un livello specifico e quantificato di prestazioni" - vengono semplicemente buttate nel backlog e perse tra tutte le altre "feature": nessuno si preoccupa di performance (perché "va tutto bene ... c'è una storia da qualche parte") e poi quando qualcuno alla fine lo riprende (stranamente, queste cose vengono sempre lasciate a durare, nonostante l'alto valore per il cliente) si trovano con un compito impossibile per i pochi giorni che ci si aspetta che una storia prenda, e probabilmente realizzabile solo con qualche serio rearchitecting del sistema che avrebbe dovuto essere fatto molto prima e ora ha un enorme costo di refitting.