riflessioni personali: organizzazione e metodi di lavoro

[71104]

io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.

ricordo che in una vecchia discussione si parlava dei metodi di lavoro che insegnano in genere alle università, in particolare di UML e di come questo linguaggio sia utile a formalizzare il funzionamento del software che si vuole creare, fase progettuale secondo molti assolutamente essenziale e da risolversi prima della stesura di qualsiasi riga codice; io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.
fek in quella discussione intervenne in un modo che mi piacque molto (adoro quando si scopre che i prof dicono cavolate ): se ben ricordo disse più o meno che UML e metodi simili sono roba da... "perbenisti" (mia interpretazione della sua risposta ) e che in realtà nel lavoro sono richiesti metodi molto più... "agili" e soprattutto produttivi, come ad esempio il metodo che stiamo usando nello sviluppo di Diamonds: refactoring continuo della codebase in base a obiettivi sempre nuovi (gli obiettivi posti dai vari task). apparentemente un metodo molto più lento di quello che insegnano all'università, il quale invece ci dice all'incirca "prima formalizzare e progettare il tutto e poi scrivere codice", ma di fatto non è così: i miei giudizi empirici dicono che è l'esatto opposto; perché? be', innanzitutto il metodo che ci insegna fek ricalca precisamente quella della mente umana, che orientativamente è molto buono: quando un programmatore free-lance fa un programma per conto suo in genere non progetta un bel nulla all'inizio, semplicemente si mette giù a buttar codice e ad aggiungere funzionalità strafiche al suo software; il fatto che poi non arrivi quasi mai molto lontano dipende da due cose:
1) una semplice proporzione: Microsoft Word sta al numero di persone che l'hanno creato (che saranno svariate decine, probabilmente centinaia) come x sta a una sola persona: quanto è grande x?
2) la pigrizia: a volte capita che una sola persona si scoccia di fare il programma che aveva inizialmente pensato, perciò semplicemente lo interrompe senza finirlo e non arriva a nulla di concreto; al contrario nelle aziende il lavoro è lavoro, e sei obbligato a farlo.

secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds ), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.

ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.

ora, qualcuno ha mai visto il film "Scoprendo Forrester"? be', per citarlo, il mio concetto di programmare non è pensare, è programmare; questa è la mia filosofia, la quale sembra sposarsi perfettamente col metodo di lavoro che ci insegna fek.
a quanto pare secondo la libera interpretazione di un regista era anche il metodo di un famoso scrittore inglese

