Upmc tpdev2

Click to add text
© 2016 IBM Corporation
Jazz et le développement collaboratif
Jean-Yves B. Rigolet
IBM Cloud, France Lab
rigolet.j@fr.ibm.com
TPDEV
UPMC STL M2 – 2016/2017

TPDEV
2
Agenda
 Overview of the Rational CLM solution
 Jazz platform & CLM solution
 Rational Team Concert development tooling
 A day in a life of an agile developer
 Planning our work
 Keeping track of our work
 Sharing our work with our colleagues
 Tagging well known SCM configurations
 CLM project growth and multi-stream development
 Building CLM
 Achieving quality-driven deliveries
 RTC & CLM end game and a tightened process

TPDEV
3
Classic collaboration between tools
Tool A
Tool A’
Tool C
Tool B
Tool E Tool F
Tool D
Too often
synonymous
with complexity
Requires a
cross
understanding
of tools

TPDEV
4
Collaboration based on middleware services
Tool A Tool B Tool C Tool D Tool E Tool F
Events &
Services
Team Collaboration Services
• With Jazz, tools communicate only with the platform:
• By listening events from the platform
• By sending events to the platform
Adaptive
Process Enactment
& Continuous Analysis
Artifact
relationships
Tool A’

TPDEV
5
Storage
Collaboration
Query
Discovery
Administration:
Users, projects, process
Presentation:
Mashups
Rational
ClearQuest
3rd-Party
Offerings
Rational
Team
Concert
Rational
Quality
Manager
Rational
Build Forge
Rational
Requirements
Composer
Best Practice Processes
Open Services Web Integrations
HTTP / REST API
Built on Jazz
Integrated with Jazz
5
Jazz: Open, extensible, web-centric, integration architecture
Jazz is a project and platform for transforming how people work together to
deliver greater value and performance from their software investments.

TPDEV
6
Rational solution for Collaborative Lifecycle Management
Rational ALM platform
Set of seamlessly integrated tools that work together as one
–Rational Team Concert
–Rational Quality Manager
–Rational Requirements Composer & Desing Management
Lifecycle traceability to gain insights & improve software delivery
predictability
Ease integration with 3d party tools (JIRA, Git, HP ALM,...)
–Based on specifications from Open Services for Lifecycle Collaboration

TPDEV
Open Lifecycle Integration Platform
Software Change
and Configuration
Quality
Build and Deploy
Requirements
Design
IBM Rational solution for
Collaborative Lifecycle Management
with Design
Focus on the five imperatives
to establish effective ALM
Integrate software design for
broader collaboration and
traceability
Prioritize entry point; extend
as needs evolve
Leverage Jazz platform to
unify and protect current
infrastructure investments
Integrated and effective Application Lifecycle Management

TPDEV
8
Rational Team Concert development tooling
Collaborative SCM, work item, build automation & iteration planning
Achieve common goals
by optimizing how
people work
Increase control
and efficiency by
integrating workflows
Collaborate
Continuously improve
by measuring progress
in real time
Report
Automate

TPDEV
9
To improve coordination and visibility
Look for ways to collaborate across the software delivery process
Drive organizational consensus on
priorities and improve
workforce productivity
Collaborate
• Leverage social networking capabilities to
enable broader and richer participation in
software projects
• Virtualize "team memory" to overcome
geographic and temporal gaps in the software
lifecycle
• Enable flexible, global resourcing and energy-
saving workplace models

TPDEV
10
To ensure progress towards business outcomes
Look at how to report on the software delivery process
• Make better informed decisions by leveraging
the real-time instrumentation of the software
delivery process
• Leverage metrics for continuous individual
and team capability improvement
• Gain insight into a projects which span
organizational and geographic boundaries
with minimal disruption
Continuously improve
by measuring progress against
desired
business outcomes
Report

TPDEV
11
To increase efficiency
Look for ways to automate the business process of software delivery
Lower costs and improve quality
by automating workflows based
on real-time information
Automate
• Improve productivity and reduce headcount
• Standardize processes and automate repetitive
tasks to improve team efficiency while reducing
time to value
• Enhance regulatory compliance through
self documenting data and workflows

TPDEV
12
Agenda
 Overview of the Rational CLM solution
 Jazz platform & CLM solution
 Rational Team Concert development tooling
 A day in a life of an agile developer
 Planning our work
 Keeping track of our work
 Sharing our work with our colleagues
 Tagging well known SCM configurations
 CLM project growth and multi-stream development
 Building CLM
 Achieving quality-driven deliveries
 RTC & CLM end game and a tightened process

TPDEV
13
Planning application development work
Use of a bug tracking system
–Application to help our development teams keep
track of reported software bugs in our work.
–Support the concept of bug life cycle which is
tracked through status assigned to the bug.
Development work to be done
–Keep an history of the work done
–Large variety of the development tasks
… and many more

