Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, edit the default.aspx page in your Subtext installation.

To learn more about the application, check out the Subtext Project Website.

Powered By:

Blog Stats

  • Blogs - 715
  • Posts - 31071
  • Articles - 310
  • Comments - 106438
  • Trackbacks - 591062

Bloggers (posts, last update)

Latest Posts

Kanban Board–Massimizzare il flusso

Come accennato nel post precedente sulle Split Columns della Kanban Board in VSO, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è:

Maximize Throughput while Minimizing Inventory and Operating Expense.

In questo post vorrei fare una precisazione sul concetto di Flusso e Throughput, di centrale importanza per il metodo Kanban. Se avete letto The Goal sapete benissimo che uno degli scopi principali di una azienda è fare soldi, punto! Sembra cinico, ma senza un flusso di cassa costante, potete avere delle idee bellissime, essere innovativi, brillanti, ma sicuramente avrete difficoltà nel realizzare le vostre idee.

Nel software, quando andiamo a declinare il metodo Kanban, che ricordo essere nato in un contesto manifatturiero (Toyota), bisogna capire cosa intendiamo con il termine throughput. Facciamo però prima un semplice ragionamento in ambito manifatturiero, pensando ad una azienda che produce elettrodomestici. Supponiamo che la azienda usi Kanban, il flusso sia ottimale e le linee di produzione lavorino in maniera efficiente, i colli di bottiglia sono stati individuati, etc etc.

La domanda interessante che ci si deve porre è questa: se si vuole massimizzare il flusso dell’azienda, bisogna definire in maniera inequivocabile quale sia lo stato finale della nostra Kanban board, altrimenti rischiamo di non trovare colli di bottiglia. Facciamo un esempio in cui consideriamo come ultima colonna della Kanban lo stato “imballato”, che identifica quando il nostro elettrodomestico è stato imballato e pronto per la vendita.

Possiamo da subito capire che probabilmente questo non è corretto, se per qualche ragione il nostro magazzino non è efficiente, rischiamo di accumulare prodotti in magazzino senza essere in grado di farli pervenire ai distributori. In questo modo, se il magazzino è il collo di bottiglia, esso non verrà individuato, e ci accorgeremo dei problemi quando gli elettrodomestici “imballati” non hanno più posto dove essere stoccati.

Ok! Per risolvere consideriamo come ultima colonna Kanban una nuova colonna chiamata immagazzinamento, in questo modo se il magazzino diventa saturo, essendo Kanban un metodo pull, le linee di produzione dovranno fermarsi, dato che il magazzino non è più in grado di accettare pezzi. Anche in questo caso, se in alcuni periodi dell’anno quel tipo di elettrodomestici si vede di meno (frigoriferi in inverno), rischiamo di riempire il magazzino perché i grossisti non hanno bisogno di nuova merce.

Piano piano ci si rende conto che idealmente, l’ultima colonna Kanban per la nostra azienda fittizia, dovrebbe essere “venduto al cliente”. Ora è chiaro che ragionare in questi termini è decisamente difficile, ma se nel nostro monitoraggio del processo non consideriamo che il nostro elettrodomestico deve essere venduto ad un cliente finale, si rischia di non vendere, non fare soldi, e fallire.

Tornando quindi al concetto iniziale: Throughput!! Se seguiamo le indicazioni di Goldratt, dobbiamo accertarci che quando parliamo di flusso, stiamo includendo tutti gli stadi fino a quello che ci permette di fare soldi per far vivere l’azienda!

Cosa implica questo in Kanban applicato ai processi software? Che nella nostra Kanban Board, l’ultima colonna deve essere, per lo meno, Usabile in Produzione, ovvero il software deve essere rilasciato e disponibile al cliente finale. Se ci dimentichiamo di questo, rischiamo di accumulare una grande quantità di lavoro “finito” ma che non è usabile dal cliente/utente finale, e che quindi non può generare soldi.

Ricordate quindi che in Kanban la massimizzazione del flusso è fondamentale ed è altrettanto fondamentale che nel flusso si considerino tutti gli stadi, dall’idea alla produzione!

In realtà nemmeno questo alla fine è realmente sufficiente e capiremo perché nel prossimo post.

Gian Maria.

posted @ 21/03/2015 12.11 by Gian Maria Ricci

How to assess, communicate and manage uncertainty and risk with Agility?



The thought that disaster is impossible often leads to an unthinkable disaster.

Gerald M. Weinberg

Doubt is not a pleasant condition, but certainty is absurd.
Voltaire



Every time there’s a good business opportunity to develop a new product or evolve an existing one, executives want to know required investment amount, expected ROI and probability, and risk involved.

Therefore product and development teams are asked to figure out if the new product or product evolution is technically feasible, how long it will take to implement, how much it will cost, when will be finished, and how much risk and uncertainty is involved.
Then Project/Release/Iteration manager will present a release plan where time, effort and costs estimation are expressed with ranges. The degree of uncertainty and the level of risk determines amplitude of the estimations range.

