July 2010 - Posts

• Chi è il cliente nella gestione dell’ALM?

  Nella gestione del ciclo di vita di un software la figura più importante è il cliente, anche se il termine esatto da usare sarebbe stakeholder. La definizione di wikipedia è Project stakeholders are those entities within or outside an organization which: a) Sponsor a project or. b) Have an interest or a gain upon a successful completion of a project. c) May have a positive or negative influence in the Project Completion. In sostanza gli stakeholder sono coloro che sono interessati alla realizzazione del progetto stesso, senza i quali il software non esisterebbe. Formalizzare il concetto di stakeholder è importante, perchè troppo spesso si considera cliente solo chi mette i soldi oppure in generale chi commissiona il software, dimenticando completamente altre figure più importanti. Le categorie di persone che fanno parte degli stakeholder possono essere identificate a grandi linee in: Chi paga per il prodotto Chi lo ha richiesto Chi conosce il dominio del problema Chi lo usa Chi interagisce con l’output del prodotto stesso. Purtroppo spesso solo i punti 1 e 2 sono considerati come clienti, provocando problemi nel raccoglimento delle specifiche dato che sono gli unici ad essere contattati dagli analisti. Dal punto di vista della raccolta requisiti infatti ogniuna di queste figure deve essere coinvolta per raccogliere tipologie differenti di requisiti. Gli stakeholder del punto 1 e 2 forniscono la visione del progetto  e sono in grado di dare la direzione principale da seguire cosi come una sommaria descrizione delle regole di business. Gli stakeholder del punto 3 forniscono invece le specifiche dettagliate sulle regole di business che il software deve implementare. Questa categoria di stakeholder è solitamente quella che realmente preme per realizzare il prodotto stesso, ed è rappresentata da coloro che hanno la necessità di creare il prodotto stesso. In questa categoria risiedono gli “esperti di dominio” ed una figura di questa categoria dovrebbe essere sempre presente o contattabile da tutto il team per dirimere eventuali dubbi durante lo sviluppo. Gli stakeholder del punto 4 sono invece gli utenti, dai quali vanno ricavati gli use case a livello utente del sistema, ed eventuali mockup. In questa categoria troviamo anche le figure che dovrebbero validare l’usabilità del sistema. Il problema classico è che spesso queste persone non sono contattate per nulla, sebbene siano coloro che utilizzeranno fisicamente il sistema. Il nostro sistema infatti può implementare perfettamente le regole di business, ma essere poco usabile perchè ad esempio per compiere le operazioni più comuni richiede un numero elevato di interazioni con l’interfaccia utente. Gli stakeholder del punto 5 infine non sono sempre presenti, ma in alcuni casi sono invece molto importanti. Se ad esempio un software deve generare un output da spedire a tutti i fornitori, sarebbe necessario raccogliere da loro alcune specifiche sommarie sui formati attesi, invece di creare una esportazione xml e scoprire che il 90% dei fornitori utilizza un formato CSV. Se un programma deve generare delle informazioni da passare ad un altro dipartimento di un azienda che usa SAP, è doveroso contattare una persona di tale dipartimento per determinare come scambiare i dati. Queste piccole considerazioni fanno capire come la raccolta requisiti coinvolga molteplici figure, ma spesso gli stakeholder non vogliono spendere tempo con gli analisti, presupponendo che chi realizza il software sia in grado di lavorare da solo sulla base di specifiche vage del tipo: “ci serve un software di gestione magazzino da installare nel palmare dei magazzinieri”. Tra le regole di Extreme programming vi è infatti un contatto costante con il cliente, e si richiede di avere sempre almeno uno Stakeholder che lavora a fianco con il team. Anche in Scrum e nei processi iterativi gli stakeholder sono sempre necessari, perchè vengono resi partecipi del risultato di ogni iterazione o sprint e della riprioritizzazione dei requisiti ad ogni iterazione/sprint. Sebbene coinvolgere molti stakeholder nel progetto sia difficile, è fondamentale se si vuole avere una elicitazione dei requisiti completa e non parziale. Dato che in letteratura troviamo molti esempi che mostrano come il 40% o più dei difetti di un software può essere ricondotto ad errori fatti durante la raccolta dei requisiti, viene da se che gli investimenti nel migliorare questo settore porterebbero sicuramente benefici, anche nel breve termine. alk. Posted Jul 30 2010, 09:24 AM by Alkampfer's Place Filed under: Analisi

