Project Management |
Discworld Playtester help |
Working with Projects |
What is a "project"?
A "project" is a discrete piece of work, with specific objectives, with a beginning and an end[1]. Project Management is the act of initiating, planning, executing, controlling and monitoring, and closing projects.
Thrilling stuff.
Simply put, a project is a bunch of planned tasks that, when completed, produces some desired and specific end result.
Projects in the Real World
In the real world a software project is usually initiated by a customer or program manager, planned by technical architects and domain experts, executed by programmers and testers, and ultimately delivered to massive acclaim. Somewhere in the mix is a "project manager", whose job it is to play ringmaster and make sure the whole thing is coordinated.
Development usually follows some "process", which is often an accepted method(ology) of getting from an idea to a working solution. As an example, consider the waterfall model[2]: development goes through several stages, analysis, design, coding, testing, delivery.
Planning/Design
Let's focus on "design" a moment. In general non-software projects, for example a movie marketing campaign or an airport's construction, design is called "planning". This is the bit where we break down the work right down to the level of individual tasks; we need to be able to say that on the 16th of October next year, three cubic metres of premixed concrete will arrive at _this_ location (that might not exist yet at the time of planning) at 10:30am, and that four labourers will be present to decant and shape it at that time. Importantly, we need to decide this _before_ the construction work begins.
In software, planning (or design) is where we break down the work required to create the software, right down to the level of writing individual functions or algorithms. Notably, this comes before the coding stage. Only when we understand the nature of the problem to this degree can we plan timescales and deadlines, manage risk, and deliver the project with all features intact.
Now that I've scared you, you'll be glad to know that on Discworld MUD, we work slightly differently.
Projects on the MUD
We have very few professional programmers on the MUD, and those we have are reluctant to engage in any more bureaucracy than necessary. As such, there is a tendency for bad habits to sink in; coders sometimes create things without proper consultation or approval, code is released into game without adequate documentation, and bugs are ignored while coders get on with more fun things.
In an attempt to solve some of these problems, we have a project management handler, available to creators via the "project" command, and to playtesters via the "playtesting" command.
How a Project Begins
When a domain leader approves an idea for a project, he adds the project to the project handler, assigning creators, writing a description, and specifying both "size" and "complexity". These last two settings are used by the handler to assign testers and decide rotation number and length. Creators then add tasks and notes as the design progresses, breaking the project down into individual easily understood pieces and assignments. Once tasks have been identified, the "complexity" and "size" may be revisited to more accurately reflect the project; in the real world, it is this point where a more accurate estimate of the project duration can be made, and deadlines set.
As we are volunteers, few of us have regular mudding schedules, and so our working time is neither predictable nor mandatory. As such, the concept of "deadline" doesn't really hold much weight; we tell our domain leaders when we expect a piece of work to be done, and they fit that into their idea of when some larger goal will be reached, but they normally don't hold us to our promises too much.
The MUD's Project Management System
Our project management system reflects this, so projects in development don't have deadlines or expected delivery dates as far as the tracker is concerned. In fact, during the development stage of a project, the tracker is typically used to show only the summary of the project, and its estimated completion percentage. This information is useful for communication between project creators in larger projects, and so that the playtesters domain can keep an eye on upcoming projects.
The project management system changes focus when a project finishes development. At this point, all tasks has been completed, the project has reached 100%, and the project's status becomes "playtesting". The handler now uses the "size" and "complexity" settings to decide:
- How many playtesters to assign,
- How many rotations, and
- How long each rotation lasts
An average project goes through several "rotations" during the playtesting phase. Ideally, the last rotation or two should be entirely dedicated to bugfixing; the project should be considered feature-complete (i.e. no more ideas being implemented) by the time the last rotation is started.
Each rotation lasts for a set period, and gives a new set of playtesters the opportunity to work on the project. As an aside, it's not unusual for developers to underestimate the amount of testing required, so one of the functions of the handler is to remove or at least obscure that failing behind the "size" and "complexity" settings.
The "size" setting determines the number of playtesters and the length of each rotation, as follows:
| Size | Example | Number of PTs | Rotation Period | |
| ---- | ------- | ------------- | --------------- | |
| Very small | One to five room area, miscellaneous small item, standard NPC | 2 | 1 week | |
| Small | Five to ten room area, Complex NPC | 3 | 2 weeks | |
| Medium | Ten to twenty room area, normal spell/ritual, complex item | 4 | 2 weeks | |
| Large | Twenty to Fifty room area, complex spell/ritual, widely used system rework | 5 | 4 weeks | |
| Very Large | Fifty to Two hundred room area, major system rework | 6 | 4 weeks | |
| Huge | Two hundred+ room area, critical system rework | 8 | 6 weeks |
The "Complexity" setting determines the number of rotations, as follows:
| Complexity | Number of Rotations | |
| ---------- | ------------------- | |
| Low | 2 | |
| Medium | 3 | |
| High | 4 | |
| Very high | 5 |
Examples:
300 room city (Huge, low complexity)
8 PTs per rotation, 2 rotations for 6 weeks each.
Total time in PTing: 12 weeks
Rewrite of the combat system (Huge, high complexity):
8 PTs per rotation, 4 rotations at 6 weeks each.
Total time in PTing: 24 weeks
Murder mystery hotel (Medium size, very high complexity):
4 PTs per rotation, 5 rotations at 2 weeks each.
Total time in PTing: 10 weeks
Assignments
For each rotation, the handler assigns playtesters randomly. Any PT who is not currently assigned is ripe for the picking. However, if there are no unassigned PTs, it will randomly choose from the assigned testers. This means that some PTs will have multiple projects assigned at any given time.
Playtesting executives are responsible for managing these assignments, and are many times more clever than the handler at matching projects to testers. If any creator or playtester has an issue or suggestion regarding any assignment, bring it to an exec, and they will sort it out.
Going into Game
It goes without saying that the purpose of the project system, and of the playtesting domain, is to ensure that our code is as good as it can be. There is no point in rushing the process; releasing half-baked code into play is likely to affect the game in all sorts of negative ways. Because of this, it is recommended that the project is approved by your domain leader before it enters the game, preferably in conjunction with the playtesting executives.
In the outside world, this is called "sign-off", and means that there is a single point of responsibility for the project, in the event of some other project intersecting with it or of some problem arising during its execution or release. On the MUD, it means that Admin and other domain leaders have an idea whom they need to speak with when discussing big questions like the future of the MUD, or current plans and recent developments. Keeping your work under your hat in a team as diverse as ours is a recipe for disaster, so we have "chain of command" to communicate information projects throughout the different levels. Use it!
"Limbo" and "Heap"
The project management system supports the obvious statuses: development, playtesting and play. In addition, we have "Limbo" and "Heap". A project that's in planning but not yet ready for development is considered to be on the "Heap"; someone will get to it at some point, but it's not ready for development. A project that's had some work done on it, but is being cast aside, and may never be touched again (but may!) is considered to be in "Limbo".
