La regola del “Sei”

Una delle più importanti pietre miliari che hanno contribuito a far diventare Kaspersky Lab uno dei principali rappresentanti dell’industria della sicurezza informatica è stata la release della “allora” rivoluzionaria versione di Kaspersky Anti-Virus 6.0. Ufficialmente lanciato nel 2006, il prodotto ha riscosso un grande successo nel mercato internazionale degli antivirus, ponendo le basi della sua leadership per gli anni a venire. Può apparire poco modesto da parte nostra considerare i nostri prodotti le migliori soluzioni antivirus sul mercato, ma non siamo noi a dirlo, bensì numerose riviste e diversi studi di mercato indipendenti.

Il cammino che ci ha portato al successo è stato lungo, pieno di curve e difficoltà – magari un giorno qualche sceneggiatore di Hollywood prenderà in considerazione la nostra storia per farci qualcosa. Per il momento, cercheremo di raccontarvi le tappe del nostro successo con l’aiuto delle foto, degli appunti e dei ricordi del nostro originale team di sviluppatori (a cui spesso ci riferiremo come dev team o dev team di “Sei”). Speriamo che questa storia servirà da esempio per i giovani sviluppatori di oggi, desiderosi di creare nuove app e servizi, dando loro la stessa forza e  voglia di diventare i migliori che avevano i creatori di “Sei”.

2003: un anno difficile

Il successo di “Sei” è dovuto in parte alla catastrofe della versione precedente. Infatti, la quinta versione non ha mai visto la luce del giorno.

Per capire l’essenza della catastrofe, dobbiamo viaggiare indietro nel tempo, nel 2002: Windows XP aveva appena battuto ogni record, i CPU erano in grado di  raggiungere 1 GHz di segnali di clock e la relativamente giovane industria antivirus aveva appena iniziato a scoprire tutta una serie di nuove minacce. Tutte le aziende antivirus stavano ansiosamente ampliando le capacità dei loro prodotti: al tempo, una soluzione competitiva doveva includere un firewall, un sistema di monitorizzazione costante dei file in esecuzione e una dozzina di altre funzionalità.

Con un potente sistema di scansione costruito nel 1990, il developer team di Kaspersky Lab si reso conto che includere nella soluzione antivirus altre funzionalità lo avrebbe inevitabilmente rallentato – persino l’allora esistente versione 4.0 era stata condannata dall’utente (l’accusa “l’AV Kaspersky Lab è lento” faceva parte del “folklore informatico” dell’epoca). Per questa ragione abbiamo dedicato molta attenzione al processo di sviluppo della nuova V 5.0: venne assunto un nuovo Chied Technology Officer, impiegata una nuova framework di sviluppo e scelta una nuova architettura antivirus.

L’azienda impiegò tutte le sue risorse per supportare il progetto. E dopo un anno si era giunti alla conclusione che tutte queste nuove regole di sviluppo non sarebbero state sufficienti per garantire la creazione di un prodotto competitivo. Il risultato fu un sistema che imitava le app aziendali client-server (era la scelta dell’architettura fatta dal CTO) e che non era in grado di rispondere ai parametri dal mercato AV dell’epoca. Era lento e pesante, una volta eseguiti i test, il numero dei bug non diminuiva – anzi, aumentava.

“Ho iniziato a chiedere alle persone, ai veterani della nostra azienda, cosa pensassero. Dissero che è colpa dell’architettura. È come un castello di carte: toccandone una, si potrebbe finire col farle cadere tutte”, afferma Eugene Kaspersky. Ecco perché non aveva senso continuare il progetto così com’era. Doveva essere demolito e ripensato daccapo.

Ce la faremo!

Il team degli sviluppatori di Kaspersky Lab si separò i due gruppi: uno si occupava della riparazione del prodotto, indipendentemente dall’architettura scelta, forse imprudentemente, e un altro della trasformazione della versione precedente, la V 4.0, in una più idonea.

