misc

Responding to "What about design?" -> refactoring, siplicity  page 103

Have references memorized: Winson Royce (waterfall), Tom DeMarco and Laurie Williams (pairing), Steve McConnel (exponential cost increase)

As in a consultant-client relationship, a good first question is: "If you could improve one aspect of your projects, what would you change?"

When confronted with questions about architecture, respond with: "But imagine if it was possible to develop in this way and have superior architecture, would you want to know more?"  This is also a good opening to begin discussing the practices of this approach, the practices that allow it all to happen.

slide 0

The bottom line: What does this approach deliver?  How does it maximize business value? 


slide 1

Defining the four properties of business value


slide 2

Diagram the waterfall with assumed cost increase chart.

Waterfall assumes that the later changes occur, the more costly they will be.  Waterfall minimizes costs through spending a lot of time "up front", thoroughly designing the system.

With Waterfall, the sponsor must stick with the original priorities for the entire process or accept a higher cost or delayed release date.

The agile approach assumes that it is extraordinarily to difficult to get the system communicated and designed correctly on the first try.  Iterative Development minimizes costs by increasing the frequency and amount of feedback between the system, the development team, and the business sponsor. By ecouraging the sponsor to steer, the current business goals are always the top priority.

Iterative has an excellent side effect: improved estimates.

Draw the steering chart with assumed cost increase chart.

Steering is the critical aspect of this approach.  Maximizing business value is absolutely dependent on the customer steering development.  If the customer isn't steering, the final product will not match up with what the customer actually wants on the release date, regardless of what they said they wanted at the beginning of the project.

The customer prioritizes which features should be implemented first.  This ensures that the system always has the most possible value.

Business value is maximized through not doing what they don't need:  "barely sufficient"

Features
o o o o o
o o o o o  Set of requested features
o o o o o

1 o o o o
o o 1 o o  First iteration
1 1 o o o

1 o o o o
2 o 1 o 2  Second iteration
1 1 2 o 2

1 3 o 3 o
2 o 1 3 2  Final iteration: the "o's" represent business value...unneeded features
1 1 2 3 2


slide 3

So how do we implement the features the customer wants?  This approach pays attention to implementation.  In order to be responsive to change, a set of practices are used to keep the system simple, clean, and flexible.  The practices also increase developer accountability and therefor productivity.


slide 4

Refactoring is dependent on TDD

Rename Method
Customer	 Customer
getInvCrtLmt  -> getInvoiceableCreditLimit

Decompose Conditional
if (date.before(SUMMER_START) || date.after(SUMMER_END))
	executeSomeMethod();

if (notSummer(date))
	executeSomeMethod();


slide 5

* TDD is dependent on Pairing
* Talk about Barely Sufficient vs. Overdesigned


slide 6

Pairing has many benefits


slide 7

CI is dependent on TDD


slide 8

* Collective Ownership is dependent on CI and TDD
Jeffries: CO lets the team make faster progress because you don't have to wait.  The code stays cleaner because you aren't working around deficiencies
* Coding Standard facilitates Pairing, Collective Ownership