Download
1 / 21
210 likes | 235 Views
Continuous Delivery Effective Software Delivery under ridged Business Constraints. Kai-Uwe Maetzel kai-uwe_maetzel@us.ibm.com Chief Architect and Lead of Rational Team Concert IBM Rational. Overview. Product What is cost? Influencing cost Our process.
E N D
Continuous Delivery Effective Software Delivery under ridged Business Constraints Kai-Uwe Maetzel kai-uwe_maetzel@us.ibm.com Chief Architect and Lead of Rational Team Concert IBM Rational
Overview • Product • What is cost? • Influencing cost • Our process • Many of the aspects have been discussed in the software development methodology, project management and management literature. • This is a concrete example of what we doand why.
Rational Team Concert • Team collaboration tool combining • agile and formal planning • task and defect tracking • source code management • build, packaging, deployment, and promotion • dashboards: queries and reports on life and historic data • configurable process • From small teams to large teams of teams • From MS Windows to z/OS • Eclipse, MS Visual Studio, Web, command line, MSSCCI, Window Shell integration, ISPF • Open protocols, numerous integrations
Technologies • Java • modeling technologies for persisted data and wire transfer • C++, C#, .NET • JavaScript, HTML, CSS, Dojo • JDojo • relational databases, SQL • RDF triple stores, SPARQL • REST architecture • REX, DTL • distributed object caches, …. • …
Team Toronto Paris Portland Ottawa Beijing Zurich Boston Tokyo Nantes Costa Mesa Raleigh Bangalore Sydney
Other Facts • IBM Rational’s flagship product • Part of Rational’s Collaborative Lifecycle Management initiative • We develop RTC using RTC with new deployments at least every 4 weeks, but usually once a week • We develop transparently on jazz.net • We are an agile team using a mix of Scrum, XP, Kanban, … evolving since 1999 • strong skill set • Hundreds of builds a day (person, team, team of teams, project) • measure “everything” • … • ~ 80developers • development, L3, release engineering, deployment management, testing
Business Measures • Effectiveness • Expense to Revenue (E/R) • Budget • Development budgetis based on an E/R. • Budget can be adjusted quarterly if deemed necessary but mostly relies on projected revenue. Projected revenue combines historic revenue and market trends. • Budget will become expense.
Execution Measures • Execution goals • Grow revenue • Increase team productivity • Reduce team expense • Execution measures • Projected Revenue Impact of near future work • Team Velocity to Team Expense ratio • measured against the not yet released highest product version • Controllable factors • Selection of future work • Team Velocity • Team Expense
Selection of Future Work: Growing Revenue • Increase number of people who try the product • Increase number of people who tried the product and then buy it • Increase the number of people who bought and then buy more • Decrease the number of people abandoning the product • Controllable factors • Quality perception • Meeting the needs of the customers
Selection of Future Work • Ensure that the top of the backlog is prioritized to sustainably maximize revenue • estimate revenue impact of each backlog item • new revenue, incremental revenue, retained revenue, operational efficiency • revenue overlap between backlog items • work necessary to enable future revenue impacting plan items • reduce technical debt • re-architecting • infrastructure • Short feedback cycles allow for better revenue estimates • Transparency to allow involvement
Team Velocity • Find effective composition and distribution of teams • prioritize co-location • ensure critical mass on all sites • utilize time zone affinities • mix of experience, culture, and skills • Pay upfront to avoid costly unproductive work later on (optimization problem) • customer critsits • customer handholding • maintenance work • educating sales and support teams on already released versions • manual testing • waiting for test machines to be available • waiting because of server down • following stupid processes • Track effort/cost for better future estimation by analogy
Team Expense • Geographic location • Seniority of the team members • Salary levels • Hardware costs • Travel • … • If the revenue is acceptable, all these are superseded by Team Velocity.
Process • Clear core values • Prioritized product backlog of plan items as single source of truth • Quarterly releases • Comprehensive Definition of Done • One Feature Team per plan item • Feature Teams are shielded by Run team • Feature Teams are supported by free-floating outstanding senior technical people • Fully automated build, test, and deployment pipeline • Monitor diligently • Process is clearly communicated
Core Values • Simple. Fast. Elegant. • Seamless task flows. • Best of breed. • Your way. • Deep analysis. • Team focused. • Across teams, functions, projects. • Multi-platform. • Extensible. • Scalable. • Flexible deployment. • Secure. • Safe investment. (Open resource formats and stable APIs)