MA (c'è un ma)

è possibile che in alcuni casi in realtà il metodo di iniziare a scrivere codice solo *dopo* aver progettato *tutto* si riveli più efficiente dell'altro? è possibile che in alcuni casi si abbia fin dall'inizio un'idea estremamente precisa della soluzione finale (possibile in effetti), e che aspetti ancora ignoti si possano chiarire in futuro senza il minimo ritardo nello sviluppo del lavoro?
mi pongo questa domanda perché lavorando nel Night Sun Network oggi io e un membro dello staff abbiamo capito che dobbiamo darci una metodologia di lavoro più precisa e razionalmente scandita, e che dobbiamo stabilire delle timelines, anche approssimative (o almeno, quest'ultima cosa era quello che ho pensato io, ma l'altro tizio non so se ci è arrivato ancora ).
dunque abbiamo iniziato a scrivere un txt in questo modo: lui ha scritto un primo abbozzo di quella che poteva essere una scaletta di lavoro; non aveva restrizioni di alcun tipo, ha semplicemente scritto qualsiasi cosa che poteva essere utilizzata come scansione del proprio lavoro; siccome il lavoro a cui mi riferisco è un software che bisogna realizzare per il network, si da il caso che il tizio abbia scritto una scaletta tipo gerarchica delle varie funzionalità di questo software; bene.
il passo successivo era che io avrei dovuto perfezionare il txt e ripassarglielo; poi lui avrebbe dovuto riperfezionarlo e ripassarmelo, e così via.
ebbene siamo giunti a qualcosa; anzi per l'esattezza siamo giunti a due cose ESTREMAMENTE diverse: per farla breve posso dirvi che io ho usato un metodo un po' alla fek, ed ero sul punto di definire delle timelines, mentre lui è partito in quarta andandoci giù non proprio di UML ma di schemi concettuali su come funzionerà il software (in altre parole ha usato un metodo che assomiglia molto a quello delle università e dell'UML).
ora ho osservato la seguente cosa: lui ha avuto una ispirazione, e le ispirazioni sono sempre utilissime perché estremamente produttive (dico sul serio); è estremamente probabile che il suo metodo funzioni, mentre se lui avesse usato il mio probabilmente la cosa sarebbe stata controproducente perché lui non ci si capacitava: non gli era congeniale e non gli ha suggerito nessuna ispirazione.
molto probabilmente riuscirà ad essere più produttivo procedendo come insegnano i miei prof (doh -.-' odio quando si scopre che i prof dicono cose giuste) anziché come insegna fek; come è possibile tutto ciò?

ho pensato che tutto questo potesse costituire uno spunto per una discussione interessante (e nessuno risponde )

PS: scusate la lunghezza del post e scusate se sono stato prolisso

[71104]

aggiungo una possibile spiegazione che sono riuscito a darmi all'ultimo quesito del precedente post: io penso che in effetti qualsiasi metodologia vada bene, purché sia basata su un criterio razionale.
quando si progetta un metodo di lavoro l'obiettivo primario dovrebbe essere la velocità e la produttività: bisogna agire il meno possibile producendo il più possibile, e questo vale sia per il pensare sia per lo scrivere righe di codice (soprattutto per la seconda però).
se il metodo di lavoro che si è progettato si basa su un criterio razionale e corretto a mio parere il metodo può essere molto produttivo. perché allora nelle aziende UML non si usa (o comunque non si usa all'inizio del lavoro)? premesso che non so se veramente nessuno lo usa, magari non lo usano solo alla LionHead e solo per certi lavori , il progettare prima e programmare dopo è un metodo rischioso: potrebbe portare molto facilmente a un vicolo cieco a causa del fatto che non si sa a cosa si va incontro; per applicarlo con certezza bisogna aver avuto un'ottima ispirazione (sapete, tipo quando il cervello aumenta la sua velocità e diventa in grado di controllare 8 cose contemporaneamente ) e bisogna avere le idee molto molto chiare su cosa si vuole fare (e tutto questo non è impossibile); ma un'azienda impegnata in un progetto di enormi dimensioni (quale può essere un videogioco tridimensionale molto complesso o un programma di videoscrittura degno di questo nome, o addirittura un sistema operativo come Microsoft Windows) l'ultima cosa che vuole fare è rischiare di cadere in costosi vicoli ciechi, anche perché sicuramente le centinaia di persone che lavorano nel team avranno ispirazioni molto diverse
more likely un'azienda di grosse dimensioni impegnata in un grande progetto preferirà fare centinaia degli spikes di fek per vedere che possibilità ha, poi inizierà a porsi i primi rudimentali obiettivi, inizierà a scrivere tonnellate di codice, e man mano gli obiettivi si perfezioneranno e raffineranno fino a raggiungere la soluzione finale con un rischio quasi nullo (perché purtroppo quello c'è sempre) di finire nel costoso vicolo cieco; dico che quello c'è sempre perché gli spikes per quanti siano purtroppo non possono prevedere ogni tipo di imprevisto: noi ad esempio in Diamonds abbiamo appena scoperto che le librerie che usiamo per interfacciare Java con OpenGL non accettano textures le cui dimensioni non siano potenze di due; in caso contrario parte una simpaticissima eccezione. tutto questo mi suggerisce una situazione un po' diversa: che avremmo fatto se non fossimo riusciti a scoprire il motivo di quella eccezione, o se addirittura il motivo fosse stato un vero e proprio bug di qualche libreria??? fortunatamente avevamo già pronti gli spikes (fatti da me ) per JNI, coi quali avremmo potuto interfacciarci con una nostra DLL fatta in C++ e successivamente con OpenGL, dunque avevamo uno o più spikes che ci avrebbero salvati, ma l'imprevisto avrebbe potuto essere ancora peggiore e avremmo potuto non avere spikes del caso.
c'è da dire che più grosso fosse stato il problema incontrato, più sarebbe stato improbabile incontrarlo (caso estremo: hardware failure che si verifica in tutti i modelli di schede grafiche ATI e che impedisce solo a noi di realizzare il videogioco perché nessun altro se n'è mai accorto; dire che è impossibile è dir poco ); comunque questo discorso rende bene l'idea di cosa significa "non conoscere la soluzione finale".

[VICIUS]

Originariamente inviato da 71104

io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.

Ah. Il waterfall. Che ricordi

Originariamente inviato da 71104

secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds ), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.

È ovvio che il committente non conosca la soluzione. Altrimenti non sarebbe venuto da te "programmatore" ad ingaggiarti. Il vero problema è che non sanno quello che vogliono. Peggio ancora, se ti capitera di lavorare per grandi società, le persone con cui parlerai saranno diverse da un giorno all'altro. per farti un esempio Vodafone cambia ogni 6 mesi. Un vero inferno insomma perchè con la gente cambiano anche i requisiti.

Originariamente inviato da 71104

ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.

Basta semplicemente tenere uno storico di alcuni indici prestazionali del team. Se durante l'ultimo meeting salta fuori che la nuova metodologia BuGLeZs provata ha dimezzato il numero di codice scritto e raddoppiato il numero di difetti si torna indietro. Tutte le società con un minimo di cervello misurano le prestazioni del processo di sviluppo e cercano di migliorarlo. Cosa che dovrebbero fare anche i programmatori che pero viene considerata peggio della scrittura di documentazione :P

Originariamente inviato da 71104

è possibile che in alcuni casi in realtà il metodo di iniziare a scrivere codice solo *dopo* aver progettato *tutto* si riveli più efficiente dell'altro? è possibile che in alcuni casi si abbia fin dall'inizio un'idea estremamente precisa della soluzione finale (possibile in effetti), e che aspetti ancora ignoti si possano chiarire in futuro senza il minimo ritardo nello sviluppo del lavoro?

In genere anche usando metodologie agili un minimo di fase di preparazione ci vuole sempre. Non puoi alzarti alla mattina e dire oggi scrivo Doom 4 altrimenti rischi di comemttere errori gravi con ritardi paurosi. Quando si è familiari con il dominio del problema e si intravede gia la soluzione si lavora incredibilmente meglio con metodologie agili. Si puo evere un prototipo pronto in 1/ 2 giorni da far vedere al cliente che avra gli occhi luccicanti dalla commozione per aver assunto dei Mega-Hackers . Se invece anche dopo 2 giorni di colloqui e meeting non si è ancora capito che cavolo dovra fare il prodotto è meglio fermarsi. Oppure anche quando il progetto è piuttosto consistente un progetto con UML con una anlisi della fattibilità è molto meglio farla. Se porti ad una riunione piena di quarantenni inbrillantinati dei fogli con i sorgenti e qualche scansione del K&R ti guarderanno storto e riprenderanno a parlare delle macchinette per il caffè. Se invece gli porti qualche slides con un usecase o un diagramma potrebbero, bada bene, potrebbero capire qualcosa

ps: ma quante volte hai scritto "fek" in questo messaggio ?

ciao

[Angus]

Originariamente inviato da 71104

CUTTONE

Secondo me nel tuo pensiero si stanno un pò mischiando i molteplici aspetti della produzione del software: dalla raccolta e analisi dei requisiti fino al testing e deploy.

Innanzitutto è meglio ribadire che UML != progettazione.

Detto questo, la giusta via è anche in questo caso nel mezzo: se il dominio del problema riesce a stare nella testa di una singola persona, questa riuscirà con qualsiasi metodo a lui più congeniale a venirne a capo, ma non appena si aggiunge un'altra persona al team le cose cambiano.
Oltre al problema del 'mi metto a pensarci ad occhi chiusi, butto giù qualcosa su carta o scrivo direttamente il codice', sorge il problema della comunicazione fra gli elementi del team. Personalmente è il problema più costoso e difficile da risolvere.

Senza poi dimenticare l'aspetto manutenibilità: una buona documentazione a tutti i livelli è essenziale in questi casi, altrimenti si finisce per metterci meno a riscrivere il codice tutto da capo piuttosto che cercare di capire il perchè e il percome del suo (non) funzionamento...

[Giakino]

Qualche domanda
UML è il fatto di mettersi prima su carta e buttare giu tutto il progetto (funzionamento, grafici, diagrammi, etc) per poi passare al codice vero e proprio?
A quanto ho capito in diamonds lavorate a task, ognuno si occupa di una piccola parte basata su dei test, quando è finita (e funzionante) si cerca di sistemare un pò le cose (proprie o altrui) e poi si continua, ho capito bene?
I task come si fanno a definire dall'inizio? Cioè, sotto un progetto di game 2d ok, devo partire dal fatto di creare una finestra, caricare le basi, etc etc, ma per esempio per un'applicazione come si potrebbe iniziare?
E ancora, questo stile dei test è applicabile anche per programmi e quindi non giochi? Come ci si basa per iniziare da un test? Il problema è scriverlo, poi il codice si implementa in modo che non fallisca (penso). Ci sono delle regole da seguire per scriverli?
Cos'è uno spike?
Molto interessante questo metodo, e spero di capirci qualcosa...
Per ora è tutto (non uccidetemi )

[71104]

Originariamente inviato da VICIUS

In genere anche usando metodologie agili un minimo di fase di preparazione ci vuole sempre. Non puoi alzarti alla mattina e dire oggi scrivo Doom 4 altrimenti rischi di comemttere errori gravi con ritardi paurosi.

lo so, infatti una certa fase di preparazione era comunque prevista nel mio metodo; sarò più preciso: quello su cui io e il tizio non eravamo d'accordo erano il tipo di considerazioni da fare all'attuale fase progettuale (che è l'inizio): lui è partito in 4 a fare considerazioni di tipo concettuale preso dalla sua ispirazione, mentre io dico che, visto e considerato anche che comunque una certa familiarità con la soluzione già ce l'avevamo entrambi grazie ad alcune prove e ad una versione provvisoria del programma già esistente (che però fa molto poco), si sarebbero dovute selezionare le considerazioni da farsi al momento attuale in base ad un criterio funzionale, e non concettuale. la mia scaletta era questa:

1) versione iniziale
   a) progettazione di primo livello (livello di dettaglio basso; abbozzo di idee insomma :))
   b) strutturazione e definizione delle priorità (secondo il criterio make it look good, make it
      work)
   c) implementazione delle varie funzionalità
      I) progettazione di secondo livello relativamente alla funzionalità scelta (alto livello di
         dettaglio, ma solo relativamente alla funzionalità prioritaria corrente)
      II) implementazione della funzionalità
