Project RightStart

RightStart. Perché non il più usuale QuickStart? Perché partire in fretta non significa arrivare prima, né tanto meno arrivare meglio alla meta. L'inizio di un nuovo progetto è un momento carico di aspettative, ma anche di interrogativi; di energie, ma anche di incertezze; di possibilità, ma anche di rischi. Il bisogno di vedere subito dei risultati è più che comprensibile, così come il desiderio di attività, che dimostri sin dall'inizio la capacità del team di arrivare in fondo al progetto. Non dobbiamo però confondere attività e progresso: molti progetti partono senza una chiara architettura di fondo, e semplicemente esplorano, con grande dispendio di energie, un gran numero di possibilità. In questi casi il prodotto finale manca spesso di integrità concettuale, e molti aspetti sono il risultato del trial-and-error ("é fatto così perché così funziona") e non di chiare scelte progettuali. Miglioramenti ed estensioni diventano così il prossimo incubo di manutenzione.

I vari schemi di QuickStart, spesso accompagnati da tool che promettono produttività elevatissime a breve termine (e che quasi mai reggono il passo via via che i requisiti si evolvono e le richieste si moltiplicano), danno sempre l'illusione di una partenza rapidissima, salvo innescare brusche cadute nel progresso (ma non nell'attività!) quando ci si scontra con l'ennesimo limite imprevisto, e si cerca giusto un'altra scappatoia per uscirne fuori.

Esistono ovviamente approcci alternativi. Con il nome RightStart, noi intendiamo un approccio che non insegue il risultato immediato ma punta ad ottenere una architettura stabile, cercando nello stesso tempo di eliminare i rischi latenti attraverso prototipi mirati.
Più esattamente, l'approccio RightStart è così strutturato:

Definizione di una architettura di sistema, in grado di soddisfare i requisiti presenti e futuri.

Eventuale studio di mini-framework domain/problem-specific all'interno dell'architettura.

Risk-management aggressivo: ogni zona d'ombra che emerga durante il design architetturale viene immediatamente sottoposta a prototipazione per verificarne la realizzabilità nei termini di tempi e di qualità previsti.

Release a stadi: l'architettura definita viene realizzata secondo un planning che consenta di ottenere un sistema minimale (ma già basato su solide fondamenta), verificarne proprietà e potenzialità, ed estenderlo nel rispetto dello schema architetturale sino alla versione finale.

L'approccio RightStart prevede un coinvolgimento sin dalle prime fasi del progetto, con l'obiettivo di aiutare il team a definire l'architettura, identificare i rischi, valutare e sperimentare insieme le migliori soluzioni, e pianificare gli stadi di release.

Confrontato con il classico approccio QuickStart (spesso seguito anche involontariamente dai team di sviluppo) si nota un progresso iniziale meno rapido (mentre si definiscono i primi elementi dell'architettura e si analizzano i primi rischi del progetto) ma anche una crescita stabile e senza esitazioni, priva dei crolli di produttività e morale che affliggono chi si affida prima agli strumenti e poi ai trucchi per portare a termine un progetto complesso.

Interessati? Parlatene con noi all'indirizzo rightstart@eptacom.net, o chiamateci allo 019-8160697.