zwinny rational
TRANSCRIPT
®
IBM Rational Software
© 2010 IBM Corporation
Zwinny Rational
Martin Stenkilde, CISSPIBM Rational Tiger Team Leader, CEE
IBM Rational Software
2
Agenda Introduction
Core Agile Development – living Scrum with RTC
Scaling up AgileDisciplined Agile Delivery - Agile in an Enterprise contextAgility@Scale – dealing with scaling factors, beyond traditional Agile
Summary and Conclusions
* Most content thanks to Scott Ambler and Jean-Yves Rigolet…
IBM Rational Software
Agile Methodologies or Religions?
•Scrum •by far the most widely adopted
•Out of the box support in RTC
•Feature Driven Development
•XP•Fairly narrow, development-focused but also useful
•RUP •Tackle risks up front
•Be iterative and adaptive
•Our position is to defuse the religious/brand name debate and focus on the practices
IBM Rational Software
4
Our Practices – the Jazz Way
milestonesfirst
APIfirst
endgame
retrospectives
always havea client
continuousintegration
community involvement
new & noteworthy
adaptiveplanning
continuous testing
consume yourown output
componentcentric
drive with open eyes
validate
reduce stress
learn
enable
attract to latest
transparency
validateupdate
dynamic teams
show progress
enable
explore
validate
livebetas
feedback
signoff
common agile practices
common Open Source practices
scaling-up practices Our unfair advantage
IBM Rational Software
5
Agenda
Core Agile Development – living Scrum with RTC
Scaling up Agile Disciplined Agile Delivery - Agile in an Enterprise context Agility@Scale – dealing with scaling factors, beyond traditional Agile
Summary and Conclusions
* Most content thanks to Scott Ambler and Jean-Yves Rigolet…
IBM Rational Software
Core Agile DevelopmentFocus is on construction
Goal is to develop a high-quality system in an evolutionary, collaborative, and self-organising manner
Value-driven lifecycle with regular production of working software
Small, co-located team developing straightforward software
Disciplined Agile DeliveryExtends agile development to address full system lifecycle
Risk and value-driven lifecycle
Self organisation within an appropriate governance framework
Agility@ScaleDisciplined agile delivery and one or more scaling factors applies:
Team size, GDD, technical complexity, org. complexity, …
Agile Scaling Model (ASM)
6
IBM Rational Software
7
Core Agile Development
Core Agile Development
IBM Rational Software
Example Team: Rational Team Concert for Z/OS
DevelopmentBeijing, China
DevelopmentPornichet, France
Mgt, DevelopmentRaleigh, US
UASan Jose, US
DevelopmentAustin, US
Arch, DevelopmentParis, France
DevelopmentPerth, Australia
ResearchHaïfa, Israel
Rational Team Concert
SCM
Work Items
Build
3
4
2
6
103
8
1
37 developers
IBM Rational Software
9
Our (old) 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
Teamawareness
Buildawareness
Projectawareness
IBM Rational Software
Drinking our own Champagne
• RTCz development project– Self hosting on System z
• Access from Jazz.net– ‘RTCz for System z Project’– Iterative, based on the Scrum
template• Geographically Distributed
Development team– 4 main Scrum teams
• RTP (Raleigh, US)• FASL (France & Australia)• BF (Austin, US)• UA (San Jose)
• 2 parallel development lines– No code maintenance– Main development
• Release v2.0• Post v2 development
– Product Delivery
IBM Rational Software
Scrum applied
•RTCz development process
•Based on the standard Scrum process template
•Roles: Stakeholder, Product Owner, Scrum Master, Team Member
•Artifacts: Work Items, Product Backlog, Sprint Backlogs
•Minor process adaptations
•New role: PMC (Project Management Council - based on Stakeholder role)
•New Minutes work item
•Updated permissions
•PMC can update Plans
•Limited operations for externals
•New automatic tasks when joining a team
•[Joining a Team] Update your calendar with your Scheduled Absences
•[Joining a Team] Update your Work Environment
IBM Rational Software
Sprint planning detailed
First days of each Sprint
Sprint directions from Product Owner
Analyze Stories with the Architects
All Scrum team members are involved
1 Sprint planning per Scrum team
Check time budget
Verify absences in RTCz
From Product Backlog...
Query Work items
Team members try to fully understand User Stories with the help of the Architects
Give estimates using the Planning Poker technique
...To Iteration Plan
Fill Sprint backlog with selected Stories based on team velocity and priorities
IBM Rational Software
Continuous Integration Rational Build Forge
Rational Team Concert Daily builds are a good start
Agilists update and test their code constantly
Therefore they need to build the system constantly
Compile Regression testing Static code analysis
Critical points: Must be automated Don’t forget database integration Need a protocol for automatically
deploying builds to higher-level sandboxes
Doesn’t mean that you’re deploying into production every 2 weeks
IBM Rational Software
Share & build source codeIntegration Streams and flows
Integration Streams and flows
Build definitionsBuild definitions
Source code ComponentsSource code Components
Pending updatesPending updates
Build resultsBuild results
IBM Rational Software
15
Regular Deployment of Working Software
How many projects have you seen that: Were “90% complete” for
months? Delivered wonderful plans but no
software? Delivered wonderful models, but
no software? The only accurate measure of
software development is the delivery of software Deliver something at the end of
each cycle/iteration Iterations should be short At all points in time stakeholders
can see what they’ve gotten for their investment to date
Rational Build Forge
Rational Team Concert
Rational Method Composer
RMC Practices: Iterative Development
IBM Rational Software
16
RTCz V2 Development Rhythm
Monthly Sprints
9 iterations
Initial iteration (training, envt set up,...)
5 development iterations
All Sprints include FVTs
End-game & Cleanup
Including SVTs, TVTs, GVTs
3 phases in all development iterations
Planning (2-3 days)
Development
Stabilization (3-4 days)
IBM Rational Software
17
Test/Behavior Driven Development (TDD/BDD)
Add a test
Run the tests
Make a littlechange
Run the tests
[Fail]
[Fail]
[Pass]
[Developmentstops]
[Developmentcontinues]
Rational Build Forge
Rational Team Concert
Rational Application Developer
Automated acceptance testing drives your detailed requirements efforts
Automated developer testing drives the detailed design of the system
Tests form the majority of your detailed specifications
You’ll still need some high-level models to provide overviews
This is the first time in IT history that developers are motivated to keep the specifications up-to-date
An example of single sourcing information
IBM Rational Software
18
Agenda
Scaling up Agile Disciplined Agile Delivery - Agile in an Enterprise context Agility@Scale – dealing with scaling factors, beyond traditional Agile
Summary and Conclusions
* Most content thanks to Scott Ambler and Jean-Yves Rigolet…
IBM Rational Software
19
What is disciplined agile delivery?
Disciplined agile delivery is an evolutionary (iterative and incremental) approach that regularly produces high quality solutions in a cost-effective and timely manner via a risk and value driven lifecycle.
It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders.
Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
“Fits just right” processContinuous testing and validationConsistent team collaborationRapid response to changeOngoing customer involvementFrequent delivery of working solutions
Core Principles
IBM Rational Software
The disciplined agile lifecycle: An extension of Scrum
IBM Rational Software
21
Agile Requirements ManagementRational Team Concert
Rational Requisite Pro
Rational Requirements Comp
RMC Practices: Requirements Management, Use-Case Driven Development
Requirements are prioritized by stakeholders
Requirements are estimated by the development team
Requirements will evolve throughout the project
Stakeholders see working software each iteration
Stakeholders can change the level of funding as appropriate
Stakeholders determine when “enough is enough”
Rational DOORS
IBM Rational Software
22
Agile Model Driven Development (AMDD) Rational Design Tools
Rational Requirements CompRational Requirements Composer
RMC Practices: Shared Vision, Evolutionary
Architecture, Evolutionary Design, TDD,
Component Software Architecture
IBM Rational Software
23
Concurrent, Independent Testing
Rational Testing Tools
Rational Team Concert
Rational Quality Manager
Independent Testing
Const.Iteration…
Const.Iteration
TransitionIteration(s)
Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing
Defects must be prioritized and put back on the team’s work stack
Defects == Requirements
Scales TDD: TDD is a form of confirmatory testing. TDD is a great start, but it’s not the full testing picture
Critical strategy for addressing non-functional requirements
IBM Rational Software
Coordinate our tests in RQM
All defined in Rational Quality Manager
FVT, SVT & Performance Test Plans
Defined by developers
During the Stabilization phase
Executed by all members
Developers, release engineer, ..., and even managers
Test execution records
Creating Defects on execution failure
Formal reviews
Test cases approvals by Product Owner & ScrumMasters
Metrics & charts on quality presented at Sprint stakeholders meetings
Test case design
Test case design
Execution reportExecution report
IBM Rational Software
25
Domain Complexity
Straight-forward
Intricate,emerging
Compliance requirement
Low risk Critical,audited
Team size
Under 10developers
1000’s ofdevelopers
Co-located
Geographical distribution
Global
Enterprise discipline
Projectfocus
Enterprisefocus
Technical complexity
HomogenousHeterogeneous,
legacy
Organization distribution(outsourcing, partnerships)
Collaborative Contractual
Agile scaling factors
Disciplined Agile
Delivery
Flexible Rigid
Organizational complexity
IBM Rational Software
Agile inhibitors – we can help overcome…
IBM Rational Software
27
Geographical Distribution
Distributed teams Increase communication risk Increase risk of delivering the wrong
product Leverage people in disparate locations Require greater discipline Require improved tooling
Best practices Initial architecture envisioning Invest in travel Invest in communication/collaboration
technologies
Rational Build Forge
Rational Team Concert
Rational Method Composer
Rational Requirements CompRational DOORS
IBM Rational Software
Collaborate using Work items and Plans
Instant collaboration / share contextInstant collaboration / share context
Various levels of work planification
Various levels of work planification
Discuss/exchange work with members
Discuss/exchange work with members
IBM Rational Software
29
Team Size Large teams
Increase management complexity Increase communication overhead
Best practices Initial architecture envisioning Architecture drives team organization Architecture ownership team Program management team Stakeholder team Requirements management
Rational Build Forge
Rational Method Composer
Rational Asset Manager
Rational Team Concert
Rational Quality Manager
Rational DOORS
IBM Rational Software
Check the project status & health
Burndown chartsBurndown charts
Various project health dashboards
Various project health dashboards
Team communicationTeam communication
IBM Rational Software
31
Regulatory Compliance
Recognize that this is a reality for many teams
Best practices Read and understand the regulations Automate as much as possible Embed compliancy into your culture Lean development governance
Rational Team Concert
Rational Policy Tester
Rational Quality Manager
Rational DOORS
IBM Rational SoftwareIntegrating with existing Governance systems Highly regulated industries require strict control, auditability, archive…
Rigorous Change Management
Auditable builds, archives..
May require integrating with existing CM, SCM, and Build systems
Teams can do their daily work in more agile tools and deliver to the “mother ship” as needed
Bridges can be automated or manual
Our example team does this with our formal support system
Corporate Repositor
y
Scrum Repo
IBM Rational Software
33
Technical Complexity Complex applications
Are the norm, not the exception Legacy systems and data sources are
often less than perfect Legacy asset owners struggle with agile
approaches
Best practices Multi-disciplined teams Multi-disciplined people – Generalizing
specialists Code refactoring Database refactoring Iterative development Continuous integration Short iterations
Rational Design Tools
Rational Build Forge
Rational Asset Manager
Rational Testing Tools
Rational Team Concert
Rational Quality Manager
Rational DOORS
IBM Rational Software
Managing Technical Complexity – Tracking AdoptionsThe RTCz team builds on the Jazz Foundation
Jazz Foundation architectural changes and API evolution need to be coordinated across adopters
The Jazz teams have instituted formal Adoption tracking
IBM Rational Software
35
Agenda
Summary and Conclusions
…
IBM Rational Software
Walker Royce’s Top Ten Agile Principles for Success1. Reduce uncertainties by addressing
architecturally significant decisions first.
2. Establish an adaptive life-cycle process that accelerates variance reduction.
3. Reduce the amount of custom development through asset reuse and middleware.
4. Instrument the process to measure cost of change, quality trends, and progress trends.
5. Communicate honest progressions and digressions with all stakeholders.
6. Collaborate regularly with stakeholders to renegotiate priorities, scope, resources, and plans.
7. Continuously integrate releases and test usage scenarios with evolving breadth and depth.
8. Establish a collaboration platform that enhances teamwork among potentially distributed teams.
9. Enhance the freedom to change plans, scope, and code releases through automation.
10. Establish a governance model that guarantees creative freedoms to practitioners.
http://www.drdobbs.com/architecture-and-design/222300750
IBM Rational Software
37
Agile does scale, and IBM Rational can help
In addition to the development practices of Scrum and other Agile methodologies, Disciplined Agile Delivery practices can help deliver complex software and systems in a repeatable and predictable way.
Rational provides tools that support these practices.
Rational and our customers are using these tools to successfully scale Agile in many different dimensions.
Delivering greater value from your investments in software
IBM Rational Software
38
© Copyright IBM Corporation 2010. All rights reserved.
The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.
IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
IBM Rational Software
39
Resources
Agile/Scrum
Agile Manifesto: http://agilemanifesto.org/
Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development
Wikipedia: http://en.wikipedia.org/wiki/Scrum
Scrum Alliance: http://www.scrumalliance.org/
Scrum Community: https://scrumcommunity.pbwiki.com/
Rational agile development: http://www-01.ibm.com/software/rational/agile/
IBM Rational Team Concert for System z
Jazz community: https://jazz.net/projects/rational-team-concert-z/
Articles & papers:
In tune with IBM Jazz and IBM Rational Team Concert entreprise development tools, by JY. Rigolet: http://www-949.ibm.com/software/rational/cafe/docs/DOC-2943
Easier, faster collaborative development by globally distributed teams, series by R. Radcliffe: http://www.ibm.com/developerworks/rational/library/09/rationalteamconcertsystemzjazz1/index.html
Drinking our own Champagne – In the concert of RTCz development, by JY. Rigolet: http://jazz.net/library/presentation/393