What About Requirements?


The RUP hump chart (see Appendix A) shows that even during Transition phase iterations you need to manage requirements. New requirements come in during all phases of a project. During the Transition phase, it's especially likely that you will see new requirements, because stakeholders have time to work with the product and to think about its implications. You need to manage the requirements carefully and thoughtfully. You don't need to implement each new requirement, but you do need to capture each one and use the collection to help you plan the next release.

Avoiding Late Changes

In our experience, most projects decree that during the Transition phase no new features will be added to the software. Compare this style to XP, where you welcome any change up to the final iteration. We find that the final packaging, documentation, manufacturing, and deployment of software to your customer community take time and benefit from stability. Significant changes at the project's end can cause delays in these non-coding activities. And these activities are ones that can determine the success of your product.

How many times have you used software and found something that you couldn't quite get right, either during installation or the first few times you used it? Most of us have experienced this phenomenon . When that happens, what do you do? You avoid using the software and look for a different way to get your job done. If the software is a commercial product, you look at competitive products. If the software was developed by your in-house IT staff, you try to get help from the IT staff, usually starting from an adversarial position. In either case, you probably won't want to use software from them again.

This illustrates a truism about selling, in general, and selling software specifically :

It takes time to sell your product to a customer and earn his or her trust. It takes only one bad experience to lose that trust and the business.

Aiming for a Short Transition Phase

Sometimes you can't avoid changing the software just before you deliver it to your customer, but you can minimize the changes. We recommend that you make your Transition phase as short and as focused as possible. In this section, we outline a few techniques.

If you work closely with your customers during development, there should be few surprises at the end of the project. Your customers can evaluate the software from the early iterations through the final Construction phase iterations and, more importantly, provide feedback on whether the product is meeting their expectations and needs. During the project, you work with your customers to manage the project's scope and to prioritize work so you deliver as much value as possible in the time available.

By delivering working software at each iteration, you are already developing the non-code artifacts starting early in the project. You end up working on some of the less obvious code artifacts, too, such as install modules and programs. As a result, by the time you reach the Transition phase, you have made substantial progress toward this phase's goals, allowing you to shorten the Transition phase.

Compare this approach to a more traditional one where developers defer Transition phase work to the end of the project. At the same time, developers are fixing defects, and the documentation, quality, and release team members are scrambling to meet impossible deadlines. On a small team, this means that all team members are working ridiculously long hours, forgetting their life outside of work, in order to make the delivery.

There is a lot to do after you finish writing code and before you ship a complete software product, even on a small project like PSP Tools. No matter how short you make the Transition phase, you will get new requests and requirements. Manage them. If there is a good reason to satisfy a new or expanded requirement, do so. And make sure your stakeholders (including the development team) understand the cost and the benefit of satisfying the requirement. In most cases, given the choice to ship on time without implementing the requirement or to delay the release, your stakeholders will opt to ship on time.

Example

It is important to convey requirement changes to your team throughout the project, but the importance is amplified during the Transition phase. Before he took a job with Rational, [1] Gary was offered a position at a smaller company as a development manager. The offer was tempting and their product had great potential. Luckily, Gary knew many members of the development and QA team from a previous company and was able to learn how well they were meeting the business requirements.

[1] Actually, Gary was with PureAtria when Rational acquired them.

Their first release was just weeks away and they had several major defects to address. They needed to release on time to display the product at a major trade show. Finishing the project was completely possible. There was still time to finish the work and produce a quality product.

Gary stayed in touch with the QA manager. In a three-day period, the number of major defects almost doubled . It didn't take long to figure out what was happening. One of the owners of the company was spending his evenings thinking up new requirements and implementing his "solutions" for those requirements. Most of the solutions caused integration errors with the rest of the product. Instead of a downward trend, the defect rate was going up because of the new requirements imposed, without any input from the rest of the development team or other stakeholders.

Gary realized that the company wasn't a good fit for him. He liked the people, and he liked the product. But he also knew that if he accepted the job, he would spend too much of his time managing the owner so his team could ship the product with the necessary commercial quality for each release. This was one of the better decisions Gary made in his career. He ended up at Rational and the small company lasted about nine months before it went out of business.

There is a simple moral to the story. If you have to meet an unchangeable date, then you simply cannot continue to accept requirements changes up to the end of your project. After a certain point, you have to defer requests, while keeping your team both informed and focused. Communication is perhaps more important in the endgame than at any other time during a project.

Defects Are Not Requirements

During the Transition phase, Gary and Russell met or talked frequently, sometimes daily, to ensure that everything was on track. Russell and his engineers started to use PSP Tools for their day-to-day work. They uncovered some defects that we missed in our testing.

Because we were in the Transition phase, it was important to decide which defects to fix before the release and which fixes to defer to the next release. Russell and Gary served as our change control board (CCB). They used two simple criteria to help direct their decisions:

  • Did the defect cause the program to fail in such a way that data was lost or corrupted?

  • Did the defect cause the product to become unusable?

If the answer to either of these questions was "yes," then the defect needed to be fixed. In all other cases the defect would be deferred.

Many of the defects could be fixed quickly. In fact, teams are often tempted to fix all the "easy" bugs. But remember that fixing a bug can have ramifications for other members of your team. For example, a bug fix might require changes to the documentation because screen shots can change or a sequence of actions might change. A bug fix needs to be tested ; if it affects other code, your testers can spend extra time diagnosing the new bugs. And then your CCB needs to decide which of the new bugs to fix. Simple changes during the Transition phase can quickly become time sinks for the whole team.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

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