Ken Auer RoleModel Software, Inc. Copyright , RoleModel Software, Inc.

Transcription

1 Ken Auer RoleModel Software, Inc. Copyright , RoleModel Software, Inc.

2 Documentation is not Understanding (tacit) One Study of Typical Requirements Documents (Source: Elemer Magaziner): 15% Complete, 7% Correct, Not cost effective to increase Formality is not Discipline Process is not Skill Initial Requirements define a fuzzy view of a point on the horizon

3 Pragmatic Technical Business Academic

4 Pragmatic Technical Business Academic

5 Pragmatic Making computers do something useful without actually thinking critically Technical Business Academic critical thinking about how computers work without actually doing anything useful

6 Pragmatic Making computers do something useful without actually thinking critically Technical understanding how to make things work, wanting someone to pay them to play and gain more understanding Business wanting things to work without any desire to understand how or paying for someone who does Academic critical thinking about how computers work without actually doing anything useful

7 Pragmatic Technical Business Academic

8 Pragmatic Technical Business Academic

9 Pragmatic Technical Iron sharpens iron, Business So one man sharpens another. (Prov 27:17) Academic

10 * Alistair Cockburn, Agile Software Development, Addison-Wesley 2002

11 Requirements Design Results Plan People

12 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. *

13 ! "! Bright people are good to have I don t pay them to be bright I don t pay them to learn I pay them to produce something of value for someone other than them Bad individual things Only one who has a clue about X or Y Knows nothing about W or Z Not communicating with the people defining the value Good individual things Learning about another part of the system (or another approach) Teaching someone else what he knows about some part of the system Working each day on something the customer would like to see done AND is the operative word bright people uncovering clues and sharing the information

14 How do we engage them? End user demos and feedback on Working Software Informal planning sessions Daily or weekly meetings Case study Scientist engaged daily Representatives engaged weekly (demo, feedback, and prioritization) Planning with scientist weekly Sponsors involved in planning bi-weekly or monthly Sorting out cards

15 !#$ Person defining system pays for everything out of his own pocket Gets immediate feedback when he made a good/bad decision Good: Profits Bad: Feels a loss Though he only makes good decisions Can anticipate every change in the market Can efficiently negotiate the best price/value point Is given accurate options and estimates from multiple sources Is not locked into using any particular person/team to make stuff happen Can instantly find and engage the best sources for each feature

16 %&' $ Person defining the system makes educated guesses about the value and cost of everything To the nearest $1000, $10,000, Recognizes his own cost and cost of requests Recognizes the cost of delaying vs. acting on what they know Recognizes the value of being able to change a decision Focus on revenue stream and cost stream Everyone on the team is focused on providing the best value for the least cost Provides customer with educated guesses about options/costs Always looking to improve, but not fixing what ain t broke Thinks about the best way to get what s most important Without being so short-sighted that they ll be sorry

17 ( ") Absence of trust Fear of conflict Lack of commitment Avoidance of accountability Inattention to results These Need to be Attacked Every Day!!"#$ %&'&()%&*)

18 * XP is setting up a game which attacks dysfunctions daily Two categories of rules: Rules of Engagement The big picture These are similar to what I suspect the rules for most agile methodologies are about There are those doing SCRUM/XP SCRUM is basically used as the strategy for the Rules of Engagement Rules of Play The basic daily activity This is what happens every day, to make sure the details are being followed through on Most other Agile methodologies don t appear to have them This is daily accountability ++, / 0-

19 1. An XP team consists of a group of people dedicated to the production of a software product there must be at least a customer and a developer role. 2. The customer must set and continuously adjusts the objectives and priorities based on estimates and other information provided by the developers The customer is always available and supplies information on demand to assist developers in forming estimates or supplying desired deliverables. The customer is an integral part of the team. 4. At any point, any member of the team must be able to measure the team's progress towards the customer's objectives. 5. The team must act as an Effective Social Network, this means: a. Honest communication leading to continuous learning. b. Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs. c. Alignment of authority and responsibility. 6. Timeboxing is used to identify segments of development effort and each segment is no more than one month in duration.

20 ) 1. Work produced must be continuously validated through testing. 2. Write unit tests first (before coding), Program in pairs (if there is more than one developer on the team), and refactor code to meet Coding Rules (P3) while working on current customer priorities. 3. All code written for potential use in the software product must a. Pass all the unit tests (or not make any unit tests fail) b. Clearly express every concept c. Contain no duplication d. Contain no superfluous parts 4. Collective Ownership. Everybody has the authority and at least two people have the understanding necessary to do any task.

21 Requirements Design Plan People Code? Potential Value!