TPDEV
14
How is Rational Team Concert handles the work?
RTC calls them work items.
–The set of work item types is open-
ended.
–Standard types: Plan Item, Story,
Task, Enhancement, Defect,
Adoption Item
–The set can be redefined by each
team.
–The work item life cycle is
configurable.
–All work items are stored in the
Jazz repository

TPDEV
15
Report
Work items are central to Rational Team Concert
Work
Items
Plans
define &
organize
work items
Planning Source Control
Change sets
implement
work items
Build
includes
change sets
Build
Reports
show work
item activity
Work items
describe
the builds

TPDEV
16
The situation: a bunch of work items
 We have a bunch of work items
 We have a deadline (M2)
 Who will work on what?
 How can we track our progress on M2?
 What if there’s too much to fit in?

TPDEV
17
RTC solution: Planning(s)
 A collection of work items…
– Assigned to a given milestone
– For a given team
 Plans are live
– Changing work items changes the plan
– Changing the plan directly changes the
work items
– Create new work items from the plan
 Plan structure is dynamic
– Easily be grouped by owner, category,
tags, custom folders
 Plans are visible
– Available to everybody on the team
– Observable by interested outsiders
 Different types of plan
– Product & Sprint backlog, Release plan

TPDEV
18
Principle of an application development lifecycle
Release N
Milestone 1
Warm-up Milestone i Milestone M End Game
Decompression
Retrospective
Initial
Release
Plan
Test
Plan
Development
Retrospective
Test
Plan
Development
Retrospective
Test
Plan
Development
Retrospective
Work Items
Previous
Plan
Next
Plan
Postponed
Work Items
Organize and
Distribute
Work Items
Resolve and/or
Create
Work Items
Postpone
Work Items
Iteration
Plan
Continue
working
 Aligned milestones schedule across CLM products

TPDEV
19
Software requirements management in an agile world
Disciplined
Agile Delivery
 Requirements are prioritized by
stakeholders
 Requirements are estimated by the
development teams during the iteration
planning (beginning of each iteration)
 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”

TPDEV
20
Planning the development work
https://jazz.net/library/video/408c
Demo

TPDEV
21
Work item at the heart of the team work
We just saw RTC plans as a way to plan and follow work, but there is
more…
RTC provides a query mechanism to find work items in a Project Area.
– The query scope for work items is the project area.
– The user interface includes:
• an editor for building structured work item queries and
• an end-user configurable work item view to browse the query results.
Risk tracking
– tracked in the Plan Item’s Execution tab
– Updated at the end of the iteration
Adoption Item
– Tracks changes from Jazz Foundation that need adoption
– Attributes: Affected teams, Impact, Workflow (Proposed, Approved, Done)

TPDEV
22
Keeping track of our team: Team Central
Keep track of things like…
–News
–Build results
–Team load
–Who’s online
–Changes in work items you care
about
–Events in team areas you are a
member of
–Any other queries you find handy
Configurable (RSS feeds)

TPDEV
23
Keeping track of our own work: My Work view
Keep track of work items
–Owned by you
–Assigned to the current iteration
Use sections from Team
Central
Check you work
–Newly assigned work items
–Past, current & future work
–See updated work items

TPDEV
24
Keeping track of the work
Demo
https://jazz.net/library/video/287

TPDEV
25
Sharing work with our team using Jazz Source Control
As you would expect, it manages source code and other digital
assets
–Maintains previous configurations of source code
–Prevents unauthorized access to assets
–Alerts users when an asset has changed
In addition
–Is aware of the structure of your components
–Maintains an integrated history of changes
–Helps you handle interruptions and conflicts
–Integrates with the rest of Jazz

TPDEV
26
Repository
Workspace
Stream
Basic Jazz SCM anatomy
Local Workspace
Other’s changes
Your changes
The SCM is composed of:
1) Streams are for sharing resources
2) A repository workspace is your personal space in the repository
3) Local workspaces are where you edit resources
4) Changes flow back and forth
Subsequent charts will cover each of these

TPDEV
27
Repository Workspace
Repository
Workspace
Component
Component
Local Workspace
Repository Workspaces
–Partitioned into components
–Jazz understands the structure of your components
–Jazz directly supports component based development

TPDEV
28
Components
Local Workspace
Eclipse Project
Folder
Eclipse Project
File
File
File
File
File
Eclipse Project
Repository
Workspace
Component
Eclipse Project
Folder
Eclipse Project
File
File
File
File
File
Folder
Eclipse Project
Component

