Fit Workflow

We describe the process by following an example feature from concept to completion, focusing on how Fit is used to help implement the feature. We start with a concept and end with a completed feature. Here's the final Fit document, describing the completed feature:

From Concept to Completion: Making a Feature Fit

A Fit document is best created through the collaboration of the whole software production team. Customers, testers, and programmers all work together to achieve success. The end result is an "executable specification:" a readable document that not only describes the software, but shows what it actually does.

The process starts with a customer (domain expert, business person, product manager, etc.) informally describing a new feature and providing examples of how it should work. Programmers and testers ask questions and help refine the examples. This conversation should take place around a whiteboard and is characterized by lots of discussion and learning.

A whiteboard conversation

The customer, working with testers and developers, refines these examples into tables, using business-friendly tools such as Microsoft Excel and Word, and incorporates them into a document.

Customers' initial examples

Testers and developers suggest additional areas to cover...

Testers' and programmers' additions

...and programmers make sure the tables are formatted in a way Fit can understand.

Fit-friendly formatting

The document is saved as HTML and developers create "fixtures:" small bits of program code that can understand the examples and try them out on the software being developed. The Fit framework provides infrastructure to make this easy.

A Fit Fixture (in C#)

As the fixtures are completed, Fit is run on the document and the results are reported to the whole team. At first, examples fail and are colored red. As developers implement the feature, examples turn green.

Incremental progress

As they work, the developers ask questions of the customer that inspire discussion and even changes. Meanwhile, customers improve the clarity of the document so it may be used as a reference in the future. Testers review the examples to make sure all important aspects of the feature are covered. Both groups use throw-away Fit examples to experiment with the software as functionality is completed.

As people discover new things, they share them with the rest of the team, causing more ideas to emerge and fuzzy areas to be clarified. The Fit document becomes increasingly more sophisticated. Eventually, the feature is done and all examples are green.

The finished Fit document

Once the feature is done, the document is kept for future reference and included in developers' automatic build tools to ensure everything keeps working.

Automatically running Fit

Over time, questions will arise about what the software does. The Fit document helps answer these questions. When the document doesn't say, an example is added and Fit reports the answer.

Conclusion

The process described above is a brief overview. In practice, things are more messy. You'll find yourself going back and forth between steps, not following a straight path from beginning to end.

As you use the process, you'll learn ways to make it work better in your environment. Make changes to improve it, and as you do so, remember to keep focusing on collaboration and communication. Changes that make collaboration easier and more common are good changes. Changes that make collaboration harder and less common should be questioned.

You're following the Fit documentation trail. The previous article in the series was IntroductionToFit. For a table of contents, see FitDocumentation. The next article in the series depends on your role. Pick the one that fits your job best:

• CustomerGuide
• TesterGuide
• ProgrammerGuide