Come consentire l'innovazione in una metodologia agile [chiuso]

Una cosa è dire che le metodologie agili sono buone in contesti in cui i requisiti sono scarsamente compresi o che sono coinvolte novità significative . Ma dovrebbe essere applicato laddove è richiesta un'innovazione assoluta? Se si, come?

Se ciò che stai contemplando è sconosciuto nel settore, o addirittura ritenuto impossibile, potrebbe essere difficile concepire le storie degli utenti e le attività correlate. Ad esempio, avrebbe beneficiato Albert Einstein (o un ipotetico datore di lavoro a cui riferisce) di aver ideato la teoria della relatività generale suddividendola in epiche, sprint e compiti? Se la risposta è "sì", quali alloggi speciali avrebbero dovuto essere incorporati per aiutare un approccio agile a funzionare meglio con il modo di Einstein di ottenere una visione rivoluzionaria?

Per fornire un esempio di software specifico, immagina che l'anno sia il 2008 e che desideri utilizzare WCF per fornire funzionalità di tipo COMET o " polling lungo ". Tutte le tue ricerche sul "lavoro precedente" non danno risultati e hai persino letto un blogger di MSDN dicendo che non è possibile.

Ancora una volta, quali aggiustamenti o "sapori" potrebbero essere introdotti nelle storie utente e nei compiti per soddisfare l'inventiva (o audacia?) Di questo endeaver? O sarebbe davvero meglio concludere che lo sforzo è così innovativo (nel 2008), che è meglio lasciarlo come esercizio di riflessione non indirizzato?

L'innovatore che opera con sprint di due settimane certamente non vuole essere abbattuto ogni volta che abbandona un'attività senza uscita e inizia a lavorare su un'attività appena scoperta che non era prevista al momento della definizione dello sprint. Allo stesso modo, quando lo sprint termina e non viene fornito alcun codice funzionante o approcci lavorativi, l'innovatore non dovrebbe essere abbattuto dalla direzione. Deve esserci un modo per etichettare lo sforzo come "successo" anche in queste circostanze. In forse uno o tre ulteriori sprint di questo tipo di "vicoli ciechi", l'innovatore potrebbe finalmente colpire qualcosa che funziona.

In che modo l'agile consente al management di sapere che ogni sprint è stato "ok" nonostante le battute d'arresto innovative? Come viene gestito in modo tale che il diagramma di burn-down non appaia assurdo?

La domanda del titolo, in cui l'innovazione si riferisce a progressi creativi su scala ridotta in un team che sta già andando bene in Agile.

La migliore risposta è riassunta in questo articolo su "Gold Card Days" .