2) aggiunta di una nuova funzionalità
   a) progettazione di una strategia di refactoring (spesso questa fase è considerata implicita,
      cioè la si fa semplicemente "a mente")
   b) preparazione del codice alla nuova aggiunta: refactoring e adattamento
   c) implementazione della caratteristica
3) aggiunta di un'altra funzionalità
   a) ecc. ...

NB: i punti 2a e 2b vanno minimizzati il più possibile.

nel punto 1a bisognava fare una progettazione a livello puramente funzionale, evitando considerazioni di altro tipo (cioè evitando tutte quelle che invece ha fatto lui). ora si da il caso che questa progettazione funzionale fosse già stata fatta da lui all'inizio del txt che ci siamo passati a turno; io quindi sarei passato dritto dritto al punto 1b: avrei scritto dei numeri accanto ai vari elementi della sua scaletta indicanti la priorità della funzionalità da implementare; successivamente avrei implementato le diverse funzionalità in ordine prioritario.
come puoi leggere nella scaletta, le priorità andavano stabilite in base ad un criterio "first make it look good, then make it work"
nel senso che nello stabilire le priorità, ovunque possibile avremmo dovuto dare la precedenza ad aspetti esteriori appetibili dalla nostra utenza.

Quando si è familiari con il dominio del problema e si intravede gia la soluzione si lavora incredibilmente meglio con metodologie agili.