As result, the degree of uncertainty and the level of risk will impact the investment decision, budgeting, governance of products portfolio, release plan, and external customer where one is involved.

 



How to assess and communicate risk and uncertainty

Visualising and communicating risk and uncertainty with agility it means to do that in a lightweight form that’s quick and simple to understand, easy to constantly and frequently update, and straightforward to iteratively enact.
This is very different from heavyweight approaches for documenting risks with long documents that quickly become outdated, often remain unread and very seldom if ever lead to timely action.


The lightweight assessment is
constantly and frequently updated
as new learnings and new information emerge


The assessment of risk and uncertainty is typically done after initial high-level identification of features and user stories and after initial high-level effort estimation. The assessment is then updated periodically as new learnings and new information emerge.
A high-level way to assess and visualise the overall degree of uncertainty and the level of risk consists in categorising the implementation of the new product or the evolution of the product as an Exploration type of work or as a Production type of work.



Investing more time detailing upfront requirements,
specifications and design wont reduce risk or uncertainty



- Production type of work is characterised by known problems and known solutions. It occurs when implementation work is similar to previous implementations. As a result it has very low degree of uncertainty and very low level of risk. Estimation ranges can be narrow because of low estimation errors expected.

- Exploration type of work is characterised by high level of uncertainties and unknowns in the problem and/or in the solution, and in the product/market fit. In addition to this, there could be plenty of things outside the area of control or influence that can change anytime impacting the success of the implementation and of the product. For this type of work, investing more time detailing upfront requirements, specifications and design wont reduce risk or uncertainty.

There’s a continuum between the very low risk and uncertainty production type of work and the high risk and uncertainty exploration type of work.






Different opinions and different points of view
are invaluable sources of information,
therefore are encouraged and explored


Product and development teams’ members that will do the actual work, should collectively vote where they think the current implementation work stands, placing each one a dot between the two extremes, discussing whenever they see differences among their votes and revoting after the discussion. In case of persistent differences in opinion among team members, it’s advisable to raise the level of risk & uncertainty. This evaluation can alternatively be done by team's Product Owner together with the Tech-Lead and the Project/Release/Iteration Manager.



Actual effort or scope can be up to 4 times the initial estimate



For an implementation work estimated to be on the extreme left-end, a pure exploration type of work, the estimation error can be up to 300% of the initial estimate. In other words the actual effort or scope can be 4 times the initial estimate. For a pure production type of work the estimation error can be 5-10%. While for an implementation work that stands in the middle, the estimation error can be up to the 50%. For examples see the Cone of uncertainty, based on research in the software industry and validated by NASA's Software Engineering Lab.



How to detail and explain risk and uncertainty

When executives and managers want to know reasons behind estimated overall risk and uncertainty level, when product and development teams want to improve the assessment accuracy, when they want to verify their assessment or present it in more detail, it’s useful to drill down into these three main risk and uncertainty components:

1) people and market
2) domain and requirements
3) technology and architecture

For each component the level of risk and uncertainty can be rated Low (green), Medium (amber) or High (red) and presented, for example, like this:






The following lists break down each of the three main risk and uncertainty components into multiple elements. While discussing the elements, new elements specific to teams’ and product context and circumstances could emerge and should be added to the list.


The elements in the lists below are placeholders
to provoke discussions and provide basic guidance


Note that the elements in the lists are placeholders to provoke discussions and provide basic guidance. A team experienced in dealing with risk, uncertainty and complexity would probably start with empty lists and populate them throughout discussions.



1) People and market





2) Domain and requirements





3) Technology and Architecture





Each element of the lists should be discussed one at time by the product and development teams to rate the level of risk and uncertainty.

The rating of each element should be given for example considering historical data, or absence of historical data, listening to professional judgment of team members, and considering the weight of each element in the current context and circumstances.  Whenever there are differences among team members' estimate, there should be a discussion to learn from each other point of view, and after that a re-estimation. In case of persistent differences in opinion among team members, it’s advisable to raise the level of risk & uncertainty.


This approach should help to rate the overall level of risk and uncertainty for each of the three components and explain reasons behind each rating.


Every new information, findings and learnings
are used to verify, validate, update and enhance
results and decisions from previous stages


From those estimations and from the conversations that lead to the estimations, product and development teams should be able to re-vote where the current implementation work stands in the continuum between the production type of work and the exploration type of work, considering possible interactions among the components, and producing a more accurate assessment.

Tip: Keep it simple! Update the assessment frequently using new info and new learnings available over time.




How to manage high risk and high uncertainty

