1
Agile Survival Kit
Gallotti Stefano © - http://www.galoz.it

Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a
fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti:
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
2
Manifesto per lo Sviluppo Agile di Software
Ovvero, fermo restando il valore delle voci a destra,consideriamo più importanti le voci a sinistra.
I principi sottostanti al Manifesto Agile
• La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
• Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del
vantaggio competitivo del cliente.
• Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi
brevi.
• Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
• Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di
portare il lavoro a termine.
• Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.
• Il software funzionante è il principale metro di misura di progresso.
• I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere
indefinitamente un ritmo costante.
• La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità.
• La semplicità - l'arte di ottimizzare la quantità di lavoro non svolto - è essenziale.
• Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
• A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
http://agilemanifesto.org/
Gallotti Stefano © - http://www.galoz.it

3
The Scrum Framework in 30
seconds
• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to
implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to
assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store
shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
Gallotti Stefano © - http://www.galoz.it

4
Scrum terminology
We've introduced some new terms in describing the Scrum framework. Let's look at them in more detail.
Scrum is made up of three roles, four ceremonies, and three artifacts.
Three roles
Product owner: responsible for the business value of the project
ScrumMaster: ensures that the team is functional and productive
Team: self-organizes to get the work done
Four ceremonies
Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint
Daily scrum: the team meets each day to share struggles and progress
Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint
Sprint retrospectives: the team looks for ways to improve the product and the process.
Three artifacts
Product backlog: ordered list of ideas for the product
Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint, broken
into tasks
Product Increment: required result of every sprint. It is an integrated version of the product, kept at high
enough quality to be shippable.
Gallotti Stefano © - http://www.galoz.it

5
What is Kanban
Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-
time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the
underlying mechanism for managing the production line can still be applied.
A software development process can be thought of as a pipeline with feature
requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an
informal ad hoc process to a highly formal phased process. We assume a simple
phased process of:
(1) analyze the requirements,
(2) develop the code
(3) test it works.
The Effect of Bottlenecks
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.
Using development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to
produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.
If the analysts and developers aren't aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the
pipeline ties up investment, creates distance from the market, and drops in value as
time goes by.
Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting
bugs released into production cause problems for the users and waste future pipeline
capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources
to help relieve it. For example, the analysts could help with testing and the developers
could work on test automation.
But how do we know where the bottleneck is in any given process? And what happens
when it moves?
Gallotti Stefano © - http://www.galoz.it

6
Kanban Example
Kanban reveals bottlenecks dynamically
Kanban is incredibly simple, but at the same time incredibly powerful. A kanban system consists of a big board on the wall with cards or
sticky notes placed in columns with numbers at the top.
The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of
each column are limits on the number of cards allowed in each column.
The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress
(WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before
they get out of hand.
The board shows a situation where the developers and analysts are being prevented
from taking on any more work until the testers free up a slot and pull in the next work
item. At this point the developers and analysts should be looking at ways they can help
relieve the burden on the testers.
We’ve split some of the columns in two, to indicate items being worked on and
those finished and ready to be pulled by the downstream process. There are
several different ways you can layout out the board. This is a fairly simple way.
The limits at the top of the split columns cover both the "doing" and "done"
columns.
Once the testers have finished testing a feature, they move the card and free up
a slot in the "Test" column
Now the empty slot in the "Test" column can be filled by one of the cards
in the development "done" column. That frees up a slot under
"Development" and the next card can be pulled from the "Analysis"
column and so on.
Gallotti Stefano © - http://www.galoz.it

7
What move us to think about something
else…
The model most frequently applied in project management is called Waterfall (composed of 6 steps)
1. Description (vague and rough) of project requirements
2. Evaluation and estimation of effort and resources required
3. MONETARY OFFER TO THE CUSTOMER (often "out of the box", all inclusive and without variations possible)
4. Functional analysis (where you begin to understand what was wrong in step 2)
5. Architectural analysis (where the doubts of phase 4 become certainty)
6. Development & Test (where the disaster assumes irreparable proportions)
If for a moment we make the assumption of being able to do without the “Estimation", we can imagine a process of Project
Costing & Estimation effective and, above all, beneficial for all parties (win-win).
This process is an iterative process that takes place within a "sprint" of time.
Gallotti Stefano © - http://www.galoz.it

8
Move to Sprints
Gallotti Stefano © - http://www.galoz.it

9
Grooming
A well-groomed product backlog facilitates the development of a successful product:
It incorporates the team’s learning, and provides items that are ready to be implemented.
But when should grooming take place?
Option 1: Grooming Takes Place before New Development Starts
Groom the product backlog before any new development work starts. This includes obtaining feedback from
users and customers, analysing it, integrating the learning into the backlog, and getting the product backlog
ready.
Option 2: Grooming Takes Place after New Development has Started
Continue the development work while you are collecting and analysing the user feedback. Choose this option if
you do not require the user data to continue developing your product, doing more coding without having first
analysed the user feedback does not imply a significant risk of taking your product in the wrong direction..
Gallotti Stefano © - http://www.galoz.it

10
Curve your Enthusiasm
Gallotti Stefano © - http://www.galoz.it

11
Let’s start to do it
Gallotti Stefano © - http://www.galoz.it