Tag Archives: DevOps

How to configure access policies to Work Items on Azure DevOps

One of the strengths of Azure DevOps is that it’s very scalable. It can be configured to work for company of all sizes: from small teams of a few people, to a large enterprise with thousands of users.

When we work in complex environment we should follow the best practices to choose how to organize people and projects on our Azure DevOps Organization. This is a great piece of documentation to get started when we work in an enterprise scenario and I recommend reading it.

A general (but please double check if it is suitable for your environment) guideline is to work inside a single project and create many teams.

With this kind of setup is common that customers ask me to provide a way to limit visibility of work-items. This way only some people could access some work items. This is to provide better focus to teams, for example. But your project could have other needs to do this.

Continue reading

Deploy a new IIS Web Site with Azure DevOps Pipelines

I was experimenting with deploying a completely new Web Site to a machine with a brand new IIS installation to see what are the required parameter to do a basic deployment.
I share here my findings.

Continue reading

GLV OnAir Febbraio 2019 – Video Link

Qualche settimana fa GLV ha trasmesso il suo episodio di GLV OnAir di febbraio 2019. La puntata è andata in onda col solito formato di 3 sessioni da 30 minuti ciascuna che elenco qui di seguito:

Improve leadtime and workflow with WIP limits on VSTS

A powerful method to keep or make a customer happy is to satisfy his needs quickly. In our typical very busy day we do a lot of things and this hurts our ability to concentrate and focus. This is true for us individually but this is also true as a team.

Little’s Law

We can improve the response time to our customer by leveraging the Little’s Law:

It is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system. – Wikipedia

L = λ W

For example if our team completes 2 user stories every day (𝜆 = 2) and every user story takes 4 days to be developed (W = 4) we have a system with L = 8 ongoing activities.

If we write Little’s Law like this

W = L / λ

we discover that wait time (W) can be reduced if we reduce L, the amount of ongoing activities at the same time.

VSTS boards and WIP-limits

If you manage your team activities with Visual Studio Team Services (VSTS) you can improve the flow and reduce lead-time by limiting the amount of work in progress in your kanban board.

You can setup the WIP-limits in the board of your Backlogs. Go to Work -> Backlogs and then click on Board.

2.png

As you can see VSTS has the default value of 5 for the Active and Resolved statuses. It means that your team cannot drag more than 5 PBIs in the Active or Resolved column otherwise the number of activities turns red, indicating that your team is doing too much work at the same time.

1.png

Default settings of VSTS

3.png

Too much activities!

You can change the values for to better fit the needs and size of your team by clicking the gear icon in the board and access the settings and then click save.
Of course you can also change the column names and add other statuses as well but we’ll cover this in another blog post.

4.png

Where do I start?

A very low WIP-limit can freeze the activities of your team and it may be very hard to respect. Don’t spend lots of time to calculate or debate about WIP limit: start with number that gives flexibility, plan a meetings two week later and discuss it again. You and your team will find the right balance.

TL;DR

Limiting the work in progress is a powerful way to improve the lead-time of our activities and it’s very cheap, too! It’s a team discipline activity and at the beginning it can be counter-intuitive and hard to respect. When a team is doing too much activities at the same time the quality goes down and the lead-time goes up and rework will be required. If the WIP limits block you from starting a new user story you can pair programming with a colleague or reply to that old e-mail that’s waiting so long.

Picture1.gif

 

Agile@School – episodi otto e nove

Si è concluso oggi il progetto Agile@School presso l’IIS di Rovigo che ha coinvolto alcuni studenti delle classi quinte indirizzo informatica.

pexels-photo-267885.jpeg

Il post di oggi riassume gli ultimi due incontri (l’ottavo e il nono) dove abbiamo portato a termine un’app con Xamarin Forms per accedere a Twitter come output finale.  Continue reading

Agile@School – sesta lezione

Sono ripresi oggi gli appuntamenti all’ITI F.Viola / Marchesini di Rovigo di Agile@School dopo le vacanze: siamo al sesto episodio su dieci. Come ripromesso negli episodi precedenti abbiamo ripreso in mano dei principi Agile/DevOps che negli ultimi incontri erano stati parcheggiati in favore di approfondimenti tecnologici su Xamarin Forms.

Continuous Delivery

Continue reading

3 ways for the DevOps practitioner

We all have to start

Every high-profile software house started somewhere, in the middle of nothing (in a garage?) and with a code-base not so good.

