Che tipo di problema è questo?

Il problema si chiama natura umana. È molto difficile anticipare questo tipo di problemi senza vedere un'implementazione funzionante, sia per sviluppatori che per scrittori di requisiti, anche se con esperienza su lavori simili si migliora.

La maggior parte dei processi software moderni riconosce questa difficoltà fondamentale e si concentra invece sul rafforzamento del ciclo di feedback. Invece di lavorare per 3 mesi e spedire qualcosa che ritieni completo al QA, gli permetti di vederlo in qualunque stato si trovi ogni 2 settimane o anche prima. Se uno sviluppatore ha una scelta su come comportarsi in una condizione di errore, chiede al BA giusto allora invece di solo indovinare o fare qualunque cosa sia più facile. Se il tuo ciclo di feedback è già stretto, ma i cambiamenti ti infastidiscono perché sembrano "non pianificati", quindi pianificalo. Pianifica in un determinato momento per risolvere i problemi relativi ai requisiti trovati nel QA.

Molto probabilmente si tratta di requisiti scarsamente definiti. Il modo migliore per minimizzare lo stuiff come questo, secondo me, è spingere il Ba dall'inizio per rendere i requisiti più descrittivi. Quando li prendi per la prima volta. Chiedigli come desideri che il sistema gestisca l'immissione di dati errati o altre cose che ritieni da precedenti esperienze non siano state adeguatamente trattate. Nella mia esperienza, la maggior parte dei BA non sa cosa mettere nei requisiti una volta che si esce dai campi dell'interfaccia utente. È necessario respingere praticamente tutti i requisiti e chiedere ciò che è necessario per gestire correttamente gli errori, per gestire ciò che è necessario andare dietro le quinte, ecc. Se si vede un punto decisionale nel requisito, assicurarsi di chiedere cosa succede se il viene presa una decisione meno comune (ad esempio, supponiamo che ci sia l'approvazione di amanger, molti BA non ti diranno senza chiedere cosa dovrebbe succedere se il gestore disapprova la richiesta). Prima si respinge per ottenere più risposte, meno rielaborazioni sono necessarie.

Per aiutarti con questo, tieni una lista di esecuzione da qualche parte di quali cambiamenti di requisiti hai avuto per cose che avrebbero dovuto essere definite ma non lo erano. Allora saprai quali sono le cose da chiedere riguardo alla prossima volta che ottieni un requisito. Risolvere un fabbisogno inadeguato è l'unico modo migliore che io conosca per risparmiare tempo e denaro in un progetto.

scope creep, poorly defined requirements, lack of an overall business process for error management, lack of technical foresight on part of the BA/Dev, a valid request

Tutto sopra ... Davvero ... ANCHE una richiesta valida.

• Lo scope creep perché una nuova funzionalità si è introdotta nel rilascio richiedendo più sviluppo e minacciando il successo del progetto.

• Si tratta di requisiti scarsamente definiti perché questo requisito richiesto dalla BA era mancato nelle specifiche formali.

• È la mancanza di un processo generale in quanto manca il controllo delle modifiche nella gestione del progetto. Ammettiamolo, i requisiti vengono ignorati, ma il controllo dei cambiamenti aiuta a prevenire i nuovi requisiti mancanti e da striscianti e a minacciare la scadenza del progetto.

• Mancanza di lungimiranza tecnica perché i requisiti devono essere stati esaminati da un responsabile tecnico o uno sviluppatore prima dello sprint / iterazione e lo sviluppatore non ha previsto i problemi tecnici a cui i requisiti mal definiti potrebbero portare.

• È una richiesta valida perché tutto sommato è detto e fatto, i BA e le parti interessate vorranno che il software si comporti in un certo modo alla fine . È sfortunato che sia mancato, ma il problema dovrebbe essere di proprietà del direttore di BA o dell'applicazione e aggiunto al backlog per la prossima priorità in attesa di sprint.