程序代写代做代考 17spm_L12

17spm_L12

Agile Software Development

SPM 2017 © Ron Poet Lecture 12 1

The 90’s Time of Change

� Agile processes arose to solve issues with many manufacturing
processes.
o Long design between initial idea and delivered product.
o Existing processes were excessively bureaucratic.
o Assuming no change was unrealistic.o Assuming no change was unrealistic.

� The car industry led the way, in particular Toyota.
o Better, cheaper, safer cars were produced.

� The software industry was steadily adopting object oriented
programming, starting in the 80’s.
o New object oriented design paradigms started to be adopted and

needed an appropriate framework.
� We will consider Lean Software Development (Toyota way)
� We will also look at XP (eXtreme Programming).

SPM 2017 © Ron Poet Lecture 12 2

Aims of Agile Processes

� To spread decision making over the length of the project.
� Balance the communications between users and developers.

o If users dominate, they demand a functionality and timescale that
can’t be delivered.

o If developers dominate, they lose the opportunity to learn what is

SPM 2017 © Ron Poet Lecture 12 3

o If developers dominate, they lose the opportunity to learn what is
needed.

� Reduce paperwork.
o The code is the main source of documentation.

Lean Software Development

SPM 2017 © Ron Poet Lecture 12 4

Introduction

Origins in Toyota

� A way to design and build cars that has been transferred to software.
o Became popular around 1990.

� There are 7 principles to Lean Software Development, based on the 14
principles of Lean Development in the car industry.
o Eliminate waste, the main way that agile processes are better than

SPM 2017 © Ron Poet Lecture 12 5

o Eliminate waste, the main way that agile processes are better than
traditional approaches.

o Amplify learning.
o Decide as late as possible.
o Deliver as fast as possible.
o Empower the team.
o Build integrity in.
o See the whole picture.

Eliminate Waste

� Non-value-adding work.
� Overburden.
� Unevenness.
� Eliminating waste is an iterative process:

o Identify wasteo Identify waste
o Find the source.
o Eliminate it

� The main source of waste is excess documentation, which is removed
in agile processes.

� Management bureaucracy can also cause waste.
� Some things that look like waste are not.

o Throwaway code for experiments.

SPM 2017 © Ron Poet Lecture 12 6

Amplify Learning

� Software development is a continuous learning process.
� Agile processes make sure that everyone shares in the learning process.
� Short iterations with reviews provide opportunities for reflection and

learning.
� Developing prototypes and showing them to the customer early makes � Developing prototypes and showing them to the customer early makes

it easier to learn what is really required.

SPM 2017 © Ron Poet Lecture 12 7

Decide Late

� Keep all options open by putting off decisions as late as possible.
� This can be difficult to get right.

o It is easy to never make a decision!
� The iterative approach means that some decisions have to be made at

the start of each iteration.the start of each iteration.
� Planning meetings consider all the different options.

o The options are costed and the best one chosen.
� Set-based Design: Several teams may be asked to design solutions to

the same requirements.
o The best one is chosen.

� This may seem like waste, but waste is defined by activities that have
high costs and low benefits.
o The benefits of finding the best solution can be high.

SPM 2017 © Ron Poet Lecture 12 8

Deliver Fast

� In the internet age, the first product in a new area usually wins.
� Short iterations produce usable code quickly.

o It can be difficult to maintain quality as well.
� Set-based design means that several different options can be explored

in parallel.in parallel.
o This is quicker than trying them out one at a time.

SPM 2017 © Ron Poet Lecture 12 9

Team Empowerment

� The role of the manager is not to tell people how to do their jobs.
� Find capable people and let them do their jobs.

o How do novices become capable?
o Let other companies train novices?
o The managers must also develop novices and help them to improve o The managers must also develop novices and help them to improve

their skills.
� Human resources

o People are not interchangeable resources but individuals.
o Company procedures should reflect this.

� Self organising teams.
o The teams should be able to work out how to organise themselves

without a manager telling them what to do.
� Teams should be able to choose a leader to coordinate things.

SPM 2017 © Ron Poet Lecture 12 10

In-built Integrity

� Architectural Integrity
o The design is simple and complete. All parts fit together well.
o This is achieved through refactoring.

� Conceptual Integrity
o All parts of the system fit together well.o All parts of the system fit together well.
o The system is not made of separate pieces glued together

somehow.
o Small iterations so that the requirements are refined together.
o Regular refactoring.

� Product integrity
o Thorough testing.

� Perceived Integrity
o It is not enough to be good, we must also be seen to be good.

SPM 2017 © Ron Poet Lecture 12 11

See the Whole Picture

� Everyone involved should see how the final product fits in and will be
used.
o Not just focussing on their own little piece.

� Lean thinking has to be understood by all.

� Think big
� Act small
� Fail fast
� Learn rapidly

SPM 2017 © Ron Poet Lecture 12 12

XP

SPM 2017 © Ron Poet Lecture 12 13

Introduction

Extreme Programming (XP)

� First used by Kent Beck at Chrysler (96 – 99).
o He led the development of a payrol system.

� Focus is customer satisfaction.
o Deliver what the customer wants when they want it

� Frequent releases and short timeboxed iterations.
� Fits in well with Scrum and often used as the methodology within the � Fits in well with Scrum and often used as the methodology within the

Scrum framework.
� Requirements defined with user stories.
� Release plan and iteration plan decides when the user stories will be

done.
� User stories are broken down into tasks and team members choose the

