quando utilizzare un framework di sviluppo software agile scalato / aziendale e quando lasciare emergere i processi agili?

Grazie per aver elencato il mio libro tra i primi 5.

"Agile Project Management for Government" prende un nuovo approccio in quanto descrivo la vita reale, attribuito pienamente successi agili. Questi sono casi di studio su scala Enterprise.

Non sono d'accordo con DSDM (anche se il libro inizia con un caso DSDM su una svolta nello sviluppo tecnologico del campo di battaglia del Regno Unito). L'uso spettacolare di Scrum all'FBI negli Stati Uniti per salvare il loro progetto di Sentinel da 750 milioni di dollari, in precedenza fallimentare, è assolutamente da leggere. Molti altri esempi da Stati Uniti, Regno Unito e in tutto il mondo.

Quindi la mia raccomandazione è di usare qualsiasi struttura prescrittiva che ti piace dagli altri 4 autori - ma se hai bisogno di convincere la tua gestione ad andare agile, usa il mio libro per fare il backup dei tuoi argomenti con prove.

Brian Wernham

bit.ly/Brians-Blog

Londra

Question 1: When should one choose an enterprise agile software development framework, and when should one just let their agile processes 'emerge'.

Devi sempre lasciare che i tuoi processi emergano, agili o meno. Applicare un processo è un ottimo modo per quel processo di non corrispondere a ciò che è necessario fare, causando inefficienza per lo meno. (Vedi Rands ' per buoni link e consigli di esperti sul perché è così).

La scelta di un framework dipende dal fatto che si desideri emergere dal nulla (leggi: alcuni stati iniziali su cui decide il tuo team) o da un framework che ha funzionato molto bene per gli altri. Non c'è una risposta giusta lì. Se la tua azienda lavora in modo molto simile ad altre società, con personalità simili e strutture aziendali simili, allora iniziare con la struttura di qualcun altro è grandioso. Se la tua azienda è davvero strana in quello che fa, come funziona e chi ci lavora, magari iniziare con quello che pensi sia il migliore potrebbe rivelarsi migliore dell'usare qualcosa che non si adatta bene alla tua situazione.

L'obiettivo in questa scelta è scegliere un punto di partenza che ritieni più vicino a dove evolverai il processo, in modo che l'evoluzione non sia molto dolorosa.

Scopri come essere agile per primo.

Penso che ci sia un problema con l'adozione di agile per la prima volta insieme a un sistema aziendale? Se avessi una startup useresti qualcosa come QuickBooks o qualche grande sistema di contabilità aziendale come SAP? Sembra che dovresti capire come gestire la contabilità e altri sistemi per la tua azienda prima con qualcosa di più appropriato. Consiglierei di iniziare con un piccolo progetto che sia agile e che abbia abbastanza importanza in modo che tutti prendano sul serio il processo, ma non così super-mission critical e tempestivi che probabilmente soffriranno provando qualcosa di nuovo.

Question 1: When should one choose an enterprise agile software development framework, and when should one just let their agile processes 'emerge'.

Inizia con un piccolo gruppo. Nella mia esperienza, agile come qualsiasi altra cosa dovrebbe iniziare con qualcosa di stabilito quando possibile. Perché reinventare la ruota soprattutto se non sai come inventare una ruota? Molte metodologie agili hanno molto in comune. Ci saranno alcuni aspetti in cui molti membri del tuo team vedranno alcune parti come assassini di affari assoluti (ad esempio programmazione della coppia). Probabilmente sarai in grado di estirpare molti di loro. Seleziona alcuni per la revisione a seconda di quante risorse hai per questo processo. Certo sarebbe bello se si potesse scegliere 10, ma potrebbe avere solo il tempo sufficiente per 3.

Sì, ci saranno dei vincoli, ma è possibile iterare questo processo (che è nello spirito dell'agile) e apportare modifiche basate su alcuni dati ed esperienze e non solo sulle preferenze personali. C'è il rischio che qualcuno sia un fanatico di un particolare processo e vuole aderire a esso a scapito del progetto, ma ciò può accadere con qualsiasi cosa. La chiave qui è di non avere troppe parti mobili con troppe modifiche, proprio come il buon design sperimentale. Se si escludono alcuni aspetti troppo presto, si rischia di perdere l'effetto di alcune parti che lavorano insieme (la programmazione delle coppie subisce un brutto colpo, ma sostituisce lo sviluppatore solitario su un progetto.). Tuttavia, se ci sono aspetti di una particolare metodologia che sarà una grande impresa per la tua squadra (ad esempio, nessuno ha la minima idea dei test unitari), potrebbe essere necessario dargli un po 'di tempo prima di provare a fare tutto in una volta.

Question 2: If choosing an enterprise agile software development framework, how does one select the appropriate framework to use for their organisation?

Questo dovrebbe essere molto più semplice una volta adottato e possibilmente adattato alle tue esigenze su piccola scala. Sarà più facile mettere una lista di bisogni. Puoi chiedere ad altri tipi particolari con domande più specifiche perché sarai in grado di comunicare le tue particolari esigenze.