ESSAP Agile Loops

Post on 01-Jul-2015

201 views 0 download

Transcript of ESSAP Agile Loops

Agile loops

from jargon to understanding

(cc) F. Gobbo, S. Gentilini, F. Bertone, V. Del Bianco,please refer to: federico.gobbo@uninsubria.it

Dipartimento di Informatica e ComunicazioneUniversità degli Studi dell'Insubria

Acknowledgements

This is a derivative work from the talk "XP loops"presented in XP BE 2007

by

• Vera Peeters (Tryx)• Pascal Van Cauwenberghe (NAYIMA)

Wannabe Agile?

What Agile is not

• Not a panacea.

• Not a silver bullet.

It doesn't tell you if a project is worth starting.It tells you how to start and when to stop in time.(c) artwork / graphic by Michael Whitehead for Next 16-9-2003

Ready to start?

Start from your (onsite) customers...

Business decisionsare taken by thecustomers

Technical decisionsare taken by thedeveloper team

...and trust!

Principles and values• Collaboration instead of negotiation

User stories

• Customers tell:

the value

• Developers tell:

the price

Don't show the kitchen, serve the dishes!

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation

Small releases• Steering and adapting

• Short-time planning

• release = iteration (XP)• release = sprint (Scrum)

• Timeboxing everywhere

Be realistic, don't pretend to look in a crystal ball!

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!

Planning game

How much business value can you deliverin the next release? • Pair writing

• Product backlog

Delivering business value early and often

Principles and values• Collaboration instead of: negotiation• Communication instead of: requirement elicitation• Feedback, feedback, feedback!• Business value instead of: overdesign & unused features

Sustainable pace

Find your natural rhythm of work

(for all involved!)

• Think about the long run• No overtime

Our suggestion: the Pomodoro Technique

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending

Daily Standup Meetings

3 questions:

• What I have done?• What I will complete today?• I need help with...

Keep it short!

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day

Pair Programming

Two programmers work together at one keyboard:

driver types in code,

observer-navigator reviews code and considers the strategic direction of the work.

Not for everyone...

Pair Programming and Productivity...

PairProgramming reduces productivity! That would be true if the most time consuming part of programming was typing... Martin Fowler

– Start with a reasonably well-defined task

– Agree on one tiny goal at a time

– TDD please– Rely on and support your

partner– Sync up frequently– Be especially courteous– Take a moment to celebrate– Often switch roles

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism

Unit Tests

Automated test that validates that units of source code are working properly.

Test cases written in the same language as the production code.

Each test case is independent from the others.

So what?

– Safety Net– Facilitates change– Facilitates refactoring– Simplifies integration– Documentation– Design– Separation of interface from implementation– Force code being testable– ...

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time

Test Driven Development

without

inmagine.com

with

forbes.com

Test Driven Development

write a test

implement code to pass the test

refactor

testdriven.com

forbes.com

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence

Refactoring

without with

Refactoring

clean code that works!

get rid of smelling code:

duplicationlarge classeslarge methods

long parameters list etc etc..

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity

Continuous Integration

• Small steps• Small changes• Small problems

Integrate frequently (multiple integrations per day).

Each integration is verified by an automated build.

Not so easy...

Once you are there, great benefits:• Control• Visibility• Early warnings• Availability of a

"current" build

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control

Collective Code Ownership

Everyone can contribute to everything

Any developer can change any line of code

Everyone is responsible for all the code

No one person becomes a bottle neck for changes

Prerequisites and Alternatives

Prerequisites, at least:CodingStandardsVersion managementUnit tests

Alternatives?CodeStewardship...

So what?Define who ones the code! More "collective", is better, but has more prerequisites

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control• Trust your teammates

Acceptance TestsCustomers specifies scenarios to test when a user story has been correctly implemented

A story can have one or many acceptance tests

Acceptance tests are black box system tests

Customers sign completed stories when their acceptance tests pass

Acceptance Tests HowTo

– Written at the start of each iteration– Start a story executing acceptance tests– Write unit tests– Keep adding unit tests and production code

until all the acceptance tests pass

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control• Trust your teammates• Working software is measure of progress

Velocity

Velocity is the rate at which you complete your work, in a certain period of time.

In project management terms: velocity is the amount of work that a team can complete in a specified period of time.

Velocity and Burndown

Velocity to make commitments in future iterations

If a team does not know its velocity, how will that team be able to know how much work to put into an iteration?

Burndown to meet commitments in one iteration

If a team doesn't focus burndown, it is probable that the team will miss the scope of the iteration

Open Workspace

Self-organizing teams

Collaboration

Comunication

Trust

Simplicity

Self-organization

Feedback!!

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control• Trust your teammates• Working software is measure of progress

μεταφορά: "a transfer", in rhetoric "transference of a word to a new sense", from μεταφέρω - metaphero, "to carry over, to transfer"

Metaphor

Shared Vision Ubiquitous Language Communication Simplicity

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control• Trust your teammates• Working software is measure of progress• Shared understanding

Retrospectives

Principles and values• Collaboration instead of negotiation• Communication instead of requirement elicitation• Feedback, feedback, feedback!• Business value instead of overdesign & unused features• Respect for people instead of pretending• Small, realistic chunks of work every day• Fun and quality instead of heroism• Quality work every time• Technical excellence• Simplicity• Be in control• Trust your teammates• Working software is measure of progress• Shared understanding• Continuous improvement

Agilemanifesto.org (re-read it!)• Individuals and interactions

• Working software

• Customer collaboration

• Responding to change

Naturally non-fondamentalist:many methodologies,many technologies.

over processes and tools

over comprehensive documentation

over contract negotiation

over following a plan

based on the community!

Thanks for your attention!

Questions?The answers during this week!