Swe 03 (st 2013) agile software engineering

1
W. Weitershagen page 03-1
Software EngineeringFFMFH
Dr. Werner Weitershagen
Software Engineering
summer term 2013
- Agile Software Engineering -
Agile way of thinking (1)
Agile way of thinking
• ... sees a project within its individual environment that is
changing permanently: requirements and conditions
can be changing.
• ... wants very flexible projects. These projects should
adapt easily to economical and technical conditions that
could be changing every day. Contracts are usually
blocking adaptions that are necessary to be done.
Result: The customer gets a system he has ordered
initially, but gets not a final system he really needs.

2
Manifesto for agile software development
„We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.“
Quelle:http://www.agilemanifesto.org
Agile way of thinking
• ... criticises, that contract negotiation have negative
effects on projects: contracts constrain at all. But why?
Conditions can be converting and changing. A high
effort has to be payed to succeed changes and to
modify a contract.
Cantracts are often used as „legal weapons“
between contractor and customer. That means:
confrontation instead of cooperation.
• ... wants to achieve a good relationship between
contractor and customer with a common awareness of
„play to win“ instead of „play not to loose“
within a „win-win-situation“.

3
Usage of contracts
• Contracts should be used when both sides accept the
circumstance that there are aspects that can not
achieved by contract.
Both sides should know:
A contract is not the only solid platform of a project.
A contract can help to avoid misunderstandings
concerning tasks and conditions.
A contract can not force a project to its successful end.
Usage
• common target
• adaption of priority and project objectives
• transparency of riscs, that both sides should know and
accept each other
• search for practicable solution
• ability for making decisions permanently
• ability for taking riscs permanently

4
Critics:
„Can agile projects run in contract-free space?“
– „Are agile projects just a fiction?“
Both sides also have some more interests that do not
coincide with the project‘s interests:
so there can be interest conflicts / target conflicts
Example: The contractor wants to reuse the system or
parts of the system he developes within other projects.
But the customer wants to keep the know-how and the
right by himself. Possible solution: joint venture.
Agile methods
Extreme Programming (XP)
• ... is a development method / engineering method,
• ... is customer-oriented,
• ... is test-driven,
• ... is evolutionary.
Scrum
• ... is a project management method,
• ... is iterative,
• ... is incremental,
• ... is very team-oriented.

5
Extreme Programming (XP) (1)
... describes an agile iterative method of software
engineering with a lightweight methodology and less
documentation.
... is based on values like communication, simplicity,
feedback, learning and quality.
... needs strict principles and strict disciplin.
... is made for small teams.
... achieves long-life software.
... allows reaction to cloudy and changing requirements.
... has no strict requirements catalogue. Customer can
change – modify or extend – his requirements and
conditions.
Extreme Programming (XP) (2)
The developing process runs in short cycles – usually
within one or two weeks:
requirements analysis design implementation test
XP-projects are extremely customer-driven.

6
Extreme Programming (XP) – Principles (1)
User Stories:
Requirements are not defined by use cases (as RUP does),
but within user stories – a description of graphical user
interfaces (GUI), functionality and testing scenarios.
On-site Customer:
A competent and high experienced representative of the
customer supports the developer permanently.
Pair Programming:
Usually two programmers are building the same source
code together.
Advantages / Disadvantages:
☺ More errors can be detected and corrected immediately
during coding process.
☺ Know-how is being shared between programmers.
☺ Programmers can be used universally.
☺ The company is making itself less dependent on
experts.
☺ The progress is not disturbed by personal drop outs.
Programming causes double cost.

7
Testing:
Each mudule needs its individual unit test that should be
run automatically.
Simple Design:
No unnecessary features should be implemented.
Small Releases:
Many iterations should be done with executable results that
can be evaluated by the customer.
Refactoring:
Existing parts and structures should be changed without
changing basic functionality. Source code should be
restructured as soon as possible (if required).
Continuous Integration:
Source code should be integrated and consolidated
permanently. Problems of missing or wrong compatibility
can be detected and corrected very early.
Collective Ownership:
Source code belongs to the whole team and not to a single
programmer. Every programmer – every team member – is
responsible for the source code.
Teams should rotate!
Coding Standards:
Coding standards – notation standards, style guides etc. –
are necessary rules.

8
Extreme Programming (XP)
Links:
• http://www.extremeprogramming.org
• http://www.xprogramming.com
Scrum
... can not translated directly. Scrum
describes a situation within American rugby
match.
... tries to transfer the sportsmanship (Sportgeist) towards
a software developing team.
... is a lightweight management method.
... defines a sequence of 30 day iterations called sprints
with nearly constant increments.
... is made for small self-organized teams.
... cares a human component.

9
Scrum
Quelle:Schweitzer,R.(2003),S.6
new functionality
(daily)
(1 month)
Scrum – Sprints
Sprint
• ... is a 30-day-iteration.
• ... is defined within a Sprint Planing Meeting by all
team members.
• ... is based upon contents and priorities described by
Sprint Backlogs.
• ... is evaluated by management and customer within a
final Sprint Review Meeting.
• ... is permanently controled and adjusted within Daily
Scrum Meetinggs – 15 minutes each day.
• ... achieves a runable product version.

10
Scrum – Team
Scrum Team
• ... contains ca. 7 persons.
• ... is totally self-organized and acts autonomic.
• ... is committed to achieve the Sprint Goal.
• ... is directed by the Scrum Master.
• ... is not separated into different roles.
• ... defines the sprint goal and all tasks within the initial
Sprint Planning Meeting (about 4 - 16 hours each
task)
Scrum – Master (1)
Scrum Master
• ... is central person. He is responsible for the whole
team. He is the representative of the whole team.
• ... is responsible for the enforcement of scrum rules.
• ... is tracking the progress within daily scrum
meetings.
• ... is making decisions immediately within daily
scrum meetings.
• ... is supporting the team to define sprint goal and
sprint backlog.
• ... is solving each kind of problem mentioned by
team members.

11
Scrum – Master (2)
Scrum Master
• ... acts as an „interface“: He keeps external influences
away from the team.
• ... is an „interface“ between management and team.
• ... supports the management building up the scrum
team.
Scrum – Backlogs (1)
Backlog
• ... is a priority-ordered list of features, functionality,
extensions, error corrections that should be integrated
continuously.
• ... should be an every-time open book to all team
members. There they have the chance to add
requirements.
• ... is used in diffrent types: Product Backlogs, Core
Backlogs, Sprint Backlogs, Product Line Backlogs.

12
Scrum – Backlogs (2)
Product Backlog
• ... keeps all requirements and product specific tasks.
• ... is in the customers responsibility.
Core Backlog
• ... describes the requirements concerning the core or
architecture.
Scrum – Meetings (1)
Sprint Planning Meeting
• ... is the initial meeting of each sprint.
• ... defines the Sprint Goal.
• ... defines the volume of the next sprint.
• ... defines all tasks to be done within the sprint (4 - 16
hours each sprint).
• ... modifies the Sprint Backlog if required.

13
Daily Scrum Meeting
• ... lasts 15 - 20 minutes. – No discussions wanted!
• ... is directed by the Scrum Master.
• ... improves the communication within the team.
• ... represents all other kind of meetings.
• ... is asking each programmer:
What have you done and finished after the last
meeting?
What are you going to do and finish until the following
meeting?
Is anything disturbing your work?
• ... puts themes concerning details into special
meetings if required.
Sprint Review Meeting
• ... is the end of sprint.
• ... is the presentation of the product result (= build)
by the whole team.
• ... evaluates the sprint execution (problems etc.).l
• ... is the important platform for decisions made by
management and customer concerning release, next
steps, stop, cancel etc.
• ... is for adaption the Product Backlogs.
• ... can be combined with the following Sprint Planning
Meeting.

14
Scrum
new functionality
(daily)
(1 month)
Scrum
What else?
• If there is more than one scrum team, there should be
a kind of central coordination (Scrum of Scrum).
• Scrum and Extreme Programming (XP) are no rivals,
they can be combined:

15
Scrum
Links:
• http://www.mountaingoatsoftware.com/scrum/scrumtea
m
• Home Of Scrum: http://www.controlchaos.com

Swe 03 (st 2013) agile software engineering

Recommended

Recommended

More Related Content

Similar to Swe 03 (st 2013) agile software engineering

Similar to Swe 03 (st 2013) agile software engineering (20)

Recently uploaded

Recently uploaded (20)

Swe 03 (st 2013) agile software engineering