analisi-disegno.com
Nella newsletter precedente ricordavo che la divisione del lavoro nello sviluppo software viene spesso motivata con la complessità delle conoscenze necessarie a chi sviluppa. L'effetto è la creazione di ruoli diversi (capo progetto, analista, architetto software, programmatore, eccetera).
Agli albori dell'informatica non era così. I primi programmatori lavoravano alla definizione del problema, progettavano la soluzione, la implementavano, la testavano, a diretto contatto con l'hardware. Senza divisione del lavoro.
Nessuna divisione del lavoro neppure all'avvio delle imprese più dinamiche degli ultimi decenni. Microsoft, Apple, Google, molte delle aziende più importanti del mondo IT attuale nascono in modo artigianale, senza strutture, senza distinzione di ruoli.
Nessuna divisione del lavoro neppure nelle piccole realtà di oggi. Massima flessibilità, niente burocrazia, contenimento dei costi.
Ma se le piccole realtà hanno successo avviene, naturale, una crisi di
crescita.
Aumentano il carico di lavoro e il numero delle persone, diventa
difficile tenere sott'occhio gli avanzamenti complessivi, si ha la
sensazione di perdere il controllo. Che può anche essere percepita come
carenza di uniformità e di standardizzazione.
La risposta tipica è una nuova organizzazione del lavoro. Che a livello potenziale può essere effettuata in modi diversi. Ma spesso, nel software, porta alla specializzazione dei ruoli.
La specializzazione dei ruoli, dal punto di vista di chi deve gestire un'organizzazione complessa, comporta dei vantaggi. Se riesco a definire con precisione i singoli ruoli, posso anche definire procedure standardizzate e misurabili per chi deve svolgerli, individuare percorsi formativi specifici, effettuare selezioni professionali mirate.
Il problema sta nel come far interagire al meglio i ruoli distinti, per contenere i costi e massimizzare i risultati.
Una scelta possibile è quella di definire delle unità organizzative basate sui ruoli: l'unità dei capi progetto, quella degli analisti, quella degli sviluppatori, eccetera. Di solito, queste unità organizzative fondate su ruoli omogenei si cristallizzano in silos ciascuno dei quali tende ad ottimizzare localmente le proprie attività, e a rapportarsi con le altre unità nel modo più formalizzato e standardizzato possibile. La conseguenza è la logica seriale della catena di montaggio, che nel mondo del software corrisponde ai processi a cascata, fortemente burocratici.
Una risposta alternativa al crescere della complessità organizzativa è quella degli approcci agili allo sviluppo. Sulla divisione del lavoro, gli approcci agili tendono a forme di non-separazione, o ri-composizione dei ruoli.
Il caso più significativo è quello di extreme programming, dove l'unico ruolo riconoscibile e riconosciuto è quello di sviluppatore (programmer). Anche negli altri approcci, comunque, si tende ad enfatizzare il lavoro in team ed il superamento della logica dei silos organizzativi, per cui ciascuno ottimizza il proprio orticello senza darsi carico delle conseguenze sul funzionamento globale dei processi.
In alcuni casi, si va dritti verso una ricomposizione dei ruoli. In altri casi, la collaborazione sistematica all'interno del team dei diversi ruoli e delle diverse competenze porta ad una maggiore integrazione di ruoli che restano distinti. Ma la diffusione delle conoscenze in un contesto collaborativo porta i partecipanti ai team a farsi carico, quando necessario, anche di compiti non strettamente legati al proprio ruolo.
*** Nuovo libro su BPMN ***
Bruce Silver: BPMN Method & Style.
Silver è uno dei maggiori esperti di BPMN e ha contribuito alla definizione di BPMN 2.0. Il suo libro non è una semplice ripetizione con parole diverse dei contenuti del manuale ufficiale di BPMN, ma fornisce indicazioni utili per l'analisi dei processi, e suggerimenti stilistici con il confronto di soluzioni diverse al medesimo problema. Consigliato.
*** Good-bye ai DBMS relazionali? ***
Michael Stonebracker: The End of a DBMS Era (Might Be Upon Us).
Stonebracker è uno dei nomi storici del settore dati. A suo avviso, i DBMS relazionali attualmente leader di mercato sono pronti per la pensione, in quanto inadeguati a fornire le prestazioni necessarie a diverse tipologie innovative di sistemi, come data warehouse, OLTP, applicazioni scientifiche, motori di ricerca. Per ogni ambito esistono altre soluzioni che forniscono prestazioni migliori.
"Potreste chiedervi, 'e se per me le prestazioni non sono una fonte di preoccupazione?'. Risposta: Usate i DBMS relazionali open source. Sono maturi, affidabili, e soprattutto gratis".
*** Software sviluppato dagli utenti ***
La distinzione tra utenti e sviluppatori software sta rapidamente svanendo, scrivono Gerhard Fischer, Kumiyo Nakakoji e Yunwen Ye su IEEE Software, September/October 2009
"Crediamo che gli esperti di dominio, cioè coloro che hanno i problemi,
debbano farsi carico di svilupparsi il software che serve loro. [...]
La breve storia del World Wide Web è una prova convincente del
dissolversi della distinzione netta tra progettazione e uso. Nel primo
decennio del Web predominava una separazione chiara tra sviluppatori e
utenti. [...] Ora gli utenti prendono anche direttamente parte a varie
attività di sviluppo, e fanno evolvere gli applicativi Web adottandoli,
adattandoli, appropriandosene e combinandoli tra loro."
"
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita e regolare.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.