At ''[some given company]'' we are trying to settle on a methodology: We'd like to use ExtremeProgramming, but expect resistance from the CMM or BigDesignUpFront camps. How can we address questions like the following... * A lot of our contracts are fixed price. How can I estimate with XP how long the next project will take? How do you estimate the number of people? * One of the persons has some confusion. He sees the benefit of doing CRC and just going and writing the code, but what about the situation where the you are writing some code before other code is even designed and there are dependencies? * On PairProgramming. There is lots of code that is mindless and some that is tricky. Would it make more sense to have two people work on the tricky code and do the mindless code individually from each other? * UnitTest''''''s. How much work goes into writing a UnitTest? What is the % of total work? How do you schedule it? * Are there some techniques to get the customer to tell you things that they will tell you when they see a finished program? * There is concern on good people versus average people. How does XP work with average people? What if we were bringing in new people or right out of school? * How does XP work with third-party components? We do a lot of Web projects, where we have to use Web Servers from one place and pieces from another. How do you fit them together and ensure quality? * What is the best way of using a shared repository system (e.g. CVS) when migrating changes from pairs to a separate integration machine? Should branches be created for each new piece of work and then only merged when the integration machine passes the unit tests? Or should developers avoid committing into the repository until unit tests have passed, and generate some kind of 'patch' against the latest build to apply to the integration machine? * ''[Add your project's questions here.]'' ---- DonWells replies... * A lot of our contracts are fixed price. How Can I estimate with XP how long the next project will take? How do you estimate the number of people? Use the PlanningGame. Let the business people decide how many people by dictating when it will be done, however, let the technical people keep it reasonable by dictating what the maximum number of people will be. * One of the persons has some confusion. He sees the benefit of doing CRC and just going and writing the code, but what about the situation where the you are writing some code before other code is even designed and there are dependencies? This is a symptom of trying to do too much all at one time. Pick one card and SitOnTheOtherCards. Also related to YouArentGonnaNeedIt in that you are obviously getting ahead of yourself. * On PairProgramming. There is lots of code that is mindless and some that is tricky. Would it make more sense to have two people work on the tricky code and do the mindless code individually from each other? Do all the code in pairs so that all your code will be equally reliable and understandable. * UnitTest''''''s. How much work goes into writing a UnitTest? What is the % of total work? How do you schedule it? I have been criticized for saying this: It takes as long as it takes (ExtremeProgrammingChallengeFourteenSplit). During the life of a project an automated test will save you at least 100 times the cost of creating it. Therefore, the harder the test is to write the greater your savings. However on a more practical note: Usually twice as much to test as to create, about, kinda, sorta, you might say. You include UnitTest time when you estimate how long something will take. Remember that coding goes faster if the tests are written first so that does not mean everything takes 3 times as long. In reality it takes less over the life of the project. Obviously experience is required to be able to create good estimates, so start learning now. Never, ever schedule it separately. It is the second thing to be cut by managers. Code reviews (and PairProgramming) are the first. * Are there some techniques to get the customer to tell you things that they will tell you when they see a finished program? You try to deliver something as soon as possible. Use the PlanningGame to determine what the smallest set of functionality that makes good business sense would be. Also keep your customers and users involved in writing UserStories and creating the AcceptanceTest''''''s. * There is concern on good people versus average people. How does XP work with average people? What if we were bringing in new people or right out of school? XP is designed to work with average people. The team is stronger than the individuals. * How does XP work with third-party components? We do a lot of Web projects, where we have to use Web Servers from one place and pieces from another. How do you fit them together and ensure quality? RonJeffries is the expert on this. He has written something about using a third party tax package with ChryslerComprehensiveCompensation, but I just can't find it right now. What I remember is we created AcceptanceTest''''''s which included ensuring that the tax package gave good results. -- DonWells ---- * Are there some techniques to get the customer to tell you things that they will tell you when they see a finished program? One of the advantages of UserStories versus UseCases is that your customer writes the user stories in a language that they actually understand. With a user story you write out what the system is going to do for the customer in business terms. They can then review the stories, add stories, or delete stories. They can tell you which pieces are more valuable. This is different from specifying exactly how the system will interact with itself and the stick figures, er, I mean users. A user story is just enough to allow you to estimate the scope of the task without making a technical or design commitment. Then when you implement the story you talk to the customer and get the details in the context of the system under construction. You discuss what is, or is not possible. You show the customers prototypes. You run the embryonic system with command lines having the customer at your side. With use case analysis the goal is often to completely specify the system up front, guessing at what may or may not work. With the XP approach your customers tell you what they believe is valuable to include in your system even as the system is being built. This is different from finding out what they would have included if only they had known it was possible. * What if we were bringing in new people or right out of school? XP is an ideology that goes against the grain of many established methodologies. Kids right out of school are very idealistic and rebellious. It should actually be a good fit. * On PairProgramming. There is lots of code that is mindless and some that is tricky. Would it make more sense to have two people work on the tricky code and do the mindless code individually from each other? Getting PairProgramming started is really really hard. I have been through it twice now. In both cases we started out with pairing made optional in some way. Both times pairing didn't happen. Only when the rule that all code intended for production release must be pair programmed did pairing begin. One experience that has served me well was when I was a wannabe game designer. I went to seminars and lectures on designing systems of rules that would be fun to use. One very important thing I learned is to keep the rules both simple and concise. If you have exceptions to the rules then you must add more rules to govern the exceptions, and rules for exceptions to the exceptions and on and on. People arguing about what can be programmed individually and what must be paired will suck the fun out of your project real soon. -- DonWells again ---- Don, Thanks! Ron and Others, more comments? ----- I do not claim to be an ExtremeProgrammer, but I'd like to pitch in a few comments anyway: * A lot of our contracts are fixed price. How can I estimate with XP how long the next project will take? How do you estimate the number of people? A general rule for adopting a new methodology that promises dramatically improved productivity: '''Continue using your existing (old) methods to estimate the first few projects.''' It's likely that the new techniques won't produce as dramatic results as optimists were hoping, and it takes time for the team to learn and adopt the new techniques. After you're successful with the new techniques, it's time to adjust the project estimating process. * One of the persons has some confusion. He sees the benefit of doing CRC and just going and writing the code, but what about the situation where the you are writing some code before other code is even designed and there are dependencies? If A depends on B, do B first. ''(...same as with any other methodology.)'' To do ExtremeProgramming, you must be willing to change code that is already working. The "simplest thing that worked last week" may not be good enough to meet this week's requirements, so you'll have to change it. That's OK: Well factored code (RefactorMercilessly) will be easier to maintain than typical systems you've experienced in the past. Try it; see how it works. * On PairProgramming. There is lots of code that is mindless and some that is tricky. Would it make more sense to have two people work on the tricky code and do the mindless code individually from each other? Some of your staff is inexperienced: SellPairProgrammingAsTraining. (Yes, it's a lot more than that, but PairProgramming does work very well as a training technique.) You shouldn't be writing mindless code. In my experience, writing large amounts of "mindless code" is a symptom of inadequate code reuse: Doing CopyAndPasteProgramming is mind-numbingly easy, but it reveals a failure to factor out common code into reusable functions and objects. * UnitTest''''''s. How much work goes into writing a UnitTest? What is the % of total work? How do you schedule it? As I understand it, IdealProgrammingTime, as estimated by the developer, should include it. Without XP, when you ask a developer how long it will take to get function X "done," you assume they'll do at least minimal low-level testing, don't you? Thus, without XP, programmer estimates must include UnitTest''''''ing, right? XP is no different, except that it makes it harder to get away with cutting the schedule by doing inadequate testing. * Are there some techniques to get the customer to tell you things that they will tell you when they see a finished program? XP has a clear advantage here because it has an IncrementalDelivery strategy: Your customer will be able to see a (partly) finished program much sooner in the process. Waterfall approaches can't do this. (...without prototypes and attendant "put the prototype into production" problems.) * There is concern on good people versus average people. How does XP work with average people? What if we were bringing in new people or right out of school? Again, SellPairProgrammingAsTraining. It's the best training approach if you have a mix of people of differing skill levels. Everyone learns. Actually, paring improves skills even if everyone is average: Every person, bringing a different background of experiences to the table, can contribute knowledge that the other person missed. Even experts can learn from novices, because our field is so diverse and deep with technical detail. * How does XP work with third-party components? We do a lot of Web projects, where we have to use Web Servers from one place and pieces from another. How do you fit them together and ensure quality? Some XP writers on Wiki seem to discourage reuse. This is silly. Reuse is your friend: buy instead of build, when you can. On any OO project (with or without XP), you should encapsulate 3rd party components with wrapper classes (FacadePattern). If the 3rd party interface is not OO (like ODBC), then you have another good reason to wrap it. If you intend to swap 3rd party tools ''(even if they claim to conform to a "standard portable interface!")'' then you have an even more compelling reason to wrap them. You don't have to write test cases for everything the 3rd party components can do. However, you should be willing to write test cases for critical pieces of functionality that you use, particularly if such features are not well documented and widely accepted in the industry. Buy from reputable vendors. Report bugs to them if you find them. ''(Otherwise they'll '''never''' get it right. ;-)'' I hope this helps! -- JeffGrigg ---- I myself would not SellPairProgrammingAsTraining. For one thing there will come a day when it is expected that training is over. At that point it will be expected that you break up the pairs, but also you will be expected to produce twice as much. My experience is that you will produce less. The second thing is that if you pair experienced with inexperienced right out of the starting gate you will set up teacher-student relationships and those are not pairs. PairProgramming has a give and take between equals that can be hard to achieve and accept. The best way to start is to have the experienced people working together and the inexperienced people working together. Try to pair people together that will form an equality relationship. A shy experienced developer could work well with a fresh out. If you have a bully on your project you must watch for disruption of the pairing. Once pairs of equals are established then begin to mix them up. If you have advertised PairProgramming as training you will not be able to pair equals together. -- DonWells ---- Regarding the answer to * A lot of our contracts are fixed price. How can I estimate with XP how long the next project will take? How do you estimate the number of people? A general rule for adopting a new methodology that promises dramatically improved productivity: '''Continue using your existing (old) methods to estimate the first few projects.''' ''The thing that makes that difficult is understanding the impact of applying PairProgramming to my estimates. Typically there will be a few domains of expertise on a project (business logic, database, middleware, gui, etc) and the projects will be small in scale so that in many instances I have spec'd 1 individual per domain. (Gui done in html, middleware done in Java, or ASP, or Corba objects, or DCOM, databases done in SQL). I was hoping that the answer would be, "Use twice the people, take half the time" so that I could cost justify PairProgramming on my bids.'' -- TonyReno ''What evidence exists indicates that PairProgramming takes you faster than Singleton to the same level of quality. So if you estimate the speed of N people, and then use them in pairs, you should go faster. -- RonJeffries'' ---- I'm also interested in learning more about ExtremeProgramming. I'm ''[on a team with questions like those above]''. I'm new to ExtremeProgramming, and I'd like a good, quick starting point to learn about it. -- PaulWarner ''Try ExtremeProgrammingRoadmap and http://www.xprogramming.com. Or, for best results, hire one of the XP guys to come teach a course or boot camp. -- RonJeffries'' ---- We are 3 months into a good sized project which we have done under XP from the start. The business and developers are fully committed to XP and see the potential. We are trying to go by-the-book with this and really implement XP the way it is in the books and in the XP Immersion class. What we are finding is that as the project gets bigger, some of our problems aren't going away, and others are getting worse. Don't get me wrong here - there are many things that are going very well to include pair-programming, tests, customer involvement, xp process. There are three key things (and probably others) that aren't as smooth as I think they should be. 1 Our AcceptanceTest''''''s are getting harder and harder to reconcile at the end of each story. As the test base gets bigger, there are more and more broken tests each story and they take longer to resolve. Does anybody know if this gets better at some point? 1 We are using CVS as our code repository because it is built into our IDE, is easy to get going with, and does parallel development. We get nasty collisions fairly often and cause grief and wasted time when people have to chase CVS merge misses around in the code. We can use whatever makes sense, but I don't want to waste even more time experimenting with tools that won't do what we need. Does anyone have recommendations on things like CVS, ClearCase, MKS, that have been best suited for XP projects? 1 We are using Java and a product called BusinessWare as the building blocks for the project. Java is a robust popular language well-suited for XP, but BusinessWare is a bit more ornery. The BW product doesn't use source code in all of its development; some is done graphically. It is also not really meant to be worked on in a concurrent development mode. Because of our commitment to XP, we have spent much time and energy trying to get BW to a point where we can do concurrent development,do as much as possible in source files, and do UnitTest''''''ing inside the product. The stuff we have done has helped a great deal, but the process is not completely reliable since BW isn't perfect for this technique. Last question is, we want to keep this under XP so is there something special we should do with this product to get it to fit better inside or alongside XP? Sorry for so many questions, but I really appreciate and look forward to hearing any and all thoughts/ideas/experiences people have on this. -- CollNicolson ---- CategoryExtremeProgramming