Summary:
The reading starts out with a definition of what the key roles are in an XP development environment: the customer, the programmer, and the manager.
The customer basically gives direction and focus to the group. Through the use of stories they decide what will be built, and they say what features are important to them. At lower levels they also provide value judgments- they say 'feature x is more important than feature y', and 'that's awful, scrap it'. They also answer questions about the stories they provided, giving more detailed feedback, allowing the programmers to better understand what the customer wants. From experience, a spec without an understanding of the customer will generate an unusable application. In an ideal situation, a customer is on site to facilitate a rapid feedback process, and to lower the bar for ''what's important enough to ask."
The programmer is responsible for realizing the customers wildest dreams in a timely manner. Which is to say, much of the programmer's job is what it has always been- to understand what needs to be built, and then to build it. XP places a few additional requests on the programmer. All production coding should be done by pair programming to ensure low ownership and high cross training. A working software product needs to be built quickly, and maintained. Stories or changes need to be released for customer feedback early and often. But, at the core, the programmer is still a programmer.
The manager is responsible for much of the day to day rigmarole of organizing a group. The manager is responsible for organizing meetings between the programmers and customers. He is responsible for resolving conflicts, and removing impediments to progress. The manager lacks some of the more traditional tasks usually assigned to managers: he is not responsible for assigning tasks to individuals, he is not responsible for deciding prioritizations, and he's not necessarily given a say on "What is right". In these ways, Manager is perhaps the wrong name, rather the role is better described as "Facilitator".
After the descriptions of the roles is given, a set of 'Rights' is spelled out, for both the Manager/Customer, and the Programmers. For customers the rights come down to "You can have it your way, and you can leave at any time with what's in front of you," and for programmers it comes down to "You have a right to work, and to understand what you are doing."
Chapter 2 looks at the project life cycle. Starting with the customer, a set of stories are generated for a system. Programmers will typically estimate what each story will cost, and defer back to the customer. The customer will make a value judgement for what they want, and then the programmers will do their best to fulfill the customers deepest desires. The customer can then change their mind based on what they see in front of them, and the process will repeat.
Chapter 2 also covers some basic pitfalls of XP: either promise a deadline or promise functionality, but not both. Trying to get programmers to work longer or harder will come back to bite you in the long run. It's possible that the customer will hear deadlines that they don't like, and it's better to stay to the deadlines then to make broken promises.
Chapter 3 talks about the benefits of having an onsite customer. Namely, that they provide nearly instant feedback to questions, and will remove a lot of guess work on the programmers part from the code base. It's also worthwhile because the customer can see how the development team operates, see that they are (or are not) making real progress, and establish a "rapport' between the customer and development team. Chapter 3 also addresses a few of the issues with having an on site customer, namely that they may be unable to complete their normal duties.
Discussion:
1. Why is this paper interesting or significant?
It sets a cornerstone for many of the ideas behind XP. Chapter 1 is basically an overview of the entire XP process in macro-level detail. It defines the 3 major roles in an XP team, what their responsibilities are, and how they work together. Chapter 2 defines the life cycle, the basic idea behind iterative development, and emphasizes the idea of delivering quickly to the customer.
So, it's interesting because it gives a good glimpse of things to come.
2. What are the faults of this work?
There are a few things which are... nit picky. XP as a process is great for certain 'customer centered' apps. I've used in the context of web apps many times. But it's not ideal for use in all cases. Developing a web application is entirely different from developing hard drive firmware. This is in turn different from developing end user centric applications (PLC controllers meant to be debugged by field technicians, an Office Suite). In the first, the working firmware may not be the primary artifact of the process, but rather the documentation of capabilities. It may also be less iterative, focusing less on customer interaction and more on implementing and refining the spec. In the second, the customer themselves may not know what the end user needs. While it's bad for a programmer to guess about the customer's needs, having a customer guess about the user's needs is only shifting blame, not resolving the underlying problems.
3. What is the possible future work extending from this work (i.e., if you had implemented this work, what would be your next steps – either continuing or fixing this work, taking some of these ideas and applying them to others’/your work, or starting new work from some of these ideas)?
The reading so far gives a framework for interaction. When we first go about setting up our projects, interacting with our first customers, this paper will have provided part of the framework for how that interaction will work. It may be a bit indirect, as depending on the project the customer may not have real "buy in" to the teams efforts (they may not have went out seeking a developer for a product, but rather had a developer come to them), but the overall interactions will be heavily influenced this overview.
No comments:
Post a Comment