Come posso organizzare 3 ingegneri del software per lavorare insieme a 2 clienti?

Non usare Scrum - non sembra appropriato per questa situazione. Ho scritto una risposta su Software Engineering Stack Exchange sul numero minimo di persone per implementare Scrum. In questo momento, descrivi il numero minimo di persone per formare uno Scrum Team (proprietario di una società come Product Owner, 3 sviluppatori con uno che è lo Scrum Master).

Riesco a vedere qualche singhiozzo con questo piano. In primo luogo, lo Scrum Master deve essere in grado di essere un coach per il Product Owner e per l'organizzazione - la persona che selezioni per riempire questo ruolo ha l'influenza necessaria con il proprietario che agisce come Product Owner e il resto di l'organizzazione? Secondo, le persone che hai identificato hanno il tempo, le conoscenze e l'esperienza necessari per funzionare come Product Owner e Scrum Master?

Invece di Scrum, inizierei osservando un approccio modellato su Kanban.

Per prima cosa, crea una tavola per contenere gli oggetti di lavoro. Collaborare con il team e le persone che gestiscono il prodotto per determinare quali informazioni sono necessarie affinché il team possa svolgere il proprio lavoro. Talvolta viene chiamata una Definizione di pronto . Invece di fare in modo che i proprietari interrompano il lavoro, iniziano a formulare un elemento di lavoro che soddisfa la definizione di pronto. Potrebbero aver bisogno di aiuto dal team per fare ciò, però - dedicare del tempo a un controllo regolare per gestirlo. Puoi prendere alcune indicazioni dalle sessioni di "grooming" o "backlog refinement" di Scrum su come gestire la definizione di Ready e assicurarti che il lavoro sia in buono stato.

Quindi, dai la priorità agli elementi di lavoro. Cercherei di assicurarmi che una persona abbia l'ultima parola nell'ordine di priorità. L'ordine degli elementi di lavoro determina l'ordine in cui gli sviluppatori funzionano. Non appena uno sviluppatore termina un oggetto di lavoro, guarda in cima al backlog e sceglie l'elemento più in alto che è in grado di fare, progredendo da "to-do" a uno stato finito. È importante che i limiti WIP (work-in-progress) siano impostati e applicati.

In generale, i principi dello Lean Software Development dovrebbero essere utili. Le tue attività di pianificazione, revisione e retrospettiva dovrebbero avvenire in modo appropriato. Puoi scegliere un approccio più simile a Scrum in cui questi si verificano su cadenza regolare. Oppure puoi scegliere un approccio in cui accadono se necessario.

Se hai un backlog decente, buone definizioni di "pronto" e "fatto" per storie e buone abitudini in merito a pianificazione, revisione e retrospettiva, dovresti essere in grado di ridimensionare il tuo processo. Se il tuo team cresce, puoi prendere in considerazione l'adozione di un framework come Scrum. Se inizi a crescere in più team, puoi guardare altri framework come Nexus o LeSS per ridimensionare Scrum. Puoi anche imparare da Disciplined Agile Delivery per quanto riguarda la personalizzazione e la crescita del tuo processo.

Ci sono diverse cose qui che identifico come rischi di progetto che non stai affrontando direttamente con la tua proposta. Individuo anche molte risposte per risolvere i problemi che non si hanno all'interno di un team di progetto che è quello di raccogliere le richieste scritte per gestire le responsabilità.

In primo luogo, identificate "due client" e mi aspettavo che sarebbero stati due progetti distinti. Tuttavia, poiché sono i due proprietari, immagino che entrambi dirigano il progetto. In questa situazione potrebbe essere difficile ottenere un chiaro grafico prioritario, al di fuori delle ovvie priorità per entrambi hanno sicuramente diverse sfumature di quello che considerano un valore aggiunto.

In secondo luogo, identifichi che gli sviluppatori si interrompono quando gli viene chiesto di sviluppare una funzione. Questo aspetto mi sembra strano in una situazione in cui i clienti soddisfano tutte le richieste, in questa organizzazione sembra molto più naturale per gli sviluppatori chiedere il prossimo compito quando il primo è fatto piuttosto che fermare qualcosa per soddisfare una nuova aspettativa. Sospetto che gli sviluppatori identifichino priorità come il bug fixing o il refactoring su cui iniziano a lavorare quando hanno anche "tempo libero".

In questa situazione, il maggior rischio organizzativo che vedo non è la mancanza di un accordo scritto o di una pianificazione strategica, di cui sembri essere preoccupato, è la mancanza di un arbitro chiaro in una discussione a 3 vie su quale sia la squadra priorità. Questo rischio non viene affrontato pianificando, ma facendo un prerequisito urgente per tutta la pianificazione, ovvero condivisione della visione in entrambe le direzioni, così il team degli sviluppatori capisce qual è l'obiettivo aziendale finale e la commissione capisce che ci sono attività quotidiane di qualità che hanno un'influenza a lungo termine sulla velocità e sulla qualità dei nuovi sviluppi.

