Tag Archives: DevOps

Come fare un daily stand-up meeting efficiente in “stile kanban”

Gli standup meeting sono un elemento comune dei processi di sviluppo Agile.

Meeting con kanban
Meeting con kanban

Di solito si fanno al mattino primo di iniziare il lavoro e hanno un formato standard. Uno standup meeting tipico consiste nel chiedere a turno ai partecipanti le tre fatidiche domande:

  1. Cosa hai fatto ieri?
  2. Cosa farai oggi?
  3. Sei bloccato con qualcosa e hai bisogno di aiuto?

Ogni membro del team risponde a queste domande e così il team è coordinato per le attività della giornata.

Con l’adozione di una kanban board le cose si svolgono diversamente.

Non c’è bisogno di chiedere a turno ai partecipanti le tre domande perché la loro risposta è implicita dalla posizione dei kanban sulla lavagna. La lavagna contiene tutte le informazioni su chi sta lavorando a cosa. Chi partecipa regolarmente ai meeting si accorge anche di cosa è cambiato e se qualcosa è bloccato o meno è visivamente evidente.

Perciò il processo è leggermente diverso in ambito kanban rispetto a daily meeting tradizionale. Il facilitatore, di soluto un PM, “attraversa la board”. Per rinforzare il concetto di sistema in tirare/pull, convenzione vuole che la kanban board si legga da destra versa sinistra (al contrario del processo di produzione del valore). Questo perché non ha senso spendere tempo ed energie su cose “a monte” quando “a valle” ci sono problemi che ostacolano il flusso del lavoro. Inoltre, questo aiuta a far rispettare i WIP limit per cui nuove attività non possono iniziare se quelle incorso non liberano il loro posto.

Il moderatore del meeting pone enfasi sugli elementi bloccati (visivamente evidenti per delle convenzioni sui colori). Vengono poste domande sul perché questi elementi sono bloccati e si adotta un approccio proattivo per cercare di sbloccarli il prima possibile.

Dopo aver discusso gli elementi problematici, il team può passare in rapida rassegna gli elementi in lavorazione, ma i team più maturi in questo ambito non ne hanno bisogno.

Questo meccanismo consente di ridurre di molto la durata di meeting, considerando che si parlerà solo di cui c’è bisogno in maniera puntuale. La kanban board per sua natura funge da radiatore di informazioni che, con un minimo di pratica, a colpo d’occhio possiamo interpretare e capire lo stato dell’arte con un semplice sguardo.

Video

In questo video una dimostrazione su come fare! 🙂

Libri di riferimento

Kanban, Succeful Evolutionary Changes for Your Technlogy Business | David J. Anderson | Su Amazon

Personal Kanban: Mapping Work, Navigating Life | Tonianne DeMaria Barry, Jim Benson | Su Amazon

(I link ad Amazon sono link affiliati, il che significa che se vengono acquistati gli articoli tramite quel link ricevo una piccola percentuale da Amazon. Per te non cambia niente.)

GIT LEZIONE 3 – git reset: soft mixed hard – cosa fa

Introduzione

Devi annullare delle modifiche? Devi ritornare a uno stato precedente? Git reset è un comando molto potente che permette di tornare indietro e riscrivere la storia.

I 3 tree di git

Per capire git reset cosa fa, dobbiamo avere ben presente i tre “tree” di git.

  • Working Directory – La cartella di lavoro
  • Index – Il contenuto del prossimo commit che verrà fatto.
  • HEAD – Puntatore al branch attivo.

Git reset –soft

Questa è la prima variante del comando reset. Questa opzione sposta solamente HEAD al commit indicato col comando.

git reset commitid --soft

Git reset –mixed

Questa seconda variante è quella di default, quando non viene specificato altro. In questo modo git opera anche sull’INDEX. Viene quindi eseguito quanto fatto nella variante SOFT e in più viene riportato INDEX al contenuto del commit scelto.

git reset commitid --mixed

Git reset –hard

La terza variante, –hard, aggiunge un ulteriore step a quanto fatto dalla –mixed. Git opera anche nella working folder, riportandola al contenuto del commit indicato.

git reset commitid --hard

Videolezione

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 How to configure access policies to Work Items on Azure DevOps

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 Deploy a new IIS Web Site with Azure DevOps Pipelines

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 – episodi otto e nove

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 Agile@School – sesta lezione

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 3 ways for the DevOps practitioner