Allo stesso tempo, un gruppo di 4 persone decise di creare un prodotto nuovo, completamente diverso, che rispondesse non solo ai parametri del mercato, ma che possa durare nel tempo. L’obiettivo fissato dal dev team di “Sei” era facile da spiegare, ma difficile da raggiungere. La nuova versione doveva essere a prova di virus, minacce e furti di dati di sistema; doveva essere veloce, agile, trasparente e… beh, gradevole alla vista.

“Volevamo creare il miglior prodotto esistente” ricordano ora gli sviluppatori della versione “Sei”. Si trattava di un team ridotto, ma con un compito enorme: questa era anche la percezione degli altri 200 membri dello staff. Proprio per questo il team doveva essere positivo: i fondatori dell’azienda, Eugene Kaspersky e Alexey De-Monderik, stavano al tempo cercando alternative per nuove architetture e stavano per scoprire che un’alternativa c’era – e sarebbe stata scoperta da niente po po’ di meno che lo stesso team di Kaspersky Lab.

Aiuto da Praga

Bisogna dire che i due nuclei core dell’antivirus (quelli che vengono chiamati in inglese engine) operavano insieme alla versione 4.0. La verifica dei file veniva eseguita dal vecchio, ma efficiente, V 3.0 (apprezzato da diverse compagnie internazionali, da G-Data a F-Secure), sviluppato nel lontano 1996. Il nuovo e difficile compito, quello di filtrare il traffico web, fu gestito e concepito nel corso del brainstorming di Praga, nel 1998.

Il sistema (engine) sviluppato venne chiamato “Praga”, nonostante fosse stato sviluppato a Mosca da Andrey Doukhvalov, che non partecipò al brainstorming tenutosi nella capitale della Repubblica Ceca. Le idee principali, comunque, furono concepite a Praga, e Andrey si unì all’azienda per mettere a punto e implementare le idee emerse a Praga.

Praga doveva diventare il nucleo dell’anti-virus; gli obiettivi erano così ambiziosi che la flessibilità e l’ingegno del nuovo sistema che venne sviluppato furono sufficienti per dare potenza anche ai sistemi più complicati. La questione (se fosse possibile implementare l’intero prodotto basandolo su Praga oppure no)  pesava fortemente su Eugene Kaspersky, così come emerse dal suo discorso agli sviluppatori.

“Una volta ho chiesto a Victor Matyushenko come stesse funzionando Praga all’interno del prodotto e lui rispose ‘Solido come una roccia!’. Si trattava di un momento critico, il momento della fatidica Domanda (con la D maiuscola). Raggiunsi la stanza dove Graf [De-Monderik] e Petrovich [Doukhvalov] stavano lavorando e feci loro la Domanda: ‘Perché non basiamo interamente il prodotto su Praga?’ Graf farfugliò qualcosa che assomigliava a ‘Impossibile. Praga non è stato pensato per questo”, ma Petrovich esitò. Il giorno dopo arrivò in ufficio con una pila di fogli e mi disse ‘Ho pensato a qualche caso d’uso di Praga’. Graf lo guardò e disse ‘Dobbiamo parlare’. Poi, dopo la chiacchierata, ci riunimmo di nuovo tutti insieme e mi confermarono che ne valeva la pena.”

Inizialmente fu un piccolo team a lavorare sul trial, scrivendo le prime righe di codice: questi programmatori sarebbero diventati in seguito i programmatori di “Sei”.

“Iniziammo a guardarci attorno per trovare persone creative che potessero dare il loro contributo, e finimmo col formare un grande team”, ricorda De-Monderik. “Prendi il programmatore Pavel Mezhuev, era un novellino – anche se brillante. Poi c’era Mike Pavlyuschik con cui abbiamo lavorato per molto tempo. Era capace di generare idee e concetti pronti all’uso in pochi secondi. Credo fosse uno dei creatori con più talento”.

