Ho un problema con un direttore senior che non capisce lo sviluppo iterativo (molto meno Agile). Insiste sul fatto che le nostre specifiche di progettazione software (SDS) siano complete prima di scrivere qualsiasi riga di codice. Completo, per lui, significa che tutti i dettagli funzionali sono lì. Inoltre, essendo un ex programmatore Cobol, vuole vedere "moduli" e diagrammi di flusso. Questa è un'app Web Java per gridare forte!

In ogni caso, sto cercando di trovare un posto semplice per indicarlo delicatamente per dimostrare che la SDS non deve essere completa al 100% prima di iniziare la codifica (né può essere completa). Eventuali suggerimenti?

Grazie!

Come consulente, capisco una semplice regola di consulenza:

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

Non puoi far fare a nessuno ciò che non vogliono fare se non con la forza dell'autorità, che non hai.

Come allenatore, presento Agile con tre regole:

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

2. Qualunque cosa requisiti che fare raccogli sono garantiti al cambiamento.

3. Ci sarà sempre più da fare di quanto il tempo e il denaro consentiranno.

e un obiettivo:

• Offri qualcosa di valore ogni settimana.

Questo è tutto ciò che serve per iniziare.

Convincere il tuo manager è un'altra cosa.

Non puoi "far capire" a un manager agile in modo diverso da come puoi far capire a uno sviluppatore. Devi presentare gli argomenti (i libri di Kent Beck sono un buon inizio) e lasciargli prendere una decisione.

In alternativa, puoi chiedergli di lasciarti fare un esperimento. Prendi un piccolo progetto ed eseguilo con lo sviluppo iterativo e tieni sotto controllo il tempo, il budget, i problemi di qualità e la soddisfazione del team. Confrontalo con i progetti (o le versioni) precedenti e vedi se era migliore, peggiore o neutrale.

Tu no

Prima di tutto, perché un direttore senior è anche coinvolto nella scelta della metodologia di sviluppo del software? Quella decisione è molto al di sotto del suo grado retributivo, sa di microgestione e parla di sfiducia.

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

Se pensa che sia una sua decisione, sta minando l'autorità del responsabile IT, del project manager, dell'architetto IT, dei responsabili del team e del team di sviluppo. Quindi dovrebbe scrivere lui stesso il software @ # $% ing o STFU e lasciare che i professionisti facciano il loro lavoro libero 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 .

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

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

"Dobbiamo sfruttare la nostra flessibilità sinergica per generare una soluzione full service just-in-time"

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

Come altri hanno sottolineato, ciò che dovrebbe davvero importare a questo senior director è il valore aziendale. Potresti provare a fornire una rapida stima di quanto tempo trascorrerai stendendo i suoi diagrammi di flusso e i diagrammi dei moduli e scrivendo una SDS "completa" (concetto ridicolo, ma dagli ciò che vuole). Se so qualcosa di queste cose (e quando ho iniziato a scrivere software, è stato così), la tua stima sarà facilmente di diverse settimane uomo, se non di più per un progetto considerevole. Esprimi quella cifra in denaro.

Quindi mostragli quanta funzionalità potresti offrire contemporaneamente. Parla con alcune persone del settore su quanto tempo risparmierebbe loro per avere un'app Web di base che fa le cose che potresti offrire nello stesso tempo. Quindi moltiplica questo risparmio per quanto spesso utilizzi questa funzione, diciamo, in 3 anni. Esprimilo in denaro.

Probabilmente ci sono altri vantaggi aziendali che possono essere espressi in denaro. Il mio preferito è sempre la prevenzione "goofball". Se il tuo software può aiutare a ridurre al minimo i disastri o evitarli del tutto, trova un disastro recente ed esprimilo in termini di denaro. Quindi dì al tuo capo: se avessimo avuto questo in questo momento, avremmo risparmiato questi soldi.

E se il trucco dei soldi non funziona, allora forse dovrebbe avvicinarsi a lui e dirgli di smettere di micro-gestire la sua squadra. Anche se, nella mia esperienza, è più probabile che ti faccia licenziare di ogni altra cosa.

Il posto semplice potrebbe essere il Manifesto per lo sviluppo di software Agile .

Le informazioni che trovi su questo sito riguardano i principi fondamentali dello sviluppo software agile definiti da un gruppo di professionisti ben noti.

Questo è

• Individui e interazioni su processi e strumenti
• Software funzionante su documentazione completa
• Collaborazione con i clienti sulla negoziazione del contratto
• Rispondere al cambiamento seguendo un piano

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

Suggerirei di provare a dimostrargli che facendo "Rapid Prototyping" (ovvero iniziando a codificare le prime iterazioni) puoi migliorare più rapidamente e accuratamente la tua SDS (il che significa meno rilavorazioni in seguito) e iniziare a fornire valore commerciale prima. In realtà, molto probabilmente il valore commerciale è tutto ciò che conta per questo direttore e ha deciso che il modo migliore per raggiungerlo è attraverso questo processo sequenziale. Devi mostrarlo nei suoi termini perché il tuo approccio è migliore.

Questo potrebbe essere di aiuto - http://www.youtube.com/watch?v=4u5N00ApR_k

In questo film "Voglio gestire un progetto agile" seguiamo le esperienze di uno di questi coraggiosi leader del progetto, Luke, che ha molti incontri diversi in tutta l'azienda, lavorando per stabilire e consegnare il suo progetto Agile.