In realtà nella società in cui lavoro non c'è una procedura o alcun tipo di metodologia che scelga di sviluppare software. Il software sviluppato è amministrativo per la propria azienda, le applicazioni dei clienti molte di esse guidate dai dati e alcune esternalizzazioni ovunque si presentino. Il mio manager mi ha dato il compito di creare una serie di procedure per il SDLC (Software Development Life Cycle), sapendo che nel prossimo futuro implementeremo SCRUM.
Ho letto e ricercato molto sui diversi approcci alla fase dei requisiti e trovo un libro piuttosto buono, Mastering the Requirements Process, che descrive una metodologia che penso possa giovare all'azienda (perché a volte il software è in grado di produrre senza pensare al problema o al processo principale) che è il modello di specifica dei requisiti di Volere.
Non ho finito di leggere il libro e devo consegnare una bozza della procedura e sono abbastanza confuso anche nelle cose:
-
Tenendo conto del fatto che SCRUM può richiedere del tempo al team per capire e imparare, dovrei utilizzare le storie degli utenti o il caso di utilizzo aziendale per specificare i requisiti o entrambi. (Non sto chiedendo la differenza perché ci sono già molte risposte a riguardo).
-
Nel Manifesto Agile, la Metodologia Scrum esiste un principio che sta lavorando sul software sulla documentazione, che è logica, perché i requisiti cambiano continuamente. Nel libro ci sono alcuni esempi che stabiliscono in che tipo di progetti è necessaria una maggiore formalità, nel caso di progetti veloci e non così formali chiamati "Rabbit Projects", gli autori hanno sempre affermato che non è necessario avere il requisito in una documentazione SRS come possono gli stakeholder e il team del software avere una chiara comprensione di ciò che deve essere fatto se non è documentato?