Dopo due mesi di aperte discussioni e sperimentazioni di codici, decidemmo che il progetto doveva prendere la forma di una soluzione commerciale. Ora avevamo bisogno di un project manager.

“Vi ricordate di Nikolay Grebennikov, quello dell’ufficio accanto? Legge molto, è giovane e nuovo nell’azienda. Andiamo a parlare con lui!” racconta Andrey Doukhvalov, ricordandosi di una conversazione tenuta con De-Monderik. Andrey Sobko, driver software engineer, si sarebbe presto “unito alla festa”.

Cos’ è “Praga”

Questa parte susciterà soprattutto l’interesse dei software engineer. Il resto dei lettori, se vuole, la può saltare.

All’inizio degli anni novanta, quando l’industria antivirus stava emergendo, c’erano virus che non era possibile individuare attraverso le normali signature. Per esempio, un virus polimorfo che per ogni infezione crittografava il suo codice in diverse forme, non era identificabile con l’approccio delle signature (signature approach). Nella misura in cui i software si facevano più complessi, in un mondo in cui Internet stava entrando sempre di più nelle vite di tutte le persone e gli scrittori di malware, dal puro divertimento stavano iniziando a prestare i propri servigi al mercato criminale, anche i malware iniziavano a diventare sempre più sofisticati e multiforme. Persino con un sistema che incorpori capacità aggiuntive all’algoritmo di individuazione basato su signature (signature-based detect algorithm), come il caso dei prodotti Kaspersky Lab, gli sviluppatori si videro obbligati ad aggiornare costantemente ogni antivirus, non solo i database delle signature, alla ricerca di malware che utilizzassero nuove regole. Tutto questo rallentava il tempo di reazione dei nuovi virus e il successo di Kaspersky Lab arrivò dopo essere stata la prima azienda a curare il terribile virus CIH  (Chernobyl) dimostrando che ridurre il tempo di reazione contava davvero.

Con questo in mente, nel 1998, Eugene Kaspersky suggerì ai colleghi che era giunto il momento di iniziare a lavorare su di un nuovo sistema anti-virus. Dove voleva arrivare?

“L’azienda era a corto di denaro,” affermò l’attuale CEO “dovevamo lasciare la città e trovare un posto economico fuori  Mosca dove poter lavorare con tranquillità, lontano dal rumore e dal trambusto. Il posto doveva essere interamente disconnesso; non c’era nemmeno la Wi-Fi  all’epoca. Il posto più economico risultò essere una capitale europea, Praga.”

Dopo un brainstorming sulla nuova versione del sistema dell’antivirus, il team di Kaspersky Lab raggiunse la conclusione che un object-oriented approach (approccio “orientato all’oggetto”) era la migliore soluzione per il sistema. Con questo si intendeva che ogni file o oggetto analizzato doveva essere dissezionato in base alla sua struttura, e gli oggetti al suo interno dovevano essere individuati, analizzati e controllati. La gestione degli oggetti (object management), nella sua interezza, doveva essere eseguita in run-time.

Tutti gli ambienti di oggetti esistenti venivano discussi e rifiutati perché inflessibili, lenti o divoravano la memoria. Nel corso della discussione, emerse quindi un’idea: sviluppare un proprio ambiente che potesse includere capacità di gestione della memoria e altre procedure di servizio, che potesse dare all’antivirus la capacità di esaminare e analizzare un potenziale codice malware in un modo veloce ed efficace.

L’idea complessiva era nata a Praga da De-Monderik e Andrey Krykov ed era supportata dalle prime righe di codice create da Doukhvalov e Kryukov.

In seguito, per circa un anno, fu soprattutto Doukhvalov a continuare a lavorare su Praga – questa è la ragione per cui era stato assunto, dopo tutto. Avendo un architetto esperto, Doukhvalov assicurò che Praga sarebbe stato flessibile, scalabile e facile da utilizzare in un prodotto, senza nessuna limitazione a livello di architettura. Alla fine, l’obiettivo era costruire una soluzione multipiattaforma.

