Swe 03 (st 2013) agile software engineering

1

W. Weitershagen page 03-1

Software EngineeringFFMFH

Dr. Werner Weitershagen

Software Engineeringsummer 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.“

Que

lle: h

ttp://w

ww

.ag

ilem

an

ife

sto

.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 notcoincide with the project‘s interests:so there can be interest conflicts / target conflictsExample: 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 theright 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 softwareengineering with a lightweight methodology and lessdocumentation.

... 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 canchange – 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. Scrumdescribes a situation within American rugbymatch.

... tries to transfer the sportsmanship (Sportgeist) towardsa software developing team.

... is a lightweight management method.

... defines a sequence of 30 day iterations called sprintswith nearly constant increments.

... is made for small self-organized teams.

... cares a human component.

9



Scrum

Qu

elle

: S

ch

weitze

r, R

. (2

00

3),

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 bySprint 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 wholeteam. He is the representative of the whole team.

• ... is responsible for the enforcement of scrum rules.

• ... is tracking the progress within daily scrummeetings.

• ... is making decisions immediately within dailyscrum meetings.

• ... is supporting the team to define sprint goal and sprint backlog.

• ... is solving each kind of problem mentioned byteam 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 followingmeeting?

Is anything disturbing your work?

• ... puts themes concerning details into specialmeetings 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

Qu

elle

: S

ch

weitze

r, R

. (2

00

3),

S.

6

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:

Que

lle:

Sch

we

itze

r, R

. (2

00

3),

S. 1

3

15



Scrum

Links:

• http://www.mountaingoatsoftware.com/scrum/scrumtea

m

• Home Of Scrum: http://www.controlchaos.com

Date post:	30-Oct-2014
Category:	Education
Upload:	sarahflieger
View:	145 times
Download:	1 times

Swe 03 (st 2013) agile software engineering

Education