tasks they want to work on.
� Acceptance tests defined ahead of coding.

14SPM 2017 © Ron Poet Lecture 12

29 Rules of XP!

� Planning.
1. User stories are written by the customers to represent their

requirements and used by developers to estimate effort.
o Effort measured in ideal days.

2. Release planning turns the users stories into the release schedule.2. Release planning turns the users stories into the release schedule.
3. Produce working software at the end of each iteration. The

customer decides what will be released.
4. Divide the project into equally sized iterations (1 to 4 weeks) to

aid velocity tracking and control.
o Velocity = ideal days per iteration.

5. Each iteration begins with iteration planning, which turns the user
stories into a list of tasks for the developers.

15SPM 2017 © Ron Poet Lecture 12

29 Rules

� Managing
6. Open plan office for the team to encourage communication.
7. Set a sustainable pace using iteration velocity.
8. Start each day with a standup meeting in the team space and give

every team member a chance to communicate.every team member a chance to communicate.
9. Measure the velocity at the end of each iteration by adding up the

amount of work in the completed stories.
10. Move people around in the team to spread knowledge.
11. If XP is not working, fix it by changing the process if the team

decides to do so.

16SPM 2017 © Ron Poet Lecture 12

29 Rules

� Designing
12. Simplicity, a simple design is easier to implement.
13. Choose a system metaphor rather than a vast document.
14. Use CRC (Class, Responsibility and Collaboration) cards for

design sessions to represent objects in the system.design sessions to represent objects in the system.
o An old way to design classes.

15. Create spike solutions (throwaway code) to explore options and
reduce risk.

16. Never build anything into the system before it is needed.
17. Refactor whenever and wherever to reduce unwanted code. In

the long term this will save time and money.

17SPM 2017 © Ron Poet Lecture 12

29 Rules

� Coding
18. The customer is always available as part of the development team.
19. Code must be written to agreed standards.
20. Code the unit tests first. This will help the programmer to

understand the requirements and develop the code.understand the requirements and develop the code.
21. All production code is programmed by a pair. Two people

working at one computer will produce better code faster.
22. Only one pair integrates code at a time.
23. Integrate often, every few hours at least.
24. Set up a dedicated integration computer to do this.
25. Use collective ownership to encourage everyone to contribute.

18SPM 2017 © Ron Poet Lecture 12

29 Rules

� Testing
26. All code must be unit tested by setting up a unit test framework.
27. All code must pass all unit tests before it can be released.
28. When a bug is found, additional tests are created to guard against

it coming back.it coming back.
29. Acceptance tests (preferably automated) are run often and the

results are published.

19SPM 2017 © Ron Poet Lecture 12

Values

� Communications
o Everyone gets the same view of the system
o Conversations should be frequent

� Simplicity
o Design and code for now rather than designing everything up fronto Design and code for now rather than designing everything up front
o Extra functionality can be added later
o This leads to regular refactoring

� Fast Feedback
� Courage
� Respect

o For other team members and oneself
� Embrace change, because it will happen

20SPM 2017 © Ron Poet Lecture 12

Design for Now

� There is no initial design stage.
� The design evolves over time.
� Don’t design for reusability.
� Only design for what is needed now.

� There is no way of recording the overall design.
� It can be deduced from the code.

SPM 2017 © Ron Poet Lecture 12 21

Practices

� Pair programming
o One programmer writes the code
o The second programmer reviews the code as it is written.
o They swap roles regularly.

� Test driven development� Test driven development
o Think of all the ways the code can fail.
o A piece of code is finished when it passes all tests.

� Continuous integration
o Everyone always works with the latest version of the software.
o New versions of code are uploaded every few hours.
o This avoids later integration problems.

22SPM 2017 © Ron Poet Lecture 12

Practices

� Regular refactoring
o The original simple design may not be the best when more work is

completed.
o Regular refactoring means that the design keeps changing and

keeps up.keeps up.
� Small releases

o Regular feedback from the customer.
� Collective code ownership

o Everyone is jointly responsible for all the code.
o Programmers move around with different pairs and so everyone

eventually sees all the code.
o So no good for very large programs.

23SPM 2017 © Ron Poet Lecture 12

Practices

� Programmer welfare
o Software Developers should not work more than 40 hours per

week.
o If there is overtime one week then there is no overtime the

following week.following week.
o People perform best and are most creative if they are rested.
o Short iterations mean there is less of a build up of pressure that

tends to happen in the weeks leading up to a release using non-
agile processes.

24SPM 2017 © Ron Poet Lecture 12

Issues

� Change Control
o XP assumes that there is a unified customer view on what the

software should do.
o The customer representative in the team may have a biased view of

the software requirements.
o Customers may try and micromanage the development by trying to o Customers may try and micromanage the development by trying to

dictate the use of technical solutions that they have heard of but
know nothing about.

� Requirements
o Incrementally adding requirements may miss some.
o However, regular customer feedback should get them.
o It is also harder to estimate the final cost and delivery time.

25SPM 2017 © Ron Poet Lecture 12

Issues

� Design
o The final design must be reachable from the initial design by small

refactoring steps.
o The ideal design might be entirely different.

� Does not scale up for teams larger than about 12 people.� Does not scale up for teams larger than about 12 people.
o This is a management issue and true of other methodologies.
o There is no evidence that multi-team XP projects work.

� When to use XP
o When requirements will change and develop during the project.
o When the customer is willing to be heavily involved in the

development.

26SPM 2017 © Ron Poet Lecture 12