TPDEV
29
Local Workspace
Local Workspace
Repository
Workspace
Components
Repository
Workspace
Components (cont)
Components
Change set
Change set
Change set
Change set
Components Track Changes
– Configuration of resources builds from the change set flow
– Each change set builds on what came before
Component’s Change History
– A time-ordered sequence of change sets
– Describes how the component’s content was built from nothing

TPDEV
30
Change set details
Composed from a collection of changes to one or more files and folders
– Change set orientation is another example of Jazz understanding your source and its
relationships
– A change set that affects multiple resources is committed as a single atomic unit
Indicates the reason for the changes
– Via a comment, and/or
– By referencing the relevant work item
Can be shared with another team member
– Via a stream, or
– From your repository workspace via a work item
Local changes are not set in stone and can also be undone, discarded &
resumed.
– Using Undo, your pending local change will go back to the last checked in state.
– Using Discard, your pending local change will be set aside until being resumed.

TPDEV
31
Local Workspace
Local Workspace
Repository
Workspace
Components
Repository
Workspace
Streams
Components
Stream
Components
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Change set
Stream
–A place to share source with your
team

TPDEV
32
Typical journey for a change set
Stream
Component
Component
Component
Component
Local Workspace
2b.Change set
4. Deliver
1. Change
3. Complete
(usually combined
with deliver)
2a. Check-in

TPDEV
33
Change set delivery is process enabled
The deliver operation is process-enabled, allowing the team’s
process to check and enforce delivery rules

TPDEV
34
Delivery notifications

TPDEV
35
Getting our teammates’ delivered work
Stream
Component
Component
Component
Component
Accept
Local Workspace
 An incoming change set is
– In the change history of the stream, but
– Not in the change history of your repository workspace
 Accept adds the change set to your repository workspace’s change history

TPDEV
36
Sharing work amongst teams working on multiple platforms
We build & use various clients,
using many languages to
deliver RTC.
–Web Client,
–Client for Eclipse IDE
• RAD, RSA, RDz, RDp,...
–Client for Microsoft Visual Studio
IDE,
–z/OS ISPF Client,
• COBOL, PL/I, REXX, ...
–Command Line Interfaces.
–Source Control Management CLI
–Repository Tools CLI
–Jazz Build Engine CLI

TPDEV
37
Doing and sharing some work
Demo

TPDEV
38
Tagging well known SCM configurations
 What about these questions?
 How do I find a known good configuration of a component?
 How about a known good configuration of an entire stream?
 Hey, exactly what was in that milestone build a year ago?
 That is, what about fixed configurations that do not change anymore?
 Use baselines…
 and snapshots

TPDEV
39
A baseline
Is an immutable copy of a component’s configuration
– At a particular point in time, and
– There can be multiple baselines of a component
Serves as a fixed point of reference
– For initializing streams and repository workspaces
– For sharing source with people or processes
Can be easily compared
– With each other
– With the current state of a stream
– With local & repository workspace

TPDEV
40
A snapshot
Is a collection of one baseline per component in a repository
workspace or stream
–Captures an important repository workspace configuration for later recreation
–There can be multiple snapshots of a repository workspace or stream
Like baselines, snapshots are used for sharing
–Create a repository workspace or stream
–Update the contents of a repository workspace
–Recreate a prior build via a build created snapshot

TPDEV
41
Tagging well known configurations
Demo

TPDEV
42
Project growth and scaling up teams
CLM project growth leads to multiple inter-dependent teams
Each team needs its own stream
–Quickly share changes with each other
–Run their own frequent builds
Avoid churn of cross team dependency volatility
–Breaking changes
–Project build stability
Need a stream for cross team sharing and project builds
–Well known change adoption schedule
–Regular good full project builds

TPDEV
43
43
Process Repository
Jazz
Development
Changes
Scaling up: Teams of teams

TPDEV
44
April on User Interface
UI
Typical component baseline flow
Integration Stream
Core Tests
Documentation
UI
UI Tests
Core Library Stream
Core
Core Tests
User Interface Stream
Core
UI
UI Tests
Jerry on Core Library
Core Tests
UI
UI Tests
Core
Core
Core
Core
Core
Core

TPDEV
45
Project growth & multi-stream dvlpmt
Demo

TPDEV
46
Build in the world of agile team development
Enterprise Team
SCM Team
Project
Source Control
System
Enterprise team
components
SCM Team
components
Project
integration
Deliver
enhancements,
fixes
Retrieve
Publish
tests
artifacts
logs
history
reports
Alerts:
B
U
I
L
D

TPDEV
47
Jazz build: design goals
Bring awareness of build progress and results to developers.
Link build results to related Jazz artifacts.
Adaptable to existing build technologies (Ant, CruiseControl,
BuildForge, Maven, etc...).
Build engines can run anywhere
–Alongside the Jazz server, or
–On a large variety of systems (Distributed, Mainframe or Power systems).
Builds can be scheduled and executed concurrently.

