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 at...
3
The Scrum Framework in 30
seconds
• A product owner creates a prioritized wish list called a product backlog.
• During s...
4
Scrum terminology
We've introduced some new terms in describing the Scrum framework. Let's look at them in more detail.
...
5
What is Kanban
Kanban is a new technique for managing a software development process in a highly efficient way. Kanban u...
6
Kanban Example
Kanban reveals bottlenecks dynamically
Kanban is incredibly simple, but at the same time incredibly power...
7
What move us to think about something
else…
The model most frequently applied in project management is called Waterfall ...
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 ...
10
Curve your Enthusiasm
Gallotti Stefano © - http://www.galoz.it
11
Let’s start to do it
Gallotti Stefano © - http://www.galoz.it
Upcoming SlideShare
Loading in …5
×

Agile survival kit

863 views

Published on

Agile Survival kit
A short description of main concepts referring to Agile Thinking

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
863
On SlideShare
0
From Embeds
0
Number of Embeds
453
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile survival kit

  1. 1. 1 Agile Survival Kit Gallotti Stefano © - http://www.galoz.it
  2. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 8 Move to Sprints Gallotti Stefano © - http://www.galoz.it
  9. 9. 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. 10. 10 Curve your Enthusiasm Gallotti Stefano © - http://www.galoz.it
  11. 11. 11 Let’s start to do it Gallotti Stefano © - http://www.galoz.it

×