Quindi, e solo allora, puoi ottenere un backlog adeguato e un elenco di priorità per le settimane a venire.

Scrum potrebbe essere un buon modo per organizzare la squadra di sviluppo, tuttavia non salterò il quotidiano.

Ma di gran lunga il problema più grande che vedo è questo accordo verbale con il cliente. È bello parlare con le caratteristiche in modo informale, ma è necessario annotare i requisiti e chiedere al cliente di accettarli prima di iniziare a lavorare.

Questo può essere semplice come "Ok, scrivi questo incontro e mandalo per email"

Assicurati che l'obiettivo commerciale di ciascuna funzione sia chiaramente descritto e che ciò su cui lavori funzioni.

Quando tutto sta andando bene, questo è un hassel extra da passare, ma se inizia a andare storto devi essere in grado di tornare indietro e puntare a questo genere di cose.

• "abbiamo accettato di lavorare sulla funzione X, la funzione X è stata completata, inviaci i soldi"

o più probabile

• "stavamo lavorando alla funzione X, ci hai chiesto di fermarci e invece di eseguire la funzione Y. Ecco perché la funzione X non è completa"

La prima cosa di cui hai bisogno dal client è il criterio di accettazione chiamato. Il modo in cui il team suddivide le attività è solo il business delle squadre.

I criteri di accettazione sono una descrizione breve e dolce di ciò che deve essere dimostrato affinché la storia sia contrassegnata come completata. Non è necessario entrare in più con il proprietario del prodotto.

Puoi comunicare di più se vuoi, ma questo è il bit critico. Definisce ciò che si aspettano di vedere quando si demo.

Il primo passo che vorrei fare è documentare un paio di processi in cui tutti possono essere d'accordo. Quello che sembra che stia facendo è cercare di mettere il rossetto su un maiale cercando di sovrapporre un ambiente di lavoro caotico con alcuni titoli.

Il primo passo è avere un modo formale di documentare il lavoro da fare e il lavoro che è stato fatto. Una volta che hai una documentazione più formale, è più facile discutere del lavoro, stimare il lavoro e dare la priorità al lavoro. Con una documentazione più formale sullo stato corrente, quando i cambiamenti arrivano, è più facile discutere dell'impatto dei cambiamenti nel carico di lavoro e avere un'idea migliore di ciò che è possibile o meno. In alcuni casi, nuove richieste di lavoro possono essere raggruppate con richieste di lavoro esistenti o in corso di lavorazione.

Mentre sviluppi un migliore senso di ciò che stai facendo e riesaminando la cronologia per vedere quanto le tue stime stanno tenendo contro la realtà del lavoro, migliorerai la pianificazione del lavoro e migliorerai la stima lo sforzo per i cambiamenti. E le persone non tecniche avranno un'idea migliore dello sforzo richiesto e dell'impatto dei cambiamenti.

Due strumenti sono un primo passo. Per prima cosa sono necessari un codice sorgente e un repository di documenti per tenere traccia delle modifiche al codice sorgente e ai risultati finali su cui si sta lavorando. In secondo luogo, è necessario un tracker di attività e difetti per tenere traccia dei lavori in corso e per documentare e organizzare il lavoro che deve essere eseguito, ad esempio richieste di modifica e difetti.

Ci sono un certo numero di prodotti open source che faranno entrambi. Il modo più preferibile sarebbe quello di andare con un sistema ospitato in quanto vi sono un certo numero di aziende che forniscono questi servizi e strutture e sono abbastanza economici.

Il bello di questi è che un dashboard è praticamente un'offerta di prodotti standard che consente trasparenza su orari e risultati.

Una volta che il tuo team ha gli strumenti per organizzare il tuo lavoro e il tuo team è a suo agio con questi strumenti, utilizzandoli con successo, puoi passare agli aspetti più manageriali e culturali del tuo lavoro.

Sospetto che parte del problema che affronti sia che le persone non tecniche all'interno della tua organizzazione non comprendono o apprezzano lo sforzo e il tempo necessari per lo sviluppo. Mi aspetterei che siano abituati a un ambiente caotico e multi-tasking con continue interruzioni e cambiamenti di direzione. Tuttavia questo non funziona con lo sviluppo che richiede concentrazione e tempo sul compito senza interruzione.

Il tuo team è abbastanza piccolo da non aver bisogno del tipo di titoli formali che stai descrivendo. Hai bisogno di alcuni processi formali che tutti comprano e accettano, ma non hai davvero bisogno di titoli formali. E sospetto che meno processi e meno sforzi manageriali siano necessari per quei processi, meglio è.

Il tuo problema principale è l'ambiente caotico e questo è un problema culturale, educativo e formativo.