When work required to deliver a new product, or a product evolution, is expected to be mostly of Exploration type, estimation of costs, effort and time are expressed with extremely wide ranges and with estimation errors up to 300% of the initial estimate (for examples, see the Cone of uncertainty mentioned before). Therefore a linear upfront investment based on initial estimate for Exploration type of work is hazardous.



Small experiments and prototypes
are designed, built, deployed and tried out

with real users, early adopters and customers
in hours, days, or few weeks



In these cases it’s more convenient an initial exploration phase with the goal to identify and reduce main risks and uncertainties by exploring the problem space, testing assumptions, validating the solution, verifying product/market fit, clarifying the scope, and learning new info.

During the exploration phase an experimental approach is adopted: shortest possible experiments are designed and executed to gather data with minimum effort, and smallest possible prototypes are built, deployed and tried out involving as much as possible real users, early adopters and customers. Each is done in the space of hours, days, or few weeks. One of these experiments is the minimum viable product or MVP.


Investment decision and estimates
are finalized only after the end of the
exploration phase



An exploration phase ends only when risk and uncertainty are reduced enough so that a good, informed investment decision become possible. For an overall effort of one year, the exploration phase could last, for example, 2 months.





After exploration phase, sometimes estimates still have a wide range and estimation errors are up to 30-50%. I.e. the development time could be estimated in the range of 6 to 12 months.


Low priority requirements can be used as a safety net
to deal with residual risk and uncertainty



When this happens it’s particularly convenient to prioritise the requirements in the backlog using the MoSCoW prioritisation method in order to use the requirements classified Should as a safety net.

Here the best case scenario forecast, that assumes the highest velocity of the team, will include in the scope requirements classified as Must together with requirements classified as Should.
The worst case scenario forecast, that assumes the lowest velocity of the team, will include in the scope only requirements classified as Must.
As a result, in this example, the initial estimation range of 6 to 12 months, that is 6 months wide, is turned into a range of 6 to 8 months, only 2 months wide.






After a short period of time
from the beginning of the implementation work,
the investment decision and estimates
are verified against real progress



After about two months of work implementing the solution, it’s worth to observe the trend of team’s velocity:
  • When the velocity is stable or converging and is inside the ballpark, a new more accurate estimation can be done and plans can be updated accordingly.
  • When the velocity is stable outside the ballpark, this is a sign that investment decision should be re-evaluated.
  • When the velocity is diverging outside the ballpark, this is a sign that there could be still risks and uncertainties that need to be explored extending the exploration phase.

Conclusions

This lightweight, gradual, iterative approach to assess, communicate and manage uncertainty and risk is a simple and effective way to monitor and react timely to a variety of circumstances that impact investment decisions, budgeting, governance of products portfolio, and release planing. It also encourages and supports conversations on risk and uncertainty between executives, managers, product and development teams, and customers.

It is based on current lean/agile literature and on personal experience.

The mechanic of this approach is simple. In addition to it, few organisation cultural traits and leadership mindset characteristics are useful to make it work: transparency, trust, teamwork, and tolerance for experimentation.

If you are interested into the topics discussed in this post, those four suggested readings are for you:
  • Book: Lean Enterprise: How High Performance Organizations Innovate at Scale. Jez Humble, Joanne Molesky, and Barry O’Reilly. 2015
  • Article: 4 Significant Ways to Improve Your Ability to Innovate. Joanne Molesky. 2015
  • Book: Agile Project Management: Creating Innovative Products (2nd Edition).  Jim Highsmith. 2009
  • Article: A Leader’s Framework for Decision Making. David J. Snowden, Mary E. Boone. 2007

 

Thanks to Maurizio Pedriale and Carlo Bottiglieri for their help in the review of the draft of this post.

posted @ 14/03/2015 22.23 by Luca Minudel

Continuos integration di un proggetto OpenSource su github con Travis CI

Ho conosciuto recentemente Travis CI un servizio di continuous integration integrato con github. Così ho deciso di sperimentarlo con il mio primo progetto open source...

Integrazione con Travis CI

Risultato

Adesso ogni commit al sorgente del mio repository scatena una corrispondente build e l'esecuzione dei test automatici.

I risultati dell'ultima build (del branch master) sono visibili graficamente dalla pagina principale del mio progetto github...

FxCommon - Readme - First Travis CI integration

posted @ 21/03/2015 15.44 by Marco Baldessari

Frontend life with or without Visual Studio?

Un anno fa scrissi sul mio blog inglese una serie di post dal titolo "the road to Visual Studio free frontend development", nei quali spiegavo - partendo da un caso reale - il perchè e il per come avessi abbandonato Visual Studio come strumento per lo sviluppo del frontend, in favore di un editor di codice e strumenti Open Source come Npm, Bower e Grunt.

A Redmond non hanno sicuramente letto i miei post, ma probabilmente hanno fatto alcune riflessioni analoghe poichè Visual Studio 2015 (in parte già Visual Studio 2013) ha cambiato rotta integrando e supportando nell'ide questi tool.