Era impegnativo eseguire il debug sulla gerarchia degli oggetti, ma un sistema a scambio di messaggi tra oggetti adeguato e un’interfaccia di programmazione minimalista rese Praga un’architettura integrata da usare on-demand, dove applicabile.

“Era pensata per un component approach (approccio di tipo componente)”, afferma Doukhvalov orgoglioso. “Questo significa che un componente potrebbe essere aggiunto a un programma esistente. Il sistema era aperto, con l’opportunità di aggiungere elementi e cambiare le regole di comportamento”.

Un’architettura che si basa sul componente, compatta e che non consuma troppe risorse, era la base per applicare a KAV 6.0 una serie di nuove tecnologie. Erano facilmente implementabili. Inoltre, dopo che Praga venne leggermente modificato per fungere da base per l’intero progetto – quindi non solo come engine per l’antivirus – Pavel Mezhuev contribuì a rifinire la sua architettura:

“Implementammo una soluzione di architettura, utilizzando un modello di business logic separato e un’interfaccia. Inoltre, Doukhvalov and Mezhuev crearono un task manager in grado di controllare ogni singolo processo all’interno del prodotto e il processo di reciprocità era molto semplice” constata Nikolay Grebennikov, project manager di KAV 6.0.

Il principio di “Sei”

Considerando il trial e la fase di sviluppo iniziale, entrambi gestiti da un gruppo di persone ridotto, divenne immediatamente chiaro che i mostruosi approcci di sviluppo del nuovo progetto non avrebbero funzionato con il team. Di conseguenza, venne implementato un approccio simile a SCRUM: gli sviluppatori si sarebbero seduti in un open space, interagendo simultaneamente tra di loro, così da poter rispondere prontamente a tutti gli aspetti del processo di sviluppo. Questo fu il modo in cu il dev team di “Sei” iniziò a ingranare.

Una piccola parentesi: SCRUM

SCRUM è un metodo di project management per la creazione di ambienti con metodologia agile (per “metodologia agile” si intende un particolare metodo per lo sviluppo del software). SCRUM si basa sul principio che il cliente (l’utente) non sappia necessariamente di cosa ha bisogno. Ciò significa che il processo di sviluppo è caratterizzato dalla presenza di numerosi cicli sequenziali: costruzione – dimostrazione – analisi del feedback – aggiornamento della versione.

Tuttavia, noi ristrutturammo completamente la distribuzione dei ruoli del metodo SCRUM. Eugene Kaspersky definì 6 ruoli:

Architetto

Si tratta di una persona, attivamente coinvolta nel processo di creazione dei codici, che sa quello che deve costruire e come.

Technical designer

Non c’è nessuna definizione illuminante per questo ruolo; tra i compiti del technical designer vi è assicurarsi che le soluzioni prendano vita e, forse l’aspetto più importante, sapere come NON si devono fare le cose.

Inventore

L’inventore applica soluzioni non convenzionali alla risoluzione dei problemi. Nel caso di “Sei”, i problemi erano moltissimi. La soluzione doveva offrire il più alto livello di protezione e consumare il minimo della risorse del computer.

Project Manager 

Il ruolo del project manager, in relazione al metodo SCRUM, non ha bisogno di grandi spiegazioni. Controlla le risorse umane e le scadenze, ma non è un leader diretto. Non comanda i programmatori su quello che si deve fare, ma li motiva a condurre loro stessi il lavoro.

“Il team era piccolo; all’inizio non avevamo nemmeno un responsabile” afferma Doukhvalov. “Il manager pianificava, organizzava e si occupava del reporting, ma le decisioni si prendevano in modo collettivo.”

Marketing manager

