On 10/10/2014 15:04, Flavio Visentin wrote: > In realtà se si considera la separazione dei ruoli ha ragione Mario. > > Il compito di raccogliere le esigenze dall'utente, produrre il workflow, > definire i metodi di sviluppo, ecc. deve essere svolto dall'analista. > Il programmatore dovrebbe limitarsi a prendere l'output dall'analista e > produrre il codice. > Infine il tester dovrebbe prendere il codice, verificarne l'aderenza a > quanto definito dall'analista, scovare bug, ecc. e dare l'OK per le > build da sottomettere al giudizio del committente. > > Il che è proprio come funziona in ambienti complessi. Naturalmente per > piccoli team spesso i ruoli sono accorpati, ma il ruolo dell'analista è > quello più complesso e non tutti i programmatori sono in grado di > svolgerlo in modo idoneo. Ci sono certamente strutture gigantesche dove decine di programmatori implementano ciascuno un ordine di lavoro rigidamente definito di cui ignorano lo scopo, ma sono inefficienti e sempre meno diffuse. Anche in ambienti multiruolo l'analista è in grado di trasferire direttamente le necessità utente in input diretto per il programmatore solo se il dominio del problema è ridotto, oppure se l'analista è sia un programmatore, sia un domain expert. Altrimenti l'analista è di solito un esperto dell'ambito di applicazione, con alcune conoscenze di sviluppo software (non necessariamente di programmazione), in grado di dialogare sia con gli utenti che con gli sviluppatori. Discutendo con i primi per ottenere dei requisiti usabili per confezionare assieme ai secondi un programma adeguato. Il che vuol dire che se l'analista deve avere qualche conoscenza di sviluppo, i programmatori devono avere almeno un'infarinatura del campo di applicazione. Riccardo -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx