211service.com
Portare la programmazione all'estremo
Mansour Raad ha avuto un grosso problema. La sua azienda start-up, DiscoverCast, stava sviluppando un software di rilevamento delle collisioni per il settore delle compagnie aeree: errori nel codice potrebbero costare vite. Ma i soldi si sono prosciugati dopo un primo round di finanziamenti e assumere altri programmatori per completare una versione a prova di bug era fuori discussione.
Quindi Raad ha istigato una disciplina di codifica relativamente nuova chiamata programmazione estrema. Invece di lavorare da soli su incarichi individuali, i programmatori si sono associati, uno scrivendo codice mentre l'altro osservava e criticava, fornendo sia un occhio critico che un backup di fondamentale importanza. [Mia moglie] ha avuto un bambino, ma il progetto doveva andare avanti, dice Raad. Poiché lo stavo mostrando alle altre persone, qualcuno potrebbe mettersi nei miei panni. L'azienda ha rispettato le scadenze senza un aumento degli errori a causa della comunicazione.
La maggior parte dei programmatori non è più soddisfatta della qualità del software rispetto ai propri clienti. Ora un numero crescente sta cercando di trovare modi per creare software solido in un mercato che si aspetta nuovi prodotti e miglioramenti e li vuole velocemente. Sempre più spesso, le aziende di software si rivolgono a strategie di sviluppo con nomi come sviluppo agile e slogan carichi di adrenalina di programmazione estrema che ben si adattano all'immagine di sé dei programmatori come robusti eroi dell'era dell'informazione. In realtà, il trend, che ha una lunga storia, segnala un rifiuto della programmazione da primadonna a favore del lavoro di squadra e della collaborazione.
Nell'industria del software, il codice difettoso è stato a lungo accettato come un dato di fatto, anche se aggravante e costoso ( vedere Perché il software è così dannoso , BAMBINI luglio / agosto 2002 ). Il problema è che nel software le persone ripongono troppa fiducia nella propria ingegnosità, afferma Michael Stiefel, un consulente che forma i clienti sui metodi di affidabilità del software. Guarderei tutti questi giovani ventenni fare gli stessi errori che abbiamo fatto negli anni '70 e '80, e mi chiedo perché dobbiamo rivivere tutto questo.
Per ridurre gli errori, i riformatori stanno promuovendo approcci all'ingegneria del software, noti nel settore come sviluppo agile, che sottolineano il lavoro di squadra, la collaborazione con gli utenti finali e un approccio flessibile al cambiamento. Per costruire il suo software di prevenzione delle collisioni, l'azienda di Raad ha utilizzato un tipo di sviluppo agile, chiamato programmazione estrema, che enfatizza il test costante e la collaborazione.
Se sei in grado di applicare [un ambiente collaborativo] al massimo della sua potenza, la qualità dei prodotti sarà migliore, afferma Michele Marchesi, uno dei principali sostenitori della programmazione estrema e professore di ingegneria elettrica presso l'Università di Cagliari in Italia.
Uno degli aspetti più potenti della programmazione agile è la cosiddetta programmazione peer, in cui gli sviluppatori collaborano e si alternano nella scrittura del codice e nella spiegazione della sua logica all'altro. Le coppie sono temporanee, si dividono e si scambiano periodicamente per incoraggiare ancora più interazione. Nuovi occhi esaminano ogni pezzo di codice, creando un processo di revisione continua.
Due persone possono scambiarsi idee l'una con l'altra, afferma Frank Arkell, ingegnere capo del software presso l'appaltatore della difesa General Dynamics Decision Systems, che utilizza tecniche collaborative da due decenni. Per mantenere i team aggiornati, General Dynamics li cambia per ogni progetto.
Un altro vantaggio della programmazione peer? Pressione dei pari. Nessuno vuole essere la persona che si rilassa, quindi entrambi lavorano di più, afferma Scott W. Ambler, presidente di Ronin International e autore e relatore sullo sviluppo agile.
Mettiti alla prova
Gli approcci collaborativi stanno anche trasformando il modo in cui il software viene testato. Tradizionalmente, il test è stato un processo in due fasi. Innanzitutto, i programmatori scrivono il codice in base ai requisiti. Quindi un gruppo separato verifica il risultato. Ma quando il software include milioni di righe di codice, il processo in due fasi è analogo a progettare un'automobile su carta, costruirla e poi controllare se il progetto ha funzionato.
Questo approccio non ha funzionato per sviluppatori come Nicholas Stamos, direttore tecnico di Phase Forward di Waltham, MA. Phase Forward sviluppa software per l'esecuzione di studi clinici farmaceutici e i suoi prodotti devono soddisfare i severi requisiti della Food and Drug Administration degli Stati Uniti.
Stamos afferma che Phase Forward soddisfa tali requisiti, in parte grazie alla stretta e costante collaborazione tra i programmatori dell'azienda e il personale addetto all'assicurazione della qualità. Non puoi buttarlo oltre lo specchio di poppa e sperare, dice. La qualità deve essere costruita fin dal primo giorno. Quando i programmatori completano un componente, il team di qualità controlla il loro lavoro. Quindi le squadre si scambiano di posto per un altro giro di correzioni di bug. Infine, l'applicazione integrata viene testata per trovare problemi con l'interazione tra i componenti. Invece del vecchio approccio in due fasi, il test diventa un processo interattivo e continuo.
Alcune aziende stanno provando un approccio iterativo simile non solo ai test, ma in primo luogo alla progettazione del codice. Cognizant Technology Solutions, una società di consulenza con sede a Teaneck, NJ, ha scoperto che i metodi esistenti per iniziare con specifiche formali e poi scrivere codice per soddisfarle avrebbero potuto funzionare 20 o 30 anni fa. Ma in un mondo che gira sul Web e ha bisogno di flessibilità, formale può significare rigido.
Quando abbiamo provato a utilizzare i processi tradizionali per questi nuovi tipi di progetti, o i clienti si sono sentiti davvero frustrati perché li abbiamo costretti a bloccare il processo oppure i team di progetto non hanno seguito il processo, afferma Kumar Mahadeva, CEO di Cognizant. Invece, i progetti utilizzano una serie di prototipi seguiti da un ciclo di industrializzazione, consentendo all'azienda di gestire i cambiamenti improvvisi dei clienti in un modo che ha un impatto minore sull'affidabilità rispetto all'adeguamento di un programma dopo che è stato completato. Gli utenti futuri forniscono un flusso costante di feedback man mano che l'applicazione prende forma.
Ma i limiti ultimi alla qualità del software potrebbero non risiedere nelle capacità dei programmatori o nella forza del processo di sviluppo. Questo è l'enigma che noi e molti produttori dobbiamo affrontare oggi: qual è un livello accettabile di qualità? afferma James Hymel, direttore dell'ingegneria del software di Motorola. Se hai concorrenti che producono [prodotti] carini, economici, ma difettosi e i clienti dicono che è accettabile, cioè spendono i loro soldi per loro, saresti sfidato.
Con metodi come lo sviluppo agile, la partnership di sviluppo e test e il coinvolgimento degli utenti finali, gli sviluppatori di software stanno adottando misure per migliorare il loro prodotto. Ma alla fine della giornata, il più grande vincolo alla qualità può essere rappresentato dalle stesse persone che la pretendono più forte: i consumatori.