pair programming, tdd and other impractical things

Post on 15-Jan-2015

27.241 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.

TRANSCRIPT

Pair Programming, TDD and other

impractical things

by @_md

I coach teams intocollaborative software development

software is about people

software is not as much about Øs and 1s

Ø1 1 1ØØØ1ØØ1 1 1ØØØ1ØØ1 1 1ØØ1 1 1 1 1 1ØØ1 1 1Ø 1 1 1ØØØ1ØØ1 1 1ØØØ1ØØ1 1 1ØØØ1ØØ1 1 1ØØØ1ØØ1 1 1ØØØ1ØØ11 1ØØ11 1 1 1 1ØØ11 1 1 1 1 1ØØØ1ØØ11 1ØØ1Ø11 1 1ØØ11 1

as it is about Xs and Ys

it’s people who{use it

it’s people who{use itdevelop it

it’s people who{use itdevelop itorder it

it’s people who{use itdevelop itorder itaccept it...

coding is not as hard as collaborating

1impractical thing #1

Listen to your customer

Customers change their mind all the time

Customers don’t know what they want

Customers are too busy to get involved

If I listen... BANG! Scope creeps in!

Customers want everything!

I keep adding and removing must haves

impractical

why do I need to listen?can I please just sit and write my code?

http

://w

ww

.pho

tore

e.co

m/p

hoto

s/pe

rmal

ink/

1379

88-2

2339

026@

N00

“Nobody wants a washing machine just to have a machine, but to have clean clothes.”

– Jon Sundbo

When to listen?

Continuously

project mission sprint visionsprint planning sign off retrospective

First create a project mission

based on business goals...

not scope!

project mission sprint planningsprint vision sign off retrospective

http://impactmapping.org

WHY

WHO

HOW

WHAT

HOW

WHAT

WHAT

WHO

HOW

WHAT[Adzic 2012]

impact map

Include a sprint vision (example) workshop

in every iteration, prior to sprint planning

project mission sprint planningsprint vision sign off retrospective

Goal of sprint vision (example) workshop

To define sprint vision and acceptance criteria

As an <actor>I can <behaviour>So that <value>

Given <pre-condition>When <act>Then <expectation>

produ

ct ba

cklog

What if the customer isn’t available?

proxy

Write the form for the comment area

1/2 d

produ

ct ba

cklog

sprint

backl

og

sprint planningsprint vision sign off retrospectiveproject mission

sprint planningsprint vision sign off retrospectiveproject mission

sprint planningsprint vision sign off retrospectiveproject mission

2impractical thing #2

Test Driven Development

It takes time to learn TDD

How can I test something I haven’t done yet?

The team is not confident they can do it

It’s legacy. The code is untestable

Customer is not paying for tests

My manager doesn’t give me time to test

impractical

requirements

designanalysis

codetest

deploy

requirements

designanalysis

codetest

deploy

9 months

most of the cost in software comes from

feedback delay

user stories

testconversation

codedesign

deploy increment

user stories

testconversation

codedesign

20 min

deploy increment

test

coderefactor

test

Arrange

Act

Assert

test

Arrange

Act

Assert

Write the code you wish you had

code

Change the message or get it green, not right

refactor

Now get it right. Without modifying behaviour.

refactor

1. All tests run and pass2. Remove duplication3. Remove opacity4. Remove complexity

results in code

1. Testable2. Modular3. Expressive4. Simple

lack of tests breaks inner quality

1. Viscosity2. Immobility, Rigidity, Fragility3. Unreadable4. Complex

THE CODE IS TERRIBLE!!WE NEED ONE SPRINT TO REFACTOR

Refactoring: changing the structurenot the external behaviour

– Fowler, 99

There is no refactoring without testsThere is no testing without refactoring

“Code is a representation of design” – Jack W. Reeves

refactoring === design

Agile without TDD*is like cinema without popcorn

*or similar practice

3impractical thing #3

Focus on Quality over Schedule

The budget doesn’t cover quality

There is no time for quality

It’s a very simple project

We’ve done it thousand times

Quality is vague, deadlines are real!

Do the needful now. We’ll come back to it later

impractical

Quality is like onions

Outer Quality

Inner Quality

http

://w

ww

.flic

kr.c

om/p

hoto

s/m

onte

regi

na/4

1033

1783

2/

Outer Quality

Works as expected

Looks like expected Focused on goals

Built efficiently

Inner Quality

Modular

Simple

Testable

Expressive

Lack of Outer Quality Causes...

Rework

Bugs

Missing deadlines

Going over budget

Relationships deteriorate

Low Morale

Unusable systems

Project abortion http://www.flickr.com/photos/hayeycart/5900737110/

But what causes poor Outer Quality?

Lack of automated acceptance tests

Lack of customer involvement

Team not focused on Project Mission

Lack of Inner Quality

Lack of automated acceptance tests

Lack of customer involvement

Team not focused on Project Mission

Lack of Inner Quality

Focus on schedule

Haste

Fear

Re-work

Low morale

Focus on quality

Do the right thing

Align with goals

Achieve

Pride

How do you ensure Outer Quality?

Example workshops

Automate acceptance tests

Have a sprint vision statement

Sign off during Sprint

How do you ensure Inner Quality?

TDD

CI (tests, static analysis) from day one

Pair Programming or at least Peer Review

4impractical thing #4

Pair Programming

Why isn’t everyone else doing it?

2 resources 1 task? do the math!

They will just chat and not get anything done

I do all the work the other guy just looks

How do you track the time per task?

Geeks don’t want to talk to other people

impractical

2 developers

sharing a screen

working on the same task

What is Pair Programming about?

Jon Jagger’s Principles of Improvement

Company

Addiction

Feedback

Visibility

Success

Provocation

Pair programming is about improving faster

One of the few proven agile practices

“Strengthening the casefor pair programming”

bit.ly/pair-case

Should pairs be kept together?

Who to pair with who?

Important stuff

✓ Focus on the code

✓ Use the test list✓ Don’t “I-show-you” your pair

✓ Time box decisions

How do I learn this?

5impractical thing #5

Code Katas

What? Write code and delete it? What?

Who’s paying for that?

I am already working 9 to 5

Solving a problem that has already been solved?

I am committed to a sprint

I have a release, can’t join you today

impractical

“Adults don’t think their way into a new way of acting.They act their way into a new way of thinking” –

Richard Pascale

✓ 1 hour every week

✓ developers go to a meeting room

✓ do TDD in pairs

✓ 20 mins each round

✓ at the end of each round:

✓ delete the code and swap pairs

http :// lmgtfy.com/?q=code+kata

“We have a great tool in this language. We can kill it by making a mess. We can kill it by being

arrogant. We can kill it by ignoring the enterprise.”

I work here

I contribute here

I tweet here @_md

Marcello Duarte

Thank you !

Questions or Comments?

looking for a new challenge? inviqa.com/careers

joind.in/8110 slidesha.re/13sYRzS

top related