Il Product Owner è uno dei ruoli principali di Scrum, uno dei processi agili più diffusi.
In italiano, lo si può tradurre come "proprietario del prodotto", o "responsabile del prodotto".
Dal punto di vista di chi sviluppa software, corrisponde in linea di massima al ruolo di "committente", cioè di chi ha la responsabilità di decidere i requisiti da soddisfare, le priorità di realizzazione, l'accettabilità dei risultati forniti dagli sviluppatori.
Certamente è il ruolo più importante per il successo di un prodotto, di un sistema. Ma è arduo da svolgere, perché non esiste un percorso formativo per diventare Product Owner, e può capitare che il ruolo non sia riconosciuto in termini di autorità e responsabilità all'interno delle organizzazioni.
Sul ruolo di Product Owner, uno scritto interessante di Jeff Patton.
10 marzo 2009
01 marzo 2009
Il (software) design come fatto sociale
Richard Gabriel è uno dei leader storici della comunità dei software design pattern.
Ha pubblicato da poco uno scritto interessante, Designed as Designer, in cui affronta la tesi romantica della creazione di un design (di un'architettura) come espressione totalmente autonoma di un'individualità. Non è certo il primo a smontare la creatività romantica, ma la sua argomentazione è supportata da esempi illuminanti.
Gabriel evidenzia come ogni design (di un edificio, di una poesia, di un software) sia il frutto di due relazioni:
Ha pubblicato da poco uno scritto interessante, Designed as Designer, in cui affronta la tesi romantica della creazione di un design (di un'architettura) come espressione totalmente autonoma di un'individualità. Non è certo il primo a smontare la creatività romantica, ma la sua argomentazione è supportata da esempi illuminanti.
Gabriel evidenzia come ogni design (di un edificio, di una poesia, di un software) sia il frutto di due relazioni:
- del designer con altri designer, e più in generale con altre persone (collaboratori, revisori, ecc.)
- del designer con il materiale trattato, che condiziona e influenza ogni scelta di design
Lo sviluppo sw è un fatto sociale, più che tecnologico
"As we realize that software development is often more about people - collaboration, communication, and coordination - than technology, developing 'soft skills' such as meeting-management techniques is becoming more important".
Nell'articolo "When Robert Rules", su IEEE Software Jan/Feb 2009, Philippe Krutchen segnala un metodo di gestione delle riunioni pubblicato nel 1896 da un generale USA, Henry M. Robert, e ancora utile oggi, le Robert's Rules of Order.
Nell'articolo "When Robert Rules", su IEEE Software Jan/Feb 2009, Philippe Krutchen segnala un metodo di gestione delle riunioni pubblicato nel 1896 da un generale USA, Henry M. Robert, e ancora utile oggi, le Robert's Rules of Order.
06 febbraio 2009
Evolutionary System Development
Un articolo di Peter Denning, Chris Gunderson e Rick Hayes-Roth, tre esperti IT di lungo corso che lavorano attualmente per la US Navy, la marina statunitense, segna a mio avviso una tappa importante nel percorso verso la piena affermazione dei processi agili.
"The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems
where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. [...]
Whereas preplanned development seeks to avoid risks, evolutionary development mimics nature and embraces risks. The developers purposely expose emerging systems to risks to see how they fail, and then they build better system variants. It is better to seek risk out
and learn how to survive it. [...]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work."
L'articolo è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.
"The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems
where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. [...]
Whereas preplanned development seeks to avoid risks, evolutionary development mimics nature and embraces risks. The developers purposely expose emerging systems to risks to see how they fail, and then they build better system variants. It is better to seek risk out
and learn how to survive it. [...]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work."
L'articolo è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.
04 febbraio 2009
Comunità di contenuti
Un articolo di Wojciech Cellary, universitario di Poznan, "Content Communities on the Internet", confronta le comunità territoriali (le relazioni che si stabiliscono nel luogo in cui si risiede) con le comunità che si formano su internet in merito ad uno specifico argomento (ad esempio gli appassionati della Fiat 500, o le persone interessate agli standard ISO9000).
L'analisi comparativa fa emergere alcuni aspetti interessanti, tra cui:
L'analisi comparativa fa emergere alcuni aspetti interessanti, tra cui:
- nelle comunità di contenuti, il fatto che le relazioni si stabiliscano su un unico argomento porta naturalmente ad una radicalizzazione delle posizioni
- affinché la comunità di contenuti si sviluppi in modo positivo, la partecipazione non deve essere anonima.
Libro su BPMN
Scritto da Stephen White (il coordinatore del gruppo di lavoro che ha prodotto e fa evolvere lo standard) con la collaborazione di Derek Myers: BPMN Modeling and Reference Guide, Future Strategies 2008.
BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall'Object Management Group (OMG).
Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente - ma è organizzato e scritto in un modo più comprensibile. Alcuni esempi sono diversi rispetto a quelli presenti nella specifica ufficiale - in altri casi, gli esempi sono identici.
Si poteva fare di meglio, dato il livello di competenza degli autori, ma il libro costituisce comunque un'utile introduzione all'argomento.
BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall'Object Management Group (OMG).
Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente - ma è organizzato e scritto in un modo più comprensibile. Alcuni esempi sono diversi rispetto a quelli presenti nella specifica ufficiale - in altri casi, gli esempi sono identici.
Si poteva fare di meglio, dato il livello di competenza degli autori, ma il libro costituisce comunque un'utile introduzione all'argomento.
29 gennaio 2009
PMBOK 4
Nuova edizione del Project Management Book of Knowledge (PMBOK), la quarta, uscita il 31-12-2008.
Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:
Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:
- Organizational Project Management Maturity Model (OPM3)
- Program Management
- Portfolio Management
Le migliori scuole del Piemonte
Classifica delle scuole medie superiori del Piemonte, compilata dalla Fondazione Agnelli.
Magari le singole collocazioni sono discutibili. Magari sono discutibili anche i criteri di valutazione.
Ma è comunque un grosso passo avanti il fatto che si pensi a rendere esplicita, pubblicamente confrontabile e discutibile, la domanda che genitori e studenti si fanno, da sempre, su quali siano le scuole più affidabili.
Da notare la collocazione in graduatoria delle scuole private, giù giù giù.
Magari le singole collocazioni sono discutibili. Magari sono discutibili anche i criteri di valutazione.
Ma è comunque un grosso passo avanti il fatto che si pensi a rendere esplicita, pubblicamente confrontabile e discutibile, la domanda che genitori e studenti si fanno, da sempre, su quali siano le scuole più affidabili.
Da notare la collocazione in graduatoria delle scuole private, giù giù giù.
06 gennaio 2009
Fare attenzione, sempre più difficile
Email, SMS, Facebook, ... se non si è disciplinati, gli stimoli che ci distraggono ci possono risucchiare.
La capacità di lavorare, di progredire, di ottenere risultati si basa sulla concentrazione, sul prestare attenzione. Ma ogni fonte informativa ed ogni canale di comunicazione si ripromettono di ottenere, sia pure per poco, la nostra attenzione. Di distrarci dal nostro focus.
Questo articolo di Mike Elgan lo spiega bene. Sei ore di lavoro concentrato ottengono ben di più di dodici ore di lavoro inframmezzato da email, telefonate, sms, navigazioni web, ecc.
La capacità di lavorare, di progredire, di ottenere risultati si basa sulla concentrazione, sul prestare attenzione. Ma ogni fonte informativa ed ogni canale di comunicazione si ripromettono di ottenere, sia pure per poco, la nostra attenzione. Di distrarci dal nostro focus.
Questo articolo di Mike Elgan lo spiega bene. Sei ore di lavoro concentrato ottengono ben di più di dodici ore di lavoro inframmezzato da email, telefonate, sms, navigazioni web, ecc.
29 novembre 2008
Usabilità, requisiti e progetti agili
Jakob Nielsen è un esperto di usabilità. Nella sua newsletter Alertbox parla del rapporto tra usabilità e approcci agili. L'argomentazione di Nielsen prende l'avvio dai requisiti:
"Requirement specifications are always wrong.
At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".
"Requirement specifications are always wrong.
At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".
CMMI e Agile
Il Software Engineering Institute (SEI) è un'istituzione finanziata dal governo e da grandi aziende USA. Nei corsi che tengo sono solito raccomandare il sito del SEI come una delle fonti più autorevoli di documentazione sulle tematiche dello sviluppo software. Documenti di alta qualità, e gratuiti.
Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.
Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.
Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.
Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.
Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.
Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.
Risorse educative aperte
Global Warming Toward Open Educational Resources, un articolo di Richard G. Baraniuk e C. Sidney Burrus su Communications of the ACM, settembre 2008.
Sulla diffusione di ambienti e strumenti gratuiti per la formazione. Tra cui:
MIT: Open-CourseWare e OCW consortium
Rice University: Connexions
Open University: OpenLearn
Carnegie Mellon University: Open Learning Initiative
Sulla diffusione di ambienti e strumenti gratuiti per la formazione. Tra cui:
MIT: Open-CourseWare e OCW consortium
Rice University: Connexions
Open University: OpenLearn
Carnegie Mellon University: Open Learning Initiative
Destino degli strumenti Telelogic
Dopo parecchi mesi, si è delineato il quadro di integrazione degli strumenti Telelogic (per la gestione dei requisiti e per la modellazione UML - SysML) in ambito IBM.
Il problema essenziale era come far convivere l'offerta Telelogic con l'offerta concorrente della linea Rational. Un paio di articoli (SDTimes , eWeek) fanno finalmente emergere cosa IBM propone ai propri clienti.
Il problema essenziale era come far convivere l'offerta Telelogic con l'offerta concorrente della linea Rational. Un paio di articoli (SDTimes , eWeek) fanno finalmente emergere cosa IBM propone ai propri clienti.
Modelli di stima dei costi nel software
Cocomo (Constructive Cost Model) è ritenuto comunemente il modello per la stima dei costi più completo ed affidabile in ambito software.
Achievements and Challenges in Cocomo-Based Software Resource Estimation (su IEEE Software, September-October 2008) è un articolo scritto dal padre di Cocomo, Barry Boehm, insieme a Ricardo Valerdi del MIT.
L'articolo fa il punto sullo stato dell'arte, le criticità e le tendenze nell'evoluzione dei modelli previsionali.
Achievements and Challenges in Cocomo-Based Software Resource Estimation (su IEEE Software, September-October 2008) è un articolo scritto dal padre di Cocomo, Barry Boehm, insieme a Ricardo Valerdi del MIT.
L'articolo fa il punto sullo stato dell'arte, le criticità e le tendenze nell'evoluzione dei modelli previsionali.
Tecnologie digitali e disintegrazione sociale
The Dea[r]th of Human Understanding. La penuria (la morte) della comprensione umana. Un articolo di Neville Holmes su IEEE Computer, ottobre 2008.
Holmes cita Nicholas Carr (Is Google Making Us Stupid?), ma espande la sua analisi sul ruolo e sugli effetti dei videogiochi. Pessimista, e convincente.
Holmes cita Nicholas Carr (Is Google Making Us Stupid?), ma espande la sua analisi sul ruolo e sugli effetti dei videogiochi. Pessimista, e convincente.
Princìpi di software testing (Meyer)
Da un articolo di Bertrand Meyer, uno dei nomi più importanti nel campo del software design:
- Principle 1: Definition. To test a program is to try to make it fail.
- Principle 2: Tests versus specs. Tests are no substitute for specifications.
- Principle 3: Regression testing. Any failed execution must yield a test case, to remain a permanent part of the project’s test suite.
- Principle 4: Applying oracles. Determining success or failure of tests must be an automatic process.
- Principle 5: Manual and automatic test cases. An effective testing process must include both manually and automatically produced test cases.
- Principle 6: Empirical assessment of testing strategies. Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.
- Principle 7: Assessment criteria. A testing strategy’s most important property is the number of faults it uncovers as a function of time.
10 novembre 2008
La nuvola
The cloud - la nuvola. L'infrastruttura di elaborazione evaporata.
O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.
Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.
Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist.
O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.
Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.
Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist.
21 ottobre 2008
Italia: 80.000 imprese IT
La Camera di Commercio di Milano ha pubblicato i risultati di una propria elaborazione sui dati del registro imprese.
Riporto l'intestazione:
"LA CARICA DELLE 80 MILA IMPRESE INFORMATICHE ITALIANE
+7,4% in quattro anni, 4 miliardi di euro di commercio estero
25 mila nuove assunzioni di personale qualificato nel 2008
Lombardia e Milano prime in Italia per imprese. Seguono Roma e Torino."
Userei meno trionfali, visto lo stato dell'economia italiana in generale e del settore IT in particolare. 80 mila imprese (la grande maggioranza individuali!) è un dato sconsolante, indice di frammentazione e debolezza.
Riporto l'intestazione:
"LA CARICA DELLE 80 MILA IMPRESE INFORMATICHE ITALIANE
+7,4% in quattro anni, 4 miliardi di euro di commercio estero
25 mila nuove assunzioni di personale qualificato nel 2008
Lombardia e Milano prime in Italia per imprese. Seguono Roma e Torino."
Userei meno trionfali, visto lo stato dell'economia italiana in generale e del settore IT in particolare. 80 mila imprese (la grande maggioranza individuali!) è un dato sconsolante, indice di frammentazione e debolezza.
UML 2.2 e SysML 1.1
L'Object Management Group (OMG) ha approvato le nuove versioni di:
UML (Unified Modeling Language) 2.2, disponibile per il download la documentazione in formato beta con barre di cambiamento per evidenziare le pochissime novità.
SysML (Systems Modeling Language) 1.1, disponibile per il download al SysML Forum.
UML (Unified Modeling Language) 2.2, disponibile per il download la documentazione in formato beta con barre di cambiamento per evidenziare le pochissime novità.
SysML (Systems Modeling Language) 1.1, disponibile per il download al SysML Forum.
14 ottobre 2008
Software perfetto
"Perfect Software and other illusions about testing". È un libro di Gerald Weinberg, uscito da poco.
Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.
Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.
Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.
Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.
Iscriviti a:
Post (Atom)