Come implementare le procedure aziendali durante l'utilizzo di scrum?

Scrum non ti spiega come sviluppare il software, ma stabilisce semplicemente momenti di comunicazione e modi per trasferire le informazioni tra le parti interessate. Scrum non è una metodologia di sviluppo del software, è possibile applicare qualsiasi cosa che ti piace o è necessario fino a quando fai le sessioni di pianificazione, stand-up, demo, mantieni il burndown sul muro e assegna i tuoi ruoli (SM, PO, team, cliente). Se vuoi fare o devi fare ISO, questo sarà solo una parte dei tuoi compiti che dovrai tenere in considerazione quando valuti le tue storie.

Se il tuo software deve essere conforme a XYZ, questo sarà solo parte della tua definizione di fatto. Non dovrebbe esserci un conflitto, Scrum in quanto tale non ha autorità che gli consenta di invalidare i requisiti del prodotto. Se ci si sente così, è solo perché alcune persone usano Scrum come scusa per farlo a modo loro. Che non è raro.

Is there a general requirement discovering in SCRUM? Like interviews, surveys with the client and then those stack of requirements are shared with the team in the multiple sprint meetings for the backlog or it's a continue discovering with the team and the stakeholders (users stories in the sprint meetings)

Scrum è silenzioso sui metodi specifici.

Il ruolo di Product Owner è responsabile di assicurare che gli articoli nel Product Backlog siano espressi chiaramente in un modo che è utile per il Team di sviluppo, assicura che l'ordine degli articoli del Product Backlog sia gestito e assicurando che tutti gli stakeholder siano chiari su cosa sta lavorando il team adesso e lavoreremo al prossimo.

Nulla nel framework Scrum dice al Product Owner come fare queste cose. L'unica cosa che è il Product Owner è una persona. Ci può essere un gruppo di analisti o product manager, ma c'è una persona singolare (anche se consiglio anche di identificare un sostituto) che rappresenti gli stakeholder e la visione del prodotto per il team.

Parte di garantire che il Product Backlog sia in buono stato è la scoperta e l'acquisizione dei requisiti. Ma questo può essere fatto in qualsiasi modo sia comodo per gli stakeholder e il proprietario del prodotto.

I have to create a design procedure, which will describe how to approach UI design (mockups, prototype, etc), in SCRUM is not up to the team how they do it? An analyst will follow this procedures and after a view of what the project is going to be share it with the team to begin the implementation, though removing the responsibility of recreating the entire development process for each application without an specific methodology.

Qualcosa che può aiutare qui è il concetto di "Definizione di pronto". Il framework Scrum definisce una "definizione di fatto". La definizione di Fine aiuta ogni squadra ad assicurarsi che il lavoro sia completo. Tuttavia, alcuni team sviluppano anche un concetto di "Definizione di pronto" - il lavoro che deve essere fatto prima che l'articolo del backlog possa essere avviato dal team di sviluppo.

Per quanto riguarda il team che sceglie il proprio approccio al lavoro, questo è un principio di Scrum - il team può ispezionare il modo in cui sta facendo il lavoro e adattarsi. Tuttavia, è OK mettere delle restrizioni sul modo in cui la squadra lavora, se proviene da una guida esterna. È anche possibile eseguire "processi di sartoria", anche se si hanno processi documentati che corrispondono ai requisiti ISO. Hai solo bisogno di comprendere appieno l'intenzione di ogni requisito ISO e documentare gli standard organizzativi.

Per inciso, ti consiglio di consultare Agile disciplinato . Uno dei modelli del ciclo di vita dei processi implementati in Disciplined Agile è basato pesantemente su Scrum. Altri modelli si basano su altre metodologie agili e snelle. Tuttavia, a differenza di Scrum, risolve problemi come governance (standard ISO, CMMI, requisiti normativi) e come implementare metodi agili in questi ambienti.

1. Is there a general requirement discovering in SCRUM?

Non espressamente, no. Per citare Henrik Kneiberg: "L'inizio del progetto è quando ne sai meno, quindi perché dovresti pianificare tutto allora?"

