principi architettonici come le storie degli utenti “non funzionali” [chiusa]

Question

Sono in procinto di avviare un progetto pilota nella nostra azienda a introdurre pratiche agili, compreso l'uso di storie degli utenti. Dopo aver letto due libri da Mike Cohn, Agile Estimating and Planning in particolare e user story Applicata, ora ho un'idea più chiara di come procedere. Ho fiducia nella raffinazione nostre tecniche insieme con la pratica.

Tuttavia c'è una cosa che non mi convince. In questo post del blog Mike Cohn definisce uno specifico tipo di storie di utenti , che ha chiamato 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, quelli che Nick Rozanski e Eoin Woods chiamati, nel loro libro fantastico Software Systems Architecture , principi architettonici :

  

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

(anche dividere questi principi in principi di business e principi tecnologici , una differenziazione penso che non dovremmo cura di.)

Quello che vorrei fare con questi principi carte è di metterli accanto al nostro bordo carte arretrato in modo da averli sempre presenti durante la definizione storie degli utenti e le attività di pianificazione. Vorrei anche incoraggiare i clienti e gli sviluppatori di raccoglierli e metterli accanto al tabellone di iterazione ogni volta che pensano di una scheda potrebbe essere utile come promemoria per la squadra.

Avete mai provato alcun approccio simile? Ti scoraggiarlo per qualsiasi motivo? Hai qualche suggerimento in proposito?

Answer 1

Avete mai provato alcun approccio simile? Non ho provato qualcosa di esattamente simile, ma quando ero un Maestro Scrum della mia squadra abbiamo avuto un progetto di linee guida a livello di architettura e di visione (che tutte le squadre sono stati una parte di), che abbiamo ricordato a noi stessi, durante le varie controllare e adattare le disposizioni di Sprint e anche il progetto Scrum, come durante retrospettive, incontri Sprint Planning e anche incontri quotidiani Scrum. Alcuni modi che abbiamo usato per ricordare a noi erano aggiungendo Caratteristiche fatto per compiti che comprendeva un principio da seguire linee guida architettoniche, e potrebbe anche essere aggiunto come una piccola nota in arretrato. Nel mio suggerimento di seguito ho citato come questo è stato esaminato da un livello molto alto.

Ti scoraggiarlo per qualsiasi motivo? No per niente. Io dico il suo suggerimento è buono e si dovrebbe provare per una riunione di pianificazione. E come suggerito da Ken Schwaber e Jeff Sutherland nella loro Guida Scrum, è necessario controllare e adattare durante i 3 punti in una volata - "Ci sono tre punti per l'ispezione e l'adattamento in Scrum incontro Il Daily Scrum è utilizzato per controllare i progressi verso il. Sprint obiettivo, e di fare gli adattamenti che ottimizzano il valore della prossima giornata di lavoro. Inoltre, la Sprint Review e riunioni di pianificazione vengono utilizzati per ispezionare i progressi verso l'obiettivo di rilascio e di fare gli adattamenti che ottimizzano il valore del prossimo Sprint. Infine, Sprint Retrospective è utilizzato per rivedere il passato Sprint e determinare quali adattamenti faranno il prossimo Sprint più produttivo, compiendo, e piacevole. "

Avete qualche suggerimento su questo argomento? E 'sicuro per me presumere che questo progetto 'Agile' nella vostra azienda è appena iniziato e non si dispone di una visione solida serie progetto ancora? Se sì, vorrei suggerire ad organizzare una due settimane di progetto rilascio largo laboratorio di progettazione. Lo scopo di questo workshop sarebbe ottenere tutti i soggetti interessati, OP, SMS e Project Manager in un'unica sede e sviluppare un Super User Story e Vision, e il resto delle arretrato ripartiti dal Super User Story.The Super User Story sarebbe la visione di alto livello degli obiettivi del progetto. Se avete già fatto questo allora si prega di ignorare questo suggerimento, ma il mio punto di portare questo in su è che la visione di alto livello o una storia super user potrebbero / dovrebbero avere una parte che menziona seguendo il principio insieme architettonico nella vostra azienda.

I vantaggi di questo? Si ottiene lo stakeholder coinvolti sotto l'aspetto architettonico e tecnico del diritto prodotto dal User Story Super che aiuta a creare una buona comprensione della visione tra l'azienda e il lato tecnico, e non si può vivere senza l'altro.

I può aver intenzionalmente cercato di estendere la risposta al di là della portata domande in modo che io possa ottenere un feedback sulle mie idee pure.

Grazie, Sid.

Answer 2

che sto facendo nel modo che hai descritto. Ho vincoli definiti su schede (l'altro colore). I vincoli non sono scritti in formato user story, ma come una frase lineare come:

• Sistema sosterrà utilizzo massimo di 30 utenti.
• Le importazioni deve essere eseguito ogni giorno.
• Tutti i filtri e risultati di ricerca deve essere sulla stessa pagina.

Se il cliente ha alcuni requisiti speciali che non sono direttamente storia per singolo utente, ma ha 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 le storie reali degli utenti.

Answer 3

Questa è stata oggetto di una sega discorso che nel gennaio di quest'anno presso la fabbrica di architetto. Ho rintracciato il basso. Era Lee Ingram della "Business Driven Architecture: un esempio da un avvio corrente". Non riesco a trovare le diapositive, ma ha parlato dell'idea di generali principi che guida come requisiti devono essere soddisfatte.

Ha avuto cose come multi-tenancy e nero-etichettatura. Con un web-service multi-tenant, è necessario pianificare sin dall'inizio per la separazione / isolamento di utenti. Allo stesso modo, se si vuole essere in grado di white-label vostro servizio, quindi molte più cose devono essere configurabile (stile, etichette, ecc). Entrambi impatto quasi ogni storia.

Answer 4

consiglio vivamente presentazione Jeff Patton sulla mappatura user story .

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 5

Questa idea generale di "principi" (o vincoli) sembra un buon compromesso. Ho visto cosa succede quando le cose che in realtà dovrebbero essere in questa classe - ad esempio, "sistema deve raggiungere un certo specifico, il livello quantificata della performance" - appena viene gettato in arretrato e ha perso tra tutti gli altri "caratteristica" storie: preoccupazioni circa Noone prestazioni (perché "è OK ... c'è una storia per che da qualche parte") e poi, quando qualcuno finalmente non raccoglierlo (stranamente, queste cose sempre vengano lasciate all'ultimo, nonostante l'elevato valore per il cliente) si trovano con una compito impossibile per i pochi giorni una storia è prevista per, e probabilmente veramente solo ottenibile con alcuni gravi riprogettare del sistema, che si sarebbe dovuto fare molto prima ed ora ha un costo enorme refitting.