In generale, un'organizzazione dovrebbe adottare una singola metodologia o decidere in base al progetto?

C'è un problema molto serio con la scelta di una metodologia su base "per progetto", ovvero la maggior parte delle metodologie Agile rifiuta la nozione di progetti .

Un progetto implica un ambito fisso e un tempo fisso, e per molte delle organizzazioni più disfunzionali, anche un budget fisso. Questo è un anatema per ogni metodologia là fuori.

Ogni ruolo, ogni strumento e ogni rituale in un processo come Scrum si concentra sul prodotto - non su un "progetto". Si dispone di un backlog del prodotto che indica cosa deve essere fatto e in quale ordine (ma non quando o come). Hai un proprietario del prodotto che sceglie cosa va inserito nel backlog. Hai demo di prodotto o vetrine per informare l'attività di progresso. Hai versioni e iterazioni del prodotto. Anche la tua primissima versione è denominata "Prodotto minimo vitale" e non è destinata a essere la versione finale.

L'analogia più vicina a un "progetto" tradizionale sarebbe probabilmente un singolo sprint / iterazione / ciclo, perché alla fine di uno sprint, il tuo team avrebbe dovuto fornire uno o più miglioramenti significativi al prodotto che forniscano alcuni misurabili valore aziendale. Se la tua squadra non sta facendo questo, la tua squadra non è agile nella capitale: il senso della parola. Se la tua squadra non è dedicata a un singolo prodotto (o forse a una piccola suite), allora non è Agile. Se le persone esterne al tuo team dettano i requisiti o le scadenze per il tuo team, la tua azienda non è Agile.

Non sto dicendo che tu hai per essere Agile. Quello che io sto dicendo, tuttavia, è che non puoi davvero scegliere. La maggior parte delle "buone" metodologie Agile come Scrum include il miglioramento del processo come parte del processo stesso (cioè retrospettive e post-mortem), quindi non sto dicendo che il tuo processo dovrebbe essere statico. Al contrario, a meno che non sia andato tutto perfettamente durante i tuoi ultimi sprint, probabilmente dovresti modificare il processo. Ma i processi Agile sono processi per consegna continua e se passi alla modalità "progetto" in qualsiasi momento, allora stai buttando via la parte continua e potresti anche attenersi a un processo di gestione del progetto più tradizionale. Non cascata, che è stata rotta anche secondo Royce, ma qualcosa di più formale come il RUP.

In generale, direi che è OK avere alcuni team Agile e alcuni team / progetti non Agili se sono team diversi . Ho visto cosa succede quando le aziende cercano di eseguire il sandhorn project in un team / processo Agile, e sono certo che non è bello; nel migliore dei casi danneggia seriamente la qualità e la cronologia di entrambi gli obiettivi, nel peggiore dei casi guiderà i membri del team in modo così pazzo che la metà di loro smetterà. Evita, se possibile.

Non vedo il vantaggio di provare a fare tutto lo stesso a meno che tu non sia disposto a rifiutare progetti che non si adattano al tuo modello particolare. In caso contrario, si ottiene un brutto adattamento e il cliente non sarà felice in ogni caso.

Se sei così sicuro di conoscere le specifiche in un caso e sei molto sicuro che non cambieranno, puoi comunque eseguirlo come un progetto agile. Solo perché Agile è migliore quando le specifiche sono vaghe, non significa che sia inutile quando sono solide.

Mantenere le cose il più coerenti possibile in modo che i membri possano lavorare su diversi progetti senza troppi adattamenti del metodo generale. Le persone sono più brave nel fare adattamenti quando capiscono perfettamente che cosa stanno adattando; altrimenti, è solo il caos. Ovviamente, questo presuppone che tutti i tuoi clienti siano disposti a lavorare con una metodologia agile.

Agile vs Waterfall non ha solo un set di requisiti in anticipo. Esistono altri valori agili oltre a rispondere ai cambiamenti, ad esempio:

• Le persone sono più importanti del processo.
• Distribuisci software che funziona in brevi iterazioni.

Se la vostra azienda è agile, non vedo come si possa abbandonare questa agilità per un progetto, agile molto di più su una mentalità e valori fondamentali piuttosto che su pratiche concrete. Se per un progetto hai dei requisiti solidi che non cambiano, puoi ancora lavorare su questi progetti con i tuoi valori e la tua mentalità agili. Vai in piccole iterazioni, potenzia la tua squadra, mostra il software che funziona frequentemente ... con agile sei pronto a cambiare, se il cambiamento non viene visualizzato, sei ovviamente preparato a questo.

Nella mia esperienza, la maggior parte delle organizzazioni utilizza un mix dei processi che funzionano meglio per esso e per i suoi clienti (business). Sebbene l'Agilità sia un obiettivo organizzativo, ciò non significa che TUTTI i suoi progetti software debbano essere eseguiti utilizzando un metodo Agile (Scrum o altri). Agilità significa essere in grado di rispondere rapidamente ai cambiamenti e offrire prodotti e servizi di qualità che soddisfano le esigenze dei clienti e quindi gli obiettivi organizzativi. Ciò può essere ottenuto con una varietà di metodi e approcci da parte dell'organizzazione.

Preferirei fare la domanda: qual è il problema che stai cercando di risolvere? C'è un problema? La soluzione richiede la modifica o l'esame dei processi di sviluppo del software? La soluzione a questo problema è ottenere tutti con la stessa metodologia?

Anche così, posso assicurarti che la maggior parte delle organizzazioni oggi ha "agilità" come obiettivo di business in un modo o nell'altro - E lavora con una varietà di metodi di sviluppo del software a seconda delle esigenze del cliente, la natura del progetto e le capacità e la maturità della squadra coinvolta.

Spero che ti aiuti!