verissimo; le ispirazioni vengono più facilmente.

Si puo evere un prototipo pronto in 1/ 2 giorni da far vedere al cliente che avra gli occhi luccicanti dalla commozione per aver assunto dei Mega-Hackers . Se invece anche dopo 2 giorni di colloqui e meeting non si è ancora capito che cavolo dovra fare il prodotto è meglio fermarsi. Oppure anche quando il progetto è piuttosto consistente un progetto con UML con una anlisi della fattibilità è molto meglio farla. Se porti ad una riunione piena di quarantenni inbrillantinati dei fogli con i sorgenti e qualche scansione del K&R ti guarderanno storto e riprenderanno a parlare delle macchinette per il caffè. Se invece gli porti qualche slides con un usecase o un diagramma potrebbero, bada bene, potrebbero capire qualcosa

ma LOL, mi mancava questo stereoptipo

ps: ma quante volte hai scritto "fek" in questo messaggio ?

non sapevo come altro chiamare il "metodo che insegna fek"

[71104]

Originariamente inviato da Giakino

UML è il fatto di mettersi prima su carta e buttare giu tutto il progetto (funzionamento, grafici, diagrammi, etc) per poi passare al codice vero e proprio?

no, UML è un vero e proprio linguaggio usato (da quel pochissimo che ne so per ora) per la formalizzazione del comportamento del programma (la sua progettazione insomma).

