Come implementare un processo di sviluppo software in un progetto esistente?

Prima di tutto fallo passo dopo passo. È difficile insegnare nuovi trucchi al vecchio cane e se si tenta di implementare tutto in una volta - nulla verrà implementato.

Ecco alcune domande che potrebbero aiutarti a capire se sei pronto per la metodologia;)

1. Repository di codice (usi repository di codice? hai una strategia di ramificazione? se ti chiedo chi e quando ha introdotto l'ultimo bug / funzionalità principale e perché - puoi dirmelo?)
2. Hai una road map del progetto? Sei in grado di commettere nel repository direttamente in relazione con il raggiungimento del prossimo obiettivo principale.
3. Hai un bug tracker?
4. Sai (hai annotato) il processo di distribuzione della tua app? Chi decide quando si schiera? Chi unisce le modifiche al ramo di rilascio del repository di codice? etc ..
5. Sono in vigore le linee guida sul codice? (nomi di variabili, nomi di funzioni, nomi di test ecc.)

Forse non sto rispondendo direttamente alla tua domanda, ma sto scrivendo per esperienza. Anch'io mi è stato assegnato un compito per implementare la metodologia in un'azienda. Sfortunatamente è difficile costruire una metodologia se il codice viene inviato tra programmatori in file zip, archiviato in una dozzina di cartelle condivise senza versioni e nessuno sa dove viene memorizzato il codice di qualche anno fa.

Se riesci a rispondere a tutte le domande di cui sopra e ti senti ancora a mio agio sullo stato delle cose, il consiglio per l'implementazione della metodologia è: scegli cosa ti fa sentire a tuo agio.

Se hai una base strong (repository, road map, bugtracker, flusso di lavoro di implementazione, linee guida per il codice), prova le metodologie una per una e vedi quali funzionano meglio per te e il tuo team.

Nella mia esperienza, la metodologia del software è più una politica dell'organizzazione che una decisione di progetto. L'implementazione di qualsiasi metodologia in un'organizzazione richiede un livello di impegno che trascende le barriere del team di progetto (ovvero clienti, dirigenti, responsabili di progetto, parti interessate e altri decisori).

Stabilire un nuovo ordine di cose, nella mia esperienza, funziona raramente se viene dal basso verso l'alto. Funziona meglio quando negozi con tutte le parti coinvolte. A meno che tu non abbia il potere illimitato di decidere cosa dovrebbe essere fatto.

Se esiste già una metodologia, anche se non è buona (il che significa che non sta producendo buoni risultati), introdurre il cambiamento è sempre doloroso e ci sarà resistenza. Qui è dove avrete bisogno di supporto e impegno da parte dei dirigenti e dei responsabili delle decisioni nell'organizzazione.

Se desideri modificare una metodologia proponendone una nuova, dovrai raccogliere prove che dimostrino in che modo la metodologia corrente impedisce all'organizzazione di ottenere risultati migliori e potresti proporre di eseguire un progetto pilota con un progetto o due per raccogliere i risultati che dimostrano che una nuova metodologia potrebbe rivelarsi molto migliore.

Dato che lo status quo evidentemente non funziona, si può prendere in considerazione l'introduzione della nuova metodologia delicatamente, apportando prima le modifiche dove è più importante, quelle modifiche che ti aiuteranno a dimostrare con i risultati che la nuova metodologia, il nuovo ordine di cose, è prezioso.

Ad esempio, se non stai facendo alcun tipo di test, puoi prendere in considerazione l'introduzione di alcune delle pratiche di TDD e quindi raccogliere le statistiche per alcuni mesi, e poi dimostrare ai manager come le statistiche degli errori sono migliorate . Puoi mostrarlo anche al team, quindi si eccitano e sono ancora più compromessi con la metodologia. Quindi è possibile passare a una seconda fase e molto probabilmente ottenere un supporto migliore dal resto dell'organizzazione. Alla fine, l'intera organizzazione può adottare la metodologia.

Penso che sia di fondamentale importanza avere i project manager a bordo con la nuova metodologia, devono crederci e credere che migliorerà le prestazioni. Devono farla rispettare nei membri del team, che inizialmente potrebbero mostrare resistenza. Altrimenti, i cambiamenti perderanno slancio e alla fine cadranno in disuso e la gente tornerà allo status quo.

In definitiva, qualunque metodo tu scelga deve mostrare per migliorare le prestazioni della tua organizzazione, idealmente con i numeri che puoi mostrare al tuo manager e ai tuoi clienti. In quanto tale, IMHO, introdurrei il cambiamento a poco a poco, migliorando dove vedo i problemi, non mi preoccupo tanto di una metodologia in sé, ma di come migliorare le cose.

Hai preso in considerazione altre metodologie meno popolari come Processo di software personale o Processo software di Team ?

La metodologia / processo di sviluppo del software è in genere una parte importante della cultura aziendale e raramente cambia per progetto. È inoltre strongmente correlato alle metodologie di sviluppo che il team di sviluppo è a suo agio / in grado di praticare.

Una delle metodologie ampiamente conosciute e utilizzate è il design basato sul modello per gli sviluppi dei sistemi incorporati. La caratteristica significativa di questo modello basato sulla progettazione è che facilita lo sviluppo più rapido e più economico dei sistemi dinamici incorporati. Informazioni più dettagliate sono fornite qui: Embedded 360 .

Un'altra tendenza molto importante per lo sviluppo di sistemi integrati consiste nell'utilizzare Metodologia Agile . È ampiamente utilizzato dalle società di software per sviluppare prodotti incorporati in base ai requisiti inviati dal cliente in diversi momenti. Qui, diverse iterazioni dei prodotti incorporati sono sviluppate sulla base di diversi gruppi di requisiti del cliente.

Penso che alla fine, vorrai creare o acquisire un simulatore che ti permetta di testare il tuo codice in cicli più brevi di quello che dici di essere attualmente in grado di fare. Nel frattempo, guarda le altre best practice e inizia a incorporarle in un modo serio e standardizzato,

Per prima cosa, puoi certamente istituire regolarmente recensioni del codice . Le revisioni del codice, fatte bene, prevengono più bug di qualsiasi altra cosa tu possa fare. il link è un ottimo riferimento per farlo.

In secondo luogo, lavora a stretto contatto con il tuo gruppo QA - assicurati che gli sviluppatori conoscano i test su cui stanno codificando.

In terzo luogo, considera semplicemente i principi del Manifesto Agile a cuore - fai ciò che puoi fare per concentrarti sul software di lavoro e sulla comunicazione semplice durante tutto il progetto. Fai in modo che le persone parlino in modo costruttivo di ciò che è sbagliato e di ciò che può essere fatto meglio ORA. Allora fallo.

Raccomando anche il collegamento di Alistair Cockburn per suggerimenti su come costruire una metodologia appropriata per il proprio ambiente.

come per i sistemi embedded rispetto a TDD :

Quando ero all'università, dovevamo scrivere test di unità di sistema incorporati utilizzando un analizzatore logico. Tuttavia, quelli che usavamo costava circa 15.000 dollari l'uno, e ci fu detto con fermezza, per non romperli. Dall'altro lato, è stato semplice e facile: collegare il chip alla lavagna, avviare app, tadadada, green, bamm.

Ma immagino che tu abbia quello.

Come metodologie:

Le metodologie riguardano le persone. Devo ancora riuscire a forzare una metodologia su qualsiasi cultura aziendale, specialmente nelle grandi aziende.

Quando ero in una cultura RUP primaria, facevo XP con la mia squadra, per essere più veloce degli altri. Ha avuto successo.

Quando ero in un XP primario (o, fresco Agile, SCRUM non era ancora mainstream), facevamo RUP, con modellazione e tutto, per avere una migliore comprensione di ciò che sta accadendo sul progetto e agisce con molta più sicurezza. Ha funzionato.

Quando ero in un ambiente SCRUM, ho fatto RUP (per avere una migliore comprensione), oppure, realizzando che i backlock di Scrum sono sempre guasti, che non abbiamo iterazioni reali, ecc. (eravamo i "bug & team di piccole caratteristiche ") Sono passato a Lean / Kanban per avere stabilità in quello che facciamo. Funzionava principalmente, anche se non come prima (e questa era un'impresa, mentre i precedenti avevano un core team di avvio)

Quando ero nell'ambiente the SCRUM (sai, il test N), passavo a RUP come se fosse acqua nel deserto, io ero fuori per settimane lì: ero rimasto solo con ma non ho avuto problemi ed è stato incredibilmente veloce solo perché non ho accettato tutte le scuse che SCRUM aveva.

Ma tutto sommato: nel nostro nuovo mondo agile, il programmatore è il re . Se i programmatori si sentono bene nel caos, puoi cambiare azienda o cambiare programmatore.

Suggerirei invece di parlare di implementazione per trattare i tuoi programmatori come i tuoi utenti : devi risolvere i loro problemi per aiutali a lavorare . Non mi piace sempre questo approccio (o meglio, non mi piace l'approccio di alcuni programmatori e trovo difficile supportarli in ciò che vogliono) ma il leader di oggi è qualcuno che dovrebbe aiutare gli altri, non qualcuno che dovrebbe essere obbedito .