• Rapporti con il cliente–questi sconosciuti

  In un recente post si sono aggiunti alcuni commenti con spunti interessanti e proprio stamattina ho letto un altro post di Luka molto interessante. Uno degli errori più macroscopici che si fanno solitamente durante lo sviluppo è quello di creare contrapposione tra dev e cliente. Tipicamente quando il cliente chiede una modifica, lo sviluppatore si sente frustrato e spesso accusa il cliente con frasi del tipo: “non sa mai cosa vuole”, “non è in grado di capire che cosi è meglio”, “debbo rifare tutto per colpa del cliente”, e potrei continuare ancora a lungo. Questo conflitto spesso è determinato dal mancato contatto cliente / dev, che viene solitamente mediato da figure di “Analisti Marchettari”, ovvero persone che vanno dal Cliente non con lo scopo di raccogliere veramente requisiti e fare gli analisti, ma piuttosto per “Vendere” un prodotto. Qui spesso si cela il male perchè il ciclo di sviluppo adottato molto spesso è 1) andare dal cliente, cercare di capire alcune vaghe specifiche 2) vendere al cliente il proprio prodotto, convincendo il cliente che si è capito quello di cui ha bisogno 3) gettare le vaghe specifiche in una stanza con X sviluppatori 4) periodicamente aprire la porta di suddetta stanza e chiedere “è pronto?”. 5) quando si ha qualche cosa di più o meno funzionante lo si fa vedere al cliente quindi in sostanza non si ha nessun processo, è come costruire una casa senza progetto, prendendo X persone e dando loro calce e mattoni. Molto spesso inoltre le specifiche sono fumose e non sono corrette, principalmente perchè non le si è nemmeno cercate, ma le si è imposte al cliente stesso. Al termine il cliente ha un prodotto che non è quello che vuole e chiaramente inizia a chiedere cambiamenti creando quindi attrito con gli sviluppatori. La frustrazione maggiore è vedere il tempo perso ad implementare cose inutili. Se non si ha il controllo sul processo, ovvero se siamo meramente le persone nella stanza, è comunque utile adottare un approccio più costruttivo, e come nel link citato da Luka invece di dire “It’s Them” preferiamo dire “It’s all of us”. Lo scopo è quello di cercare di coinvolgere il più possibile il cliente nel processo, con la maggiore trasparenza possibile, e soprattutto continuando per tutto il corso del progetto a cercare di elicitare i requisiti con il cliente stesso. Cerchiamo quindi magari di convincere l’analista a parlare periodicamente con il cliente, facendo vedere il lavoro svolto fino a quel punto, e cercando strumenti che permettano di “aiutare” il cliente a capire cosa vuole (casi d’uso, mockup, prototipi, interviste). Lo scopo finale è quello di soddisfare il cliente, per cui ogni richiesta di cambiamento è lecita. Se adottiamo questo modo di pensare, probabilmente ci si eviterebbero arrabbiature… d’altra parte “Il cliente ha sempre ragione” Alk. Posted Jul 27 2010, 02:29 PM by Alkampfer's Place Filed under: Analisi

• Introduzione alle Client-Side API di SharePoint 2010

  E' appena stato pubblicato un mio nuovo articolo su SharePoint 2010 all'interno di SharePoint Community . E' una breve introduzione sulle API esposte dalla nuova versione di SharePoint, per lo sviluppo di applicazioni client-side che girano... Posted Jul 26 2010, 06:40 PM by PeppeDotNet Blog Filed under: Sharepoint