A quanto ho capito in diamonds lavorate a task, ognuno si occupa di una piccola parte basata su dei test, quando è finita (e funzionante) si cerca di sistemare un pò le cose (proprie o altrui) e poi si continua, ho capito bene?

si: ognuno si prenota per un task, lo svolge cercando di soddisfare i test prescritti da VICIUS o da fek (o almeno in teoria dovrebbe essere così -.-') e al termine tutti fanno un po' di refactoring per migliorare la qualità del codice e uniformarlo un po'.

I task come si fanno a definire dall'inizio? Cioè, sotto un progetto di game 2d ok, devo partire dal fatto di creare una finestra, caricare le basi, etc etc, ma per esempio per un'applicazione come si potrebbe iniziare?

in maniera del tutto analoga: prendiamo ad esempio un programma di videoscrittura; i primi task essere più o meno aprire una finestra, metterci la toolbar e i menu, disegnare il foglio nella client area, implementare un caret, e così via...

E ancora, questo stile dei test è applicabile anche per programmi e quindi non giochi?

i videogiochi sempre programmi sono...

Come ci si basa per iniziare da un test? Il problema è scriverlo, poi il codice si implementa in modo che non fallisca (penso).

infatti è così: uno scrive il test e *dopo* un altro implementa la feature relativa cercando di soddisfarlo e se necessario aggiungendo altri test...

Ci sono delle regole da seguire per scriverli?

giusto quelle di JUnit... il test altro non è che codice eseguibile...

Cos'è uno spike?

un semplice esperimento di programmazione

[cionci]

IMHO anche "il metodo fek" necessita di progettazione... Prima una progettazione d'insieme: vengono individuate le parti topiche del progetto, scelte gli strumenti e le metodologie di programmazione...

Poi la progettazione viene svolta ogni qual volta si scrive una storia e un task... Di fatto è una progettazione continua...e che tiene conto dei problemi che ogni volta si presentano... Ma sono problemi concreti, che la maggior parte delle volte potrebbero non presentarsi durante la progettazione preventiva dei canoni classici dell'ingegneria del software...e di fatto, appena si presentano (perchè bene o male in UML non si potrà mai generare TUTTO il codice) si dovrà ritornare a progettare, magari a sconvolgere l'intero progetto buttando via decine di mesi uomo di programmazione... Stessa cosa per i bug...nella progettazione classica un bug prevede un ritorno alla fase di progettazione e di testing... Con il test driven development un bug corrispondente a trovare un test che fallisce se il bug è presente...dopo si scrive il codice che non fa fallire quel test... Ecco...siamo pronti... Il nostro programma non ha bisogno di ulteriori test (sempre che vengano passati tutti i test)...visto che ci sono sempre gli altri test a garantirmi che la mia correzione non ha introdotto ulteriori bug già testati...

L'unico difetto che si può inputare al "metodo fek" è che il capo del progetto deve essere una persona veramente competente...se questo si verifica il metodo è perfetto... In una progettazione di team (ognuno progetta interamente un componente rispettando delle specifiche) se non sono tutti competenti allo stesso modo si avrà uno sbilanciamento che porterà a perdere moooolto tempo...

71104 : hai ancora visto la progettazione con UML all'uni ? Guarda che arrivi quasi a schematizzare il codice che scrivi...ad un dettaglio che forse non ti immagini... In pratica programmi prima in UML e poi il programma ti genera il codice

[Giakino]

Uhm, forse è che sono abituato a fare direttamente in maniera visuale per inserire qualcosa (lo sò, è un metodo sbagliato, infatti pian piano sto studiando anche per fare tutto solo da codice)
Però mi sfugge una cosa, qual'è proprio il modo per creare dei test? Cioè, devo pensare e vedere nella palla di cristallo che quel determinato metodo avrà determinati problemi che devo prevedere oppure esiste un modo per creare/pensare in maniera più semplice un test? Se ora ne dovessi scrivere uno non saprei nemmeno da che parte iniziare
Tornando all'esempio del programma di videoscrittura, quali potrebbero essere dei test iniziali?
fek/vicius mostrateci i vostri arcani poteri...

[theClimber]

Originariamente inviato da 71104

... io penso che in effetti qualsiasi metodologia vada bene, purché sia basata su un criterio razionale.......

Quasi .......
Qualsiasi metedologia va bene se le persone sono sufficientemente capaci di portare a termine il progetto (e quindi soddisfare il cliente, e portare a casa la pagnotta) 'nonostante' questa.
La scopo dei metodi e' di permettere alle persone di dare il meglio, e a seconda dei contesti, ma se chi deve fare il lavoro non e' capace c'e' poco da fare....

Per una analisi relativa all'impatto delle persone vs metodi, puoi dare un occhio a questo articolo:
http://alistair.cockburn.us/crystal/...nonlinear.html

E' stato scritto dell'autore del libro "Agile Software Development" (http://www.amazon.com/exec/obidos/tg...ooks&n=507846), che tratta proprio del problema di come "costruire" una metodologia, in un modo magari un po teorico ed accademico, ma sicuramente ricco di spunti interessanti.

Originariamente inviato da cionci

L'unico difetto che si può inputare al "metodo fek" è che il capo del progetto deve essere una persona veramente competente...se questo si verifica il metodo è perfetto... In una progettazione di team (ognuno progetta interamente un componente rispettando delle specifiche) se non sono tutti competenti allo stesso modo si avrà uno sbilanciamento che porterà a perdere moooolto tempo...

La situazione riguardo alle skills di livelli diversi non e' cosi' drammatica: tramite pair programming e la condivisione del design e' possibile colmare spesso divari di competenze. Generalmente i problemi peggiori nascono in presenza di personalita' che non sono disposte a dialogare e mettersi in discussione; questo puo' succedere sia in caso di persone "de coccio" sia in caso di "primedonne".

L'uso di metodi agili demolisce il mito del programmatore introverso e non comunicativo e richiede un affinamento delle skills di comunicazione, presentazione, mediazione e interazione personale.

Proprio per quest' ultimo motivo penso che il progetto che state affrontando sia un esperienza utile ed interessante.

Ciao e Buon lavoro

[Ozn ZzZ]

Originariamente inviato da 71104

io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.

ricordo che in una vecchia discussione si parlava dei metodi di lavoro che insegnano in genere alle università, in particolare di UML e di come questo linguaggio sia utile a formalizzare il funzionamento del software che si vuole creare, fase progettuale secondo molti assolutamente essenziale e da risolversi prima della stesura di qualsiasi riga codice; io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.
fek in quella discussione intervenne in un modo che mi piacque molto (adoro quando si scopre che i prof dicono cavolate ): se ben ricordo disse più o meno che UML e metodi simili sono roba da... "perbenisti" (mia interpretazione della sua risposta ) e che in realtà nel lavoro sono richiesti metodi molto più... "agili" e soprattutto produttivi, come ad esempio il metodo che stiamo usando nello sviluppo di Diamonds: refactoring continuo della codebase in base a obiettivi sempre nuovi (gli obiettivi posti dai vari task). apparentemente un metodo molto più lento di quello che insegnano all'università, il quale invece ci dice all'incirca "prima formalizzare e progettare il tutto e poi scrivere codice", ma di fatto non è così: i miei giudizi empirici dicono che è l'esatto opposto; perché? be', innanzitutto il metodo che ci insegna fek ricalca precisamente quella della mente umana, che orientativamente è molto buono: quando un programmatore free-lance fa un programma per conto suo in genere non progetta un bel nulla all'inizio, semplicemente si mette giù a buttar codice e ad aggiungere funzionalità strafiche al suo software; il fatto che poi non arrivi quasi mai molto lontano dipende da due cose:
1) una semplice proporzione: Microsoft Word sta al numero di persone che l'hanno creato (che saranno svariate decine, probabilmente centinaia) come x sta a una sola persona: quanto è grande x?
2) la pigrizia: a volte capita che una sola persona si scoccia di fare il programma che aveva inizialmente pensato, perciò semplicemente lo interrompe senza finirlo e non arriva a nulla di concreto; al contrario nelle aziende il lavoro è lavoro, e sei obbligato a farlo.

secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds ), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.

ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.

Se ho capito bene,vorresti fare dei programmi software efficenti senza neanche utilizzare un minimo di documentazione UML?
Io invidio chi ci riesce,e stai pur certo che di "luminari" del settore che riescono ad utilizzare extreme programming ce ne sono,ma sono davvero mosche bianche.
Non penso ci si possa illudere di fare dei progetti utilizzando metodologie agili tranne se non si e' sotto determinate condizioni.
Forse meglio chiarirci sul "cosa" intendiamo per metodologie agili;

Un team coordinato da un esperto con la E maiuscola.
Un team che enfatizza il codice alle "scartoffie" di UML.
Un team che a fine giornata deve ottenere dei "build" eseguibili.
Un team che include il customer,in modo da proporgli ogni build realizzato per ottenere un feedback istantaneo.
Un team che fa uso di pair programming avvidendando programmatori ogni due ore in quanto si e' visto che facendo cosi aumenta la qualita' del codice anche se ne risente il tempo di realizzazione.

Ma questo tipo di team impone anche :
- Metafora condivisa,ossia descrivere a tutti il progetto
-Collettivizzazione del codice,ogni persona del team interviene sul codice scritto da altri
-Integrazioni di codice e test frequenti.

E qui ti sorge spontanea la domanda.Ma e' cosi facile creare un team di sviluppo che riesca ad intervenire sul codice scritto da altri e a sviluppare lo stesso progetto software senza fare uso di "scartoffie UML" che descrivano un percorso guida?

