ERD-WEIJI

WEIJI da anni sviluppa secondo la metodologia ERD (Evolutionary Rapid Development), ma in chiave rivisitata.
I fondamentali dell’ERD WEIJI-styled si basano…
 … sulla creazione di un modello architettonico guidato dal focus sugli aspetti macroscopici della “costruzione” ed al contempo slegato dalla prospettiva di dettaglio,
 …sul riutilizzo di componenti,
 …sull’uso di modelli validi per l’intera durata del progetto.
 La mancanza di definizione progettuale degli aspetti di dettaglio consente allo sviluppo di rimanere svincolato dai nodi tecnologici ad essi connessi e quindi dalla necessità di trovare soluzioni definitive per il singolo passaggio prima di poter procedere con l’evoluzione dell’intero schema. Lo sviluppo procede in parallelo per brevi timeboxes di scrittura, analisi e test. Inoltre, ogni step di avanzamento viene subito rilasciato in test al gruppo di produzione, che verifica in tempo reale le nuove funzionalità e richiede eventuali modifiche.
 La chiave di successo del progetto è quindi da ricercare nella combinata metodologica di scouting, definizione e sviluppo di funzionalità modulari, infrastrutture e componenti ad hoc, e dell’adozione di tecnologie all’avanguardia, che consentono cambi di rotta istantaneamente reattivi quando nuovi rilasci tecnologici, nuovi orientamenti del mercato o delle esigenze rilevate lo rendano necessario.
 Il framework è modellato direttamente sullo sviluppo progettuale, così da garantire l’operatività di tutti gli attori in gioco attraverso ogni singolo step della timeline. Tradizionalmente, viene adottato un framework di base sul quale poggiare il successivo sviluppo del progetto: per WEIJI, il progetto È il framework.
 Altri vantaggi nell’uso di questo modello di sviluppo sono:
 rilasci frequenti
 team di lavoro snelli e svincolati l’uno dall’altro
 la pubblicazione costante di beta-release, che permette agli analisti e debugger di verificare in tempo reale la congruità del software
 il fatto che non si parta dalla “carta”, ma che ogni timebox “transita” su di essa per poi venire subito dopo gettata; non esiste un project iniziale, ma continui draft che perdono la loro ragion d’essere nel momento in cui si passa allo step successivo
 le timeboxes corrispondono ad intervalli prefissati in cui compiti specifici devono essere eseguiti; piuttosto che definire obiettivi vaghi in termini di sviluppo, si preferisce l’impostazione “Timeboxes /Vs Funzionalità realistiche”, con minimo scostamento rispetto alla previsione iniziale.
 IN SINTESI stabilita l’architettura, il software viene sviluppato, integrato e testato su base quotidiana; questa modalità consente al team di verificare i progressi compiuti in maniera oggettiva e rilevare potenziali problemi con estrema rapidità. Proprio perché vengono sviluppate piccole componenti del sistema alla volta, la diagnosi e risoluzione del bug è quasi instantanea. La modalità demo è erogabile praticamente in ogni fase dello sviluppo, perché a livello macro la release è la stessa utilizzata dagli sviluppatori.