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.
With these properties in place, we can use another automated tool to check on the project's progress whenever we like. I've put together a simple example of such a tool, named FB4CodingProgress, which is shown in Listings 4-6. When this tool is run in the root directory, it produces an HTML file with the report shown in Figure 2.
For each circuit, we get a list of templates (fuses), and if the fuse has been coded (or coded and tested) a note is shown along with the date from the Fusedoc. Any nested directories are indented in the report. At the end of each directory's (circuit's) section, there is a set of totals for the directory showing percentages coded and tested, and a grand total section appears at the bottom of the report. We are able to grab an instant status report for the coding and testing of the project, without even bothering any of the coding staff.
So, finally, on to the last question, "What was done?" We want to answer this question with system documentation. This is typically one of the most overlooked parts of application development, usually because we coders don't put much emphasis on documentation. However, using techniques we've already seen, we can take the pain out of creating documentation for the code that exists in our finished application.
Once again, we're relying on a tool to take the pain out of the process. This time, it's a tool called FusedocMiner, which is somewhat like FB4CodingProgress, but not nearly as specialized. All it does is cruise through a directory tree, pull out all the Fusedocs, and apply an XSL stylesheet to each one. The code is shown in Listing 7. The default XSL stylesheet (Listing 8) produces HTML that, along with the default CSS stylesheet (Listing 9), renders some nice documentation ready for printing, as shown in Figure 3. When printed, each template gets its own page in the documentation, so it makes a nice bound document for delivery to the customer.
Unfortunately, there's not enough space in this article to dissect the XSL stylesheets used in FusedocMiner and FB4CodingProgress. They are both fairly simple examples of XSL, and I hope they'll serve as good starting points if you haven't already explored XSL. Both the XSL stylesheets and the CSS stylesheets are provided so you can modify them to suit your local project management needs.
This article is really just a quick overview of the sorts of things that are possible in terms of project management when a structured and consistent process is used for development. One last time, I'll repeat that, although the examples used in this article are based on Fusedoc, there's no requirement to use Fusebox or the Fusebox Lifecycle Process when using Fusedoc; I just happen to have a lot of Fusebox-based examples lying around. Even if you want to use your own XML-based template documentation standard, all the techniques would remain the same. It's important not to lose the point of the management techniques in the irrelevant fact that the samples use Fusedoc.
With a bit of thought and a few tools, it's possible to have very good project management with minimal tedium and, even more importantly, low impact on team members' time. All the tools I've shown in this article are available for free download at www.GrokFusebox.com, in the Grok's Goodies section. As with all my tools, they're free for use and modification. Use them to feed your own ideas and let me know how you've made them better.