Non e' facile,sicuramente puo' esistere, ma trovare delle persone "affiatate" che riescano a realizzare un tipo di progettazione software di questo tipo e' abbastanza difficile da realizzare.
Sicuramente se fossi una azienda e avessi un team del genere,me lo terrei abbastanza stretto

P.s. Se ti interessa l'argomento c'e' questo libro Giancarlo Succi, Michele Marchesi, Extreme Programming Examined

[cionci]

Ozn ZzZ: guarda la sottosezione...stiamo proprio facendo un gioco tramite XP + TDD

[71104]

la documentazione in generale è un discorso a parte, quella serve sempre; noi (io ) abbiamo messo su un thread apposito (Diamonds Knowledge) dove man mano che procede lo sviluppo scriviamo le "cose da sapere", senza contare l'altro thread che già esisteva, sempre sulla documentazione, che contiene documentazione ad un livello un po' più alto.

[cionci]

Poi se non sbaglio anche fek è d'accordo ad utilizzare UML per generare la documentazione alla fine dello sviluppo...e meno male ci sono strumenti che generano tutto in maniera automatica...

[71104]

*alla fine* però
dopo che si sa con precisione che cosa si è fatto

[Ozn ZzZ]

Originariamente inviato da 71104

*alla fine* però
dopo che si sa con precisione che cosa si è fatto