Il prodotto viene creato per i clienti, non per il team di sviluppatori. È fondamentale farsi un’idea delle aspettative degli utenti, del loro giudizio sul prodotto e del modo in cui lo useranno. Mentre i principi operativi vengono definiti da coloro che comprendono la natura dell’anti-virus, per quanto riguarda alcuni aspetti minori, come le impostazioni, i messaggi o l’UI (l’interfaccia utente) è bene prendere in considerazione le opinioni degli utenti.

Psicologo

Lavorare sotto pressione, dormire poco, conflitti di gruppo, instabilità: qualcuno deve assicurarsi che l’ambiente di lavoro sia amichevole e produttivo. Questo ruolo venne assegnato allo stesso Eugene Kaspersky a cui spettava il compito di aiutare i suoi collaboratori, a gestire le risorse del team e a proteggerlo dalle influenze esterne.

Ma c’è un altro ruolo che è di vitale importanza per i progetti SCRUM: è lo “scriba”, colui che prende appunti sul processo. Tuttavia questa posizione non era occupata da nessuno, e ciò costituì un problema.

“Davvero, non sappiamo perché abbiamo preso questa decisione solo un anno fa” afferma Kaspersky.

In base a questo principio, il numero dei ruoli non corrispondevano al numero dei membri del team. Un ruolo poteva essere diviso tra diverse persone, mentre un singolo membro poteva realizzare diversi ruoli.

“Anche se eravamo organizzati formalmente ognuno con i propri ruoli, in realtà eravamo un unico team; per questo talvolta non si poteva tracciare un contorno netto tra i ruoli: in particolare, durante il brainstorming, le persone assumevano ruoli diversi”, confessa Nikolay Grebennikov. “Ad esempio, una persona stava programmando, ma al tempo stesso esprimeva il suo punto di vista rispetto al design –  e  il suo parere veniva preso in grande considerazione. Io, per esempio, come project manager, partecipavo anche alla discussione;  fu questo approccio a contribuire al nostro successo. Ci preoccupammo per ogni singolo elemento dei nostri progetti.”

Secondo De-Monderik, i programmatori erano altamente intercambiabili: “Il 50% delle abilità di ogni membro del team si sovrapponeva a quelle di qualcun’altro. Mike era in grado di programmare driver se Sobko non era presente, gli specialisti dell’interfaccia utente potevano gestire compiti relazionati con l’engine e vice versa. Io potevo occuparmi del design al posto di Max Yudanov, e anche Kolya Grebennikov poteva farlo”.

Nel modello SCRUM, ogni ruolo è fondamentale in relazione a ogni specifica fase del progetto. Durante la fase iniziale, l’architettura è la figura centrale. L’inventore entra in azione durante la fase centrale del processo di sviluppo, quando vengono create e sviluppate le funzionalità. Durante l’ultima fase, la figura chiave è il manager, dato che il progetto ora ha un sacco di risorse che richiedono un’ottima gestione per aiutare il team a raggiungere la deadline.

Alla ricerca della perfezione

Dato l’approccio “SCRUM-iesco” e la complessiva “ambiziosità” del progetto, la versione “Sei” non aveva nessuna lista fissa di requisiti. Secondo i requisiti standard, il prodotto doveva contenere le seguenti funzionalità:

• Supporto completo contro le minacce alla sicurezza;
• Uso ottimizzato delle risorse del PC;
• Infrastruttura basata sul componente per una migliore scalabilità;
• Capacità di adattarsi con facilità alle diverse piattaforme.

Con questi meta-requisiti, i corrispondenti requisiti tecnici del prodotto vennero sottoposti ad una serie di cambiamenti. Di conseguenza, la release veniva continuamente rimandata, ma il team fu in grado di sviluppare una soluzione rivoluzionaria con un paio d’anni di anticipo rispetto alle richieste generali del mercato, superiore anche alla versione precedente in termini di velocità.

