Agile Team Development with Jazz at Rational Software Comes 2You
Update on IBM Rational Strategy on Agile Team Development with Jazz.
RSC2U-Jazz
Download session material
Update on IBM Rational Strategy on Agile Team Development with Jazz.
RSC2U-JazzAre you a part of a global development with distributed development teams across geographic regions and timezones? Or are you part of a small local teams with members across departments, workflows and objectives? Regardless of your organisational type we can help you achieve your objectives as individuals and as a team. The Jazz technology is designed to meet your needs and ensure your project success.
JazzFestival_WhatIsJazzApplication Lifecycle Management is an integral part of the Ericsson development processes. IBM Rational tools form a key component in the Ericsson ALM development process and tool chain.Rational is using a scenario based approach, the Greenthreads, to drive our Solution Strategy and to identify, document and test our end-to-end workflows and cross-product integrations. Green Threads is an approach to solution management and validation that; ‘Captures workflows across a set of products to solve a complex customer problem’ and move our organization beyond point product thinking
This presentation will team discuss the benefits of Collaborative ALM. Examples will be taken from the new Rational ALM Redbook covering continuous integration between stakeholders, integration between distributed team roles and team functions, and integration between development teams and the enterprise software delivery chain using an agile at scale approach.
This year Bob Myers and I present our experiences regarding scenarios and practices for an integrated Application Lifecycle Management solution using the ClearQuest ALM schema and the Jazz products Rational Team Concert and Rational Quality Manager. We also present experiences from developing and deploying such solutions to Rational internal Development Operations.
More details on the CQALM schema has been published at IBM DeveloperWorks in Application lifecycle management with Rational ClearQuest: Part 1, Part 2 and Part 3.
CRMA45This session will present the new C/ALM integrations for Enterprise Change Management between Rational ClearQuest, Rational Team Concert and Rational Quality Manager delivered in 2009. Scenarios from the CALM@Scale greenthread will be used to exemplify the improvements in cross team collaboration, transparency and openness. The session will also discuss deployments of the ClearQuest Bridge Connector, OSLC server communications, and role-based usage examples of the ClearQuest Dashboard viewlets.
ERUC09-EnterpriseCM_and_CALMDesign studio like group session to validate SSE solu4on scenarios, key personas and UX storyboards. We will deep dive into the areas of 2014 design exploration of SSE lifecycle scenarios developed by the Ra4onal Design Factory. Product line engineering. Requirements lifecycle change. And Impact analysis.
Innovate2013-2650_SSE_Solution_validation_and_design_playbackThis session starts by listing the roles presumed involved in the SSE solution.Key scenarios for practitioner productivity are discussed. Design improvements are presented and reviewed with the attendees. Areas of additional practitioner productivity discussed.
Innovate2013_BOF-2597_Designing-Practitioner-ProductivityIn this IBM® Redbooks® publication, we provide a blueprint for Collaborative Application Lifecycle Management (CALM) and show how the new IBM Rational® products support this evolving market. Driven by the business demands of global software delivery, many large organizations are seeking guidance in how to incorporate agile methods.
In this book, we provide a reference scenario and tool architectures for deploying the new IBM Rational products into an existing enterprise environment. We also provide a set of blueprints that define each of the key disciplines in the development life cycle to help you understand the domain and how the Rational products support the need of that discipline. Our primary focus is to highlight the value of CALM by providing a user view of the solution that is used to support a distributed enterprise development team that incorporates aspects of the “Agility-at-Scale” approach.
While most Redbooks publications provide details about a single product, this book provides a “green-thread” reference scenario that details one end-to-end path through an iteration of a software development project. The scenario demonstrates a reference architecture for an enterprise that uses the new Rational Jazz technology-based products along with the existing Rational team products. The scenario includes Rational Build Forge® Enterprise Edition, Rational ClearCase®, Rational ClearQuest®, and Rational RequisitePro®, and introduces Rational Quality Manager, Rational Requirements Composer, Rational Software Analyzer, and Rational Team Concert.
The leading ALM solution from IBM is the Collaborative Lifecycle Management (CLM), which consists of Rational Requirements Composer (aka Rational DOORS NG), Rational Team Concert, Rational Quality Manager and Rational Design Manager. The Jazz platform is strategic for implementing the Rational solution for CLM. The Jazz platform is all about collaboration; it allows individual products to integrate better and more easily, and allows the users of those products who take on distinct roles to work more effectively together than has historically been possible. The Jazz platform supports a more collaborative approach to ALM tools and their users. The approach is open. It leverages the standards used by the Internet. Just as the internet works with data spread around the world, the approach is to allow development team data to be spread around an organization, and yet to have development artefacts as easily accessible as surfing the world-wide-web. Through the support for OSLC, integrations can be provided for Jazz-based products. Additionally, third party vendors and customers can consume or provide their own OSLC interfaces to support heterogeneous environments made up of Rational, third party, and/or customer solutions. The combination of Jazz and OSLC provides the ability to have unprecedented collaboration, transparency, automation, and traceability.
The artefact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CQ the complete lifecycle was managed in complex schema. In CALM the state of is distributed over a network of linked and related artefacts. User research on the use of schema based change management systems identified user pain points
Research at our enterprise clients reports on similar pain points in establishing a state schema, resulting in years in negotiating a corporate wide schema in ClearQuest that managed the lifecycle of Change Requests as a single state model.
The artefact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CLM the state of is distributed over a network of linked and related artefacts.
Lets consider an example by walking the structure in the image below
Based on our research we formulated the ‘ALM Principles’ that was validated by our sponsors
In 2009 I co-led the publishing of the CALM Redbook together with Carolyn Pampino and a group or Rational SMEs. The Redbook provides a blueprint for Collaborative Application Lifecycle Management by using an end-to-end reference scenario for deploying the new Rational products and ‘Agility at Scale’ into an existing enterprise environment. The scenarios produced for the Redbook covers Change Management, Requirements Management, Enterprise Integration Builds and Test Management. It also discusses metrics for team success in Application Lifecycle Management.
From this generalised CLM@scale lifecycle we focus the System Delivery scenario on a story in six acts. These acts focus the scenario to exploring key workflows and lifecycle capability requirements of a System Lifecycle Management solution and are designed to answer a primary lifecycle question which is critical to the projects success. The six acts cover aspects configuring project, planning the project, delivering a part of the system, managing changing requirements, stabilizing the system release, and hand-off of the release.
These acts are common to the CLM scenarios. The figure below indicate where specific extensions has been identified to explore system delivery scenes.
Act 1 – Inspect and Adapt. The project admin(s) and the project lead(s) are setting up and configuring lifecycle management for the project. This act covers upgrading the system delivery platform to the latest release of the products. It also covers deployment of new tools and capabilities in the system delivery platform. The act also includes how the project environment is configured and related CLM repositories are linked. Finally it explores how the team selects an improvement strategy and how the practices and process automation used by the project is configured and deployed to the system delivery platform.
Act 2 – System Engineering / Plan Release. This act explores System engineering, Project release planning, and how these two practices interact in a System Delivery project. The act explores how system requirements engineering is supported by the tools on the System Delivery platform, and how Stakeholder Requirements, System Requirements, System Use-Cases, System Architecture relate to the project Iteration plans and Test Plans.
Act 3 – Complete a System Requirement. In this act one of the software delivery teams is planning, modeling, delivering and integrating a sub-system use-case. This explores the use of model driven development using the System Delivery platform. It also explores new development collaboration workflows using Modeling and CLM scenarios. The CLM@scale scenario reference this act as Complete a Story.
Act 4- Respond to Change. Requirements Change Management is a key capability for System Delivery teams. This act explores how new formal change requests are submitted, triaged, how impact from change is analyzed, and how requirements are updated, reviewed, approved, and baselined.
Act 5 – Stabilize. Lifecycle Management with Jazz enables rich capabilities for monitoring project health through CLM queries. This act explores how reporting and Jazz Dashboards help the team ensure quality and prepare for the release.
Act 6 – Deliver. The team is handing off the system release.
Acts are broken into scenes to explore smaller, concrete goals. Browse the links above to learn more about the scenes in each act.
The actors in the System Delivery scenario share common CLM scenarios personas. In some cases, the role name may be adjusted to suit the vocabulary and needs of the scenario. In summary, for this scenario we use the following teams and roles
Project Management team
Ursula – Product Manager. Owner of the product. Prioritizes stakeholder needs.
Patricia – Project and Resource Manager. Responsible for project schedule & deliverables.
Scott – Development Manager. Managing the project development teams.
Andy – Project and tool administrator. Manages the project repositories and servers and clients used by the project.
System Engineering team
Bob – Requirements engineer. Responsible for system requirements.
Sally – System architect. Defines and validates the system architecture. Manages subsystem dependencies.
Software Engineering / Software subsystem team
Marco – Software team lead and developer. Manages the agile plans for the software subsystem.
Al – Software subsystem architect. Responsible for the software architecture.
Deb – Developer. Practices model driven development. Performs unit testing of her changes.
Tanuj – Tester. Validates the quality of the software subsystem.
Integration and Validation
Tammy – Test manager. Responsible for the overall quality of the system delivery. Leads the independent test team that perform integration validation, and system acceptance tests.
Rebecca – System integration engineer and Release engineer. Manages software integration builds.
Terry – Test architect. Responsible for test architectures and test configurations.
The System Delivery scenario story starts with the project team preparing the System Delivery platform for the new project. Andy, one of the project admin(s), deploy or update the system delivery platform tools. Scott, the development lead, configures the discipline processes and reports for the project. Some of the steps in the scenes below are shared cross the CALM scenarios. Other steps are scenario extensions for System Delivery platform.
In this act we are deepening our understanding about
* Scenario extensions for system delivery
In this act we explore how the project is started. Our focus is on System Engineering and Project Planning.
The first scene explores how Ursula, the product manager, is establishing the concept for the project through managing the stakeholder needs and managing the proposal and approval of the system delivery project. We then switch to the next scene where the System Engineering team captures the system requirements, system use-cases and how traceability is established between the system requirements. In the following two scenes we explore how the project leadership team is transforming the prioritized system requirements into a project plan, development plans, and test plans. In the final scene the project leaders are reviewing, approving and baselining the project plans.
In this act we are deepening our understanding about
This act in the scenario focuses on two areas in the lifecycle management resource structure; the system requirements, and the plans of the project
In this act we use the System Development practices to explore how the team uses the System Delivery platform to realize a system requirements as part of one increment / iteration.
The software sub-system team (in the system delivery project) is using an agile approach to iterative (incremental / spiral) development. Each project iteration is planned for about 4-6 weeks. The objective of each iteration is to realize and validate a set of system requirements and use-cases, resolve prioritized defects and change requests, and to integrate the sub-systems into a complete an integrated demonstrator / prototype of the system product.
There are potentially many details to explore in this act. We primarily focus the exploitation on two workflows
In this act we are deepening our understanding about
This act in the scenario focuses on the lifecycle resources managed by one of the development teams. It expands the resource structure established in Act 2 in context of the realization of a system requirement. The key lifecycle resources are
In this act we explore the Requirements Change Management capability in the System Delivery platform.
In Act 1 the team approved a set of requirements. In this Act a change request has come in that impacts the baselined plan. We explore the steps of how the team agree to accept it, which changes the requirements, the dev & test teams also respond to the change.
The Requirements Change Management scenario outlines a set of core OSLC resources
This act in the scenario expands the lifecycle resources to explore the relations to project planning, and realization and validation of the changed requirement. These resources include
The system project is approaching its delivery. The focus of the remaining iteration/increment is to stabilize the release. Process changes where deliveries require approvals. But main focus is on the system versification
In this act we are deepening our understanding about
Completion = how done the project or phase is
Rate = the rate at which work is being done
Quality = the quality and stability of the deliverable
Schedule = the accuracy of the scheduling and estimating process
Complexity = how hard the work is
Systems Engineering Metrics
Requirements analyzed – # of requirements that have been reviewed and allocated to a use case
Use cases analyzed – # of use cases analyzed (incl. scenario elaboration and executable state machine run)
Use cases allocated – # of analyzed use cases allocated into the selected systems architecture (includes construction of logical ICDs and messaging between architectural subsystems)
Use case complexity – # of transitions + # of actions on use case state machine
Requirements productivity – # of requirements allocated to use cases and to the selected architecture per person-month of effort
Requirements volatility – # of requirements changed
Use Case Defect density – # of identified defects per use case
Schedule variance – % difference between actual effort and estimated effort
Task variance – average % difference between actual effort and estimated effort per task
Software Engineering Metrics
Defect Density – # defects per 1000 lines of delivered source code OR # defects per class
Unit Test Density – # unit tests per 1000 lines of delivered source code OR # defects per class
Use Case Velocity – rate at which use cases are being achieved (# use cases realized and validation tested / unit time)
Work Item Velocity – rate at which work items are being completed (# work items completed / unit time)
Test Coverage – # of source lines code tested / total number of source lines of code
Requirements velocity – # of requirements demonstrably represented in design, implementation and test per unit time
Integration rejection rate – average # of submissions to continuous integration rejected due to breaking the build
Architectural volatility – # of changes made to the software architecture
Validation density – # of tested requirements / # of requirements
Validation test failure rate – # of validation tests that fail / total number of validation tests
Schedule variance – % difference between actual effort and estimated effort
Task variance – average % difference between actual effort and estimated effort per task