Thursday, December 27, 2007

Making Process Results Public

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/making_process_results_public.htm]

Enterprise applications require a lot of supporting processes - continuous builds, feature tracking, monitoring production, etc... One sign of a mature department is that the non-secure output from those processes is publicly available to the entire team, as opposed to "hidden" in a personal file on some manager's computer. This keeps everyone on the same page, encourages team feedback, and reduces bureaucracy.

 

For example, anyone on your team should be able to tell you the release dates, their current expected feature list, the amount of open issues they have, and if their code patch broke any unit tests on the server. Those should not be "special" things that only a manager has access to view.

 

There are several processes that any development department should have, and these processes should all have publicly accessible results (such as via a web dashboard or shared network drive).

  • Issue Tracking System (we use a web-based solution)

  • Continuous build with unit test results (we prefer CruiseControl)

  • Wiki (we started with FlexWiki to just get started, but now use SharePoint)

  • Production performance results (you should be able to go to a web dashboard, not pester your IT department for the raw IIS log files)

  • Available project plan (even an Excel sheet on a shared network drive)

There's no doubt more to this list, but it's a good start.

No comments:

Post a Comment