In the past decades, speed-to-market has been increasingly emphasized. To be successful enough to survive, an IT company must always provide high-quality products productively in short life cycles. As a result, XP becomes widely recognized and commonly used, replacing traditional software methodologies such as waterfall model and Rational Unified Process in a number of environments where customers’ requirements are changing or even still up in the air. For extreme programmers working in XP teams, it is a challenge to work in accordance with the disciplines brought by XP. A rule of thumb is to understand specific customer requirements.
First, in XP teams, everyone besides QA is responsible for quality. So an extreme programmer should also work hard to make sure that the “correct” things are being created. Under such conditions, specific customer requirements can be seen as the best criteria. For example, a customer may ask for an API returning the product of two numbers. A qualified extreme programmer should at least ask some more questions, such as how many digits would be allowed after the decimal point (because the result may be a number expressing money), and also what is the maximum limitation of the result (because there may be additional operations required for numbers that are too big in some programming languages). You shouldn’t just write the code and then wait for someone else to find the bug.
Second, an extreme programmer also takes part in requirement analysis, system design, as well as workload estimation up to a point. In an XP team, there is no one who is exclusively responsible for requirement analysis and system design. Backlogs (items about what should be delivered in the release) are created by project owner, but they are only in draft form until an agreement has been achieved around the whole team. Assume, for example, a customer may ask for a new style for a given page, the project owner may have no idea about whether it is feasible, how to implement it, what is the impact on the other pages, and so on. At this moment, suggestions from extreme programmers are definitely important. If she/he is not familiar with the specific customer requirements, how can she/he help project owners to make a decision?
And finally, an extreme programmer should know what the product delivered in the release would look like from the beginning of the release. Only when you begin with the end in mind, can high-level productivity be achieved. In case a customer would like the web application to be able to accept ten thousand of requests at the same time, as an extreme programmer, you should take this into consideration from the original phase of the release. As well, it is necessary to check if there are any bottleneck dependencies. Before starting the coding, also write down the test specification, and then make sure function code and test code are developed at the same time. In other words, do everything you can do to make you walk on the right road so that, up to the end of the release, no time and effort have been spent on anything other than the target.
网友评论