Agile in un ambiente multidisciplinare

1

Lavoro per una società di consulenza ingegneristica che combina design industriale, meccanica, elettronica e software. Per la loro natura - o forse semplicemente per la storia - la filosofia di sviluppo generale è stata cascata. Ma quando sono entrato mi ha sorpreso il fatto che Agile, che ora direi uno standard del settore, fosse a malapena sentito. Per quanto mi riguarda, pur restando scettico nei confronti di Agile, riconosco i suoi vantaggi sia per gli sviluppatori che per i clienti e sono stato propenso a promuoverne l'utilizzo.

Mi sembra chiaro che non puoi costruire hardware in modo Agile. È troppo dispendioso in termini di tempo e costoso "refactoring" una cosa fisica. Ciò significa che ci stiamo muovendo verso l'essere software-Agile e hardware-Waterfall, e il Project Manager sta facendo fatica a far lavorare le due cose insieme. Peggio ancora, diventa difficile quando siamo di fronte a fornire ai clienti un costo definitivo per un progetto. Agile non fa piani super e le proiezioni di velocità richiedono che un progetto sia attivo, in esecuzione e che alcuni sprint siano passati per essere significativi. Ciò significa che tendiamo a sopravvalutare come contingenza, facendo salire i nostri prezzi e la nostra competitività diminuisce.

Mi sembra allora che

Vendiamo Agile esplicitamente al cliente e otteniamo il loro buy-in per ricevere nuove iterazioni di software per sprint, potendo aggiungere al backlog e dare la priorità alla prossima tranche di lavoro. Li convinciamo che questo è un modo di lavorare senza fronzoli e che la cascata non è realistica e si traduce in overspend. Il Product Owner è del cliente in questo modello. In che modo quindi ci avviciniamo ai contratti, affermando quanto fatturiamo per il software? Come evitare l'impressione che si tratti di un flusso di entrate illimitato in cui è nel nostro interesse impiegare tutto il tempo che ci piace?

Adottiamo Agile solo internamente. Il Product Owner è uno dei nostri ragazzi / ragazze. Il client ottiene solo una versione alpha / beta / release del software come in cascata. Se siamo nel corso del tempo, possiamo allora fondere lo slittamento nelle fasi finali? È persino agile?

In breve, avere un contratto tra noi e un cliente sembra un modo molto poco agile di fare le cose. Eppure la cascata è destinata a fallire in un ambiente in cui vediamo ogni giorno che non solo non comprendiamo il dominio del problema il giorno 1 di un progetto, né il client. E come facciamo Agile per software e cascata per hardware - c'è un software in grado di gestire entrambi sotto un unico ombrello? Come sposiamo questi mondi?

    
posta Julian Gold 05.08.2013 - 15:19
fonte

3 risposte

2

Il modello di Agile che utilizzi deve sempre essere adattato all'ambiente, in modo che il processo fornisca un valore tangibile al cliente. Un vantaggio chiave di Agile è che il valore viene consegnato in anticipo e clienti come quello. Dopo averlo visto in azione, iniziano ad accettare l'approccio.

Nel tuo caso, i ragazzi dell'hardware consegneranno solo il kit di lavoro il giorno X. Cosa succede prima del giorno X? Se stavi lavorando a un approccio a cascata, quando inizi la progettazione e la costruzione del codice? Come testate il codice prima che l'h / w sia costruito? Usi un emulatore?

Vai lentamente, usando Agile internamente. Non tutti i clienti vorranno essere parte di un "esperimento" Agile (come lo vedrebbero). Costruisci un track record di sprint e velocità. Con velocità nota, i nuovi progetti possono essere stimati in modo più accurato rispetto al passato. Quindi l'azienda può vendere l'approccio Agile ai clienti interessati. Agile richiede un impegno extra da parte del client e non tutti i client vorranno esserci, finché non vedranno quale sarà la differenza di costo.

    
risposta data 05.08.2013 - 15:45
fonte
2

"Se hai solo un martello, ogni problema sembra un chiodo".

Agile è un'ottima metodologia che ha ottenuto (a ragione) un'ampia accettazione all'interno della comunità degli sviluppatori.

Tuttavia, non è l'unico gioco in città e non è sempre la risposta giusta. (Mi viene in mente il codice per le sonde spaziali e l'avionica).

Agile è uno standard di settore nel tuo settore ? (Non lo sviluppo in generale, ma lo specifico business in cui ti trovi). Sembra che potrebbe non essere il caso. I tuoi clienti non lo chiedono e i ragazzi dell'hardware non lo vogliono o ne hanno bisogno. (Agile richiede uno sforzo aggiuntivo da parte del cliente che potrebbe essere o non essere disponibile).

Se lo adotterai, assicurati di farlo per i giusti motivi e amp; non solo perché tutti i bambini su SO o P.SE lo stanno facendo.

Se decidi di andare avanti comunque, prendilo lento, inizia a usarlo solo internamente e crea un track record. Adottare una metodologia è un cambiamento della cultura aziendale e non avviene mai in fretta.

Sii paziente.

    
risposta data 05.08.2013 - 15:57
fonte
2

Penso che sia necessario indagare sul "tipo" di Agile che è necessario adottare. Scrum è una forma di agile che si adatta bene allo sviluppo del software quando ci sono nuove funzionalità da sviluppare. Il Kanban è un'altra forma di Agile che a volte si applica meglio ai gruppi che non possono impegnarsi in un intervallo fisso per risolvere problemi come il mantenimento del codice sviluppato con la maggior parte dei bugfix. Sono solo due tipi di "agili" e ci sono altri che puoi investigare. Da ciò che altri hanno risposto prima, agile è progettato per aiutarti ad adattare un processo flessibile alle esigenze della tua azienda.

La nostra compagnia ha messo in gioco sia i team software che quelli hardware. Non posso commentare come sta andando il team dell'hardware, ma aiuta i ragazzi del software su scrum ad allineare i loro programmi.

    
risposta data 05.08.2013 - 17:25
fonte

Leggi altre domande sui tag