Quale metodologia di programmazione ci starebbe bene?

Agile è stato effettivamente progettato per risolvere molti dei problemi esatti che stai riscontrando. Se la direzione ha veramente acquistato e non perverrà il processo, si potrebbe vedere un grande miglioramento. Lasciatemi indirizzare i tuoi problemi punto per punto. La mia esperienza è con scrum, quindi parlerò da questo punto di vista, ma sono sicuro che altre implementazioni hanno vantaggi simili.

• Lavoro che cade dal cielo Queste storie vengono messe in fondo al backlog fino a quando il proprietario del prodotto e il team non possono incontrarsi per accettare di spostarlo. La sua priorità viene determinata in relazione a tutti gli altri impegni del team, e tale priorità è visibile a tutti gli stakeholder che sono interessati a guardare. Dovrebbe essere estremamente raro aggiungere una nuova funzionalità nel mezzo di uno sprint, e solo i bug con la priorità più alta dovrebbero poter interrompere uno sprint. È incredibile quante "emergenze" possono aspettare fino alla fine della prossima settimana, quando ciò è reso normale.
• intraprendere progetti più grandi Avrai la visibilità per mostrare come le priorità a breve termine influenzano i 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 conosceranno l'impatto che avrà sul programma del progetto a lungo termine.
• I piani di progetto sono elaborati da manager non tecnici Le storie degli utenti sono supposte da scrivere da un punto di vista non tecnico, ma il team di Scrum dovrebbe essere autorizzato a fare stime e determinare i dettagli di implementazione.
• Le date sono orribilmente irrealistiche il tuo team gestisce tutte le stime, perché tu sei quello che sa cosa stai facendo. Se tali stime non sono accettabili per l'azienda, devono decidere come dare la priorità alle funzionalità. Se hanno bisogno di più lavoro di quello che puoi gestire, la necessità di assumere più persone sarà chiaramente visibile.
• le date sono spesso mancate Innanzitutto, le tue stime saranno più realistiche, il che dovrebbe aiutare. Inoltre, stai tagliando blocchi più piccoli e in realtà li rifiniscono , il che aiuta l'azienda a pensare di aver prodotto qualcosa di utile anche se non la funzione è stata completata.
• riunioni piene di momenti difficili Agile offre maggiore visibilità e un ciclo di feedback molto più rapido, con un proprietario del prodotto strongmente coinvolto. I tuoi problemi di blocco e i motivi del ritardo non dovrebbero essere una sorpresa.
• anche facendo supporto tecnico Contrariamente alla credenza popolare, agile non è incompatibile con un programma diviso. Fattori di mischia nelle tue interruzioni nella velocità della tua squadra. Se normalmente trascorri metà del tuo tempo facendo supporto tecnico, avrai solo metà della velocità.

Ciò che la gestione e le vendite devono rendersi conto è che agile non è un modo per esercitare un controllo più stretto sul team di sviluppo, dà al team più autonomia per fare ciò che è bravo mentre aiuta il business a considerare realisticamente tutto le sue priorità ogni volta che assegni lavoro al team.

Direi che approfitta dei capricci della tua gestione! Sembra che ti stiano facendo un favore e ti diano una mano per migliorare i tuoi metodi di lavoro.

Dì loro OK andremo agili richiede tra l'altro: -

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

Se non lo accettano, allora di 'loro che non puoi diventare agile.

Agile non è una metodologia di programmazione, Agile è una metodologia di project management. Se il management superiore vuole veramente che tu provi questa nuova parola d'ordine che hanno trovato, devono essere in grado di capire che il metodo Agile inizia 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 Powerpoint di 30 minuti su Agile per dare loro un po 'di educazione. I manager adorano Powerpoint.

Tuttavia se, come dici tu, il team di sviluppo sono le uniche persone disposte a cambiare, nessuna metodologia di sviluppo sarà in grado di aiutarti. Senza attenuare il resto dei tuoi doveri, le interruzioni continueranno ad accadere e ti verrà chiesto di rispettare le scadenze che non puoi semplicemente rispettare.

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

Nessuna metodologia di sviluppo del software e di gestione del progetto può aiutare in un'organizzazione in cui le persone di vendita dettano il programma giorno per giorno. Come dovresti gestire un progetto in una settimana di lavoro così caotica e distratta?

Così tanti dirigenti superiori vedono il valore di Agile e ne vogliono 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 di software gestito o cascata che fa la mossa perché richiede un cambiamento fondamentale nella cultura.

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

Un cambiamento nella cultura è di solito richiesto da un concorrente che minaccia l'esistenza dell'azienda o una situazione di produzione o rottura o qualche altra situazione coinvolta in modo simile per giustificare un re-org. Nella tua situazione, la tua azienda è completamente al di fuori dello spettro in cui il denaro in questo momento è facile e tutti stanno ingrassando.

Le aziende non cambiano MAI dall'interno quando i soldi sono facili. Perché dovrebbero, hanno successo nonostante i problemi di sviluppo del software, non a causa del successo dello sviluppo del software.

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

guarda extremeprogramming.org - XP è una forma di Agile con aspetti facilmente comprensibili che puoi scegliere e scegliere come 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 considera il panorama delle metodologie, sia tradizionali che contemporanee, ci si rende conto che "Agile" è più di un "anti-metodologia" che una metodologia. I pattern mirano a rappresentare la soluzione "best-case" per un dato problema all'interno di un particolare contesto. I tentativi di violare direttamente una soluzione o uno schema del genere sono generalmente definiti "anti-schemi" o pratiche di casi 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.) Tentano di violare direttamente qualsiasi struttura all'interno del processo di sviluppo del software, in favore di un casuale, caotico approccio - che (di recente), sembra anche richiedere l'applauso degli spettatori (ingenui).

