Discipline In Xp
It's interesting to read that, as it is wholly inconsistant with what I've experienced. I've always found that discipline and agility/weight are independent. I'm not aware of more discipline being required for an agile process. What I have found is that disciplined developers will tweak the process more to get the ideal collection of practices for their situation. --TimHaughton (on the XpNewsgroup)
Dom: You're a bad boy. Say it.
Sub: I'm a bad boy.
Dom: What did you do?
Sub: I don't wanna say!
Dom (crack!): What did you do?
Sub: Ow! I made more than 12 edits before hitting the test button.
Dom: What do you say?
Sub: I'm sorry!
Dom (crack): Say it like you mean it!
Sub: I'm sorry!
Dom (crack!): Did the tests pass then?
Sub: OW! I learned my lesson!
--Phlip
ExtremeProgramming recommends a number of practices that are counter to some conventional wisdom. And Kent and I like catchy names for the Extreme Rules, such as DoTheSimplestThingThatCouldPossiblyWork, RefactorMercilessly, and so on. We believe that abstract design is almost universally overdone, so we recommend getting into the code as quickly as possibly. We believe that TheSourceCodeIsTheDesign (or most of it), so we eschew (bless me) most formal documentation.
However, even though it is a self-managing process, ExtremeProgramming requires very high discipline on the part of the team. Here are some examples:
- Designing
- We design using CRC and in the code itself. Within those practices, we hold ourselves to very strict principles of system quality. We keep the system well-factored so that everything is done OnceAndOnlyOnce. This gives us great flexibility in moving forward rapidly. We say YouArentGonnaNeedIt, meaning that we will build no object before its time. We don't implement functionality because we know we're gonna need it. (This is surprisingly hard to do.)
- Testing
- All code that could possibly fail must have UnitTests written by the developer who wrote the code. All UnitTests in the whole system must run at 100% before we release any code. The system must have AcceptanceTests for all functionality that the customer expects to work.
- Coding
- All developers write code to the exact same standards, within the limits of human ability. We write all production code using PairProgramming. Formatting and naming are all done just the same way. We practice CollectiveCodeOwnership. There is no "my code / your code" thinking. Everyone owns and is responsible for everything.
- Communication
- We tell the same story to everyone up and down the chain of command. We ensure that all developers know everything important about everything that is going on. We ensure that our customers know what we are doing and when we're going to be done with it. We don't do "spin".
- Planning
- We plan all our work, in three-week iterations and CommitmentSchedule's that lead to releases. Individual developers estimate how long it will take them to do things, from as little as a couple of hours to a few days. We never accept a time estimate over a week. We track our performance against estimates.
- Rule following
- The team can decide to change the rules, and we do if they aren't serving us. But while a rule is in effect, everyone follows that rule.
ExtremeProgramming is a very lightweight methodology, but one that requires very great discipline from the members of a team that does XP. It's possible to be successful by running fast and loose. But that's not ExtremeProgramming. --RonJeffries
You mean this page is not supposed to be about Ron whacking a programmer on the nose with a RolledUpNewspaper and saying "Bad, bad programmer"? -- BillTrost
I forgot to mention that part ...
That's the soft way. Kent uses a baseball bat - JosephPelrine
Just as long as everyone keeps the whip and handcuffs out of the office... -- BT
Programming (well) requires discipline. ExtremeProgramming lets one use InternalDiscipline, which for many people is preferable to ExternalDiscipline, but there is still no getting around the need for discipline. There are NoFreeLunches.