Alternative di pianificazione del prodotto agili per aiutare la qualità delle funzioni orientate agli obiettivi

Ci sono due parti: QA e pianificazione.

QA

there are more ways to write bad/unusable user stories than writing really good ones. And it's easy to get to the wrong tracks even if you're careful.

Quanto è vero.

Questo è vero per il software. Lavorazione del legno. Plumbing. Pittura. Scendendo le scale.

In tutti i casi, abbiamo una tecnica per impedire che tutto il male / inutilizzabile travolga il bene.

Si chiama "Quality Assurance".

I would like to know what other alternatives are to plan a project on the high level that ensures better results.

Senza garanzia della qualità, niente funziona meglio.

I've heard of Effect Mapping ...

Senza la garanzia della qualità, questa tecnica sarà altrettanto negativa delle storie degli utenti senza garanzia della qualità.

Can we follow some easy to understand and narrow guideline that will lead us to a great high-level plan?

No. Non proprio.

Si scopre che è difficile. Non è possibile ottenere un piano "fantastico" senza "grandi" user story. E non puoi ottenere storie di utenti "fantastiche" senza una definizione di grandezza e la garanzia della qualità per stabilire la loro grandezza.

What are other more reliable approaches that simple user stories planning that are used in agile planning?

Niente è più affidabile delle storie degli utenti. O. Per essere più precisi. L'affidabilità non deriva dalla tecnica, ma dalla garanzia della qualità. Con un QA scadente, tutte le tecniche sono ugualmente scadenti. Con un buon QA, tutte le tecniche sono ugualmente buone.

Apparentemente "Quality Assurance" non è un termine popolare per Quality Assurance. Se vuoi chiamarlo "Verifica e Validazione", puoi chiamarlo così.

Hai già degli standard di qualità che ritieni importanti. Li hai elencati nella domanda.

Ciò che non stai facendo è assicurarti che le storie tutte soddisfino gli standard di qualità. Quello che devi fare è assicurarti che le storie tutte soddisfino gli standard di qualità prima di utilizzarle per la stima.

Pianificazione

Probabilmente hai aspettative non realistiche per un "grande piano di alto livello". Se pensi di stimare in un piccolo fattore il costo del progetto finale, sei ingenuo. La tua pianificazione iniziale non ha alcun valore.

Zero.

La gente Agile (in particolare Scrum) ti dirà che l'arretrato è una cosa molto, molto flessibile che cresce e si riduce selvaggiamente mentre le persone apprendono del prodotto, delle storie, della tecnologia e del dominio del problema.

La stima iniziale non è davvero utile per nulla, dal momento che molte delle storie di utenti con bassa priorità possono essere facilmente rimosse. Alcune delle user story sono davvero epiche con numerose user story sepolte al loro interno. Alcune delle user story sono sbagliate. E alcune delle storie degli utenti suggeriscono solo il vero problema che deve essere risolto.

Dopo alcuni sprint, il backlog combinato con le funzionalità consegnate assomiglia molto poco al backlog iniziale. Questo è il segno di un progetto ben gestito in cui le persone hanno il permesso di apprendere qualcosa e di correggere l'arretrato per riflettere tale apprendimento.

"porta a un piano / risultati di valore." è un backlog. Non molto più di una lista di storie e relative complessità. Le stime dettagliate basate su storie super precise non aiutano in realtà a sviluppare software. Tutte le stime dettagliate aiutano con la stima.

"Un grande piano di alto livello non è solo un insieme di requisiti funzionali, ma piuttosto una visione del prodotto con un obiettivo ovvio in mente" È un backlog. Niente di più. Stime dettagliate Le user story di alta qualità non sono essenziali . Le cattive user story fanno parte di un ottimo piano perché vengono rielaborate per migliorare la loro qualità.

Nel nostro gruppo di sviluppo utilizziamo Scrum e gestiamo il prodotto e rilasciamo il backlog usando solo le storie. Alcuni suggerimenti che potrebbero aiutarti:

1. Non scrivere storie di basso livello all'inizio. Se stai pianificando un rilascio di 6 mesi, non è necessario riempire il backlog con storie di 1-2 punti. Questo crea troppo da gestire. Invece, definire blocchi più grandi (ad es. Storie epiche). Analizza quelli più importanti su cui inizierai a lavorare per primi, ma lascia gli altri al punto più alto. Ciò ti aiuterà a mantenere basso il numero di storie nel backlog

2. Come altri hanno sottolineato, le gerarchie di storie sono i tuoi amici. Che lega a (1). Quando arrivi a un punto in cui è necessario un preventivo migliore, prendi la tua storia di Epic (o semplicemente di grandi dimensioni) e dividerla in storie più piccole che diventeranno i suoi bambini.

3. In passato, il nostro arretrato si presentava come un disordine ingestibile di roba che non serviva a un valore predittivo. La chiave, che abbiamo appreso nell'ultima versione, consiste nel fare continuamente una qualche forma di pianificazione della release e controllare periodicamente per vedere cosa c'è nel backlog. L'ordine delle storie dovrebbe corrispondere alla priorità in cui queste storie dovrebbero essere fatte. Poiché le priorità / i requisiti cambiano, l'arretrato deve cambiare con loro. Recensioni periodiche

   • assicurati che il team sappia cosa sta succedendo e
   • impedisce al backlog di diventare una discarica

4. L'ho letto da qualche parte (un libro o un blog, ma non ricordo dove). L'autore ha suggerito che il backlog non dovrebbe mai essere pianificato per più di 12-18 mesi in futuro. Ha detto che anche se ci sono elementi "importanti" che pensi di fare nella prossima versione, non è necessario scriverli e gestirli. Se sono veramente importanti, verranno visualizzati nella prossima pianificazione della versione.

5. Qual è la dimensione della tua squadra? Abbiamo diviso il nostro gruppo di sviluppo in 3 team agili separati. In questo modo abbiamo 3 maestri di scrum, 3 riunioni di pianificazione e ogni squadra ha solo 1/3 delle storie che devono effettivamente gestire e mescolare. Il nostro team è stato suddiviso in base alle aree funzionali del prodotto e quindi le aree funzionali sono state regolate per un carico uguale.

Ottenere i requisiti non è sempre facile, richiede quasi sempre una certa esperienza. L'approccio "User story" è solo uno strumento che potrebbe aiutarti ad avere una forma unificata di scrivere le caratteristiche del tuo prodotto mancanti, ma non aspettarti che sia un proiettile d'argento. Se hai bisogno di altre forme di specifiche dei requisiti su un diverso livello di astrazione, non esitare a crearlo.

In realtà, non credo che ci sia una linea guida facile da imparare che può aiutarti - praticherai semplicemente "ingegneria dei requisiti", e dopo averlo fatto per alcuni mesi, migliorerai in questo lavoro. Inoltre, hai già identificato alcuni punti cruciali che vuoi evitare, il che dimostra che sei già sulla strada giusta. E se ti manca il "grande piano di alto livello", perché non provi a scrivere preventivamente alcuni obiettivi generali di progetto di alto livello? Nella maggior parte dei progetti a cui ho partecipato, questa è stata la parte facile: le parti difficili sono sempre i dettagli.

As a visitor I want to login so that I'm logged in - Cattivo esempio. Esempio migliore: As a visitor I want to login so that I'm allowed to _______.

flat list of unmanageable stories - Disporli gerarchicamente, per aree funzionali. As a logged-in user, I want ____ so that ____ o, as an Accounting user, I want ____ so that ____

too many value-less goals - Smetti di scrivere quelli.

Can we follow some easy to understand and narrow guideline - Questa User Story porta a requisiti significativi e testabili?