In seguito al lancio di Kaspersky Anti-Virus 6.0, Maxim Yudanov, responsabile del disegno dell’interfaccia grafica, ci racconta: “uno degli elementi che hanno fatto in modo che il progetto si distinguesse fu l’assenza di una lista di requisiti fissi, incisa nella pietra. Abbiamo creato prototipi, discusso del prodotto, aggiornato la lista dei requisiti tecnici e delle funzionalità, annotato i punti e le questioni più importanti sui post-in gialli e li abbiamo appiccicati sui monitor; qualche volta abbiamo dimenticato qualcosa, altre volte ci siamo ricordati e in linea di massima abbiamo sempre chiesto aiuto degli utenti (con questo intendo la beta test community). Sono sicuro che il prodotto finale non sarebbe stato quello che vediamo oggi se avessimo basato il nostro lavoro sulla tradizionale lista dei requisiti. In tal caso, avremmo finito col creare un prodotto diverso e sono sicuro che la qualità del prodotto sarebbe stato di gran lunga inferiore a quello che abbiamo creato”.

Extreme programming

Oggi questo approccio non è una novità. Ma 10 anni fa, applicare questo metodo a progetti di grandi dimensioni era piuttosto rivoluzionario e non convenzionale. La grande differenza tra il così detto extreme programming (il termine allora era ampiamente usato, ora tali metodi vengono raccolti nella categoria agile software development, con cui si intende, come sottolineavamo in precendenza, la metodologia agile per lo sviluppo del software) e il burocratico CMM-coding approach (ora praticamente estinto) sta nell’assenza della lista di requisiti tradizionale, una sorta di Bibbia che, una volta approvata come unica base del progetto, rimaneva così per gli anni a venire. L’approccio CMM potrebbe essere un buon metodo per i progetti di sviluppo esterni, ma per progetti commerciali è inutile.

Nikolay Grebennikov, ora CTO di Kaspersky Lab, è d’accordo sul fatto che: “Se avessimo dovuto stabilire una serie di caratteristiche fisse che non si potevano cambiare, non avremmo saputo di cosa gli utenti avevano bisogno e non avremmo ricevuto il loro supporto. La prima versone del build non era usabile e aveva un sacco di problemi. Per riparare i problemi, abbiamo speso un sacco di tempo, trascorse un anno e mezzo tra la versione alpha e la release tecnica. Nel mondo di oggi, è un lusso che non si può avere, ma a quel tempo, fu un’esperienza molto utile.”

Eugene Kaspersky è piuttosto fermo su questo punto: “Quando stai sviluppando progetti innovativi, preparati a non rispettare mai le deadline”.

Vita e lavoro

I membri principali del dev team di KAV 6.0 spesso si abbandonano ai ricordi del passato con nostalgia. Dormivano poco, passavano poco tempo con la propria famiglia, non avevano molti weekend liberi ed erano sottoposti a un grande stress. Ma venivano ricompensati dal vedere il prorio lavoro avanzare e dalla qualità dei risultati.

Una delle email che Nikolay Grebennikov scrisse durante il periodo in cui il progetto era in corso,  ne offriva una descrizione quasi poetica:

“Ad un certo punto, già non era più un semplice progetto. Era come essere dentro un videogioco potente e terribile, di quelli che ti assorbono, che si vivono dall’inizio alla fine. Mentre vai al lavoro, in metro, inizi a pensare alle vittorie e alle sconfitte dell’ultimo salvataggio del gioco; poi arrivi al lavoro e inizi a pensare a come giocare e raggiungere il livello successivo. Dopo aver messo tuo figlio a letto, entri nuovamente nel gioco dove sei capace di realizzare tutte le cose che hai immaginato, e tutto è possibile”.

“Erano tempi memorabili”, ricorda il CEO di Kaspersky Lab. “Gli occhi ci brillavano per l’entusiasmo, post-it ovunque e un intero team insonne. Un potpourri di idee e azioni”.

