Struttura del progetto per le generazioni di prodotti che si sovrappongono?

Potresti seguire l'approccio dei due team e ridurre gli impatti negativi di:

• consente agli sviluppatori di lavorare in entrambi i team quando ha senso scambiare le risorse del team intorno a
• documentare e presentare lavori di ricerca agli sviluppatori del team di produzione per consentire loro di sollevare dubbi o mettere in evidenza cose di cui il team di ricerca non è a conoscenza, magari mettendo in atto presentazioni regolari, ad es. ogni venerdì pomeriggio o invitando i membri del team di produzione a ricercare demo di sprint alla fine di ogni sprint

Un altro approccio sarebbe quello di avere un team e chiedere alla direzione di nominare un proprietario del prodotto per creare un backlog priorizzato su entrambi i flussi di lavoro. Il team non dovrebbe fare un lavoro che non è prezioso per il business. Il proprietario del prodotto deve dare la priorità in base al valore aziendale, quindi quanto è prezioso ciascun aspetto del business (che si tratti di ricerca o produzione).

Sì, questo potrebbe significare che il lavoro di produzione è più prezioso, quindi la priorità è più alta; ma se la definizione delle priorità viene effettuata in base al valore aziendale e la ricerca per N + 1 garantisce che l'azienda rimanga competitiva sul mercato, il lavoro di ricerca potrebbe essere priorizzato rispetto ad alcune delle caratteristiche di produzione.

Mantieni la stessa squadra ma diversi rami nel tuo SCM. Generalmente il tuo prodotto di generazione N sarà più stabile, quindi dovresti ottenere (cherrypick) il codice stabile o eventuali miglioramenti rilevanti dal ramo N a N + 1.

Gli stessi sviluppatori che hanno lavorato alla feature X nel prodotto N funzionano con la stessa funzione nel prodotto N + 1. In questo modo avranno familiarità sia con le codebase sia con qualsiasi migrazione di codice o unione di codice. Inoltre, li renderà felici mentre lavorano sia sul livello di produzione che su una tecnologia all'avanguardia. Basta focalizzare la gestione su N + 1 oltre a N.

A seconda della situazione, puoi cambiare gli sviluppatori da un prodotto a un altro - ad esempio il prodotto N richiede una patch critica quindi il tuo team che lavora su N + 1 può impiegare una settimana per lavorare su N. Allo stesso modo supponiamo di aver implementato un reporting stabile framework in N e vogliono un framework di reporting all'avanguardia in N + 1, avere lo stesso team per portare i cambiamenti da N a N + 1 e anche migliorare N + 1 con la tecnologia più recente. In questo modo tutti gli sviluppatori lavoreranno come un singolo team, il che è importante perché dopo tutto N e N + 1 sono lo stesso prodotto, i tuoi prodotti saranno più coerenti e ti aiuteranno a lungo termine nella migrazione dei clienti, nella devops, ecc.

nota in calce: Apple ha fatto mac e lisa contemporaneamente negli anni '80, guidando un cuneo tra gli sviluppatori dei team. Vuoi una sinergia all'interno dell'azienda, specialmente se le sue diverse iterazioni dello stesso prodotto.