Weitere ähnliche Inhalte
Ähnlich wie Upmc tpdev1 (20)
Mehr von Jean-Yves Rigolet (9)
Kürzlich hochgeladen (20)
Upmc tpdev1
- 1. © 2012 IBM Corporation
© 2016 IBM Corporation
Jean-Yves B. Rigolet
IBM France Lab
rigolet.j@fr.ibm.com
Module NI514
En route pour une transformation agile des
équipes de développement
UPMC STL M2 – 2016/2017
- 2. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
2
‘Software development is hard’
Grady Booch
- 3. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
3
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery
- 4. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
4
Traditional/Waterfall Development Model
Models the development process as
moving from one step to the next.
Delays confirmation of critical risk
resolution
Measures progress by assessing
work-products that are poor
predictors of time-to-completion
Delays and aggregates integration
and testing
Frequently results in missing targets
or unused features/products
Code & Unit Test
System Test
Integration Test
Design Requirement
Requirements Def
Concept Definition
Development proceeds sequentially through a series of phases
Acceptance Test
Deployment
Maintenance
- 5. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
V-Model
Extension of the Waterfall model
Coding is central
Meticulous design, development,
and documentation
Often view as too simple, giving a
false sense of security
Like the Waterfall model, It is
inflexible, offering no way to
respond to change
Testing comes late & too tight to
design
Coding
Requirements
Analysis
High Level
Design
Detailed
Specifications
Unit Testing
Integration
Testing
Operational
Testing
- 6. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
6
Realities can stall software delivery
Complexities in software delivery compounded by market pressures
2010 Spending in U.S. on governance,
risk and compliance was $29.8 billion
Increasing
Mandates
62% of projects fail to meet
intended schedule
Unpredictability
in Software Delivery
50% of outsourced projects
are expected to under perform
Globally Distributed Software
and Product Supply Chains
Complex, Multi-platform
Systems and Applications
62% of companies have agile projects
requiring integration with legacy systems
30% of project costs are due to rework
and poor execution of requirements
Changing Requirements
and Time to Market
Cost
Reduction
70% budget locked in maintenance and
37% of projects go over budget
Source: Numerous sources, see speaker notes for details
- 7. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
Coding
So, let's look at the V-Model again
What if?...
Requirement
s Analysis
High Level
Design
Detailed
Specification
s
Unit Testing
Integration
Testing
Operational
Testing
- 8. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
Coding
… We change the way we work
Requirement
s Analysis
High
Level
Design
Detailed Specifications
Unit Testing
Integration
Testing
Operational
Testing
Goal is to reduce risks & costs while delivering better quality software
- 9. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
9
Agile Manifesto www.agilemanifesto.org
February 11-13, 2001, The Lodge at Snowbird ski resort
- 10. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
10
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery
- 11. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
11
Agile software development applied
“Uses continuous stakeholder feedback to deliver high-quality,
consumable code through use cases (user stories) and a
series of short, stable, time-boxed iterations.”
This figure shows the "Four S's" that describe agile in a nutshell.
- 12. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
12
Agile Basics
Agile value-add focuses on:
– Delivering business value early and often in a project lifecycle
– Being able to incorporate requirements as they emerge and are identified as
valid
– Providing frequent delivery of new deployable business value (workable code)
– Leveraging tight, self-organizing teams
– Incorporating customer feedback early in the development cycle
All of these create an environment that can sustain itself over time
rather than experience the peaks and valleys of the traditional
methods, which ultimately tire employees and lower overall quality.
Change should not equal crisis!
- 13. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
13
What Agile software engineering is not...
A waterfall
A Big Bang with limited intermediate opportunities for stakeholder
interaction, code convergence typically late
Rigid, with change requests often viewed as interruptions
Individualistic
Document, process, or design heavy
Plan driven
A trivial cultural transition for many teams
A fad
A silver bullet
- 14. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
14
What Agile software engineering is...
Iterative, typically time-boxed as short iterations
About frequent, sometimes constant, validation with stakeholders
Highly focused on mitigating risks
Adaptive; comfortable with-and even embracing-change and reprioritization
Open (communication, code, process, and so on); a team sport
Communication-intensive (for example, daily Scrums)
Suspicious of non-code artifacts
Aimed at making incremental progress: working software is the measure
Deliberate about reflecting on what works and what does not
Disciplined, scalable, and even workable across sites
- 15. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
15
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery
- 16. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
16
What is Scrum?
An agile software development framework
–Structured in cycles of work called Sprints
• iterative work
• team pull from prioritized customer requirements (User Stories)
• produce a potentially shippable
A simple framework
–3 roles
• Product Owner,
• ScrumMaster,
• and the self-organized team
–3 ceremonies
• sprint planning meeting,
• daily scrum meetings,
• and sprint review meetings
–3 artifacts for prioritizing and tracking tasks
• product backlog,
• sprint backlog,
• and a burndown chart
A piece of cake?...
- 17. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
17
The Scrum roles (1/2)
Product Owner
–Represents the voice of the customer
–Writes user stories, prioritizes them
–Places stories in product backlog
ScrumMaster (or Facilitator)
–Scrum is facilitated by a ScrumMaster,
–Ensure team is functional
–Remove all team impediments to deliver
–Buffer between team and influencers
–Ensure Scrum process is used as intended
Team
–Self-organized
–Responsible to deliver the product
–Made up of 5-9 people with cross-functional skills to do the actual work
Pigs are the ones committed to the project and the Scrum process
- 18. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
18
The Scrum roles (2/2)
Users
–Users of the software being built
Stakeholders (customers, vendors)
–Enable the project & for whom the
project will produce the agreed-upon
benefit(s) which justify it
–Provides feeback
–Involved in reviews
Managers
–People that will set up the environment
for the product development
organizations
Chicken roles are not part of the actual Scrum process,
but must be engaged and provide feedback
- 19. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
19
The Product Backlog
Owned and Prioritized by the Product Owner
Created with Stakeholders and the Delivery Team
Contains the potential work for this release
–Features, Development requirements, Exploratory work, Known bugs
Articulates the product vision
Ideally expressed such that each item shows value to the
customers or users of the product
Contains user stories at both Epic and detailed levels
Is a living list, changes over the course of the release
Is assessed and reprioritized every iteration
- 20. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
20
Dynamics of a Product Backlog
Each Sprint (or Iteration)
is made up of small
automatable chunks
called User Stories
The Product Backlog
holds all the User Stories
until they are ready to be
implemented in a Sprint
Once selected by the
team to go in a Sprint, a
User Story goes into a
Sprint Backlog
- 21. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
21
User Stories detailed
A concise, written description
of a piece of functionality
that will be valuable to a software stakeholder.
As a <role>, I can <goal> so that <business value>
- 22. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
22
Where User Stories Help
Value to stakeholders
–Stories target functionality valuable to stakeholders
–Story demos each iteration keeps stakeholders engaged
Simplified features
–Stories enable light-weight requirements gathering, progressive discovery
–Stories focus on feature essentials
Estimated by the team using story points
Release predictability
–Stories by definition fit in time-boxed iteration
–Stories that fail in an iteration provide early warning system
–Cadence of story completion over multiple iterations will demonstrate
release predictability
- 23. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
23
Why use User Stories?
Right size for planning, works for iterative development
Defer detail until you have the best understanding you are
going to have about what you really need
Focus on user goals rather than feature attributes
Emphasize verbal rather than written communication
–Fixes many issues with “vague requirements”
Comprehensible by both you and the dev team
Stories support evolutionary development
- 24. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
24
User Story Roles
As a <Role>, I want to <Goal> so that I can <Business value>
User role is a collection of defining attributes that characterize a
population of users and their intended interactions with the
system*.
–Avoid “the user”; different stakeholders have different requirements
–Mike Cohn recommends using roles so that you do not “miss” stories
–Teams can develop a set of user roles (personas) to help define relevant
stories
Examples
–As a ClearCase CTO I want Access Control Lists on all my common
objects to provide critical security to my confidential information.
–As a Jazz Admin I want to bulk modify Access Control Lists for multiple
objects to enable security updates for 1000 objects with 2 clicks.
*Source: Software for Use by Constantine and Lockwood
(1999)
- 25. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
25
User Story Goals
As a <Role>, I want to <Goal> so that I can <Business value>
Goal is “what the user role can do”
–Valuable to a stakeholder
–Epics – less specific about the what
–As stories are broken down, the details of what will be delivered
becomes clearer
Examples
– As a BuildForge Administrator I want BuildForge to be able to use virtual
machines for running jobs so that I can maximize the use of my infrastructure
– As a BF Admin I want to identify VMs in the server panel so that I can use existing
VM servers
– As a BF Admin I want a configuration for a static server manifest so that I can
configure VM servers without starting them
- 26. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
26
User Story Business Value
As a <Role>, I want to <Goal> so that I can <Business value>
Business value justifies the value of the story
–Clarifies why a feature is useful
–Can influence how a feature should function
–Helps prioritize the story in the backlog
Why the “so that” Phrase Matters
–As an IT manager I want my Enterprise Content Management system to
be represented as a library in the Windows Explorer interface
–…so that it works with existing Windows applications on my users
desktops?
–…so that it looks like another repository in the Explorer Interface?
–…so that I do not have to train my users to use a new interface?
The real business value requested by the IT departments told
us how to build the interface
- 27. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
27
Overview of the Scrum process
Product Owner
provides
prioritized Stories
Team estimates
Stories
Team moves
Stories to Sprint
Product Owner
sets Sprint goal
Team exchanges
progress in Daily Scrum
Team produces
shippable increment
Team breaks
Stories into Tasks
Team reassesses estimates
‘Chickens’ give
feeback
Team analyzes
Sprint during
Retrospective
- 28. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
28
The Sprint planning meeting
Goal is to get everything ready for the
Sprint
Team meeting
–But stakeholders can silently assist
Filling the Sprint backlog
–The Scrum team takes stories from the Product
backlog
–Break stories into tasks
–Give estimates
The planning poker technique
–All team members simultaneously provides
estimates
–High and low estimators briefly explain why
–Repeat 3-5 times until estimates stop converging
*Planning Poker® Cards
*image from http://store.mountaingoatsoftware.com/
- 29. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
29
Scaling using Scrum of Scrums
Scrum is a good fit for both large and small
teams
Need to add a second level if:
–Several interdependent Scrum teams that need to
communicate
–Several teams working together on a single product,
with inter-dependencies.
Indefinitely scaled through multiple layers
Frequency & presence determined by the team
–Technical contributor
–No need of Product Owner or ScrumMaster, but they
can assist
Are you about to put
something in another
team’s way?
- 30. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
30
Burndown Chart
Burndown charts quickly determine if an
iteration is on track
Accessible to the team
Track work daily during iteration
–Indicates whether or not iteration on track
–Adjust if iteration off track
–Useful in scrum meetings
In practice…
–Burndown will not reach an ideal line
• Work finishes sooner than planned, takes
longer than planned
• More tasks are added, some are
removed,...
–Goal is to handle deviations from the
burndown line
- 31. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
31
Scrum preparation steps for success
• Ready…
Get right people on board & the Scrum roles filled
Fill product backlog & prioritize stories
Development and test environment are ready
Team knows how to transfom product stories into shippable product
increments
• Steady…
The team estimates the product backlog items
The product owner identifies a sprint goal and discusses the related
product backlog items with the team
The team determines its availability
The ScrumMaster prepares the meeting
• GO!
Project set-up for success
First sprint planning meeting can start now
- 32. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
32
Scrum projects can fail
• Failure
– From Wikipedia, the free encyclopedia
« Failure (colloquially fail, phail or flop) in general
refers to the state or condition of not meeting a
desirable or intended objective. It may be viewed as the
opposite of success. Product failure ranges from failure
to sell the product to fracture of the product, in the worst
cases leading to personal injury, the province of
forensic engineering. »
So you need to quickly identify Scrum Smells...
- 33. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
33
Some reasons Scrum projects can fail (Scrum Smells)
Not Acting Like a Team
Talking Chickens
Missing Pigs
Status not clear from Daily Scrums
Lack of Progress
Persistent Signatures
ScrumMaster Assigns Work
The Daily Scrum is for the ScrumMaster
No One Wants to Attend Retrospectives
Executive Pressure
Specialized Job Roles
Testers will not integrate with Team
Team takes complete responsibility for
testing
Reluctance to estimate Backlog Items
Is It Really Done?
Nothing Ever Gets Better Around Here
Consistently Missing Sprint Commitment
No Engineering Practices
Gorilla in the Room
Technical Debt
Let's detail some smells...
- 34. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
34
#1: Not Acting Like a Team
• Fixed Roles
• Tasks are assigned
• Not helping each other
• No mentoring is going on
• Stories aren't shared and all work is being
done in parallel
• No cooperation
• Not listening to (and talking over) one and
another during meetings
• No Laughter - a team that is working well
together often laughs
- 35. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
35
#1: Not Acting Like a Team
• Fixed Roles
• Tasks are assigned
• Not helping each other
• No mentoring is going on
• Stories aren't shared and all work is being
done in parallel
• No cooperation
• Not listening to (and talking over) one and
another during meetings
• No Laughter - a team that is working well
together often laughs
Lead by example, mentor and help
team members with their tasks
Breakdown silos and fixed roles
Help change the Corporate structure
to reward team work and not heros
Encourage pair programming, code
reviews and other practices that
increase co-operation and
communication
Scrum projects gain
efficiency from the Team as a
whole
Example
Remedies
- 36. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
36
#2: Talking Chickens
- animated -
Stakeholders talk in Daily Scrums
Features selected outside of sprint
planning meetings
Team cannot make purely technical
decisions without an outsider’s
blessing
Status reports are required outside
sprint planning meetings
Executive sponsors try to influence
the team
Product backlog languishes or is
ignored
- 37. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
37
#2: Talking Chickens
- animated -
Stakeholders talk in Daily Scrums
Features selected outside of sprint
planning meetings
Team cannot make purely technical
decisions without an outsider’s
blessing
Status reports are required outside
sprint planning meetings
Executive sponsors try to influence
the team
Product backlog languishes or is
ignored
Consistently enforce the no talking
rule
Conduct training as part of project
start
Negotiate rules at project start
Use retrospectives to reinforce
expectations
Move chickens away from the pig pen
Change the meeting time and place
Maybe the chicken can lay an egg
Become a barnyard dog
Scrum member living the pain
of a bad technical decision
vs.
outsiders who feel compelled
to make decisions for a team
Example
Remedies
- 38. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
38
#3: Missing Pigs
• Unclear expectations?
• Competing assignments?
• Lack of commitment?
• Supervisory interference?
• Weariness?
• Fear?
- 39. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
39
#3: Missing Pigs
• Unclear expectations?
• Competing assignments?
• Lack of commitment?
• Supervisory interference?
• Weariness?
• Fear?
Role model
Change meeting time and location
Explanation, persuasion, and
negotiation
Embrace technology
Reorganize the team
Face-to-face meetings over
paper systems
Example
Remedies
- 40. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
40
#4: Loss of Rhythm
Inconsistent Daily Scrum ritual
Daily Scrums skipped
Meeting times vary
Inconsistent Sprint durations
Sprint duration changes arbitrarily mid-
sprint
Inconsistent Sprint planning ritual
Skipping Sprint planning meetings
- 41. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
41
#4: Loss of Rhythm
Inconsistent Daily Scrum ritual
Daily Scrums skipped
Meeting times vary
Inconsistent Sprint durations
Sprint duration changes arbitrarily mid-
sprint
Inconsistent Sprint planning ritual
Skipping Sprint planning meetings
Be consistent
Avoid noise during Scrum and focus
on delivery
Clarify expectations
Conduct training
Be consistent
Resort to mommy rules
Rhythm helps make routine
things routine
Example
Remedies
- 42. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
42
#5: Lack of Progress
• Backlog keeps growing instead of shrinking
• Too much work in progress
• Features never get finished
• The 90 percent complete syndrom
• Revision or repair on “Completed” features
• “Completed” features waiting on
uncompleted features
• Stakeholders complaining about lack of
progress
• Missed deliveries
- 43. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
43
#5: Lack of Progress
• Backlog keeps growing instead of shrinking
• Too much work in progress
• Features never get finished
• The 90 percent complete syndrom
• Revision or repair on “Completed” features
• “Completed” features waiting on
uncompleted features
• Stakeholders complaining about lack of
progress
• Missed deliveries
A backlog with early visible progress,
early visible value, and on-time
completion
Features of great value to the
customer that are easy to construct
A “zero-defect” product
Commitment at all times to a
“potentially shippable product”
A willingness to ask, “If it does not
deliver useful working code, what
good is it?”
Realization that bugs are not
inevitable
Good Sprint backlog
management
Example
Remedies
- 44. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
44
#6: ScrumMaster overdrives the work
• Work is assigned by the
ScrumMaster rather than signed
up for by developers
• Team not in control of their work
• The Daily Scrum feels like it is a
status update from the team
members to the ScrumMaster
- 45. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
45
#6: ScrumMaster overdrives the work
• Work is assigned by the
ScrumMaster rather than signed
up for by developers
• Team not in control of their work
• The Daily Scrum feels like it is a
status update from the team
members to the ScrumMaster
Let the Team in control of work
Team define assignments
Daily Scrum by and for the team
Self-organization is one of the
underlying principles of
Scrum
Example
Remedies
- 46. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
46
#7: Specialized Job Roles
• Project team has highly specialized job
roles or descriptions such as:
– Architect,
– Designer,
– DBA,
– or Tester,…
• Team includes dedicated “testers”
• Scrum teams doesn’t show a “we’re all
in this together” attitude
• Scrum team does not need to be
comprised entirely of generalists
- 47. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
47
#7: Specialized Job Roles
• Project team has highly specialized job
roles or descriptions such as:
– Architect,
– Designer,
– DBA,
– or Tester,…
• Team includes dedicated “testers”
• Scrum teams doesn’t show a “we’re all
in this together” attitude
• Scrum team does not need to be
comprised entirely of generalists
Work assigned only by Team
Daily Scrum to re/assign work
Each specialist must accept general
responsibility for the system as a
whole
“I’m going to do whatever I can to
help” attitude
“We’re all in this together”
attitude
Example
Remedies
- 48. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
48
#8: Reluctance to estimate Backlog
• Individuals guessimating
• No re-estimate during Daily Scrum
• Team refuses to play the planning
poker technique
- 49. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
49
#8: Reluctance to estimate Backlog
• Individuals guessimating
• No re-estimate during Daily Scrum
• Team refuses to play the planning
poker technique
(Re-) do release planning with whole
team
Make release burn-down visible
Retrospective focus on the difference
release targets and estimation
Focus estimation on an area in which
there is the clearest need for it
Use estimation to identify uncertainty
Plan spikes for areas of uncertainty
Retry estimation, review uncertainty
Make commitments based on
estimates
Review how team met commitments
Missing releases or
substantial feature reduction
tracking
Example
Remedies
- 50. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
50
#9: Executive Pressure
• Executive's demand the team
commit to releasing a set of
"minimum" features by a certain
date.
• Executive's attend the team's
meetings
• Executive's communicate directly
with team members to remind them
of deadlines
- 51. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
51
#9: Executive Pressure
• Executive's demand the team
commit to releasing a set of
"minimum" features by a certain
date.
• Executive's attend the team's
meetings
• Executive's communicate directly
with team members to remind them
of deadlines
Speak privately with the Executive
and suggest that their approach is
likely to have the opposite of the
desired effect
Ask the Executive what they really
need and use that to help guide the
team
Get the Product Owner to negotiate
priorities with the Executive
To support it, commitment
has to come from the Team
Example
Remedies
- 52. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
52
#10: Gorilla in the Room
• One person (Sr Developer, Tech Lead,
Executive) dominates conversations
and meetings
• People won't speak until the Gorilla
has spoken
• Team members defer to the Gorilla's
opinion
- 53. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
53
#10: Gorilla in the Room
• One person (Sr Developer, Tech Lead,
Executive) dominates conversations
and meetings
• People won't speak until the Gorilla
has spoken
• Team members defer to the Gorilla's
opinion
Gorilla to speak last on any issue
Ask the Gorilla to ask questions rather
than making statements
Is the Gorilla a required attendee?
Ask to be absent for a meeting or two
In the case of stakeholder it may be
necessary to ask to permanently
leave meeting (since even without
speaking they can have tremendous
impact on the team)
The wisdom of the Team
vs.
the beliefs of a single person
Example
Remedies
- 54. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
54
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery
- 55. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
55
Test Driven Development (TDD)
Overview of the TDD
practice
Method to design software,
not just a testing method.
1) Technique where a test case
covering a code change or new
functionality is written first.
2) Then just enough code to
make the test pass is
implemented.
TDD requires automated
unit tests
*From Kent Beck, author of the book Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002
2 simple rules*
– Never write a single line of code
unless you have a failing
automated test.
– Eliminate duplication.
- 56. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
56
Test-driven development cycle
TDD is a programming practice in which all production code is
written in response to a test. The cycle is as follows:
1) Pick one of the requirements in your requirements list and write a test.
2) Run the test to make sure it fails. It's easy to inadvertently write a unit test
that passes without putting the code in that implements the requirement. A best
practice is to ensure the test fails before the implementation code is written.
3) Add or modify just enough code to make the new test and all previous tests
pass. You will not run all of the tests in the project, but you will run all of the
tests in the given class or package.
4) Once the new test and all the previous tests pass, refactor the code if
necessary to "eliminate code smells" such as duplicated code.
5) Then, write another test.
6) Keep going until requirements are met.
7) When needed, refactor the code to “eliminate code smells”, like duplicated
code, and fix any broken tests before adding any new functionality.
- 57. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
57
Continuous Integration (CI) Main Characteristics
Set of software development practices, behaviours and principles
CI objectives:
– For automating and improving the integration and validation of software
continuously
– Allowing engineers can detect and fix problems early
– To deliver quality software
CI enables development teams to:
– Reduce risk
– Improve efficiency
– Generate deployable deliverables at any time
–Enable transparent view of project health
– Establish greater confidence in the software product from the development
team
- 58. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
58
Walk-through of a Basic Continuous Integration
Implementation
1) An engineer picks up a new piece of
work (a defect or a new feature)
2) The engineer changes code and
satisfies themselves that the code seems
to work.
3) Once the engineer is satisfied that the
code is unlikely to break any other code,
the engineer is ready to commit/check-
in/deliver their unit-tested code to the
source code repository.
4) The engineer checks whether either they need to fix the broken build (a top
priority) or they can move on to their next task/defect.
5) Builds can be scheduled to run a complete set of test suites against the latest set
of changes.
- 59. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
59
All Continuous Integration Practices (1/2)
Build
–The team can initiate a build on-
demand
–The team can initiate a build
without human intervention
–A build runs whenever code is
integrated
–The build fails if any test or
inspection fails
–Broken builds are fixed as soon as
possible
–The compilation and packaging of
your build are automated*
–Keep the build fast*
Code and Unit Test
Coding and design standards are
enforced
Developers write automated unit tests*
Developers check-in unit tested code
Developers integrate code frequently *
Static analysis is part of the build
Deployment
Avoid getting broken code
Automated deployment is in the build*
* Those practices above indicated by an asterisk are recommended by Martin Fowler in his paper on Continuous Integration.
- 60. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
60
A More Typical Continuous Integration Cycle
- 61. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
61
Agenda
Evolution of software delivery
Agile software development
Scrum & scrum smells
Agile pratices: TDD & CI
Scale & govern software delivery
- 62. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
8 Years Ago: Our Pain Points…
joining a team
get my environment configured to be productive
what is happening in my team
collecting progress status
following the team’s process
ad hoc collaboration/sharing of changes
starting an ad hoc team
is the fix in the build?
run a personal build
tracking a broken build
why is this change in the build?
reconstructing a context for a bug/build failure
interrupting development due to a high priority bug fix
working on multiple releases concurrently
tracking the code review of a fix
referencing team artifacts in discussions
how healthy is a component?
collecting project data/metrics?
keeping plans up to date
Boring and painful
Team
awareness
Build
awareness
Project
awareness
- 63. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
Canada
Toronto,Ottawa
,Montreal, Victoria
London/Staines
Milton Keynes
Hursley
Warwick
York
Haifa
China
Beijing
Shang Hai Yamato
Taipei
Paris
Pornichet
Beaverton
Kirkland
Seattle
Foster City
San Francisco
SVL/San Jose
Almaden
Agoura Hills
El Segundo
Costa Mesa
Las Vegas
Rochester
Boulder
Denver
Lenexa,KA
Tucson
Pheonix
Austin
Dallas
Andover
Bedford, MA
Bedford, NH
Lexington
Westborough
Westford
Cambridge
Cork
Dublin
Galway
Boeblingen
India
Bangalore
Pune
Hyderabad
Gurgaon
Cairo
Rome
Gold Coast
Sydney
Canberra
Fairfax
Raleigh
Charlotte
Lexington, KY
Atlanta
Boca Raton
Tampa
Perth
Krakow
Warsaw
Sao Paulo
Malaysia
Delft
Stockholm
Pittsburg
Poughkeepsie
Princeton
Somers
Southbury
NY, NY
Singapore
Helsinki
El Salto
Over 150 Rational development projects
(~2800 users) using Rational Team Concert
Plus an additional 700+ projects around IBM
-- hosting 8500+ users!
Boarding time for new projects -
less than one day
Applicable to agile/iterative and
waterfall projects
Rational Development
Rational Customer Support
WebSphere Development
Lotus Development
Tivoli Development
IBM Research Division
IBM Global Business Services
IBM Systems and Technology
Group
Agility @ scale at IBM
- 64. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
64
- 65. © 2016 IBM Corporation
2016
La transformation agile des équipes de développement
TPDEV
IBM & le développement logiciel d'entreprise
65
Team work
3 team members
7 weeks following agile principles
Using TPDEV resources & knowledge
User story:
As a student, I can use a collaborative app so that
I can get valuable tips for my studies