Quando il team si ingrandì, lo spririto del gruppo venne trasmesso ai nuovi arrivati, come ricorda De-Monderik:

“Per fare in modo che il team lavorasse bene, contavamo sulll’abilità di coloro che ne rappresentavano il ‘nucleo principale’ di diffondere entusiamo. Il ‘cuore del team’ maturava le idee generali, si occupava della sfida centrale: creare la migliore soluzione mai vista. Si trattava dell’obiettivo principale: Kolya [Grebennikov], Pavel Mezhuev, Doukhvalov, io, Mike Pavlyuschik… eravamo in grado di trasmettere l’entusiasmo ad altri memebri del team. Quando tutti attorno a te lavorano duro, e tu ti trovi nella stessa stanza, quando vedi come tutto questo avviene, cerchi inconsapevolmente di fare lo stesso”.

La gestione del progetto era piuttosto informale ma diede i suoi frutti.

“Se non ricordo male, all’inizio della giornata avevamo sempre un meeting in cui facevamo il punto della situazione”, afferma De-Monderik. “Nella mattinata quando il gruppo si riuniva nella stanza, Kolya era solito dare un discorso ‘ricapitolativo’: abbiamo tot risorse, oggi facciamo tot cose; era molto bravo in questo. Avevamo un’enorme lavagna bianca dove scrivere e rappresentare le nostre scoperte. Dato che non eravamo un team numeroso, era tutto ciò di cui avevamo bisogno”.

Grebennikov riconosce che tra le cose che possiamo ricavare da questa esperienza vi è il fatto che il meeting sul punto della situazione come metodo formale di organizzazione del progetto non è l’aspetto principale. Si deve riunire il team solo se il meeting porta benefici ricavabili dal progetto.

Ampliando la ricerca

Dato che il progetto si evolveva nel tempo, da settembre 2003 a marzo 2006, il team cresceva e il giorno della release il gruppo si componeva di circa 30 persone. Con maggiori requisiti e la transizione allo stage Alpha, il team allora includeva Maxim Yudanov (designer), Pavel Nechayev, Denis Guschin, Eugene Roschin e Andrey Gerasimov (software engineer). Essi apportarono una serie di caratteristiche innovative, tra cui un’interfaccia utente basata su skin e un firewall build-in. Il gruppo inoltre includeva esperti di installazione e supervisori beta test. Una delle fasi definitive per cui siamo passati per modificare e rifinire KAV 6.0, fu la creazione di un nuovo approccio; fu il dev team di “Sei” a inventarlo: un beta-test basato sul forum.

Forum

Tutti i stakeholder ammisero colletivamente che era grazie al forum tester se Kaspersky Anti-Virus 6.0 risultò essere così ben disegnato e attentamente testato. Il testing beta (che divenne una pratica comune in Kaspersky Lab) era allora una grande novità, non senza rischi: le aziende concorrenti avrebbero potuto cogliere l’occasione per conoscere le caratteristiche del prodotto prima della release.

“Abbiamo presto la questione molto seriamente, dato che un test beta espone il codice beta agli hacker e alla concorrenza”, afferma Grebennikov. “E così le persone iniziarono a dire la loro. Gli avversari diedero la loro opinione e i loro argomenti di base sono elencati qui sopra. Anche i sostenitori hanno presentato una solida prova del loro punto di vista. Le nostre risorse erano limitate, disponevamo di soli 2 tester mentre il resto dei tester erano destinarti al trial V 5.0. Il nostro prodotto era stato creato da zero e avevamo bisogno di un grande gruppo per eseguire i test. Per la prima volta, abbiamo impiegato l’approccio build update approach, inizialmente settimanalmente, poi a livello giornaliero. Testare i build sul forum ci permetteva di offrire la massima qualità di testing senza coinvolgere troppe risorse interne”.

Tutti gli sviluppatori erano attivamente coinvolti sui forum nelle discussioni con i tester.