Detto questo, è opportuno tenere a mente il contesto in cui la filosofia Agile è sorta. 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 completa dei requisiti, quindi completa la progettazione, quindi sviluppa / codifica la soluzione, quindi implementa la soluzione. Chiaramente, questo approccio ingegneristico allo sviluppo del software è stato sconsiderato e ha portato a un mucchio di scartoffie prima (e talvolta senza mai) vedere una soluzione eseguibile.

Tuttavia, non garantisce ancora il lancio del bambino con l'acqua del bagno, come nel caso degli stregoni di Agile. L'approccio Agile quasi impone una negazione diretta di tutto ciò che è stato usato prima - tranne forse la codifica effettiva della soluzione. Chiaramente, questa è un'indicazione di intuizione limitata da parte dei suoi ideatori, o forse è semplicemente il caso di "non ci sono nessuno come ciechi, come quelli che non vogliono vedere".

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

ORA, per rispondere alla tua domanda più direttamente:

Data la tua panoramica del tuo ambiente, ti suggerisco di selezionare innanzitutto un'implementazione Agile (ad es. Scrum, XP, ecc.). Personalizza quindi l'approccio alla suite del tuo ambiente, delineando un chiaro processo di funzionamento della tua squadra, ad esempio:

• Ricevi richiesta dagli utenti;

• Assegna la priorità alle richieste degli utenti;

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

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

• Esegui miglioramenti effettivi sul sistema esistente (ovvero codifica).

• Esegui il test degli utenti e ottieni l'impegno degli utenti (ad esempio via email) che le modifiche richieste siano state implementate con successo.

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

Con quanto detto sopra, ricorda che il vecchio discorsetto inglese, "As Agile as a monkey", non è stato coniato senza ragione!

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

Se hai intenzione di respingere il personale addetto alle vendite e richiedere scadenze realistiche, devi giustificarlo con i piani organizzati.

Inoltre, in una nota seprata, se vengono da te con delle stime senza consultare i tecnici, basta semplicemente rifiutarli.

Forse concentrarsi sugli aspetti incrementali / iterativi è ciò che sia il vostro team, sia i soggetti interessati a fall-of-the-sky devono essere in grado di fornire regolarmente e coerentemente. Nel corso del tempo, il team di vendita e il management acquisteranno fiducia nel fatto che quando invieranno una nuova richiesta di funzionalità, potranno essere certi che il team fornirà in un lasso di tempo adeguato.

Ovviamente, devi investire in unità / sistema / test di regressione, build automatici, dogfooding, ecc. per arrivarci se non ci sei già.

Per prima cosa suggerirei di raccogliere alcuni dati. Siediti in un momento di calma e cerca di capire qual è lo status quo in realtà: come vanno le cose. Se la gestione è decisa a implementare qualcosa che può chiamare agile, quindi capire qualcosa che potrebbe funzionare per la tua squadra, redigere un documento, schiaffeggiare "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 rapidità per la sua usuale definizione in inglese. Quindi quello che sto sostenendo è che il tuo team esce di fronte al problema, trova un sapore che funzioni per te e poi lo presenta alla tua gestione come Agile (tm). Altrimenti alcuni PHB raccoglieranno un libro e cercheranno di inserire il piolo quadrato nel buco rotondo e nessuno sarà felice.

Se segui una forma "pura" di agilità, potrebbe essere difficile per il tuo team dover svolgere anche 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 "fammi creare un articolo arretrato, arriverò a quello in (tempo per finire di sprint) settimane".

Il più grande ostacolo è il denaro. Se tutto è salsa verde, è molto più difficile dire che qualcosa è sbagliato e deve cambiare.

Buona fortuna.

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

La tua gestione ha indicato di essere interessata a questa nuova parola Buzz. Molto probabilmente vorranno usarlo per dare il massimo risalto al marketing dei tuoi prodotti. questo non è necessariamente un aspetto negativo, ma sarà necessario gestirlo con molta attenzione se vuoi che un metodo Agile funzioni per .

Metà della battaglia sta ricevendo un buy-in dalla direzione. Averli 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 volere che tu sia agile, e per evitare che diventino disincantati quando e se i tuoi manager si sentono come se il loro controllo sulla gestione dei progetti stia in gran parte scivolando tra le dita. p>

Prima che la tua azienda decida qualcosa, ti consiglio di salire su un pullman Agile per fare un seminario e un seminario di mezza giornata. Fate in modo che tutti pensiate come una squadra, manager e sviluppatori, riguardo a ciò che riguarda Agile, che pensate possa funzionare per voi, e ciò che ritenete non lo sarebbe. Se, d'altro canto, la direzione si fida del tuo giudizio, dovrai familiarizzare con un certo numero di pratiche e metodi Agile e creare un seminario o il tuo. Personalmente, mi piacerebbe guidare 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 di Agile come riferimenti, leggili a fondo, ma lasciali anche sulla scrivania dove la direzione può vederli. La psicologia subliminale può fare miracoli in una situazione come quella che hai descritto.

Raccomando 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 menzionato):

• Pulisci codice - Robert C. Martin