QCon 2007 - What I learnt about process - Part 2

Going through my notes I discovered this useful map of an agile life-cycle. I think it came from Rachel Davies's session on user stories.



As text it reads:

Bird's eye view of life cycle

Exploration

Explore

• business domain
• technology
• process
• scope

Keep as short as possible (< 2 weeks)

Release planning - create roadmap of releases

• May not happen until some initial iterations
• Flesh out plan as you progress
• Deliver high risk / high value items early
• Set concrete release dates but vary features

Iterations

Production - aim is to arrive here ASAP

Planning phases

Customer needs

Implementation considerations

Implementation tasks

Estimated task list

Customer reviews effort vs. necessity

UI Design is often done an iteration ahead,
to help users & team understand what is required

QCon 2007 - What I learnt about process

A post in a series that summarises what I learnt at QCon 2007.

This post focuses on development processes.

For a mind map version, click here

Inspiration came from the following excellent sessions:

• Agile Leadership Tutorial - Diana Larsen
• Usage-Centered Design Tutorial - Larry Constantine
• Modifiability - Martin Fowler
• Operational Manageability - Dan Prichett, ebay Technical Fellow
• User stories and release planning - Rachel Davies
• Test driven development - Steve Freeman
• Agile PM: The Googley Way - Jeff Sutherland
• The Yawning Crevasse of Doom - Martin Fowler & Dan North

Implementing change

• Have retrospective to establish SWOT's to address
• Prioritise cultural changes each iteration / project
• Do simple things well, then focus on clever/hard things

Agree on principles as early as possible, e.g.

• design
• unit testing

Key success ingredients are

• Encapsulation
• Classes should "keep secrets"
• Tell, don't ask
• Prefer private over public
• Leads to more readble code
• Keep the domain model clean of non-domain code/entities (e.g. UI, DB)

• Do the simplest thing that will work (not the same as doing the easiest thing)
• Making code test driven: lowers cost of change
• Test for required behaviour not implementation
• Refactoring is the second leg of TDD (first being testing)
• Growing better developers is best investment that can be made in a team
  

Use risk maps

Bridges and ferries

• Bridges:
• Promote activities that build bridges between developers and the business
• Encourage activities that have feedback
• Minimise "distance between" developers and the business
• Consider co-locating developers and end-users
• Don't build "ferries", that distance or separate developers from the business

User stories

Less is more

• Tool for collaborative planning, i.e. purpose is to encourage communication between stakeholders
• Facilitates collabrative dynamics, via the 3 C's:
• Card
• Conversation
• Confirmation
• Can exist alongside more formal and comprehensive documents
• Aim is to write less sooner, to minimise cost of change
• Sometimes prior analysis should be done to understand problem domain, before moving onto stories

Why's and how's of a story

• System "commisioner" provides "why's"
• End users can provide "how's"

Format

• As a I need so that .
• e.g. As a book buyer I want to find a book by entering the ISBN number, so I can locate it quickly
• OR simply state user goal
  

Scrum

Minimise "work in progress" - "Done" means system and acceptance tests pass

Minimal process

• Artifacts
• Product backlog
• Spring backlog
• Burndown chart
• Meetings
• Sprint planning
• Daily meeting
• Sprint review
• People
• Product owner
• Scrum master
• Team

Builds

Include rollout script for use by Operations.

QCon 2007 - References to follow up on

Various resources that I haven't got round to looking at yet, but are worth doing sooner...

• Behind closed doors - people management
• Don't make me think - user interface design
• Maverick - business management
• How buildings learn - architecture
• thinktecture.com - resouces for WCF
• fitnesse.org - web based acceptance test framework
  

QCon 2007 - What I learnt about architecture

This is the first post in a series that summarises what I learnt at QCon 2007.

This post focuses on solution architectures.

For a mind map version, click here

Inspiration came from the following excellent sessions:

• Amazon Technology Platform - Werner Vogels (CTO)
• Putting qualities into architecture - Kevlin Henney
• Modifiability - Martin Fowler
• Operational Manageability - Dan Prichett, ebay Technical Fellow
• Agile Architecture is not Fragile Architecture - Kevlin Henney and James Coplien

Replacing Amazon's architecture

• Monolithic application to SOA
• Took 6 years
• Cost $2 billion
• Only 30% of cost delivered visible business value
• 70% was on the "heavy-lifting"

Architecture relates to

• how it runs
• how it fails
• how its developed
• how it changes during
• development time
• run-time

Architecture is interwoven with the development process

Operational manageability

• Design for
• operational configuration
• operational monitoring
• failure (no SPOF's)
• Maintain clear dependencies
  

Design up-front the parts that are costly to change

• Reduce the significance of remaining decisions
• Defer decisions to the last responsible moment
• Metric is cost of reversing decision
• e.g.

• testability
• security
• maintainability
  
• performance
• Its like putting stones in a bucket.

How much up front design (UFD)?

• BUFD - Big
• RUFD - Rough
• NUFD - None
• Time spent should be inversely proportional to
• Knowledge of domain
• Experience in design

Quotes

• "A stable architecure is not the same as a frozen architecture"
• "Doing the simplest thing that works is not same as doing the easiest thing"