In che senso "alla fine"?
Che utilita' avrebbe l'uso di UML a fine progetto?
Alla fine la potenzialita' di un linguaggio di modellazione come UML sta proprio nel rendere visibile lo schema concettuale che ogni progettista si fa in testa.Con il livello di dettaglio che riesce a raggiungere nei diagrammi di classi e di sequenza si raggiungono livelli di precisione notevoli.
La cosa che piu' mi ha sorpreso di uml e' la possibilita' di definire automi a stati finiti e le varie interazioni tra oggetti.Nulla e' lasciato al caso e questo tutto prima di scrivere una sola linea di codice
Io penso sia un must per realizzare prodotti solidi.Ma ovviamente e' una mia opinione

[cionci]

Originariamente inviato da Ozn ZzZ

In che senso "alla fine"?
Che utilita' avrebbe l'uso di UML a fine progetto?

Documentazione dettagliata Tra l'altro è una parte del senso che avrebbe facendolo all'inizio... Perde il significato progettuale, ma mantiene il significato di documentativo...

[Ozn ZzZ]

Originariamente inviato da cionci

Documentazione dettagliata Tra l'altro è una parte del senso che avrebbe facendolo all'inizio...

Farlo all'inizio penso sia un supporto che ti eviti "orrori" nella generazione del codice .
Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto

[cionci]

Originariamente inviato da Ozn ZzZ

Io penso sia un must per realizzare prodotti solidi.Ma ovviamente e' una mia opinione

Ha un livello alto di dettaglio, ma non 1:1 con il codice e soprattutto con le scelte tecniche del codice...questo comporta la perdita di alcuni aspetti che magari verranno alla luce solo al momento della scrittura del codice...con la possibilità di dover obbligatoriamente ritornare alla fase di progettazione, magari dovendo buttare via mesi uomo di coding...
La stessa cosa può avvenire in fase di manutenzione del codice... Nota che progettando il codice con UML bisogna ritornare alla fase di progettazione ogni volta che c'è anche un piccolo bug (ancora di più se il livello di dettaglio è molto alto)...e dopo bisogna nuovamente fare tutta la trafila del testing...
Tutto tempo perso...anche perchè magari correggendo il bug abbiamo reinserito un bug che avevamo corretto tempo fa !!!
Con il TDD non è possibile reinserire bug già corretti precedentemente perchè per ogni bug trovato ci deve essere un test che fallisce se questo viene reintrodotto...

[cionci]

Originariamente inviato da Ozn ZzZ

Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto

XP come dicevo sopra non significa assenza di progettazione, ma signiica farla un po' per volta... Sicuramente quella ad altissimo livello deve essere fatta prima dell'inzio dello sviluppo...