程序代写代做代考 database 17spm_L16

17spm_L16

Scaling Up Agile Processes

SPM 2017 © Ron Poet Lecture 16 1

Multiple Team Projects

� Agile approaches mainly describe how to run a single team on a
project lasting a few months and with uncertain requirements.

� What about larger projects with multiple teams and longer timescales?
� Most larger agile processes are based on Scrum.

o Large Scale Scrum

SPM 2017 © Ron Poet Lecture 16 2

o Large Scale Scrum
o Scaled Professional Scrum
o Scaled Agile Framework

Larger Projects

� One obvious approach is to take a pure agile process that works and try
and scale it up.

�Scrum is the usual starting point.

� Other approaches provide a list of principles, which can be helpful.

� The main issues are:

�Managing multiple teams working on the same project.

�Continuing support after product delivery.

�Managing multiple projects. The organisation would like a
pipeline of potential work: a backlog of projects.

3SPM 2017 © Ron Poet Lecture 16

Large Scale Scrum

� Sprint planning is now split into two parts.

o All teams choose the stories they will work on in the next sprint.

o Each team breaks their stories into tasks in the usual way.

� Daily meetings are in two parts.

o Each team has the usual stand up meeting.

o Each team sends one representative to a Scrum of Scrums often
called a Town Hall Meeting to coordinate activities.

� The sprint review includes everyone.

o Each team has its own retrospective.

� A chief product owner works with several area product owners.

o There will be a pre-sprint product owners meeting.

4SPM 2017 © Ron Poet Lecture 16

Scaled Professional Scrum

� The Nexus is the point of contact for several (up to 9) teams.
� There is a single product owner and a single product backlog.

� There is an overall coordinating team called the Integration Team.
o It coordinates the individual development teams.o

o It operates and uses scrum in the same way as a development team,
but focusses on coordinating teams rather than producing code.

� There is a Nexus planning meeting at the start of each sprint.
o Focuses on dependencies between the work of individual teams.

� There is a Nexus Daily Scrum.
o Equivalent to a Scrum of Scrums.

5SPM 2017 © Ron Poet Lecture 16

Scaled Agile Framework (SAFe)
(More Scrum)

� It maintains a portfolio of future work.
o A backlog of projects.

� This is summarized in the Big Picture, a diagram of this project
backlog.

� The strategic portfolio section contains a number of value streams.
o Product lines.

� The program section contains a number of ‘epics’ which can lead to
new programs and be added to the program backlog.

o Each will have a release train.
� The development teams section lists all the teams and their iteration

and release plans.

6SPM 2017 © Ron Poet Lecture 16

SAFe: Additional Roles

� Product Manager.
o Responsible for the program backlog.

� Release Train Engineer
o In charge of one program and manages the Scrum Masters.
o Supported by a team.o Supported by a team.

� Portfolio Management Team
o Looks after the financing.

� The actual development teams use Scrum / XP

SPM 2017 © Ron Poet Lecture 16 7

Feature Driven Development

SPM 2017 © Ron Poet Lecture 16 8

Origins

� Object oriented languages such as C++, Smalltalk and Objective C
became popular in the mid to late 80s.

� They introduced an entirely new programming paradigm.
� There was a mismatch between existing software design

methodologies and OO programming.methodologies and OO programming.
� A number of people worked on bridging techniques that modified

existing techniques to add OO features.
o Database design techniques such as Entity-Relationship diagrams

we called object oriented design approaches.
o Edward Yourdon was prominent in this area.

� This evolved into object oriented analysis and the Coad/Yourdon
methodology.
o Introduced by Peter Coad.

SPM 2017 © Ron Poet Lecture 16 9

Origins (2)

� In 1997 Peter Coad and Jef De Luca were brought in to rescue a failing
project by a Singapore bank.
o It had run for 2 years without results.
o They completed it in 15 months with a team of 50.

� It is a mixture of traditional and agile approaches.� It is a mixture of traditional and agile approaches.
o Not efficient enough for small teams of less than 10.
o Scales up well for larger projects.

SPM 2017 © Ron Poet Lecture 16 10

Features

� A Feature is a unit of client valued functionality.
� It is the equivalent to a use case or user story.
� There is a special notation for naming features:

