Dopo aver dato un'occhiata a SCRUM, non è lo stesso per me "sufficiente" per condurre un progetto poiché non sta eliminando il lato tecnico di esso, quindi le mie domande sono:
1-è possibile / raccomandato di combinare SCRUM con un processo unificato o qualsiasi altro processo di sviluppo software? Come fare le specifiche in questo caso?
2-Che dire del planing del progetto: dividi il progetto in sprint e usa il metodo Y in ogni pagina
Grazie
Hai ragione che Scrum non discute molti dettagli. Ma va bene perché è un framework di processo.
Ad esempio, Scrum dice che il Product Owner è responsabile dell'aggiunta, della rimozione e della priorità del Product Backlog ma non dice come fa il Product Owner. Questo perché chiunque implementa Scrum può avere un processo diverso. Scrum in un ambiente più regolamentato dovrebbe probabilmente implementare un processo di controllo delle modifiche più rigoroso per modificare il backlog, mentre altri ambienti potrebbero non richiedere la produzione di artefatti. Lascia all'organizzazione la definizione del modo in cui il Product Owner (e le possibili persone di supporto) vanno a capire quali requisiti scrivere, come scriverli e come stabilire le priorità per il team di sviluppo.
Un altro esempio è il lavoro quotidiano svolto dai team. Solitamente, i team che implementano Scrum scriveranno test unitari automatizzati perché possono essere eseguiti automaticamente dagli sviluppatori e dagli strumenti di compilazione automatica per ottenere un feedback rapido e incrementale sul lavoro svolto. Tuttavia, Scrum non lo impone. Scrum dice semplicemente che alla fine dello Sprint, dovresti avere un Incremento che soddisfa la Definizione di Fine ed è utilizzabile. Come ti assicuri di avere un Incremento fino all'organizzazione e al team.
Scrum definisce ciò che i suoi creatori vedono come la quantità minima di ruoli (Product Owner, Development Team, Scrum Master), eventi (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e artefatti (Product Backlog, Sprint e Incremento). Nella tua organizzazione, puoi scegliere di avere altri ruoli.
Ad esempio, molti software critici richiedono una verifica indipendente del lavoro. In questo tipo di ambiente, è possibile scegliere di avere un team di verifica indipendente che opera a fianco del team di sviluppo, ma con l'indipendenza appropriata dalla creazione del software e dei prodotti associati associati.
Ufficialmente, lo Scrum su misura lo rende non-Scrum (dalla Guida di Scrum ):
Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Non ritengo che ciò sia realistico in quanto non riconosce la varietà di ambienti in cui è sviluppato il software. Non consiglierei di combinare Scrum con qualcos'altro, ma invece di usare Scrum come punto di partenza e quindi di adattarlo al tuo ambiente all'interno di quel framework. Se Scrum è così selvaggiamente inadatto per te, forse un diverso framework di processo dovrebbe essere considerato come un punto di partenza per la sartoria. Se Scrum non è buono, ci sono alternative - Consegna agile disciplinata , ad esempio, si basa su idee di Scrum, Kanban, Extreme Programming, Lean e il processo unificato (in particolare Rational e Agile) . Le metodologie Crystal descritte da Alistair Cockburn possono anche essere un buon punto di partenza.
Leggi altre domande sui tag scrum planning project-planning