共用方式為

When you don't have a spec, everything is a bug

  • 發行項

How many of you regularly get a detailed and complete specification document before Dev starts coding and before Test starts testing? Raise your hands, please. Anyone? Anyone? Bueller?

Heh. That's what I thought. My team takes a full month before each milestone to focus entirely on the specs for the next milestone, and even that is rarely sufficient time to get all questions answered and the spec nailed down.

If your group uses one of the agile methodologies you're probably wondering what all this fuss about specs is about. If you truly have constant contact with your customer, and your customer is an integrated part of your team, and you organize and name your tests such that they are easily read and searched and understood, then a spec is indeed not so useful and may even just be busywork. For the rest of us, though -- especially those of us delivering components or APIs to other teams, specs are necessary documents that define the features we are to plan/code/test/document/market/publicize.

When you don't have a spec, or when your spec is incomplete and/or out of date, you have several options:
 -Camp out in your program manager's office until they write it. If you have a laptop and so can get some work done while you're there, so much the better.
 -Write the spec yourself. Either your PM will thank you for helping with his workload, or he will be mad enough to finally write it himself. Either way, you have a spec to discuss with your feature team.
 -Your bug database becomes the spec. You decide how your feature should work, and you write bugs anytime it works differently. As the bug works its way through your bug resolution process, you and Dev and PM have (probably loud and heated <g/>) conversations that result in a decision whether the feature really is/ isn't supposed to work that way. Depending how good your feature team is at recording these conversations in your bug database, you have anywhere from a "No this isn't a bug" decision to a rich history full of detail.
 -Your tests are the spec. This is what Extreme Programming and various other agile methodologies are perceived to do. One difference, though, is that a team using such a methodology recognizes and highlights the fact, whereas teams that fall into doing this accidentally don't ever realize what is going on and so can't optimize their processes around the practice the way XP does. (And even XP recognizes that certain situations (e.g., writing components for use by other teams) require specs for coordination between those teams.)

In reality, of course, the situation is never so clear cut as to be firmly in just one of these camps. I have a spec for my feature, but it is nowhere near complete. On my first review of the spec I added over seventy comments questioning various areas of the spec,  several of which hit fundamental concepts behind or behavior of the feature. I pester my Program Manager on a regular basis, asking when he will have the spec updated. In between pesterings I've begun to write my test spec, identifying test cases and  determining what changes to our test infrastructure will be needed. I'm also looking at the prototype, simultaneously providing feedback to my dev and discovering the areas that are likely to be bug farms in the production code.

*** Comments, questions, feedback?  Contact me at michhu at microsoft dot com.

Comments

  • Anonymous
    February 25, 2004
    Interesting view. We use a DSDM, Agile development process in our engineering department. In addition we are now creating use cases for our features. It's giving us a better understanding of the features use and expectations. With buy in from the users (Actors), they have input on how the feature will function.

    We are also starting the development cycle by creating test cases and building test harnesses before we actually start coding the actual application. This gives us a quicker view of how features will work and allow us to frequent test specific features.

    I would agree that most specs are incomplete and most engineers/developers end up modifying the spec to fit architecture or technology. That can really hurt a feature especially if the end users don't have buy in or buy off.

    Great post!

    --Thom

  • Anonymous
    February 25, 2004

    Interesting topic. At my company, the PM was fired for headcut reasons. The sad thing is that it didn't change an inch that we write the code, and then try to document what we get. More accurately, the person who's told to write the user documentation guesses the features, write the doc, and that's what we ultimately call the specs.
    Other than that, we use the bug database for everything. It's really the heart of anything we do.

    One more comment about specs and the development cycle : in my company, requirements change over time, a couple times. Sometimes they induce minor changes, sometimes they require a complete rewrite. Our managers just expect us to release the code on time regardless (it exemplifies how software code is regarded as grunt work).

  • Anonymous
    February 25, 2004
    The comment has been removed

  • Anonymous
    April 23, 2006
    Here is another interesting post from Jim Fawcette.&#160; He says that improving software tools are partially...

  • Anonymous
    October 10, 2008
    Better Visual Studio = Lack of jobs??

  • Anonymous
    October 26, 2008
    Better Visual Studio = Lack of jobs??