o Action … Result … Object.
o E.g. Calculate (action) the total amount (result) of a sale (object).o E.g. Calculate (action) the total amount (result) of a sale (object).

� They must be small enough to be designed, built and tested within 2
weeks.
o Larger features should be broken down into smaller ones.

SPM 2017 © Ron Poet Lecture 16 11

Feature Hierarchy

� Related features are grouped into Feature Sets.
� There is a special naming convention:

o Action-ing … Object
o E.g. Making (action) a sale (object)

� Related feature sets are grouped into Subject Areas.
o Object … Management
o E.g. Sales (object) Management.

SPM 2017 © Ron Poet Lecture 16 12

Processes

� Create the Object Model.
o This is essentially object oriented analysis.
o The specification documents are analysed and objects and classes

of objects are identified.
o The relationships between these objects and classes is discovered.o The relationships between these objects and classes is discovered.
o A UML class diagram is produced.

� Build a Feature List.
o A top down approach is used to identify subject areas, then feature

sets and finally features.
� Plan the Releases

o The feature sets are assigned to different programming teams and
the release plan is developed.

SPM 2017 © Ron Poet Lecture 16 13

Processes (2)

� Each team selects a group of features that can be developed in 2
weeks.

� This forms a Work Package.
� The features are designed

o Sequence diagramso Sequence diagrams
o User Interfaces
o Methods
o Class Interfaces

� Class Owners build and test their classes.
� At the end of 2 weeks, all the work packages are integrated into the

Main Build.
� The next work package is then developed.

SPM 2017 © Ron Poet Lecture 16 14

Roles

� Project Manager with traditional responsibilities.
� Chief Architect: responsible for overall design of the system.

o Responsible for conceptual integrity, a single vision for the whole
system.

� Development Manager: responsible for day to day management of the � Development Manager: responsible for day to day management of the
project.

� Chief Programmer: Really a team leader.
� Class Owner: A developer. Each class is owned by 1 person.
� Domain Expert: responsible for user requirements and representing the

business.

SPM 2017 © Ron Poet Lecture 16 15

Deliverables

� Object Model
o Class diagram
o Sequence diagrams

� Feature List
� Development Plan� Development Plan

o Schedule for subject areas
o Schedule for feature sets and the responsible chief programmer
o Class owner list.

� Feature Work Package: one for each team per each iteration.
� Completed Features: ready for release.
� Parking Lot Report: status of each feature set.
� Burn-Up chart: an earned effort chart.

SPM 2017 © Ron Poet Lecture 16 16

Key Aspects

� Object Modelling
o UML diagrams for classes, sequence diagrams etc.
o An object modelling tool should be used because it is easier to

track changes.
o Must be kept up to date.o Must be kept up to date.

� Class ownership
o Each class has one owner who is responsible for making all

changes to that class.
o This simplifies problem resolution.
o Opposite of egoless programming (XP).

SPM 2017 © Ron Poet Lecture 16 17

Key Aspects (2)

� Feature set teams
o All members work on a related part of the system
o Encourages ownership.
o Makes multi-team projects possible
o The temptation to keep shifting members from team to team should o The temptation to keep shifting members from team to team should

be resisted. (so not XP)
� Tracking Features

o Features are the main deliverables and are tracked through their
lifetime.

� Code Inspections (code walkthroughs)
o A good way of finding bugs and transferring knowledge.

SPM 2017 © Ron Poet Lecture 16 18

Key Aspects (3)

� Regular Builds
o Can be run once per day.
o Main integration of new features at the end of each 2 week

iteration.
o A time to fix integration errors when they are small.o A time to fix integration errors when they are small.
o Always a working version for demonstrations.
o Need automatic regression tests.

SPM 2017 © Ron Poet Lecture 16 19

Issues

� FDD will work with multiple teams but:

� It is focussed on the code, the class structure, rather than other
considerations.
o Scrum and XP also focus on developing code early on, but they

SPM 2017 © Ron Poet Lecture 16 20

o Scrum and XP also focus on developing code early on, but they
don’t have an initial design to work from.

� It is important to get the class structure nearly right at the start of the
project.

� This limits it to projects where the basic requirements are fairly well
known at the start of the project.

� In general it is better to focus on the “what” rather than the “how” at
the start of a project.