Se fino ad un anno fa la domanda del titolo - per me - sarebbe stata retorica, adesso la risposta non è più così scontata; la settimana prossima ci saranno i Community Days 2015 in cui avremo lo spazio per provare a trattare questi temi e darne una risposta.

 

posted @ 19/03/2015 14.41 by Gianluca Carucci

TFS2015 Build vNext

Nel lontano 2010, TFS2010 introduceva una nuova build, basata su Workflow Foundation, la quale andava a rimpiazzare la vecchia build di TFS 2008 basata su script MSBuild.

Personalmente debbo dire che ho sempre preferito la vecchia versione del 2008, soprattutto per la facilità di estensione. Mentre per Workflow Foundation è necessario usare Visual Studio ed addentrarsi in un designer non proprio semplice, personalizzare una build MSBuild è una operazione piuttosto semplice, alla fine si tratta solamente di file xml.

Chiaramente XML non è il linguaggio migliore per creare uno script, per cui nel corso degli anni molte persone hanno abbandonato questa strada a favore di Powershell, sicuramente più flessibile ed estendibile. Una build infatti non è altro che una sequenza, quasi sempre lineare, di operazioni da eseguire partendo dai propri sorgenti per ottenere dei risultati (build, test, deploy, etc) e quale migliore scelta dell’esecuzione di una serie di script PowerShell per definire una build?

Per questa ragione in TFS2015 la build è stata nuovamente modificata, per adattarsi a queste nuove richieste e sicuramente risolverà molti problemi emersi negli anni passati con l’attuale struttura di build. Dedicherò quindi una serie di post alle novità della build, cosi da potervi mostrare cosa ci aspetta nella prossima versione di TFS.

Build web experience

La novità più succosa e la prima che amo descrivere, è che tutta la configurazione e la gestione della build è completamente web. Niente più necessità di Visual Studio per editare una build, basta andare nella nuova voce di menu Build vNext e potrete gestire tutto dal vostro browser preferito.

image

Premendo il bottone per aggiungere una build viene subito presentata una possibile scelta tra due template già pronti, uno per una solution di Visual Studio, ed un altro per eseguire la build di Xcode.

image

Fin da subito possiamo quindi vedere che l’altra grande novità riguarda il fatto di poter avere agent di build che girano anche su macchine non Windows. La configurazione degli agent sarà appannaggio del successivo post, per cui non ci soffermeremo ora su questo aspetto.

Se scegliamo la build di Visual Studio si aprirà un editor web da cui si può configurare ogni aspetto della build.

image

Il primo tab da impostare è quello del Repository in cui basta selezionare repository git che volete utilizzare. Per questa CTP ancora è possibile solamente eseguire build vNext su team project basati su Git, nella versione finale si potrà usare anche TFVC.

image

La cosa interessante è che si può usare la build vNext per compilare qualsiasi repository git, anche su gitHub se necessario. La default Branch indica quale è la branch che verrà compilata di default per le build accodate manualmente.

Il successivo tab sarà quello dei Triggers, su cui si può indicare se si desidera la Continuous Integration (build ad ogni change), se si vuole accorpare più commit in un unica build (Batch changes) e chiaramente la possibilità di specificare tutte le branch che si vogliono monitorare, ad esempio in questo caso ho chiesto di monitorare ogni branch che comincia per feat-.

image

Una volta impostato il repository, si può direttamente fare il browsing da web per scegliere la o le solution che si vogliono compilare.

image

Nel tab dei test basta introdurre una regular expression che identifica gli assembly di test ed il gioco è fatto. Se si vogliono eseguire test differenti da MsTest, si hanno due scelte, la prima è specificare il percorso relativo dove trovare i test adapters, operazione che potete effettuare direttamente nelle opzioni del task di test.

image

Se invece usate nunit in tutti i vostri progetti e si vuole evitare di personalizzare ogni build di ogni progetto, si può andare nelle macchine dove è installato l’agent, aprire la cartella dove è localizzato il test runner di visual studio e copiare al suo interno i test adapters dopo averli scaricati dalla gallery di Visual Studio.

image

A questo punto si è creata una build minimale che esegue Build e Test run, interamente da interfaccia web con pochi semplici click. Se nell’installazione di TFS 2015 avete scelto di configurare il build agent automaticamente, potete direttamente lanciare una build e verificare che sia tutto ok.

image

Come si può vedere la build viene eseguita e potete verificarne l’output ed il progresso direttamente dall’interfaccia web.

Gian Maria.

posted @ 07/03/2015 10.46 by Gian Maria Ricci

MissMatch

Pattern matching for JavaScript inspired by one of the great features of the Haskell language.
https://github.com/pb82/MissMatch

posted @ 16/03/2015 16.41 by Alessandro Gervasoni

Libro gratuito su OWIN: OWIN Succinctly