TPDEV
48
Builds are very visible to the users
My builds
Published
builds
Recent
builds
Events
Builds
history

TPDEV
49
Personal Build
• Builds normally run from a dedicated repository workspace
assigned to that build
• Personal build use from your repository workspace
– Useful for verifying a complex change before delivering it to the stream

TPDEV
50
Build and Snapshots
When a build requests a
snapshot…
–If there are any changes in a
component since the last build…
• A new baseline is created with
the same name as the
snapshot name
• Convenient for reproducing
build problems

TPDEV
51
Continuous integration & Builds
Team of Team
–Scheduled weekly integration build
• Stabilized until green
–Continuous integration stream
–Share changes, rarely green
Each Team
–Continuous builds
–Always green
A Developer
–Personal builds

TPDEV
52
Building applications
Demo

TPDEV
53
Achieving quality-driven deliveries
Test case
design
Execution
records
53
Test Plans and Test Cases defined
in Rational Quality Manager
– Functional, System & Performance Test
Plans
Defined by developers
Tested & tasted by all members
– Developers, release engineer, ... and
even managers sometimes
– Test execution records
Formal reviews
– Test cases approvals by Product
Owner & Tech Leads/ScrumMasters

TPDEV
54
Clear view of the quality status
Test cases
Plan items
Execution
reports
Test coverage
highlighted in Plans
– Links between Work
Items and associated
Test Cases
Easy Defect creation
(in RTC) from within
test execution
– Link to Test Case on
execution failure
Metrics & charts on
quality
– Presented at end of
iteration meetings to
stakeholders

TPDEV
55
Achieving quality-driven deliveries
Demo

TPDEV
56
Motivation for the team process component
Generally all software teams have some sort of process
–May be formal, informal, …
Successful teams…
–Believe their software process helps produce quality software
–Own their process
–Continually adapt their process to changing needs
However, success depends on….
–Common understanding by all team members
–Consistent execution
Many times…
–Process relies on documents (or word of mouth) for understanding and human
memory for execution
–Leads to inconsistent or erroneous execution

TPDEV
57
Project area iteration structure & terminology
Line of Development
{1..n}
Iteration
{1..n}
Process state
 Line of Development is an element of a project area that
owns a set of deliverables and its production schedule
(maintenance, new release development).
– Often represents parallel development
– A team area is associated with a development line
 Iteration represents some project work interval
– Any depth of nested iterations
– Process specification in any iteration
– May contain start and end dates
 Process state is defined as the current iteration in a
development line
– Indicated by the blue arrow
 Example:
– Main Development Line process state:
• 2.0 M2
– Maintenance Development Line process state:
• 1.0 Fixpack 1

TPDEV
58
Project delivery plan in Jazz terms
Release 1
Release 2
Maintenance
Iteration
Iteration
Iteration
Iteration
New Release Development
Iteration
Iteration
Iteration
Line
Q1
D
e
v
R
F
S
Q2
D
e
v
R
F
S
Q3
D
e
v
R
F
S
Q4
D
e
v
R
F
S
M1
D
e
v
R
F
S
M2
D
e
v
R
F
S
M3
D
e
v
R
F
S
M4
D
e
v
R
F
S
M5
D
e
v
R
F
S
M6
D
e
v
R
F
S
Release 2
Process State
RFS: Ready for ship
Release 3

TPDEV
59
Process is defined in one or more iterations
Routine development
process
Active process defined by process state:
{1.0, M1, endgame} in this example
Team area
custom process
A team area can augment/override the process of any iteration
Special Iteration
process
 Specified as a set of component operation rules
– Specified in process graphical editor, codified in XML
 Rules are assigned to user roles (default, contributor, team lead…)
 You can have the general process defined for the project
 Override/augment the general process in planned iterations

TPDEV
60
Example: configuring the process for project roles
Team Advisor: Require Work Item
Default Role Contributor Role Team Lead Role
SCM Deliver Operation
Not Permitted!
Encouraged
Overrulable
Permitted Permitted
Encouraged
Required
Feasibility Iteration
Development Iteration
Iteration
Ready for Ship Iteration Required
 Roles allow for a custom process based on a team member’s project
responsibilities (role)

TPDEV
61
61
Adapting the conditions
of code delivery
Raising the bar: Approvals

TPDEV
62
End game and a tightened process
Demo

TPDEV
63

Upmc tpdev2

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Upmc tpdev2

Similar a Upmc tpdev2 (20)

Más de Jean-Yves Rigolet

Más de Jean-Yves Rigolet (9)

Último

Último (20)

Upmc tpdev2