Quote:
Originariamente inviato da Cimmo
Si chiama "agile development" o in italiano "metodologia agile"
|
NO, non si chiama "agile development"
nello sviluppo sw le metodologie agili prevedono che il processo di: analisi dei requisiti -> design -> sviluppo -> testing e validazione -> feedback non sia più eseguito in una successione monolitica a livello di intero progetto, ma ripetuto iterativamente in cicli dallo scope ridotto, di modo da permettere al progetto stesso di sostenere variazioni nei requisiti (e di riflesso a livello di feature, interfaccia od anche di design architetturale) in corso d' opera
quindi minimizzare i fattori di rischio del processo di sviluppo - processo che per creare qualcosa che soddisfi sia le specifiche iniziali
più quelle emerse nel tempo (soluzione completa da fornire alla clientela/ utenza, aka deliverable), richiederà comunque dei mesi o degli anni...
in questo non c'è molta differenza con le metodologie non agili (che anzi con un' accurata pianificazione iniziale possono a seconda dei casi perfino richiedere
meno risorse - scendere nel dettaglio di cicli -> stories -> singoli tasks e gestirli individualmente crea un certo overhead), a parte il fatto che se lo sviluppo dovesse per qualsivoglia motivo interrompersi a metà, esiste comunque "qualcosa" (l' ultimo snapshot della code base) da far uscire...
MA, il prodotto del singolo task o della singola iterazione è sostanzialmente una release
interna al team di sviluppo - che sia da equiparare a una deliverable non è scritto da nessuna parte, semmai è un' idea indotta dall' open source (che in questo senso è pericoloso perchè rischia di creare dei falsi preconcetti che poi si pretende di applicare al sw in generale) nella sua veste di modalità di distribuzione e deployment (visto che ogni build è anche una relase pubblica)...
Quote:
|
Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
|
così come non è scritto da nessuna parte che il sw
debba uscire con nuove relase a scadenze regolari (3 mesi piuttosto che 6, 12 o..) piuttosto che "quando è pronto" come si è sempre usato...
o che debba essere numerato secondo criteri diversi da
major_version.minor_version, dove un incremento di major_version è per
convenzione sinonimo di novità sostanziali a livello architetturale e/o (anche solo) di interfaccia
esempio classico : il sw di animazione e modellazione Real3D già dalle prime versioni implementava le proprietà fisiche degli oggetti e li rappresentava nativamente in forma di nurbs, ma aveva un menu che definire ostico è riduttivo, e parecchie idiosincrasie... la gui venne completamente rifatta, il feature set e i menu non solo ampliati ma ortogonalizzati in ottica objet oriented (quindi chiara per l'utente), lo stesso core venne riprogettato di modo che ogni property potesse influenzare programmaticamente ogni altra, oltre a essere animabile, o che mesh nurbs, sds o poligonali potessero essere composte in modo seamless nello stesso oggetto
la nuova versione fu rilasciata come "realsoft version 4", cosa giustificata da tutto il lavoro che vi confluì - ed anche l' utente sapeva di potersi aspettare praticamente un programma del tutto nuovo (cosa che in effetti era)
ora, per Google Chrome non avviene nulla del genere, tra una relase e l' altra l' interfaccia è sempre la stessa, l' architettura a process separated tabs è sostanzialmente sempre la stessa, le funzionalità sono sempre le stesse, di browser (peraltro la tipologia di applicazione fruitiva più basilare e semplice dal punto di vista dell' utente, nonchè l' applicazione
orizzontale per definizione) streamlined, con innovazioni che nella convenzione di cui sopra meriterebbero incrementi del major version number in uno o al più due occasioni ... motivo per cui Google sceglie bellamente di ignorarla, per dare all' utenza un' immagine di maggiore dinamismo (e peraltro convincerla che vada abolita in quanto anacronistica e superata)
quindi sì, occorre che la gente si faccia una cultura, ma non tanto per smettere di lamentarsi del numero delle versioni, ma per capire cosa è versioning e cosa è marketing...