I had one of those brain shifting conversations today, you know the type, where an obvious assumption of mine was totally different from the obvious assumption of the person I was speaking to.
This is another post about the IBM Rational DOORS Next Generation with Configuration Management Beta software, for more information go to jazz.net where the beta is available to try, and the development is being managed in a publicly visible Rational Team Concert database.
I had assumed that every engineer, or analyst working in DOORS Next Generation with Configuration Management, would have their own workspace and deliver changes to a parent workspace managed by an integration engineer of some description.
My colleague assumed that engineers might share a workspace and work on separate change sets within that shared space.
This is fundamentally different. Working on separate change sets, you would not see what the other person was doing, but when it comes time to deliver your change, you are merging without the same formality that would be in place from separate workspaces. When working on a change set you cannot see the effects of other change sets unless they have been completed. There are advantages to a common workspace – would the software engineers please pick themselves up off the floor and have a strong caffeinated drink – a team of requirements engineers can share the responsibility of managing requirements and the ownership of the workspace. Fewer workspaces leads to less confusion. Some projects just don’t require the rigor that can be achieved with individual workspaces.
I would still recommend a workspace for each engineer – in fact, a workspace for each version/variant for each engineer. I might have multiple workspaces if I am working on multiple versions and/or variants. I hear cries of anguish about the extra disk space needed, but disk space is cheap, even managed, backed up disk space is cheap. Confusion on changes to requirements can be ruinously expensive. As for the argument of not knowing what workspace you are in; I believe that we can educate users to take a quick peek at the top of the screen to check the name of the workspace, or the name of the change set. The confusion will be real for a few days, but very soon you will get used to the tool and find that it is not a problem. Another advantage to individual workspaces is that you can set permissions on each workspace individually, so other people cannot edit or otherwise derail your work until you are ready to commit it to a more public space.
I am sure we will see every different approach when this is in widespread use, but I do think we need to have some well defined patterns that will offer a solid framework in the majority of situations. Please comment if you have a view on this shared or individual workspace question. It would be helpful to summarize your background too, software or requirements management for example, and also which industry you are from, as I am sure there will be industry differences in opinions.