Quale metodologia di programmazione sarebbe adatta a noi?

Sfortunatamente, qualcuno ha insegnato ai nostri dirigenti la parola "Agile" e ora vogliono che ci muoviamo verso di esso. Ho una comprensione periferica dell'agile (in linea di principio) ma non l'ho mai usato in pratica. Da quello che so, non sarà adatto alla nostra organizzazione. In questo momento, le cose sono piuttosto grungey. Ecco com'è;

Siamo un team molto piccolo: due sviluppatori, un DBA, un designer. La società per la quale lavoro guadagna una quantità sproporzionatamente grande di denaro rispetto alle sue dimensioni, e quasi il 95% di questo è pura vendita online.

Dal punto di vista dello sviluppo, siamo sottoposti a molte invasioni da scrivania durante una giornata tipo (siamo supporto tecnico e sviluppo), il lavoro può regolarmente cadere dal cielo in un momento se un membro del team di vendita promette qualcosa a qualcuno . Intraprendiamo anche progetti più grandi, e sono un incubo con le continue interruzioni. Alcuni di noi stanno iniziando a strapparsi i capelli! I piani di progetto sono elaborati da gestori non tecnici in fogli di calcolo Excel, in cui cercano di suddividere l'attività in frasi di dimensioni ridotte che possono comprendere e inserire una data accanto a ciascuna. Queste date sono sempre terribilmente irrealistiche e spesso mancate, e i nostri incontri (che abbiamo circa settimanalmente) sono regolarmente pieni di momenti imbarazzanti con la gente che chiede "perché non è ancora stato fatto".

Sono abbastanza sicuro che Agile non è quello per noi. Ora, dato che (e ho provato) questa azienda non cambierà i suoi modi , e solo il team di sviluppo è disposto a cambiare, c'è una metodologia di sviluppo che potremmo adottare che è adatta per salvarci un po 'di buonsenso?

Agile è stato progettato per risolvere molti dei problemi esatti che stai riscontrando. Se il management ha veramente acquistato e non pervertirà il processo, potresti vedere un grande miglioramento. Lasciami affrontare i tuoi problemi punto per punto. La mia esperienza è con Scrum, quindi parlerò da quel punto di vista, ma sono sicuro che altre implementazioni hanno benefici simili.

• lavoro che cade dal cielo Queste storie vengono messe in fondo all'arretrato fino a quando il proprietario del prodotto e il team possono incontrarsi per concordare di spostarlo verso l'alto. La sua priorità viene determinata in relazione agli altri impegni della tua squadra e tale priorità è visibile a tutti gli stakeholder che sono interessati a guardare. Dovrebbe essere estremamente raro aggiungere una nuova funzione nel mezzo di uno sprint e solo i bug con la priorità più alta dovrebbero poter interrompere uno sprint. È sorprendente quante "emergenze" possano attendere fino alla fine della prossima settimana, quando viene fatta un'aspettativa regolare.
• intraprendere progetti più grandi Avrai la visibilità per mostrare come le priorità a breve termine incidono sui tuoi progetti a lungo termine. Se le persone spostano continuamente le storie degli utenti di fronte ai tuoi progetti a lungo termine, va bene, ma per prendere questa decisione tutti sapranno l'impatto che avrà sul programma del progetto a lungo termine.
• i piani di progetto sono elaborati da gestori non tecnici Le storie degli utenti dovrebbero essere scritte da un punto di vista non tecnico, ma il team di scrum dovrebbe avere il potere di fare stime e determinare i dettagli di implementazione.
• le date sono orribilmente irrealistiche Il tuo team gestisce tutte le stime, perché sei tu che sai cosa stai facendo. Se tali stime non sono accettabili per l'azienda, devono decidere come stabilire le priorità delle funzionalità. Se hanno bisogno di più lavoro di quanto tu possa gestire, sarà chiaramente visibile la necessità di assumere più persone.
• le date sono spesso mancate Innanzitutto, le tue stime saranno più realistiche, il che dovrebbe aiutare. Inoltre, stai mordendo pezzi più piccoli e in realtà li finisci , il che aiuta l'azienda a pensare di aver prodotto qualcosa di utile anche se non completo.
• incontri pieni di momenti imbarazzanti Agile ha più visibilità e un ciclo di feedback molto più rapido, con un proprietario del prodotto fortemente coinvolto. I tuoi problemi di blocco e i motivi del ritardo non dovrebbero essere una sorpresa.
• anche facendo supporto tecnico Contrariamente alla credenza popolare, l'agile non è incompatibile con un programma diviso. Mischia fattori nelle tue interruzioni nella velocità della tua squadra. Se normalmente passi metà del tuo tempo a fare supporto tecnico, avrai semplicemente metà della velocità.