L'intera idea di Scrum è che i bisogni dell'utente e il design "giusto" sono emergenti. Il processo di raccolta dei requisiti è in corso. Detto questo, non è raro avere un prodotto kick-off o una sessione di pianificazione del rilascio che dura forse un giorno o due in cui tutta la squadra parla con gli utenti, discute dove sarebbe un buon posto per iniziare, ecc. Nel mio decennio di esperienza, vale la pena spendere un po 'di tempo in anticipo, ma partendo dal presupposto che tutto ciò che identifica potrebbe essere sbagliato e dover essere buttato fuori dovrebbe impostare la barra esattamente per quanto breve dovrebbe essere.

2. I have to create a design procedure, which will describe how to approach UI design (mockups, prototype, etc), in SCRUM is not up to the team how they do it?

Domanda fantastica! Gli accordi di lavoro sono completamente compatibili con Scrum. Le migliori pratiche di sviluppo dovrebbero venire dal team, ma quella squadra di solito deve lavorare con altri team e con la società nel suo insieme. Dovrai trovare il saldo. Ovviamente, se una squadra vuole costruire l'intera app in Access '97, probabilmente è un no. Non importa se è quello che vuole la squadra. D'altra parte, cerca di tenerli alla luce. Ad esempio, se l'intera azienda utilizza un particolare programma per la prototipazione rapida, includerla come norma aziendale, ma essere aperta ai team che dicono che esiste un'opzione migliore o un'altra scelta che non interferisce (forse una versione open source che salva negli stessi formati di file).

Ci sono due strumenti fondamentali in Scrum che ti aiuteranno qui: Definizione di Pronto e Definizione di Fatto. La spiegazione molto breve di questi è che gli elementi devono soddisfare la Definizione di Pronto prima che la squadra li porti in uno sprint e devono soddisfare la Definizione di Fatto prima che la squadra possa dire che sono finiti. Molti luoghi con più team hanno una DoR e una DoD comuni a tutti i team e quindi i singoli team possono aggiungerli.

Gli analisti

Quindi, questa non è la cosa principale, ma ne parli ed è qualcosa che potrebbe farti saltare in aria: il "cosa" o il bisogno che deve essere affrontato o il problema che deve essere risolto è identificato e raffinato dal proprietario del prodotto che parla con il team e le parti interessate come un controllo sul suo modo di pensare. Quindi il team determina in che modo tale necessità verrà risolta, creando l'implementazione. Se l'elemento del backlog arriva al team con l'origine dati, il flusso dell'interfaccia utente e gli elementi grafici completati, parte della implementazione avviene al di fuori del team di Scrum e dello sprint.

Spesso, quando vedo questo, l'Analista e / o il designer stanno facendo tutte queste cose prima del tempo e il risultato è sempre lo stesso: l'analista e / o il designer vengono sepolti. 6 programmatori scrivono il codice molto più velocemente di quanto un analista possa risolvere problemi complessi. In questo caso, risolvendo questi problemi, la progettazione di tale interazione è parte integrante dell'implementazione. Quel progettista o analista fa parte del team e dovrebbe essere collegato in loop - quel lavoro dovrebbe far parte dello sprint. So che è un po 'fuori dalla tua domanda, ma ho visto così tante squadre cadere in quella trappola. Volevo dire qualcosa.

Penso che valga la pena sottolineare che SCRUM è in realtà più che un insieme di principi di sviluppo agili. Dalla mia comprensione, in realtà ha un processo di sviluppo abbastanza ben definito (sprint, scrums quotidiani, pianificazione sprint, ecc.). Quindi questa tua affermazione

because in SCRUM the steps are iterative the team decide who process will they use, I'm feeling that it conflicts with having a technical procedure of how the things should be done.

mi irrita, perché SCRUM ha una procedura tecnica su come sviluppare il software al suo interno.

Per quanto riguarda la tua domanda

Is there a general requirement discovering in SCRUM?

Il ruolo del proprietario del prodotto è responsabile della formulazione delle richieste di funzionalità, che vengono ulteriormente specificate (nelle storie degli utenti) durante le riunioni di pianificazione dello sprint.

Sfortunatamente, non conosco molto sulla ISO 27001, quindi non posso dirti se ha senso cercare di combinarla con SCRUM. Tuttavia, e lo ripeto, solo perché SCRUM è agile non significa che non definisca un processo . Al contrario, SCRUM definisce chiaramente un processo ed è piuttosto severo nel rispettarlo (rispetto ad altri metodi agili, ad esempio Kanban, in cui si ha molta più libertà nel definire i propri aggiustamenti al processo o incorporarlo nei processi esistenti). / p>

Qui puoi leggere di più su SCRUM e sul suo processo.