image_thumbSono lieto di annunciarvi che é appena stato pubblicato il libro che Ugo Lattanzi ed io abbiamo scritto su OWIN.

Dal titolo OWIN Succintly, il libro parla di OWIN, le specifiche open per l’interoperabilitá tra web servers e applicazioni .NET.

OWIN é anche l’ispirazione che, tramite Katana, ha contribuito alle fondamenta di ASP.NET vNext (5), quindi questo libro é un ottimo spunto per iniziare a “pensare” vNext giá con la versione attuale del framework, o semplicemente se volete vedere come portrebbe essere il futuro.

Il libro comincia con le specifiche OWIN, per poi andare a vedere come Microsoft le ha implementate in Katana. Prosegue poi con alcuni tutorial a passi che mostrano come usare Katana da solo e coi vari framework web (WebAPI, SignalR, MVC, Nancy), esamina come usare l’autenticazione in OWIN e finisce con un capitolo piú avanzato, su come sviluppare Middleware custom.

Per leggere il libro é sufficiente andare sul sito Syncfusion, registrarsi, e scaricare il libro, sia in formato PDF che Kindle (.mobi).

Spero che il libro vi sia utile, e nel caso abbiate feedback, non esitate a contattarmi via twitter o con il form di contatto.

posted @ 16/03/2015 14.38 by Simone Chiaretta

Novità di VSO Sprint 79

Come sempre potete leggere tutte le novità sul blog di Visual Studio Online, precisamente a questo indirizzo, ma per chi si fosse perso il post, ecco le novità che sono ora disponibili. In questo sprint il team si è focalizzato nel risolvere alcuni issue di UserVoice che hanno un numero elevato di voti e che sono quindi sentiti come molto importanti da parte della community. Questo significa che, come sempre dico a tutti, il team legge i suggerimenti di User Voice, per cui se qualche cosa non vi soddisfa, quello è il posto migliore per dare i vostri suggerimenti.

Finalmente, dopo tanto tempo, ecco arrivare il parametro @currentIteration, che vi permetterà di fare delle query sui Work Item assegnati alla iterazione corrente. Purtroppo questo parametro non funziona in Excel.

Le novità più importanti riguardano però la Kanban Board, la quale supporta ora il riordinamento delle card, operazione molto importante per la prima colonna, che rappresenta il BackLog.

La modifica più importante è però l’introduzione della Definition of Done per le colonne della Kanban Board. Tornerò sull’importanza di questa funzionalità in un successivo post.

Un’altra importante aggiunta è la possibilità di visualizzare i bug come task nella Taskboard e considerarli logicamente figli dei vostri requisiti.

Come potete vedere il team di Visual Studio ALM continua, sprint dopo sprint, a migliorare il prodotto.

Happy VSO.

Gian Maria.

posted @ 12/03/2015 19.42 by Gian Maria Ricci

bignumber



A JavaScript library for arbitrary-precision decimal and non-decimal arithmetic.
https://github.com/MikeMcl/bignumber.js/

posted @ 11/03/2015 12.51 by Alessandro Gervasoni

[AngularJs] $http passaggio dati

 $http({
              method: 'POST',
              url: url,
              data: data,
              headers: { 'Content-Type': 'application/x-www-form-urlencoded' }
          }).success(function (result) {

              });

posted @ 11/03/2015 12.40 by Alessandro Gervasoni

[AngularJs] Conditional logic in AngularJS template

IF CONDITION

<div
ng-if="condition">
<div>{{object.property}}</div>
</div>

SWITCH

<div ng-switch on="selection" >
<div ng-switch-when="settings">Settings Div</div>
<span
ng-switch-when="home">Home Span</span>
<span
ng-switch-default>default</span>
</div>

posted @ 10/03/2015 14.33 by Alessandro Gervasoni

CQRS: “A” come de-normalizzazione asincrona

Nelle nostre divagazioni su CQRS di qualche tempo fa abbiamo parlato di eventualmente consistente ma non ci siamo addentrati nelle implicazioni tecniche che eventualmente consistente porta con se. Qualche, più di qualche, divagazione tecnica la approfondisco sul mio blog in inglese parlando di Jason che è un toolkit che ho scritto per eliminare dai pensieri dello sviluppatore tutta la parte infrastrutturale.

In uno scenario come il seguente però abbiamo un piccolo problema nel momento in cui la parte di de-normalizzazione è asincrona:

image_2

Supponendo una Single Page Application in cui i comandi arrivano via HTTP avete il seguente flusso:

  1. Invio del comando in POST;
  2. Ricezione del comando e gestione dello stesso da parte del back-end;
  3. Broadcast dell’evento;
  4. Invio della risposta HTTP-200;
  5. De-normalizzazione;

