Procedures


Students cannot devote 40 hours per week to a single class, and they are not, in most instances, seasoned programmers. Twelve XP "practices" are listed in Chapter 10 of [Beck2000]: the planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards. To accommodate our restrictions, we tried to simulate only those practices that were feasible in our situation.

There were two groups of 11 students, each working on one of the following projects: a MathML editor and a floor plan drawing tool. Once into the project, each team had two 50-minute periods and one two-hour period per week in a computer lab where we could simulate an XP working environment. Some XP practices were not simulated. We were unable to provide on-site customers for either project. Neither did we have students attempt to estimate the time it would take to complete a task (planning game). Estimates would be guesses at best, because most of our students had limited experience in implementing the types of tasks their projects required. Other practices such as developing a guiding metaphor, continuous integration, small releases, and refactoring we chose to encourage but not require. What we did require was that the teams develop coding standards, write unit tests, program in pairs, and practice collective ownership.

The student teams were responsible for devising the details of how they would proceed within these guidelines. Near the end of the course, all students completed a questionnaire concerning their impressions of XP (see the sidebar Questions Used in the Survey). They also wrote a short paper in which they were asked to evaluate the experience in light of what they now thought it might be like to work professionally as a developer.

Questions Used in the Survey

Extreme Programming Your Reactions

Please answer the following questions concerning our use of the Extreme Programming method. You need not sign this sheet unless you so desire. The answers will in no way affect your course grade.

Coding Standards. Your group established coding standards near the beginning of the process. Did you follow those standards in the code you wrote for the project? If so, was it difficult? (If you did primarily other things than develop code, indicate so.) What percentage of your group followed the standard? Do you think it was easier to read and modify others' code as a result of the standards?

Unit Testing. Did you ever really write unit tests before starting to code a class? (Or even in conjunction with coding the class.) Did you ever use the tests developed by the group as you changed or refactored code? (If not, give some reason.)

Collective Ownership. Was there a feeling of group ownership of the project code? How did you like the fact that anyone in the group could change code you had written? Was that a help or hindrance to the progress of the project?

Pair Programming. Did programming in pairs make the process go more quickly or do you think it slowed you down? Were you able to split the work equitably or did one person tend to dominate? Did working in pairs help you to better understand the project as a whole? Were you ever able to learn more about an area originally unfamiliar to you by working with someone with more experience? Did one partner tend to work on an immediate problem while the other focused on strategy? Was there anyone that you just could not work with? If you tried pairing and it did not work, what went wrong and how do you think it could be fixed? Did you like programming in pairs? That is, give an overall thumbs-up or thumbs-down to it.

Customers. XP projects ideally have a client/customer on the team. We faked this. Would your team have benefited from having the customer more accessible? Were there enough "stories" to guide your work?

Refactoring. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the system but improves the internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. Were you involved in refactoring any code written by your group? (I know you all changed code to get it to work the way you wanted it to. That is not necessarily refactoring.) Describe. Was the resulting code in your opinion better from the maintainability standpoint? That is, do you think a person coming "cold" to the code would be better able to understand what it did reading the refactored version? In what way was the structure of the code improved in your opinion?

Multiple Small Releases. One of the basic tenets of XP is to get a stripped-down version working and release it. Then add a few features and release the updated version. The process continues in this manner until the final release. Did your group continuously integrate code so that you had a simple working version early in the term that could have been "released" with the proviso that more features would be added in future releases? If yes, did having a "working version" help with making desired additions? (Describe how in your opinion.) If no, why not?



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net