Advanced Software
Engineering –
Agile Software Engineering
Basic direction
A „agile“ method has to be
Incremental
Cooperative
Easy
Adaptive
Based on Abrahamsson et al 2002
A method is called agile if it follows the principles of the agile manifest.
Based on Haneberg 2009
The agile manifest
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan That is, while there is value in the items on
The twelve principles
Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles
The twelve principles
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
The twelve principles
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.
Réalisez les projets avec des personnes motivées.
Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
La méthode la plus simple et la plus efficace pour
transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
The twelve principles
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Un logiciel opérationnel est la principale mesure d’avancement.
Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir
The twelve principles
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle
The twelve principles
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its behaviour accordingly
Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
The agile manifesto – focused statements
Process and tools Individuals and
interactions over
Following a plan Responding to
over
Comprehensive documentation Working software over
Contract negotiation Customer
collaboration over
What is Scrum?
Scrum is a action in Rugby
The action is complex and have to be planned and orchestrated
Requires disciplined teamwork
Scrum scope
Identify reasons, develop solutions
Identify problems and handicaps early
To perform the correct activities To check the
realisation of requirements inside software frequently
Scrum process
Product increment
Scrum-Philosophy
Requirement for a new version should be minimal
Deliver functionality as fast as possible and frequently
No „Big-Bang“-Release with extensive amount of new functionality
Every sprint create a product increment
Procedure: Identify the lowest number of marketable attributes, which have a real added value
Scrum roles
Roles
Product owner
Scrum master Scrum
Team
Scrum process
Requirement
description Realisation
Common procedure
Requirement description Realisation
Scrum procedure
Sprint 1 Sprint N
Scrum process
Customer End-user Stakeholder
Product Backlog
Scrum Process
Cancel
Gift wrap Return
Sprint
2-4 weeks Return
Sprint goal Sprint
backlog
Potentially shippable product increment
Product
Coupons Gift wrap
Coupons Cancel
24 hours
Sprint review meeting
Daily scrum
Sprint planning
meeting Part 2
Part 1
Backlog task
(worked by the team)
Product Backlog
Not fixed, it is a „living“ document
Iterative an incremental development
Scrum does not know „Change requests“, but the Product Backlog should include changes
All entries should be prioritised and the effort should be estimated
Product Backlog
Product Backlog
Attributes, from the product concept, will be included in the product backlog.
Product Owner group requirements to topics
Product Owner has to set priority to the topic
Product Owner refines the high priority requirements with the team
Actualisation, refinement or cancellation of existing requirement
Inclusion of new requirements
Set priority
Prio Topic Description Acceptance criteria Effort 1 Calendar User wants to create a
meeting
Test the input of false values, e.g. End time before start time
2h
2 Calendar User wants to delete a meeting
Test if a meeting can be delete twice
3h
3 Calendar User wants to change a meeting
Test if changes are applied
1h
…… …… …… …… ……
Requirement workshop
Helpful tool for the identification of requirements
All on one table
Support for a common understanding, a common language and
•Establish a common understanding, language and adequate description
More then one before the first sprint, regular during the sprints, to identify new sprints
Set priority
Why? Relevant things first
Precise refinement on the relevant requirements
Team knows what is necessary for the success of the project and it is focused on this
Setting priority is difficult! Product owner has to know customer requirement, and has to know which function relevant is.
Set priority
Aim of the project is the generation of added values
Primary question: How much added value is created by a requirement
Risk, value, and costs Priority
Set priority
Avoiding First
Last Second
Risk
Value
Low High
Set priority (MuSCoW pyramid)
Must have
Should have
Could have
Scrum process
Product increment
Sprint
Scrum process
Product Backlog
Release planning
Sprint planning
Daily planning Actual progress
and current problems
Release Burn down Chart
Sprints
Standard sprint
Smallest unit, to create an useable product
Time frame is fixed
Max 30 day
Explorations sprint
For trial
Release sprint
For configuration
Sprints
Product Backlog
Conversion activity and
daily scrum
Sprint review and sprint retrospective Improvement
activities
Sprint planning
Sprints
Standards prints
Start with a Sprint planning meeting
Are used in analyse, design, implementation and test phase
Use Agile techniques as TDD, FDD, Pair Programming, Refactoring etc.
Deliver a product at Sprint Review
Support the improvement of process in the Sprint retrospective
Sprint planning meeting
Moderation by scrum master
Sprint aims requirements and
Activity definition
requirements, Add if realisable
Product owner
Sprint Team
Sprint backlog
Priority Requirement To Do In Progress Done
1
2
3
Sprint burn down
Activities
Daily scrum
Max. 15 Min.
Same time
Same place
Moderation by Scrum Master
All have to participate (passive Product Owner)
Organisation, address problems (do not solve it!)
Daily scrum
Preparation:
Sprint Backlog
Sprint Burn down Chart
Three question to everybody:
Work done??
Work planned?
Problems?
Write down all problems
Use speech token if necessary
Sprint review
Approval of work results
Only requirements are discussed, which are completely and error free implemented (no 99% solutions)
~ 1 hour.
Moderated by Scrum Master
All have to participate
Sprint review
Sprint aim
Live-Demo of working result
Product Owner analysis
Product Owner decide
Sprint Retrospective
Aim: Work together to improve the process
When: Direct after the Sprint review
Duration: ~ 1 hour.
Who: all
Moderation by Scrum Master
Sprint Retrospective
Check -In, Jump outside the box
Collect information max. 3 pos. and 3 neg./person – all group
Gain experience, group set priority, how this could happen?
Take decision
Conclusion
Training
SCRUM ON ONE DAY (SOOD)
Rules
We are simulating SCRUM
3 Groups
Aim is to develop a software architecture for program controlling ALL things necessary for the METRO in Paris (Ticketsystem, Train cotnrolling, Timeplan, Web, Mobile access,..)
Simulation
A working task (45 minutes is a day in real life)
SOOD - Initial Steps
Step 0: Decide who is the Product Owner and who is the Scrum Master
Step 1: Make a Requirement Session with the Product Owner ~ 60 Minutens
Find as much requirement as you can find even you cannot focus all today
Make a Product Backlog with Priorities
Create a Burndown Chart
Step 2: Make a Sprint Planning Meeting ~ 15 Minutes
Plan 2 Weeks (Simulation)
Plan 1 Task (UML Diagramm) per Person
Create a Sprint Burndown Chart
Create a Sprint Backlog
SOOD - Daily Scrum
Step 3 - Each person work on your Topics (45 Minutes)
Step 4 – Make a first Daily Scrum Session (15 Minutes)
Product Owner (Passiv)
Scrum Master (Looking at the time and make Notes)
Update your Sprint Backlog with history
Each person should say
Work done??
Work planned?
Problems?
SOOD - Daily Scrum
Step 5: Work on your next topics (45 Minutes)
Step 6: Make a second Daily Scrum Session (15 Minutes)
Step 7: Work on your next topics (45 Minutes)
See Step 4
Step 8: Make a Sprint Review (See slide 39; 20 Minutes)
Step 9: Make a Sprint Retrospective (20 Minutes)
Remember Focus is to make your process better not the product