Amazon was a monolithic system that in 2002 started a very smart process of re-engineering that lasted years. LinkedIn underwent a 2-monts full stop of feature development in 2011 to restructure the code-base. Now they are the example to follow. How is it possible? Is it all because they have money? Maybe but that’s not the entire truth.

Screenshot_1

Continue reading

Tempo di attesa

Perché è necessario visualizzare il lavoro e controllare il WIP? Per questo semplice motivo.

Se lavoro 50% del mio tempo si ha che sono libero il 50% del mio tempo. Dato che la definizione di tempo di attesa è data da % tempo occupato / % tempo libero ottengo che => 50% / 50% = 1 unità di tempo è il mio wait time come risorsa se sono occupato al 50%.

Se lavoro il 90% del mio tempo si ha che: 90 / 10 = 9 unità.

Attenzione al punto dell’80%! Da lì in poi si vola all’infinito e oltre!

clip_image004

Se definiamo la nostra unità di tempo come 1h abbiamo che quando chiediamo qualcosa a qualcuno che è impegnato (o libero) al 50% ci impiegherà 1h per prendere in mano la questione. Se la chiediamo a qualcuno che è occupato al 90% ci impiegherà 9h per dedicarsi al nostro problema. Un incremento del 40% del lavoro porta a moltiplicare per 9 il nostro tempo di attesa. Se supponiamo che la nostra richiesta a tale persona/risorsa sia per 1h di lavoro abbiamo che la percentuale di tempo a valore aggiunto (o touch time) è del 10%!

1 ora di lavoro  / (9 ore di attesa + 1 ora di lavoro) = 1h / 10h => 10 %

Per me questo grafico è disarmante per la sua semplicità e per quanto apra gli occhi sull’avere tutte le persone coinvolte in un processo sempre cariche di lavoro.
Pensiamo a un processo che coinvolge due sole persone per un’ora ciascuna e che entrambe siano occupate al 90%. Ottengo che per un lavoro di 2 ore uomo ci vogliono 20 ore di attesa.

Avete mai ragionato su tematiche simili? Qual è la vostra esperienza sui tempi di attesa e quali sono le tecniche che usate per ridurli?

Le tre vie

Archivio qui degli appunti che avevo preso per sintetizzare un po’ di concetti appresi dopo la lettura di The Phoenix Project.

Vengono elencati e brevemente spiegati tre principi cardine che sono alla base del DevOps. Per me DevOps è un termine un po’ troppo inflazionato: qualcosa che fa figo dire adesso perché va di moda. Restano comunque validi i principi enunciati e le pratiche esposte.

La prima via – il flusso

Riguarda il flusso di lavoro da sinistra a destra dal dipartimento Development alle IT Operations al cliente finale.
Per massimizzare il flusso bisogna ridurre le dimensioni dei batch e gli intervalli di lavoro, evitando di passare difetti ai centri di lavoro successivi.
Bisogna ottimizzare per obiettivi globali, non locali per reparto.

Le pratiche necessarie richiedono: continuous build, integration and deployment; creazione di ambienti a richiesta; limitare il WIP; costruire sistemi che sono sicuri e facili da cambiare.

La seconda via – i feedback

Riguarda il costante flusso di feedback da destra a sinistra, in tutti gli stadi del flusso del valore.
Amplificare i feedback per assicurarci di imparare dagli errori (e non ripeterli!). Migliorare i processi di raccolta feedback. Facendo questo si migliora la qualità alla fonte (o dove serve).

Le pratiche necessarie includono “fermare la linea di produzione” quando le build o i test falliscono. Impegnarsi costantemente per migliorare il lavoro oltre che lavorare. Creare test suite automatiche e rapide; creare telemetrie per ambienti di produzione.

La terza via – cultura

Creare una cultura che favorisca: sperimentazione continua che richiede prendere rischi e imparare dai successi e dai fallimenti; capire che ripetere e fare pratica è il prerequisito per la maestria. Rischiare permette di migliorare il nostro modo di lavorare, richiede spesso di fare cose diversamente da come la stiamo facendo da decenni. Il non cambiare non porta a una situazione piatta, ma di declino, perché interviene l’entropia.

Le pratiche necessarie includono creare una cultura orientata all’innovazione e al rischio (in maniera opposta alla paura o al “accettare ordini” senza pensarci); allocare almeno il 20% del tempo ai requisiti non funzionali; costantemente ricordare che i miglioramenti sono incoraggiati e celebrati.