Oppure “peggio” ancora in caso di gestione asincrona anche dei comandi:

  1. Invio del comando in POST;
  2. Ricezione del comando e dispatch dello stesso su una coda;
  3. Invio della risposta HTTP-202;
  4. Ricezione del comando e gestione dello stesso da parte del back-end;
  5. Broadcast dell’evento;
  6. De-normalizzazione;

In entrambi i casi quello che per il client determina che la richiesta è stata portata a termine è l’evento non il fatto che il comando sia stato completato, come ad esempio nel primo caso, perché dal punto di vista del client non è detto che tutto quello che si aspetta di trovare sia ancora pronto o che la semplice esecuzione del comando inviato abbia effettivamente portato a termine il tutto.

La domanda a questo punto è: deve per forza essere asincrono?

La risposta ovviamente è no, nulla è per forza :-), ma renderlo sincrono introduce un interessante violazione di un principio base: un evento è nel passato e immutabile, pubblicato da un publisher nel totale disinteresse dei subscriber.

“nel totale disinteresse dei subscriber” è la parte importante.

Il rischio è quello di “infilare” gli handler di un evento nello stesso processo/thread di chi pubblica quell’evento facendo si una cosa totalmente fuori dal controllo di chi pubblica abbia conseguenze incontrollabili e imprevedibili proprio su di lui.

Nelle prossime puntate:

  • CQRS: “C” come “Conversation Id”;
  • CQRS: “N” come “notifiche”;

posted @ 05/03/2015 14.01 by Mauro Servienti

Transparency

Transparency is a minimal template engine for jQuery
http://leonidas.github.io/transparency/

posted @ 04/03/2015 12.30 by Alessandro Gervasoni

Kanban Split Column

Finalmente in Visual Studio Online sono stati introdotti alcuni miglioramenti alla Kanban Board, che per lungo tempo era stata lasciata senza sensibili miglioramenti. In questo ultimo update di VSO è stato introdotto una funzionalità realmente fondamentale, che aumenta di molto la possibilità di usare realmente la Kanban Board in TFS/VSO.

Il cambiamento di cui sto parlando è l’introduzione delle Split Columns, ovvero la possibilità di suddividere ogni colonna in due sotto-colonne, rispettivamente Doing and Done. Vediamo il perché questa funzionalità è cosi importante.

Si parte da un presupposto: Kanban è un processo PULL, in cui ogni stadio decide di prendere in carico una card dallo stato precedente, se e solo se non ha raggiunto il suo limite e se tutte le regole sono soddisfatte (regole aggiuntive e Definition of Done). Questo è il segreto e la base su cui poggia Kanban, ogni stadio inizia a lavorare su un task solamente se ha modo di farlo. Questo viene fatto per evitare ingorghi nel processo e per massimizzare il flusso. Lo strumento principale di Kanban è la Board, che deve permettere immediatamente di individuare i problemi affinché il team possa affrontarli.

Ora analizziamo la situazione seguente:

image

La situazione rappresentata ci dice che: le colonne di Analysis e Committed sono attualmente piene (3/3), quindi non è possibile aggiungere del Work In Progress a nessuna delle due colonne. La domanda che ci si pone è: lo stadio di Analysis non può prendere in carico nessun nuovo item, ma i tre item che sono attualmente nella colonna sono stati terminati o no?

La risposta alla domanda precedente è di fondamentale importanza. Supponiamo i due casi estremi. Caso A: i tre item nella colonna Analysis sono tutti "in progress” questo significa che la colonna Analysis è in stato di pieno regime. Caso B: i tre item nella colonna Analysis sono completati e pronti per lo stadio successivo, questo significa che la colonna Analysis è paralizzata, dato che non può prendere in carico nuovo lavoro fino a che la colonna successiva (Committed) non prende in carico ancora del lavoro. Purtroppo dalla Kanban Board precedente è impossibile discernere i due casi.

Senza entrare nei dettagli, stiamo toccando quella che è chiamata teoria delle code che stabilisce modelli matematici per predire l’avanzamento in una catena di processi. L’identificazione delle code è fondamentale in Kanban, ed è una delle ragioni principali per l’adozione stessa del metodo.

Il metodo Kanban ha come scopo la massimizzazione del flusso ed in questa ottica l’individuazione delle code è un’operazione di massima importanza.

D’altra parte, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è: Maximize Throughput while Minimizing Inventory and Operating Expense. La declinazione nello sviluppo software non appare sempre semplice, se da una parte è chiara la parte di minimizzare le Spese (Operating Expenses), si può anche intuire la massimizzazione del flusso (Maximize Throughput, concetto su cui tornerò in un post successivo), è difficile capire come minimizzare lo stoccaggio (Minimizing Inventory), dato che alla fine il codice non occupa spazio :).

Kanban ci aiuta a rispondere a questo problema adottando la tecnica dello split column. Nel nostro account VSO, se premiamo il Customize column troviamo una nuova opzione per le colonne.

image

