Voglio adottare una metodologia agile - in un'azienda che non ha alcun processo? [chiuso]

L'ho fatto nella mia posizione attuale, non nel caso in cui assumessimo un altro sviluppatore, ma per gestire la situazione attuale. Faccio: supporto, formazione e amp; materiali, documentazione, raccolta dei requisiti e fare una presentazione ai dirigenti di livello C ogni trimestre

Uno Sprint dura una settimana. Ho creato un piccolo database per tracciare qualsiasi progetto che abbia più pezzi. La maggior parte dei progetti è solo un documento di una pagina che è probabilmente un consolidamento di alcuni messaggi di posta elettronica. Non c'è modo di pianificare il mio programma in futuro.

Proprietari del progetto lavoro con persone diverse in diversi dipartimenti su molte piccole app, rapporti, modifiche, ecc. L'obiettivo è lavorare il più vicino possibile con queste persone per elaborare i dettagli. Se riterrò che un manager di livello superiore non avrà il tempo di farlo, suggerirò di collaborare con qualcun altro che è un po 'più vicino all'utilizzo del progetto. Pochissime persone possono concettualizzare ciò che il "veramente" vuole fino a quando non vedono qualcosa (prototipo) e escogitano un'idea migliore di ciò che vogliono. Nessuna specifica dettagliata o contratto qui.

L'aggiunta di un altro sviluppatore potrebbe cambiare a seconda del motivo per il nuovo noleggio. Se fosse il risultato di un grande progetto, allungheremo gli sprint, proveremo a rivedere il codice l'uno dell'altro, condivideremo più informazioni e coordineremo insieme il progetto. Se fosse perché c'è un arretrato di questi piccoli progetti, la maggior parte di questi non cambierebbe. L'obiettivo sarebbe quello di far funzionare la nuova persona e ognuno di loro lavorerebbe indipendentemente sui piccoli progetti. Certo, vorremmo avere più scambio di conoscenze e prepararci per lo scenario "colpisci da un autobus", ma la realtà è che la gestione non sarà felice se aggiungiamo un altro sviluppatore e non otteniamo molto di più .

Se aggiungessi solo una cosa, suggerirei retrospettive regolari. Da lì sarai in grado di scoprire dove il tuo attuale (non) processo ti fa male, e puoi iniziare da lì.

La mia ipotesi non informata è che presto capirai che hai bisogno di una buona interfaccia tra te e chiunque sia responsabile per i requisiti dei sistemi che stai sviluppando. Fornire brevi iterazioni a tempo determinato è generalmente considerato una buona idea per ridurre la quantità di lavori in corso, gestire le aspettative e stabilire un breve ciclo di retroazione.

Questo è un modo piuttosto difensivo di introdurre una metodologia agile. Se si preferisce un modo più aggressivo, basta leggere su, per esempio, mischiare e provare a utilizzare tale metodologia anche se la tua squadra è più piccola di un tipico team di scrum.