Sì

qualsiasi stakeholder, qualsiasi funzione che migliora il sistema

[lascia iniziare i downstream puristi!]

"La mia gestione desidera utilizzare Agile per tutto, comprese le attività relative allo sviluppo non software."

Questo non significa scrivere storie di utenti per ogni funzione.

Se vuoi scrivere storie di utenti per ogni funzione, non sei necessariamente essere Agile. Stai solo scrivendo storie di utenti per ogni funzione.

User Story! = Agile.

Le User Story sono un modo per raccogliere e comprendere i requisiti. Possono essere usati in modo perfettamente cascata, se lo si desidera. Alcuni lo fanno.

Agile è un modo per gestire i progetti. Puoi utilizzare User Story, o non, in un progetto Agile.

Le User Story per gestire il debito tecnico e le attività interne, ancora una volta, non hanno nulla a che fare con l'essere Agile.

Molte persone sono perfettamente contente di aggiungere funzionalità "tecniche" o di "supporto" in uno sprint senza perdere tempo a scrivere una "user story" falsa per utenti puramente interni, a valore aggiunto limitato, non di partecipazione.

Se il QA non raccoglie la loro storia, quanta perdita di business ci sono?

Se i veri interessati non ricevono le loro storie, l'azienda soffre davvero.

Questo non ha senso per me. In sostanza, una "User Story" è solo una storia di un utente, non una storia di Project Manager, non una Developer Story, non una storia di Quality Assurance Engineer.

Su questa nota, il software è:

1. definibile
2. testabile

I miglioramenti del processo sono aperti e in genere soggettivi.

Acceptance Criteria: 1. Improvement to testing 1 (by x/y)

Come si misura il miglioramento dei test? Non esiste un contratto definibile per questo.

E su una nota non correlata Sinceramente Spero che il tuo esempio sopra,

As a test manager, can I perform testing of the application using only automated tests and no manual testing so that I can test the application as efficiently as possible?

... è solo un esempio, perché c'è così tanto errore in questo che non riesco neanche a cominciare a descrivere.

Il debito tecnico potrebbe essere gestito in un moda simile a quella di un utente, ma a volte può diventare piuttosto brutto. Ad esempio, per avere una storia del tipo "Come sviluppatore, voglio avere test di unità di lavoro in modo da poter avere fiducia nei test per convalidare se altre modifiche si rompono qualcosa", non ha molto valore per il proprietario del prodotto ma potrebbe essere una buona idea per il team fare come parte del proprio refactoring che fa parte del lavoro in uno sprint.

Mi piace l'idea di avere compiti separati dalle user story in quanto le attività non saranno qualcosa che mostreresti all'utente finale di un sistema, ma potrebbero essere qualcosa che aiuti a migliorare la manutenzione e il tempo potrebbe richiedere di sviluppare alcune nuove funzionalità. A seconda di quanti compiti, in termini di punti totali totali dato che alcune attività possono essere di 2 minuti e altre di 2 settimane, è possibile che questo determini se la squadra fa uno sprint e non inserisce nuove funzionalità, ma funziona su compiti di pulire le cose che ho visto un paio di volte in cui lavoro.

Hai un grosso problema quando metti "user story" interne nel mix con storie di utenti reali.

Rileggi tutte le definizioni di "stakeholder" che puoi trovare.

link )

link

link

Leggili molto, molto attentamente in modo da poter vedere la differenza tra Polli e Maiali.

Le "user story" interne sono scritte da polli.

Le storie degli utenti reali sono scritte da maiali.

Le tue storie utente "orientate al pollo" non sono molto importanti. Non importa quanto la gestione desideri rintracciarli come se fossero vere e proprie storie utente con valore reale, non sono vere e proprie storie utente e non creano valore allo stesso modo.

Il lato sfocato dell'argomento è il problema di controllo qualità. Il QA è importante e senza di esso nulla funziona.

Questo non rende magicamente un QA un maiale. Li rende ancora un non-stakeholder. Forniscono supporto, infrastruttura e una base essenziale per il resto del lavoro. Ma sono "storie di utenti" che sono essenzialmente diverse dalle vere storie di utenti reali dell'utente.

Se il QA non mostra il test di un miglioramento nei test, nessuno cessa l'attività. Il denaro non è perso.

Se l'utente non è in grado di condurre la propria attività in un primo momento, è fuori mercato. Il denaro è perso. L'intera operazione è un fallimento totale.

Non commingle interlocutori interni ("pollo") e reali ("porci")

Il commento "polli e maiali" manca il punto. Gli stakeholder interni sono polli quando si tratta del prodotto in fase di sviluppo (a meno che non venga sviluppato per loro), ma sono porci quando si tratta del processo di sviluppo.

La domanda che ti stai ponendo è se la formula della frase "Come , mi piacerebbe poter _ , così che io può __ "essere utile per definire e migliorare i processi aziendali in cui i miglioramenti non richiedono la scrittura di un nuovo codice software. Mi sono imbattuto in questo thread perché sto pensando di fare la stessa cosa e sto cercando le migliori pratiche, ma la mia strong intuizione è che la risposta alla tua domanda è "sì". Lo scopo della struttura della frase è davvero quello di costringere lo scrittore ad astrarre soluzioni che potrebbe già avere in mente e concentrarsi su ciò che l'utente - in questo caso, l'utente del processo - vuole essere in grado di fare. Non vedo alcun motivo per cui la trama dell'utente non sarebbe utile se applicata al processo.

Il punto sui criteri di accettazione è buono, ma non deve essere dogmatico (comunque Agile). È un buon esercizio quando si progetta qualsiasi processo aziendale per chiedere: "Come faccio a sapere se il cambiamento in corso ha raggiunto il mio obiettivo?" È vero che non è sempre possibile eseguire un test automatico per rispondere a questa domanda, ma non è un motivo per squalificare la user story come strumento.