Riepilogo (parafrasato e con le mie interpretazioni che potrebbero non riflettere le intenzioni dell'autore) :

• Gli sviluppatori possono identificare obiettivi di allungamento interessanti (intellettualmente stimolanti) che sono correlati al lavoro su cui vorrebbero lavorare.
• Questi obiettivi di allungamento, dopo essere stati approvati dal team (incluso il product owner), diventano "carte d'oro".
• Il team è incoraggiato a dedicare una giornata a lavorare su queste "carte d'oro".
  • Di solito questo accade di venerdì, quindi diventa il "Gold Card Day".
• Rispetto a Scrum, le Gold Card sono programmate e tracciate proprio come qualsiasi altro articolo arretrato; il team dovrà dimostrare i propri risultati.

Ci sono alcuni altri punti (non in quell'articolo) in relazione all'applicazione di "carte d'oro":

• Non lasciare che un solo membro del team si prenda tutto il divertimento. Ogni membro del team dovrebbe essere incoraggiato a trascorrere un po 'di tempo creativo prendendo una "giornata d'oro" una volta ogni tanto.
• Sulla stessa linea, prova a trasformare una "carta d'oro" in uno sforzo di squadra (al contrario di un compito da solista) e sfrutta quel compito come un momento di socializzazione (team building).

La domanda sostanziale, in cui l'innovazione si riferisce alla ricerca (mesi o anni di lavoro raccapricciante) che hanno il rischio reale di non trovare alcuna soluzione utile.

Questa domanda precedente, quali tecniche di programmazione estrema sono appropriate da utilizzare in un ambiente di ricerca? copre gran parte del motivo di questa domanda.

(Dichiarazione di non responsabilità: ho scritto una delle risposte a quella domanda, sebbene non quella selezionata.)

Il riassunto è che il lavoro di ricerca del software può essere frenetico; richiede ai suoi partecipanti di stabilire le priorità in base a nuove informazioni (assorbendo idee scoperte / apprese e sintetizzandone di nuove). Dà l'impressione di essere "lento" solo perché è "lento a mostrare i frutti del successo, e solo se ha avuto successo".

Questa domanda su Project Management Beta - Quali sono i vantaggi e gli svantaggi dell'integrazione di un project manager in un team di ricerca? - copre anche gli stessi motivi.

Nello spirito, sì.

Come sottolineato nella risposta di mouviciel , lo spirito della ricerca software è in linea con lo spirito del Manifesto Agile. Quello che discuterò dopo è se la ricerca ad alto rischio può essere inserita in Agile come organizzazione o metodologia di gestione ("Agile in practice").

In pratica, devi rispondere ad alcune domande.
Questo elenco non è esaustivo ...

Dobbiamo risalire un po 'a come nasce la metodologia agile.

La metodologia agile viene generalmente utilizzata quando è presente uno sponsor del progetto. Inoltre, la disponibilità dello sponsor a finanziare il progetto è limitata; prevede di ricevere regolarmente software di qualità utilizzabile (potenzialmente spedibile) dopo aver finanziato il progetto per qualche tempo.

Il tipo di lavoro di ricerca in questa domanda si riferisce a "sforzi potenzialmente non risolvibili". In altre parole, la natura stessa di questo tipo di lavoro comporta il rischio che alla fine possa fallire, nonostante tutte le intenzioni e la diligenza delle persone coinvolte.

Questa non è una lista di controllo in stile ScrumButt.
Questa è più una lista di controllo di verifica preliminare che prevede se si sta meglio "Que Sera, Sera"

1. Trasparenza in anticipo. Lo sponsor del progetto sta dicendo la verità sulla natura di rischiosità del progetto?

2. Disponibilità dello sponsor. Lo sponsor è consapevole del rischio e disposto a continuare il finanziamento?

Lo sponsor deve avere un'accettazione del rischio superiore ai progetti aziendali tipici o ai progetti software / IT / Agile tipici. Non tutti gli sponsor soddisfano questi criteri. Se non va bene, sarebbe bene per un professionista ritirarsi dal progetto.

3. Trasparenza durante il progetto. Lo sponsor viene regolarmente informato del vero stato del progetto?

Questo per contrastare i tentativi di nascondere battute d'arresto o incombenti fallimenti nel progetto abusando del lasso di tempo tra gli aggiornamenti di stato.

4. Partecipazione attiva dello sponsor. Lo sponsor è interessato a conoscere i dettagli chiacchieroni, gli alti e bassi, le promesse e i limiti di ogni tentativo?

Il problema con la ricerca sul software è che ci possono essere molti falsi indizi - sia falsi positivi (credendo che un approccio funzionerebbe ma alla fine non abbia successo), sia falsi negativi (affermare che qualcosa non è possibile, solo per essere smentito da qualcun altro) .

I progetti agili consentono al team (compresi gli sponsor e le parti interessate) di assumersi rischi calcolati. "Calcolato" significa che i soggetti che assumono il rischio sono pienamente informati. Se lo sponsor non è disposto a conoscere i dettagli del progetto, allora lo sponsor non avrà informazioni complete per calcolare (giudicare) il rischio da solo.

Anche se uno sponsor è disposto a correre il rischio finanziario, se non è disposto a prendere parte ai rischi del processo decisionale (e accetta conseguenze per le proprie scelte), lo sponsor non è idoneo per tali progetti di ricerca ad alto rischio.

5. Il team di ricerca può mostrare (dimostrare) i propri progressi sotto forma di software in esecuzione, rispetto alle diapositive di presentazione?

Questa domanda è appropriata per i progetti di ricerca in cui il risultato finale dovrebbe essere in esecuzione software. Le diapositive di presentazione potrebbero essere utili per spiegare le teorie di CS, ma potrebbero anche essere usate in modo improprio per nascondere battute d'arresto nell'implementazione del software (o la completa mancanza di). Una demo del software ha lo scopo di contrastare tali abusi.

6. Il team di ricerca può fornire un prodotto software parzialmente prezioso, anche se lo sponsor decide di interrompere il finanziamento in qualsiasi momento del progetto?

Questa domanda è pertinente solo caso per caso. Alcuni progetti di ricerca sono incrementali; possono avere più pietre miliari e risultati finali. Richiede a un gruppo di ricerca di stabilire le priorità dei loro approcci per favorire "i frutti più bassi per primi" o "l'approccio più economico per dimostrare la fattibilità".

Alcuni progetti di ricerca non sono incrementali: offrire un unico progresso tecnologico molto specifico. È un successo. Per questo tipo di progetti, gli unici risultati incrementali sono il lavoro di ricerca e prototipazione e forse le pubblicazioni accademiche. Questi risultati incrementali "non consumabili" sono comunque preziosi per alcuni tipi di sponsor - vale a dire università, agenzie di finanziamento della ricerca e grandi aziende che sperano di costruire buona volontà accademica.

Tuttavia, i progetti di ricerca con tali caratteristiche potrebbero anche favorire l'approccio della "codifica da cowboy", come discusso più avanti. Questi sono giustamente definiti "hack" e si verificano nel mondo accademico.

A causa della scala temporale della maggior parte della ricerca accademica, i finanziamenti per la ricerca in stile accademico sono generalmente forniti con un impegno di uno o più anni; il finanziamento della ricerca medica (accademica e commerciale) può essere impegnato per periodi ancora più lunghi. D'altra parte, la tipica ricerca finanziata con fondi commerciali può essere chiusa senza preavviso o le loro risorse (manodopera) essere completamente riassegnate ad altri progetti.

7. In che modo il team di ricerca misura sulla scala del silo rispetto a quella interfunzionale?

Alcuni tipi di team di ricerca sono molto insensibili. Spesso ciò accade in progetti "multidisciplinari": è coinvolto esattamente un membro di ciascuna disciplina. Di conseguenza, nessun membro può assumere il compito di un altro membro, nemmeno quelli molto piccoli, perché le loro conoscenze e abilità non si sovrappongono. La difficoltà si estenderebbe anche alle comunicazioni e alle definizioni delle attività.

Squadre estremamente insoddisfatte trarranno comunque beneficio da alcuni rituali Scrum come un incontro quotidiano, ma a parte il "rituale" potrebbe non esserci molta interazione in corso. Ci vorrebbe un allenatore agile e altamente socializzante per convincere la squadra a parlare e costruire fiducia.

8. Se è presente un coach agile, il coach prescrive brevi cicli di iterazione, time boxing e fornisce stime del tempo?

Ognuna di queste pratiche agili pone difficoltà per alcuni tipi di progetti di ricerca. Tuttavia, è stato riferito che alcuni gruppi di ricerca abilmente qualificati sono stati in grado di applicare queste pratiche nella ricerca avanzata . Dal momento che non ci sono dettagli su come avviene un coaching agile all'interno di questi team di esperti, potremmo non essere in grado di sapere come superare ciascuna di queste difficoltà.

9. Il team di ricerca vota all'unanimità per l'adozione dello stile di sviluppo Solo rispetto a qualsiasi altra metodologia?

Modificato: una versione precedente utilizza la frase "codifica da cowboy", che allude alla mancanza di professionalità. Tuttavia, esiste una differenza tra lo sviluppo solista e la codifica da cowboy e le circostanze in questo elenco di controllo possono rendere lo sviluppo solista una scelta legittima.

Questa domanda mostra che ci sono programmatori che preferiscono possedere un grosso pezzo di sviluppo. Se il team di ricerca è composto principalmente da questo tipo di programmatori, dato che l'insieme di abilità dei membri del team è insostituibile (facendo riferimento al precedente silo di punti di abilità), è possibile che ai membri del team venga concesso ciò che desiderano, in cambio per le loro abilità e lavoro.

La differenza principale tra lo sviluppo solista e la codifica cowboy è che nello sviluppo solista, è possibile adottare le pratiche elencate in The Joel Test: 12 passaggi per migliorare il codice , come l'uso del controllo versione, l'automazione della build e la correzione di bug prima di aggiungere nuove funzionalità .

Alcune circostanze favoriranno ogni membro che esegue lo sviluppo solista, mentre altre favoriranno la codifica da cowboy.

La codifica da cowboy è favorita se l'obiettivo finale è "fare un punto", dimostrando che qualcosa è tecnologicamente possibile. Non ci sono requisiti per la consegna - né la qualità - a parte una buona presentazione sul prossimo DEF CON ® .

Domanda finale. Se le circostanze non consentono a un team Agile di effettuare ricerche pionieristiche, come possono utilizzare la tecnologia innovativa?

Affari come al solito. Consenti ad altre aziende (o accademici, individui o team di hacker , startup, ecc.) Di affrontare prima il problema difficile, quindi acquistare / autorizzare la tecnologia da loro. L'industria del software utilizza questi principi da molti decenni.

L'enfasi sul mostrare prototipi funzionanti nella metodologia Agile obbliga un team a cercare prima le soluzioni esistenti, il che è positivo perché potrebbe salvare il team da un lavoro ridondante.

Torna al manifesto Agile :

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

Niente in questi valori proibisce l'innovazione. In realtà, l'innovazione ha un nido migliore con Agile che con Waterfall.

Tuttavia, può accadere che le normali implementazioni di Agile ponga alcuni vincoli su un progetto software che limiti l'innovazione, come le scadenze (il periodo di tempo di uno sprint è una scadenza) o i costi. Ma questo non è un problema con Agile, è un problema con le attuali organizzazioni di lavoro.

Non penso che lo faccia. Agile consiste nel mangiare elefanti di cioccolato - svolgere un grosso compito e scomporlo in pezzi gestibili che non solo possono essere consegnati, ma vengono consegnati regolarmente.

I progetti di tipo di ricerca non si adattano a questo, a meno che il tuo progetto non possa essere suddiviso in piccoli pezzi che possono essere dimostrati ogni due settimane (o più a lungo) da nessuna parte Agile dice che 2 settimane è il tempo che il tuo sprint deve prendere, il miglior progetto agile che io abbia mai ha lavorato con sprint di 6 settimane)

Non ci proverei però. Prenderei i pezzi di strumenti agili che pensi possano funzionare per te e ignorerei quelli che non lo fanno. Troppe persone pensano che Agile significhi "devi fare tutto ciò che il tutorial di Scrum dice che devi fare e nessuna discrezione è mai permessa", tale approccio è molto poco agile.