Quello che accade è che ogni colonna viene ora suddivisa in due sotto-colonne, Doing e Done; questo ci permette di iniziare ad individuare le code nel nostro sistema. Vediamo allora come sarebbero rappresentati i due casi precedenti adottando questa nuova funzionalità. Il CasoA: sarebbe cosi rappresentato

image

è chiaro che il sistema sta larvando bene, tutte le colonne sono impegnate e a pieno regime. Il CasoB avrebbe invece una rappresentazione molto differente.

image

Si è creata una coda tra gli stati di Analysis e Committed, dato che abbiamo la colonna Analysis bloccata dal fatto che il lavoro nella colonna Committed non sta proseguendo, per questo non vengono prese in carico (pull) le card terminate in Analysis e questo fa si che la colonna Doing di Analysis sia vuota e bloccata. Tutte le card che sono nella colonna Dona rappresentano infatti card in Coda per lo stadio successivo e possono essere paragonate a quello che Eliyahu Goldratt chiama Inventory in “The Goal”.

Se siamo d’accordo che è necessario minimizzare le code ed evitare che il lavoro si accumuli nelle colonne “done”, senza questa funzionalità, è impossibile capire dalla nostra Kanban Board se siamo nel CasoA oppure nel CasoB e si perde una informazione di vitale importanza.

Un altro valore secondario dello split column è permettere in maniera semplice allo stadio successivo, di capire quali card dello stadio precedente possono essere prese in carico. Senza la colonna Done infatti, quando si libera uno spazio nella colonna Committed, non è ben chiaro dalla Board quali card dello stadio precedente (Analysis) possono essere prese in carico, perché non si ha la distinzione tra ciò che è in corso d’opera e ciò che invece lo stadio precedente ha completato.

Gian Maria.

posted @ 25/02/2015 18.01 by Gian Maria Ricci

“This eagerness to change”

E insomma, un anno fa pubblicavo il mio ultimo post chiedendomi, tronfio come un vero bauscia sa/deve essere, in quale modo avremmo potuto migliorare l’anno successivo. E allora, quest’anno, io e Daniele siamo partiti da un principio ispiratore: “diversity”. Diversity perchè:

  • se il fenomeno startup ha dimostrato di poter essere un game changer in tema sia di scelte tecnologiche sia di approccio allo sviluppo del software (“va veloce e spacca tutto”, ci disse Marco)
  • se la track “business” inserita in agenda un anno addietro ha riscosso un riscontro che ci ha fatto capire che potevamo toglierla dalla “riserva protetta” e renderla un first class citizen anche se i temi sono (apparentemente) slegati dallo sviluppo software in senso stretto
  • se la partecipazione alla CFP di “signorine & giovanotti” cresce ogni anno ed è un toccasana in un settore storicamente prettamente maschile, con alcuni esemplari (io tra questi) per datare i quali qualcuno potrebbe proporre il Carbonio14
  • se anche chi ci ospita (e s[u|o]pporta) da anni mette la barra a dritta e avanti tutta verso Linux e OS X

Beh, allora il cambiamento è l’unica strategia evolutiva sensata (e qui la mia verve agilista va in sollucchero). E quindi:

  • Volevamo le startup? Ecco Xmetrics, che ci viene a raccontare come anche in Italia un tecnico possa avere una idea, capire che la sua preparazione tecnica non è condizione sufficiente per “farcela”, imparare la lezione ed a questo punto trovare un investitore (anche) grazie al quale trasformare la propria idea in realtà. Ah si, ed avere come testimonial un campione olimpico, scusate se è poco. Io per avere una startup finanziata con oltre 1M $ che abbia per testimonial Martin Gore farei carte false, per dire.
  • L’anno scorso abbiamo inserito i “pezzi grossi” in agenda? E allora quest’anno abbiamo pescato dall’altro lato della pozza e portato in Italia un Senior Director di Microsoft Corporation. Ok, sostanzialmente ha accettato poichè interessato a mangiare decentemente per una settimana più che per il prestigio del nostro evento, ma questo è un trascurabile dettaglio di implementazione, oltretutto dotato di access modifier “private” Sorriso
  • Vogliamo scongiurare il ricorso al Carbonio 14? Ed allora anche le tematiche devono guardare avanti e prendere atto di quanto potente sia ormai il “lato consumer della Forza” ed il suo impatto anche sugli scenari applicativi “tradizionali” e quindi in agenda abbiamo: IoT, wearable, Kinect, Docker, Unity3D, Enterprise UX… Oh, io la sessione su Microsoft Band non me la perdo Sorriso

Questo (ed altro) riuscendo però, a nostro avviso, a non snaturarci: .NET, C++, cloud computing, NoSQL, Xamarin, etc sono lì come sempre in fondo, ad esempio, di “roba” come Mono ne parliamo da prima che fosse “cool” farlo.