Ciò che la gestione e le vendite devono capire è che l'agile non è un modo per esercitare un controllo più stretto sul team di sviluppo, ma dà al team più autonomia per fare ciò che è bravo mentre aiuta l'azienda a considerare realisticamente tutte le sue priorità ogni volta che si assegna lavoro a Il gruppo.

Direi che approfitta dei tuoi capricci gestionali! Sembra che ti stiano facendo un favore e ti stiano dando una leva per migliorare i tuoi metodi di lavoro.

Di 'loro OK, andremo agili tra le altre cose: -

• una separazione di sviluppo e supporto
• un processo formale di raccolta dei requisiti - sotto il controllo del team IT. "Storie" ecc. Sembrano tutte molto vaghe, ma in realtà è un metodo "formale" vestito per sembrare informale.
• la pianificazione è sotto il controllo del team IT.

Se non lo accettano, digli che non puoi diventare agile.

Agile non è una metodologia di programmazione, Agile è una metodologia di gestione del progetto. Se i vertici aziendali vogliono davvero che tu provi questa nuova parola d'ordine che hanno trovato, devono essere in grado di capire che il metodo Agile parte dall'alto e coinvolge la gestione in ogni fase del processo. Se hai bisogno di dare loro una dura dose di realtà, magari organizza una presentazione in Powerpoint di 30 minuti su Agile per dare loro un po 'di educazione. I gestori adorano Powerpoint.

Tuttavia, se, come dici tu, il team di sviluppo è l'unica persona disposta a cambiare, allora nessuna metodologia di sviluppo sarà in grado di aiutarti. Senza una riduzione del resto dei tuoi doveri, continueranno a verificarsi interruzioni e ti verrà chiesto di rispettare scadenze che semplicemente non puoi rispettare.

Il mio consiglio in questo scenario è di educare, non rimproverare, la gestione di come sia realmente in prima linea.

Nessuna metodologia di sviluppo del software e di gestione dei progetti può aiutare in un'organizzazione in cui i venditori stabiliscono il programma quotidiano. Come dovresti gestire un progetto in una settimana lavorativa così caotica e distratta?

Così molti dirigenti vedono il valore di Agile e ne desiderano i benefici, ma non sono quasi mai in grado di apportare le modifiche interne necessarie per assicurarsi che la mossa abbia successo. Gli unici negozi Agile di successo che ho conosciuto erano iniziati in quel modo. Non riesco a ricordare una singola istanza nella mia esperienza professionale di un negozio di sviluppo software gestito da vendite o in cascata che fa la mossa perché richiede un cambiamento fondamentale nella cultura.

Questo cambiamento nella cultura è possibile? Sì, ma nel tuo caso quasi certamente no.

Un cambiamento nella cultura è di solito richiesto da un concorrente che minaccia l'esistenza della società o una situazione di make o break o qualche altra situazione similmente coinvolta per giustificare una riorganizzazione. Nella tua situazione, la tua azienda è all'estremo opposto dello spettro in cui i soldi in questo momento sono facili e tutti stanno ingrassando.

Le aziende non cambiano MAI dall'interno quando i soldi sono facili. Perché dovrebbero, hanno successo nonostante i fallimenti nello sviluppo del software, non a causa dei successi nello sviluppo del software.

Il mio ultimo consiglio è che se fossi in te cercherei qualcosa di meglio. Le persone qui hanno un grande consiglio, ma ho già visto questa canzone e ballare prima e non funziona nella tua situazione.

