I must admit I've never participated in Extreme Programming. CNET's Project Management team doesn't really understand how to work with it so we've never really done any of our IT projects that way.
I'd be curious to hear from people who have participated in XP projects. Do these guidelines sound right? Would they have helped make your XP projects run more smoothly?
Discussion on:
View:
Show:
The programmer has the *obligation* to honestly report progress.
The programmer has the *obligation* to produce high-quality work at all times.
The programmer has the *obligation* to know what is most important to work on next.
I agree with your other points entirely
The programmer has the *obligation* to produce high-quality work at all times.
The programmer has the *obligation* to know what is most important to work on next.
I agree with your other points entirely
Wow, _you_ must really have it good! I agree with your take on honestly reporting progress. However...
Back when I had a job, the other 2 were NOT obligations; they were rights, and not always granted.
High quality work:
I managed to produce high quality work at *nearly* all times, but when you're deliberately saddled with more work than the next 2 or 3 developers could do, something will eventually give. Yes, that's called "forced failure", and it happens.
Priorities:
What's most important to do next is knowledge sometimes not granted. That's why I always prefer to work directly with the requestor - no middle man. Only then could I be reasonably sure of the priorities.
.jimh
ex- business database programmer / analyst
Back when I had a job, the other 2 were NOT obligations; they were rights, and not always granted.
High quality work:
I managed to produce high quality work at *nearly* all times, but when you're deliberately saddled with more work than the next 2 or 3 developers could do, something will eventually give. Yes, that's called "forced failure", and it happens.
Priorities:
What's most important to do next is knowledge sometimes not granted. That's why I always prefer to work directly with the requestor - no middle man. Only then could I be reasonably sure of the priorities.
.jimh
ex- business database programmer / analyst
It is not appropriate to define something as an "obligation" if there is no corresponding method to meet that obligation. Therefore, I would agree with categorizing these items as rights.
Honestly Report Progress - In a traditional Waterfall approach one has Requirements Definition, Analysis, Design, Integration, and Test, but there is nothing to say when any particular stage is done. How can one honestly report when Requirements Definition is Done? In Extreme Programming, one can report that a module passes all tests and specify the tests used. One can honestly report completeness and coverage.
High Quality Work - How is "High Quality Work" defined? With Extreme Programming, one can objectively verify that tests pass and the level of coverage provided by the tests.
Prioritization - With the Waterfall method, all steps within a phase are equal. Any prioritization that is provided by a Gantt chart or something similar is based on internal estimates of difficulty. With Extreme Programming, the customer is required to decide what on priority rankings.
Extreme Programming is the only approach I am aware of that attempts to provide the supporting methods. One may not completely agree with what Extreme Programming proposes, but at least something is proposed.
Honestly Report Progress - In a traditional Waterfall approach one has Requirements Definition, Analysis, Design, Integration, and Test, but there is nothing to say when any particular stage is done. How can one honestly report when Requirements Definition is Done? In Extreme Programming, one can report that a module passes all tests and specify the tests used. One can honestly report completeness and coverage.
High Quality Work - How is "High Quality Work" defined? With Extreme Programming, one can objectively verify that tests pass and the level of coverage provided by the tests.
Prioritization - With the Waterfall method, all steps within a phase are equal. Any prioritization that is provided by a Gantt chart or something similar is based on internal estimates of difficulty. With Extreme Programming, the customer is required to decide what on priority rankings.
Extreme Programming is the only approach I am aware of that attempts to provide the supporting methods. One may not completely agree with what Extreme Programming proposes, but at least something is proposed.
Sorry, I only just discovered this was reprinted in the USA!
I agree with some of your content, but in the first two cases the "obligation" has already been included as a customer right. For clarification, here's why these are stated as programmer rights:
The programmer has the *right* to honestly report progress - their reports should not be filtered or massaged, and they should not be punished for reporting the truth.
The programmer has the *right* to produce high-quality work at all times - XP says that high quality work is the only way to achieve our goals, so it's important that customers and managers not make decisions about the internal quality of the code, particularly decisions to 'cut corners' to save a bit of time.
The programmer has the *right* to know what is most important to work on next - programmers should not be expected to make business decisions; the customer is responsible for making decisions based on business value, and this includes what is the most valuable thing to work on next. Programmers can give advice, but they should not make the decision.
I agree with some of your content, but in the first two cases the "obligation" has already been included as a customer right. For clarification, here's why these are stated as programmer rights:
The programmer has the *right* to honestly report progress - their reports should not be filtered or massaged, and they should not be punished for reporting the truth.
The programmer has the *right* to produce high-quality work at all times - XP says that high quality work is the only way to achieve our goals, so it's important that customers and managers not make decisions about the internal quality of the code, particularly decisions to 'cut corners' to save a bit of time.
The programmer has the *right* to know what is most important to work on next - programmers should not be expected to make business decisions; the customer is responsible for making decisions based on business value, and this includes what is the most valuable thing to work on next. Programmers can give advice, but they should not make the decision.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