• Resoconto sedicesimo workshop Dotnetmarche

  Questo post giunge con un certo ritardo ;) causa impegni lavorativi. Innanzitutto un doveroso grazie, in ordine sparso e non di importanza, a tutti quelli che hanno reso possibile l’evento. Iniziamo con i relatori che si sono resi disponibili, da Alessandro di DotDotNet, passando per Mauro e per Giorgio e per finire con gli speaker autoctoni Ste8 e Marco Ferretti. Anche in questo caso la sinergia tra le community risulta vincente, un grazie infatti anche a Andrea di DotNetUmbria, che ha portato prodotti tipici per ETGF. Un grazie sentito va anche all’Università Politecnica Delle Marche, che ci ha messo a disposizione a titolo completamente gratuito, la sala per l’evento, accessoriata anche con un impianto di ripresa che ha permesso lo streaming dell’evento. Un grazie a tutti i partecipanti che hanno resistito al caldo dell’estate e a tutti quelli che hanno favorito la buona riuscita dell’evento. La serata si è conclusa alla Croce Del Moro, dove finalmente abbiamo potuto placare la fame di Mauro :), e poi un grande saluto a tutti quelli che sono venuti da fuori regione, Matteo, Niccolò e tutti gli altri romani e soprattutto Michele che è stato anche ospite a casa mia ed ha stranamente familiarizzato subito con il gatto :) cosa rara visto il carattere di Sgrifio. Rigrazie a tutti. alk. Posted Jul 26 2010, 11:52 AM by Alkampfer's Place Filed under: Generale

• Dove vedi girare la ballerina?

  Sono sempre stato un appassionato di illusioni ottiche, questa della ballerina non la conoscevo, anche se è veramente vecchia :)  la trovate qui (http://www.heraldsun.com.au/news/right-brain-v-left-brain/story-e6frf7jo-1111114603615) ed in sostanza è una semplice gif animata che mostra una ballerina che ruota. Il problema è che l’immagine è fatta in modo che sia possibile vederla ruotare in senso orario o viceversa. Inizialmente la vedevo ruotare solamente in senso orario, indice stranamente, che secondo il test nel mio cervello prevale la parte creativa e l’emisfero destro. La cosa interessante è che dopo un minutino che la guardate e capite il giochino, è possibile effettivametne vederla ruotare da entrambe le direzioni, è veramente curioso :) Alk. Posted Jul 25 2010, 01:23 PM by Alkampfer's Place

• Errore: "The crawler could not communicate with the server"

  Se, guardando il log dell'indicizzazione prodotto dal servizio di ricerca di MOSS 2007 su uno dei content source che avete configurato, vi trovate un errore di questo tipo: The crawler could not communicate with the server. Check that the server is... Posted Jul 24 2010, 07:28 PM by PeppeDotNet Blog Filed under: Sharepoint

• L’importanza dei requisiti

  I believe the hard part of building software to be the specification, design, and testing of conceptual construct, not the labor of representing it and testing the fidelity of the representation. The hardest single part of building a software system is deciding precisely what to build The mythical man month. L’esperienza degli anni mi fa sempre di più apprezzare questa citazione, i problemi tecnici si superano, i bug vengono corretti, le tecnologie evolvono ed aiutano, ma se non si capisce cosa si deve costruire… è tutta fatica sprecata. Per questa ragione ritengo che il successo di un progetto non può prescindere da un buon analista, figura che però è quantomeno difficile da trovare. Spendendo i miei due cents penso che un buon analista: 1) debba capire quello che serve al cliente e non imporre le proprie scelte 2) debba necessariamente dialogare con i futuri utenti e fruitori del prodotto, e chiedere a loro opinioni su come vorrebbero il software 3) generare una documentazione molto snella dei requisiti e non generare documenti chilometrici pieni di “Fuffa” per intortare il cliente 4) includere il cliente nel ciclo di vita del prodotto 5) assumere un atteggiamento socratico “so di non sapere” in particolare il punto 5 è molto importante, nei processi industriali ad esempio, bisogna approcciare l’analisi sapendo di non conoscere nulla del processo, e quindi è necessario fare interviste a tutte le figure, dai manager fino agli operai che lavorano sulla catena, approcciando ogni colloquio con l’attitudine di chi non sa nulla e deve apprendere da chi ha davanti. Spesso invece si adotta un approccio del tipo “arrivo io e ti spiego come devi lavorare”, che è foriero di problemi di ogni tipo. alk. Posted Jul 24 2010, 11:20 AM by Alkampfer's Place Filed under: Citazioni

