Come consulente, capisco una semplice regola di consulenza:

• Non puoi aiutare le persone che non vogliono essere aiutate.

Non puoi far fare a nessuno qualcosa che non vogliono fare se non per forza di autorità, che non hai.

Come allenatore, presento Agile con tre regole:

1. È impossibile raccogliere tutti i requisiti all'inizio del progetto.

2. Qualsiasi requisito che fa riunisce è garantito che cambi.

3. Ci sarà sempre molto altro da fare che il tempo e i soldi permetteranno.

e un obiettivo:

• Consegna qualcosa di valore ogni settimana.

Questo è tutto ciò che serve per iniziare.

Convincere il tuo manager è un'altra cosa.

Non puoi "fare" in modo che un manager comprenda l'agilità in modo diverso da come puoi far capire a uno sviluppatore. Devi presentargli le argomentazioni (i libri di Kent Beck sono un buon inizio) e fargli decidere da solo.

In alternativa, puoi chiedergli di farti eseguire un esperimento. Prendete un piccolo progetto ed eseguitelo con uno sviluppo iterativo e tenete sotto stretto controllo tempi, budget, problemi di qualità e soddisfazione del team. Confrontalo con progetti precedenti (o versioni) e verifica se era migliore, peggiore o neutro.

Non fai

Prima di tutto, perché un Senior Director è coinvolto anche nella scelta della metodologia di sviluppo del software? Questa decisione è molto al di sotto del suo grado di paga, sa di microgestione e parla di sfiducia.

In secondo luogo, perché ha bisogno di capirlo affatto? Se le specifiche del software sono fisse in pietra, allora ci sarà esattamente un'iterazione. Se non lo sono, allora ci saranno più iterazioni. Questa non è la sua decisione .

Se pensa che sia la sua decisione, allora sta minando l'autorità di IT Manager, project manager, architetto IT, team leader e team di sviluppo. Quindi dovrebbe scrivere lui stesso il software @ # $% ing, o STFU e lasciare che i professionisti facciano il loro lavoro liberi dai cervelli dei dinosauri.

Non sto scherzando. Se non può fidarsi di te per fare il tuo lavoro, dovrebbe farlo da solo e dovresti scappare urlando .

"Fare software è come fare un film, è necessario pianificare in anticipo, ma durante le riprese è necessario fare nuove riprese, rivedere vecchie scene e modificare il prodotto finale per garantire un buon risultato"

Poi di nuovo, è un manager, quindi nelle sue parole:

"Abbiamo bisogno di sfruttare la nostra flessibilità sinergica per generare una soluzione di servizio completo just-in-time"

Il vecchio detto vale: puoi portare il cavallo in acqua, ma non puoi farlo bere.

Come altri hanno sottolineato, ciò che dovrebbe veramente importare a questo alto dirigente è il valore del business. Potresti provare a fornire una rapida stima di quanto tempo dovrai dedicare alla stesura dei suoi diagrammi di flusso e dei diagrammi dei moduli e scrivere una SDS "completa" (concetto ridicolo, ma dagli quello che vuole). Se so qualcosa su queste cose (e quando ho iniziato a scrivere software, così è stato), la tua stima sarà facilmente di diverse settimane uomo, se non di più per un progetto considerevole. Esprimi quella cifra in denaro.

Quindi mostragli quante funzionalità potresti fornire nello stesso tempo. Parla con alcune persone del settore su quanto tempo vorrebbe salvarle per avere un'app Web di base che fa quelle cose che potresti fornire nello stesso momento. Quindi moltiplica questo risparmio, anche se spesso usano questa funzione, per esempio, 3 anni. Esprimilo in denaro.

Ci sono probabilmente altri benefici aziendali che possono essere espressi in denaro. Il mio preferito è sempre la prevenzione "goofball". Se il tuo software può aiutare a minimizzare i disastri o evitarli del tutto, allora trova un disastro recente ed esprimilo in termini monetari. Quindi di 'al tuo capo: se avessimo questo adesso, avremmo risparmiato questo denaro.

E se il trucco del denaro non funziona, allora forse dovrebbe andare da lui e dirgli di smettere di micro-gestire la sua squadra. Anche se, secondo la mia esperienza, è più probabile che ti licenzi di qualsiasi altra cosa.

Il luogo semplice potrebbe essere il Manifesto per lo sviluppo di software agile .

Le informazioni che trovi in questo luogo riguardano i principali principi dello sviluppo di software agile definiti da un gruppo di professionisti ben noti.

Questo è

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa
• Collaborazione con il cliente per la negoziazione del contratto
• Risposta per cambiare a seguito di un piano

Per favore, dai un'occhiata alla pagina in dettaglio per ottenere il pieno intento.

Suggerirei di provare a mostrargli che facendo "Rapid Prototyping" (ovvero iniziando a codificare le prime iterazioni) puoi rendere più veloce e accurato il tuo SDS (che significa meno rilavorazioni in seguito) e iniziare a fornire valore di business in precedenza . In realtà, il valore di business più probabile è tutto ciò che importa a questo regista e ha deciso che il modo migliore per ottenerlo è attraverso questo processo sequenziale. Devi mostrargli nei suoi termini perché il tuo approccio è migliore.

Questo potrebbe essere d'aiuto - link

In this movie "I want to run an agile project" we follow the experiences of one such brave project leader, Luke, as he has many different encounters throughout the enterprise, working to establish and deliver his Agile project.