do more with less
news, esperienze, esempi da condividere e qualcosa su di me

lunedì 30 gennaio 2012

Stimare rapidamente il software da realizzare

Qual’è la domanda che più temiamo quando ci viene chiesto di realizzare un nuovo software? Per molti di noi la è: quanto tempo occorre?. Oggi sono incappato casualmente in un post (cercavo una descrizione dell’acronimo MOSCOW= MUST , OUGHT , SHOULD, COULD, WON’T usato per dare le priorità alle funzionalità da realizzare) che propone un interessante approccio per rispondere a quella temuta domanda. L’articolo vale la lettura, ecco il link: Estimating your software project in a hurry.

giovedì 19 gennaio 2012

Differenza tra “Assigned to” e “Tester” in MTM

Durante una consulenza, che ho tenuto presso un cliente a dicembre, mi è stato chiesto quale fosse la differenza tra il valore del campo “Assigned to” e il campo “Tester” in MTM. Li per li ho abbozzato una risposta che però non mi ha pienamente soddisfatto. Avrei avuto bisogno di qualcosa di più incisivo e chiaro da condividere con il mio cliente. Oggi, leggendo uno dei feed che ho sottoscritto, mi sono imbattuto in un post del team di Visual Studio che forniva una risposta proprio a quel quesito. Non potevo non leggerlo e non inserirne un riferimento nel mio blog per futura memoria. Ecco il link all post: What is the difference between “Assigned To” and “Tester” in MTM?.

mercoledì 18 gennaio 2012

Vuoi influenzare il contenuto della futura MSDN? Partecipa a questo sondaggio

Spesso ci lamentiamo perchè nella documentazione non troviamo i contenuti che cerchiamo o perchè non sono organizzati come secondo noi sarebbe più logico. Bene, grazie al team di Visual Studio ALM, ora possiamo dire la nostra rispondendo a un breve sondaggio disponibile qui. Il questionario è rivolto ai clienti attuali o potenziali di Microsoft che utilizzano o potrebbero utilizzare le tecnologie di sviluppo Microsoft.

martedì 3 gennaio 2012

ll rischio dello Yin e Yang nell’ALM: valutare il grado di determinazione del management

Il successo o l’insuccesso nell’adozione di una metodologia per la gestione del ciclo di vita del software spesso passa dagli stackholders interni all’azienda in cui state introducendo il cambiamento. Le diverse fasi che si percorrono nell’adozione di una nuova metodologia o nel perfezionamento di una esistente presentano sponsor diversi a cui bisogna dare attenzioni diverse. Da qualche tempo mi sto scontrando con il comportamento ondivago di una parte del management di una società con cui sto collaborando. Da una parte (Yang) sono appoggiato per portare avanti il progetto di organizzazione, qualità e produzione per cui sono stato ingaggiato. Per questo condividiamo un piano che poggia le sue fondamenta su due pillar:

  1. l’adozione di SCRUM  come metodologia Agile per gestire il ciclo di vita del loro software;
  2. l’adozione di un’architettura software moderna per le future applicazioni da realizzare.

Dall’altra parte (Yin) sono ostacolato nell’applicazione delle modifiche che questa riorganizzazione richiede. Beh! Cosa c’è di strano, vi direte. Lo strano è che la parte che mi rende la vita difficile è una porzione di quel management che mi appoggia nei meeting in cui vengono approvati gli interventi da adottare. Un paradosso che mi ha portato a definire una nuova voce nella mia checklist di pre-assunzione di un nuovo incarico: valutare il grado di determinazione del management (aka valutazione del rischio dello Yin e Yang nell’ALM).

Meditate gente, meditate…