• Slide e demo della mia sessione all'evento GroundZero di DotNetLombardia

  Oggi era il giorno di GroundZero , l'evento organizzato dai ragazzi di DotNetLombardia , dove sono stato invitato per tenere una sessione sulle novità di SharePoint 2010 per sviluppatori. Non sono riuscito a seguire tutte le sessioni, ma sicuramente... Posted Jul 23 2010, 01:06 AM by PeppeDotNet Blog Filed under: Sharepoint

• Le novità di SharePoint 2010 per dev a GroundZero: manca poco !

  Mancano solo 2 giorni all'evento GroundZero organizzato dai ragazzi di DotNetLombardia ! Mi dicono che la sala ancora non è piena, quindi vi ricordo che potete ancora iscrivervi dal sito dell'evento: http://groundzero.dotnetlombardia.org/ Io ho... Posted Jul 20 2010, 02:30 PM by PeppeDotNet Blog Filed under: Sharepoint

• Microsoft Scrum 1.0

  Per tutti gli amanti delle procedure agili, e di Scrum in particolare, è ora uscita ufficialmente la prima versione del process template di TFS “Microsoft Visual Studio Scrum 1.0”, che permette di adottare un processo Scrum con TFS. Tutto quello che si deve fare è scaricare, installare in locale il template e poi inserirlo in TFS e creare il primo Team Project con il nuovo template. Nel sito trovate tutto quello di cui avete bisogno. alk. Posted Jul 20 2010, 10:59 AM by Alkampfer's Place

• Annunciato il rilascio dell'Administration Toolkit per SharePoint 2010

  Dal blog del team di SharePoint è stato annunciato il rilascio della versione 1 dell'Administration Toolkit per SharePoint 2010. Il toolkit vede una serie di nuovi tool per l'amministrazione di SharePoint 2010. Eccoli del dettaglio: User Profile... Posted Jul 16 2010, 12:49 PM by PeppeDotNet Blog Filed under: Sharepoint

• Update per SharePoint Foundation 2010 - KB2032588

  Due giorni fa, precisamente il 13 luglio 2010, è stato rilasciato un aggiornamento per SharePoint Foundation 2010 descritto da questo articolo della KB Microsoft: http://support.microsoft.com/kb/2032588 L'aggiornamento viene fatto tramite Microsoft... Posted Jul 15 2010, 10:00 PM by PeppeDotNet Blog Filed under: Sharepoint

• Come recuperare le Missing Web Part indicate nel report di upgrade a SharePoint 2010

  Quando ci si prepara per un upgrade a SharePoint 2010 utilizzando la tecnica dell'attach del database di contentuo, è buona regola lanciare il comando *Test-SPContentDatabase* tramite PowerShell. Questo comando controlla il database di contenuto che... Posted Jul 14 2010, 07:43 PM by PeppeDotNet Blog Filed under: Sharepoint

• SharePoint 2010 certifications: One shot two kills

  Ho ricevuto proprio ora la conferma di aver superato entrambi gli esami ITPRO per SharePoint 2010, ovvero: 70-667: Microsoft SharePoint 2010, Configuring 70-668: Microsoft SharePoint 2010, Administrator Questi due esami coprono tutta la parte sistemistica e di architettura della nuova versione di SharePoint in aggiunta sono strutturati in maniera differente dai loro predecessori (2007). Ora, dopo le ferie Posted Jul 14 2010, 09:30 AM by nonaka Filed under: Sharepoint, Personal, Headline, Featured, Technology, Microsoft SharePoint 2010

• FatalError: The file cannot be imported because its parent web does not exist

  A fronte di un restore di una site collection, oppure di uno o più siti SharePoint 2007 tramite le utility di backup e restore presenti all'interno della Central Administration o tramite l'utility STSADM, o se utilizzate le Content Migration API... Posted Jul 12 2010, 08:19 PM by PeppeDotNet Blog Filed under: Sharepoint