guarda extremeprogramming.org - XP è una forma di Agile con aspetti facilmente comprensibili che puoi scegliere e scegliere a carrello; un ottimo punto di partenza

l'impegno del cliente a non cambiare idea durante un'interazione sarebbe un buon punto di partenza per il tuo ambiente, dal suono di esso ;-)

Se si considerasse il panorama delle metodologie, sia tradizionali che contemporanee, ci si renderebbe conto che "Agile" è più un "anti-metodologia" che una metodologia. Gli schemi mirano a rappresentare la soluzione "best-case" a un determinato problema in un contesto particolare. I tentativi di violare direttamente una tale soluzione o modello, sono generalmente indicati come "anti-schemi" o pratiche peggiori. Allo stesso modo, mentre le vere metodologie di sviluppo del software tentano di prescrivere le migliori pratiche nello sviluppo di soluzioni, "Agile" (Scrum, XP, ecc.) Tenta di violare direttamente qualsiasi struttura all'interno del processo di sviluppo del software, a favore di un caos, caotico approccio - che (di recente), sembra richiedere anche applausi da curiosi (ingenui).

Detto questo, è opportuno tenere presente il contesto in cui è nata la filosofia Agile. Sebbene all'epoca esistessero sofisticate metodologie iterative (ad es. Unified Process), la metodologia principale era ancora il vecchio approccio a cascata, che prescriveva una "best practice" di analisi dei requisiti completa, quindi completa la progettazione, quindi sviluppa / codifica la soluzione, quindi implementa la soluzione. Chiaramente, questo approccio ingegneristico allo sviluppo del software è stato sconsigliato e ha portato a un sacco di scartoffie prima (e talvolta senza mai) di vedere una soluzione eseguibile.

Tuttavia, non garantisce ancora il lancio del bambino con l'acqua del bagno, come nel caso dei prestigiatori di Agile. L'approccio Agile quasi impone una negazione diretta di tutto ciò che è stato utilizzato prima di esso - tranne forse l'effettiva codifica della soluzione. Chiaramente, questa è un'indicazione di una visione limitata da parte dei suoi autori, o forse è semplicemente un caso di "non ce ne sono così ciechi, come quelli che non vogliono vedere".

Tuttavia, il merito dell'agile è che incoraggia i processi semplificati e si concentra sul codice eseguibile, che è inevitabilmente il tuo ultimo risultato.

ORA, per rispondere alla tua domanda più direttamente:

Data la tua visione d'insieme del tuo ambiente, ti suggerisco innanzitutto di selezionare un'implementazione Agile (es. Scrum, XP, ecc.). Quindi personalizza l'approccio alla suite del tuo ambiente, delineando un chiaro processo di funzionamento del tuo team, ad esempio:

• Ricevi richieste dagli utenti;

• Dai la priorità alle richieste degli utenti;

• Calcolare l'impatto del miglioramento sul sistema esistente (magari durante le riunioni stand-up giornaliere / settimanali);

• Stimare i tempi di sviluppo di ciascun miglioramento e comunicarli ai vari utenti richiedenti;

• Eseguire miglioramenti effettivi sul sistema esistente (ad es. Codifica).

• Effettuare test degli utenti e ottenere l'impegno degli utenti (ad esempio via e-mail) che le modifiche richieste sono state implementate correttamente.

Ciò dovrebbe fornire una certa struttura (e ordine), pur mantenendo una parvenza di approccio Agile.

Detto quanto sopra, ricorda che la vecchia figura retorica inglese, "Come agile come una scimmia", non fu coniata senza motivo!

Direi che hai bisogno di una metodologia come Agile è essenziale per la tua squadra. Poiché la tua azienda è così disorganizzata, devi essere più organizzata all'interno del tuo team di sviluppo. Non credo tuttavia che i tuoi manager non tecnici debbano avere a che fare con questo.

Se hai intenzione di respingere i tuoi venditori e richiedere scadenze realistiche, devi giustificarlo con piani organizzati.