“Durante il testing sui forum, l’èquipe di tester includeva diverse centinaia di utenti, con circa 500 persone in qualità di audience attiva”, aggiunge Nikolay Grebennikov. Ogni notte, Nikolay era solito passare molte ore sul forum, talvolta addormentandosi al computer. Un nuovo build veniva provato con avidità e eseguito ogni sera, senza alcun costo per l’azienda.+

I partecipanti al forum condividevano sia le informazioni sui bug, che suggerimento su come creare un prodotto migliore. Veniva prea  in considerazione una significante parte del feedback collettivo, contribuendo al  valore di KAV 6.0. Inoltre, i suggerimenti non venivano raccolti solo online. Eugene Kaspersky ricorda che gli sviluppatori scendevano spesso a fare una camminata fuori dall’ufficio e nel test della versione beta coinvolgevano chiunque, parlavano con tutti, dal sale manager al personale del supporto tecnico. Per esempio, alcuni dipendenti dell’assistenza tecnica, consigliarono di creare una funzionalità per cambiare la lingua del prodotto all’inglese e tale richiesta venne ascoltata.

I miglioramenti provenienti dalle discussioni del forum avevano un prezzo, che si poteva tradurre nel non riuscire a rispettare i tempi di consegna.

“In base al feedback proveniente dagli utenti del forum, creammo una lunga lista di cose da migliorare, ma improvvisamente mi resi conto che non potevamo aggiungere nulla a quanto avevamo già fatto, sebbene la proposizione era convincente. Ci trovavamo sotto il dictamen di una ferrea deadline, volevamo lanciare la release entro il secondo quadrimestre del 2006. Ci riuscimmo, ma all’ultimo minuto: alle 6.30 p.m. del 31 marzo”, evidenzia drammaticamente Nikolay Grebennikov.

Il lancio

Il successo

Morale della favola: il nostro “allora” non troppo grande team sviluppò un prodotto con un fenomenale installer compatto, un’interfaccia utente basata su skin intercambiabili, dal basso impatto sulla performance del PC e, cosa ancora più importante, un prodotto che includeva caratteristiche innovative e potenti, tra cui funzionalità di protezione proattive per bloccare applicazioni sospette sulla base del loro comportamento.

“Symantec rivette un duro colpo quando molte riviste americane del settore etichettarono il nostro prodotto come ‘Golden-star product’. Ricevemmo le migliori valutazioni, ovunque”, ricorda con piacere Eugene Kaspersky.

Grazie ai rapporti con i partner stabiliti in Europa, USA e Cina, il prodotto raggiunse la “catena di montaggio” e ricevette le migliori valutazione negli store online.

Il successo di “Sei” era dovuto all’architettura attentamente selezionata che permetteva l’implementazione di innovazioni tecniche e offriva un’alta performance, così come un approccio di sviluppo che si adattasse a un team ristretto ma entusiasta. Questi sono stati i nostri punti forti, ciò che ha contribuito a portare Kaspersky Anti-virus 6.0 sul mercato (per trasformare un progetto in un autentico successo, sia le architetture che le tecniche di sviluppo devono essere ben allineate per adattarsi al dev team e alla scala del lavoro).

Sei ruoli e una macchina del caffé

“All’interno della strategia SCRUM c’è una regola interessante, che ora applico ad altre sfere della mia vita”, afferma il CEO di Kaspersky Lab. “Se qualcosa s’interpone nel processo di sviluppo, dovrebbe essere eliminato immediatamente. Punto. Non importa cosa sia. Questo significa, inoltre, che se uno sviluppatore ha bisogno di qualcosa, bisogna dargliela subito”.

Il primo giorno in cui partì il progetto chiesi: Di cosa avete bisogno in primis? ‘Una macchina del caffè’, rispose Petrovich. La mattina seguente il team aveva a disposizione una costosa e nuovissima macchina del caffé. E tutto il progetto ha iniziato a filare!”.