Scegliere il giusto processo di sviluppo del software per un team di quattro persone

Non credo che nessun processo standard si adatti a questo caso, poiché hai chiaramente persone con diverse aree di competenza. I livelli di impegno non sono ciò che impedisce a Scrum di funzionare; le diverse aree di competenza sono ciò che gli impedisce di lavorare. Scrum presume che le persone siano omogenee, il che non è chiaramente vero nel tuo caso.

Poiché le aree di competenza sono diverse, vorrei semplicemente utilizzare uno strumento di gestione del progetto in cui il lavoro è suddiviso in piccoli blocchi ben definiti, e ogni blocco è assegnato alla persona che può fare meglio quel particolare pezzo. Devi anche avere buone stime per la durata di questi blocchi.

Devi anche tenere riunioni periodiche in cui ogni persona racconta ciò che ha fatto dall'ultimo incontro e cosa intende fare nel prossimo futuro. Se ti aspetti che il lavoro svolto da una persona possa, prima di terminare, ritardare il lavoro di altre persone, potresti benissimo organizzare brevi incontri di stand-up ogni giorno. Tuttavia, se non credi che tali dipendenze si verifichino spesso, la riunione potrebbe essere rara come una riunione settimanale.

Se avessi 2 esperti di dominio, andrei con Domain Driver Development. Puoi utilizzare ad esempio processo Whirpool

per chiarire i diversi aspetti del dominio e, insieme a UX designer, trasformarlo in funzionalità di app per dispositivi mobili. In questo modo tu (e il team) comprenderesti gradualmente il dominio più in profondità e creerai app con il potenziale valore aziendale più alto. Otterrai rapidamente un prototipo in grado di verificare le tue ipotesi e riceverai preziosi feedback. Questo approccio (e molto altro) è descritto nell'eccellente libro Lean Startup: come gli imprenditori di oggi utilizzano l'innovazione continua per creare radicalmente Aziende di successo di Eric Ries . Puoi quindi utilizzare qualsiasi metodologia come Scrum per organizzare il tuo lavoro e rendere il tuo processo di sviluppo sempre migliore.

Dubito che esista già un processo che si adatta perfettamente alla tua situazione. Preferirei esaminare vari processi, analizzarli e trarne aspetti utili. Tieni a mente i ruoli delle persone e delle loro interazioni.

es. Probabilmente includo la "retrospettiva" di Scrum, cioè incontri regolari in cui si discute cosa è andato bene o male, e come migliorare (e alla prossima riunione, scoprire se i passaggi per il miglioramento hanno funzionato o meno).

XP (extreme programming) è una raccolta di metodi che possono essere utilizzati in ambienti (tipicamente) agili.

Semplifica e usa semplicemente le tecniche di gestione di base del progetto:

• crea un piano di azione :
  • crea un elenco di attività con i deliverable per ogni attività, ad esempio potresti iniziare con l'interfaccia utente ed espandere da lì o se i moduli di apprendimento iniziano da lì
  • elenca tutte le dipendenze per ogni attività
• stimare la complessità di ogni attività
• stimare quanto tempo impiegano i compiti (questa può essere una figura di palla)
• avere uno status meeting ogni settimana o due settimane per assicurarti che le cose procedano senza intoppi; ricorda che tu sei responsabile per assicurarti che questo avvenga senza problemi (perché sei abbastanza attento da chiedere su questo forum!)
• creare un elenco di parti interessate e i loro livelli di impegno; ciò ti aiuterà anche a capire quanto spesso devi fare rapporto sullo stato del progetto e su chi puoi rivolgerti per un consiglio

In termini di codifica / interfaccia utente, quello che vorrete veramente fare è iniziare con un prototipo che vada end-to-end in modo da poter testare l'intero flusso di lavoro principale nella vostra app. Non è divertente implementare la schermata per schermo e poi scoprire che manca qualcosa. Questo è simile a Agile dove ogni settimana hai qualcosa che viene eseguito e può essere mostrato a vendite / marketing / clienti / dirigenti / altri stakeholder.

Concentrati sulle attività indispensabili e assicurati che le cose si muovano insieme alle informazioni di cui gli esperti hanno bisogno fornire e questo è fondamentalmente il tuo processo, la tipica gestione del progetto piuttosto che preoccuparti di SCRUM o di Agile.

Scrum non richiede realmente partecipanti omogenei. Dichiarate i compiti con i risultati, metti due settimane nella tua mischia e vai via. L'unica differenza è che dove puoi inserire 80 punti in una mischia settimanale con quattro programmatori, puoi mettere solo 20 punti di programmazione, 20 punti di progettazione dell'interfaccia utente, 20 punti materiale didattico e 20 qualunque sia l'ultimo punto che sta facendo punti.

Insisterei sulle revisioni: un compito viene svolto quando tutto il lavoro correlato è svolto, testato, esaminato e accettato. Quindi, se "la consulenza di esperti sui principi pedagogici e la sociologia dell'insegnamento" si rivela essere qualcosa che nessuno può dare un senso, o che non è utile per chi crea tutto il materiale didattico, per esempio, allora non passerà il revisione.

Direi che la mischia sarà molto utile quando le persone non vogliono aumentare il loro peso, perché dopo due settimane diventa dolorosamente ovvio che non lo hanno fatto. Possono dire "Lo farò la prossima settimana" e poi è meglio che vadano, o alla fine della seconda mischia diventa veramente ovvio e potresti dover parlare con qualcuno se vogliono far parte di questa squadra o no.

Immagina alla fine del progetto che dici "A ha fatto il 43% di tutto il lavoro, B ha fatto il 41%, C ha fatto il 13% e D ha fatto il 3%" - e hai la documentazione per dimostrarlo.

PS. Qualcuno non è d'accordo con questo essere mischia. È. È assolutamente bene avere una specializzazione nel tuo team di scrum. Ho un designer grafico nel mio team e nessun altro può fare il lavoro di quella persona. Quindi hai la possibilità di includerli nella mischia o far dipendere la tua squadra da influenze esterne fuori dal tuo controllo. Dieci volte meglio averli come parte della tua squadra.

Qualcuno non è d'accordo con le persone che sono responsabili di ciò che stanno facendo. Di solito non fa parte della mischia, ma se un membro del team non prende il suo peso, alla fine saranno ex membri del team e in una società, alla fine saranno ex dipendenti.