Anche su una nota separata se vengono da te con preventivi senza consulenza tecnica, quindi semplicemente rifiutali.

Forse focalizzarsi sugli aspetti incrementali / iterativi è ciò che sia il tuo team, sia le parti interessate che escono dal cielo devono essere in grado di fornire regolarmente e coerentemente. Nel tempo, il team di vendita e la direzione acquisiranno fiducia nel fatto che quando inseriscono una nuova richiesta di funzionalità, possono essere certi che il team consegnerà in tempi adeguati.

Ovviamente, devi investire in test di unità / sistema / regressione, build automatizzate, cibo per cani, ecc. Per arrivarci se non ci sei già.

Per prima cosa suggerirei di raccogliere alcuni dati. Siediti in un momento tranquillo e scopri cos'è lo status quo: come vengono fatte le cose. Se la direzione è decisa a implementare qualcosa che può chiamare agile, allora cerca di capire qualcosa che funzioni per la tua squadra, elabora un documento, schiaffeggia "Agile" sul nome e sei a posto. Tieni presente che l'unica cosa che sanno veramente di agile è la parola e qualche vaga associazione con la rapidità per la sua solita definizione in inglese. Quindi quello che sto sostenendo è che il tuo team risolva il problema, trova un sapore che funziona per te e poi lo presenta alla tua direzione come il modo Agile (tm). Altrimenti alcuni PHB prenderanno in mano un libro e proveranno ad inserire il piolo quadrato nel foro rotondo e nessuno sarà felice.

Se scegli una forma "pura" di agilità, potrebbe essere difficile che anche il tuo team debba svolgere il ruolo di supporto. Ammettiamolo, il tuo capo potrebbe avere difficoltà ad accettare i membri del tuo team che rispondono alle richieste dell'help desk dicendo "lasciami creare un articolo arretrato, lo raggiungerò tra (tempo alla fine dello sprint) settimane".

Il più grande ostacolo è quello dei soldi. Se tutto è sugo verde, è molto più difficile dire che qualcosa non va e deve cambiare.

Buona fortuna.

Al contrario, mi sembra che un metodo Agile sia esattamente ciò di cui hai bisogno per gestire scadenze mancate, aspettative non realistiche e progetti mal pianificati.

Il tuo management ha indicato di essere interessato a questa nuova parola Buzz. Molto probabilmente vorranno usarlo per promuovere la commercializzazione dei tuoi prodotti. questa non è necessariamente una cosa negativa, ma dovrà essere gestita con molta attenzione se vuoi far funzionare un metodo Agile per te.

Metà della battaglia sta ricevendo buy-in dalla direzione. Avere loro ricettivi all'idea stessa di Agile è la maggior parte della battaglia. Il resto è assicurarsi che le loro aspettative siano gestite in modo che continuino a desiderare che tu sia agile, ed evitare che rimangano disincantati quando e se i tuoi manager hanno la sensazione che il loro controllo sulla gestione del progetto stia in gran parte scivolando tra le dita.

Prima che la tua azienda decida qualcosa, consiglierei di salire su un pullman Agile per seminari e seminari di mezza giornata. Fai in modo che tutti pensino come una squadra - manager e sviluppatori allo stesso modo - su ciò che Agile ritiene che funzionerà per te e ciò che senti non lo farà. Se d'altro canto la direzione si fida del proprio giudizio, sarà necessario acquisire familiarità con una serie di pratiche e metodi agili e creare un seminario o il proprio. Personalmente, mi sarei orientato verso un allenatore esperto, in modo da non perdere molto tempo e mantenere lo slancio. Nel frattempo, prendi una copia di un paio di buoni libri Agile come riferimenti, leggili attentamente, ma lasciali anche appesi alla scrivania dove i dirigenti possono vederli. La psicologia subliminale può fare miracoli in una situazione come quella che hai descritto.

Raccomanderei almeno di leggere quanto segue:

• Sviluppo software snello - Mary & Tom Poppendieck
• Sviluppo software agile - Robert C. Martin

e per credito extra (perché penso che sia un ottimo compagno per gli altri libri che ho citato):

• Codice pulito - Robert C. Martin