Cerchiamo, semplicemente, di rendere il take away dei Community Days utile sia nell’immediato sia in prospettiva. Ci abbiamo provato anche quest’anno, venite e diteci se ci siamo riusciti.

Ci vediamo ai Community Days 2015?

Tag di Technorati: ,

posted @ 27/02/2015 9.31 by Andrea Saltarello

Community Days 2015

Ripetete con me “Community Days 2015”:

  • 3 giorni;
  • Circa 90 speaker;
  • Un’agenda incredibile;
  • Totalmente gratuito;

Ci sarò anche io, anche quest’anno e anche quest’anno sono onoratissimo di essere parte di quest’esperienza e anche quest’anno blatererò di qualche cosa :-)

Nello specifico parlerò di database documentali, non uno in particolare questa volta. Accorrete numerosi i posti vanno a ruba!

.m

posted @ 24/02/2015 10.25 by Mauro Servienti

Some love to Kanban Board in TFS

Nell’ultimo update di VSO che è stato effettuato ieri (http://www.visualstudio.com/news/2015-feb-18-vso) sono finalmente state fatte importanti modifiche alla Kanban Board, che era rimasta un po ferma da troppo tempo a mio avviso.

La prima novità è che è possibile aggiungere gli item direttamente dalla board, ma sicuramente la funzionalità piu succosa è la divisione delle colonne in doing e done. Non starò qui a sottolineare l’importanza di questa funzionalità, dato che senza la possibilità di capire quali Item sono realmente fatti e sono pronti per essere presi (pull) dalla colonna successiva, la Kanban board ha poco valore.

Nell’upgrade vi sono anche altre novità, tra cui la possibilità di assegnare piu persone alle test suites, e l’annuncio che le funzionalità di Application Insights saranno migrate nel nuovo portale di azure. Il nuovo link di riferimento per Application Insights è quindi il seguente: http://azure.microsoft.com/en-us/services/application-insights/

Happy VSO e buon fine settimana. Smile

posted @ 20/02/2015 19.37 by Gian Maria Ricci

ASP.NET Identity 2.1

Non nego che sia una bella novità del mondo .net ma la mancanza di informazioni al riguardo è molto alta. Ho impiegato 3 giorni per riuscire ad utilizzarla tra l'altro in un modo molto base. Con il progetto web di default si include già troppo codice che poi va commentato o scommentato. Tutti i messaggi di errore sono hard coded e non sono localizzati... Ho dovuto scaricare da nuget i samples per capire cosa non andava nel mio progetto. Gli stessi samples non funzionano se portati all'interno di un proprio progetto: usermanager e rolemanager nell'initializer vanno recuperati direttamente dallo store invece che dall'owin context. Inoltre non è molto chiaro che non posso creare un mio context ma devo utilizzare l'applicationdbcontext già presente... La ciliegina sulla torta? User.IsInRole(...) che restituisce sempre false. Ma per risolvere questo non vi fornirò alcuna soluzione qui. Inutile provare le soluzioni del lazyloading, spostare codice dal global.asax, commentare i dispose (che nei samples non ci sono), abilitare o disabilita il rolemanager nel web.config, cambiare l'entity framework default factory... vi posso solo dire che centra con il voler rinominare le tabelle relative al login ;)

posted @ 19/02/2015 19.30 by Emanuele Prato

DataDog

Interessante tool di monitoring
https://www.datadoghq.com

posted @ 19/02/2015 8.36 by Alessandro Gervasoni

Code search–In preview su VSO

Il blog di VS ALM ha appena pubblicato questo post in cui viene mostrata una nuova funzionalità, ancora in limited preview, presente su Visual Studio Online, il Code Search.

In un progetto è spesso di vitale importanza poter effettuare una ricerca nel source control, alla ricerca di una particolare porzione di codice, oppure di una classe con un particolare commento, etc. Le nuove funzionalità di ricerca introdotte in VSO permettono infatti di effettuare una ricerca semantica, in cui I risultati vengono suddivisi in base alla porzione di codice dove viene effettuato il match. Ad esempio I risultati ci permettono di dire se il testo cercato è presente in un commento, oppure in una dichiarazione di classe Etc.

E’ anche possibile andare a richiedere direttamente un filtro per restringere lo “scope” della ricerca, Es: class: per ricercare nelle dichiarazioni di classe, oppure comment: per cercare all’interno di un commento. La lista completa è presente nel post del blog sopracitato e la riporto per comodità.

image

Attualmente, data la natura di preview di questa funzionalità, esistono delle limitazioni. Il servizio è disponibile solamente per gli account del Nord America, e per progetti che utilizzano Git; la ricerca viene inoltre fatta solamente nella master branch ed il supporto ai linguaggi è per ora disponibile per C#, C e C++.

Gian Maria.

posted @ 17/02/2015 9.08 by Gian Maria Ricci

Latest Images

From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Foto
From Foto