At this year's CFUnited, I gave a talk titled "Supercharging Fusebox Project Management." As indicated by the title, that presentation was aimed at managers who use Fusebox. While I am a major proponent of Fusebox, this article deals with some aspects of team management, regardless of what framework is used. We'll take a look at some basic management goals, and how we can use simple tools to ease the task of managing development in a team environment.

The first point I'd like to make is that this is not an article about using version control. I only have one thing to say about version control if you're in a team environment: use it. No matter whose arm you have to twist to get a version control system set up, do it and do it right now. Your time is too valuable to waste on code lost to oversaves.

When it comes to project management, we're concerned about two things: time and money. Since, in the final analysis, money is just the way we count how much time it's taking to do the work, we'll focus on the time aspect of things in this article. When dealing with time, a manager is concerned about three major questions:

• What are we going to do?
• What have we done?
• What did we do?

The second question addresses the progress of work performed once the coding work has begun. With a development plan in place, a manager wants to know how much of the plan has been executed, and how much remains to be done. There needs to be a way to monitor what work has been accomplished at any given time.

The third question involves documenting the project, both for technical reasons and contractual satisfaction. With strong system documentation, a customer is far more likely to be satisfied with the work that has been done. A manager would like to have a way to create strong documentation once the project has been completed.

To answer the first question, we need to have a well-designed plan for the application. This is where I will mention Fusebox, or, more accurately, the Fusebox Lifecycle Process (FLiP). FLiP uses a planning process that includes construction of a wireframe (business process), prototype (front-end), and architectural design, as steps in its methodology. The result of these three steps of the process is a framework that has a configuration file for each circuit (directory). That file is named circuit.xml, and Listing 1 shows an example. Note: If you're interested in the rest of the FLiP process, there is a free FLiP Roadmap PDF file that you can download at www.GrokFusebox.com.

It is important to note here that every template required in the circuit is expressed in the circuit.xml file as an <include> element. Like the CFML <cfinclude> tag, the <include> element specifies the filename with the template attribute. So, within these circuit.xml files, we have the entire plan for all the templates that need to be coded for the application.

This is just the way FLiP handles the process of planning and configuring an application. As mentioned previously, I'm not saying you must use Fusebox in order to manage projects well, but you must have some sort of coherent plan, and a way to inspect that plan. If you're not using FLiP, you can still infer from this example the type of thinking that will let you build your own tools to accomplish the same things we're doing in this article. At any rate, due to the well-organized manner in which the application is planned out, we can use a CF-based tool to give us a leg up on managing the development. The tool I'd like to introduce at this point is called FB4Checklister.

FB4Checklister leverages the fact that we have all this data in circuit.xml files. XML gives us the opportunity to use CF's XML manipulation capabilities to provide easy reports based on that data. All FB4Checklister does is cruise through an application's directory tree, reading each circuit.xml file and transforming it into HTML output. The name is taken from the fact that the first stylesheet produced for the tool created a coding checklist for all the fuses (templates) in the application. The output from that stylesheet is shown in Figure 1. In case you're interested, the (obviously very small) application used here is the Wegot Widgets Basic reference application from fusebox.org.

FB4Checklister (using its default XSL stylesheet) generates a checklist we can use to check off each template as it gets coded, tested, etc. We can print out the checklist, or copy and paste it into a spreadsheet; use it however it might benefit our process. Even better, we might consider writing our own XSL stylesheet to create output that is most effective for our process. If project management software is in use, perhaps we could create a format that is compatible for import into that software to save a lot of time not typing in all those tasks. Listing 2 shows the checklist XSL stylesheet. Although this article can't provide an XSL how-to, the format for this stylesheet is basic and can be used as a jumping-off point for other stylesheets.
With the first question answered, we move into the part of the project where the coding is being done, and, as managers, we become interested in the second question, "What has been done?" We might also think about this question as, "How much has been done?"

One way to answer this question at regular intervals throughout the coding phase is to use the checklist we generated with FB4Checklister. In fact, that's how I used the checklist for several projects after I first wrote the tool. However, if the project is organized, we can take advantage of another XML vocabulary to make answering the question an automated job.
The second XML vocabulary we'll look at is Fusedoc. Although it was invented as part of the Fusebox mindset, Fusedoc is not directly related to Fusebox. It is just an XML vocabulary for describing the responsibilities, properties, and I/O of a template. You can use it quite well even if you don't use Fusebox or FLiP. Details on Fusedoc and the Fusedoc DTD are available at www.HalHelms.com.

Listing 3 is a Fusedoc for a template that displays a product to the user. The responsibilities section contains a plain language, first-person description of what the template does. The io section contains elements that describe the inputs and outputs for the template, but it is the properties section that will be most useful for the purposes of this article. The properties section can contain history, note, and property elements. A property element has a name and a value, so we can store just about any properties of the template we want using this method. In the properties section in Listing 3, there are two properties: dateCoded and dateUnitTested. These are arbitrary properties I've invented to use for project management purposes. A team member, after coding the template, also adds the dateCoded property. Similarly, when the template passes unit testing, a team member adds the dateUnitTested property.