At the WebIST conference this year, we presented a paper dealing with instant collaboration and new patterns of team cooperation. This topic is not directly related to software engineering, however, my observation is, that best-practices that emerged within the software development context, particularly in highly-distributed open source projects "diffuse" into other areas. In this entry I write about some thoughts on groupeware and software engineering methologies.
SE Toolset and Methodologies
To be more precise: in open source projects, a set of tools and methodologies are used to develop software and manage the roadmap with teams distributed over the whole world, such as:
SE Toolset and Methodologies
To be more precise: in open source projects, a set of tools and methodologies are used to develop software and manage the roadmap with teams distributed over the whole world, such as:
- Mailing lists
- Wikis
- (Sourcecode) Repositories
- Bug/Issue Tracking systems
The interesting thing is, that these tools are meanwhile also used in many companies and workgroups that have no relation whatsoever with software engineering. Subversion can be used to manage "office documents" and project information, websites and the like as well. Wikis are used for general prototyping, issue trackers like Trac are used to distribute tasks and keep track of them.
Specialised Groupware Tools?
Several attempts were made in the past to bring up more integrated tools for project/workgroup management. However, my feeling is, that the abovementioned specialised tools have a huge user basis and a lot of advantages over integrated software specialised in groupware. E.g., the capabilities of SVN is hardly reached by one of the many web-based content repositories.
The solution?
In many cases a good solution can be the installation of proven software-engineering related tools even in non-SE domains. Still, the problem persists, that different types of users with different skills want to work with these tools, and the integration between those applications is typically rather weak (particularly from the standpoint of a not so skilled user). So generally spoken, I see a significant "market" for integration software, that actually uses established repositories, content management systems, instant messaging protocols and so on, but helps to integrate those with unified user interfaces for different target audiences.
So various groupware attempts failed in the past, because a complete new toolset was introduced, and typically users did not want to leave their known application-environment and work-style. Hence the groupware forum and web-repository was deserted and discussions were still made (and files distributed ) via email; despite all disadvantages.
The solution?
In many cases a good solution can be the installation of proven software-engineering related tools even in non-SE domains. Still, the problem persists, that different types of users with different skills want to work with these tools, and the integration between those applications is typically rather weak (particularly from the standpoint of a not so skilled user). So generally spoken, I see a significant "market" for integration software, that actually uses established repositories, content management systems, instant messaging protocols and so on, but helps to integrate those with unified user interfaces for different target audiences.
Additionally we still face the problem, that a good toolset has to be used! The hardest part in establishing a groupware strategy is not the installation of the tools, but the "refactoring" of the usual work-processes. I.e., bringing the users to actually using the new software appropriately.
Establishing Groupware = Software Installation?
The suggestion here is to bring the collaboration tool to the user not vice versa: This user can be a developer who uses an advances SVN client or a command line toole, but can at the same time be a user management with less technical skills. First successful steps can be seen with the success of SVN because of good Explorer plugins. This "simple" plugin is in my opionion one of the main reasons, why SVN gets grip outside the "core development teams".
Additionally various channels, now separated, can be used on similar channels. In our paper we suggest for example, a system, where resources are exchanged via instant messaging plugins, but are actually held in a reliable backend repository like Daisy or WebDAV or SVN. Another thought is, to bring IM and resource access and exchange technology into email clients. Then users could share documents in their "favorite style", namely using the mail client, but they would actually be exchanged e.g., via SVN and not via SMTP. The advantage is clear: the user has his or her familiar environment, but in the backend a more stable solution is established (versioning, access via various systems, e.g. content management...)
This strategy should reduce the gap for the user between his old environement and work-processes and new processes and tools. Later on, more advanced tools can still follow when required.
Any thought to this connection between SE practices and general collaboration? Particularly considering different audiences?
Additionally various channels, now separated, can be used on similar channels. In our paper we suggest for example, a system, where resources are exchanged via instant messaging plugins, but are actually held in a reliable backend repository like Daisy or WebDAV or SVN. Another thought is, to bring IM and resource access and exchange technology into email clients. Then users could share documents in their "favorite style", namely using the mail client, but they would actually be exchanged e.g., via SVN and not via SMTP. The advantage is clear: the user has his or her familiar environment, but in the backend a more stable solution is established (versioning, access via various systems, e.g. content management...)
This strategy should reduce the gap for the user between his old environement and work-processes and new processes and tools. Later on, more advanced tools can still follow when required.
Any thought to this connection between SE practices and general collaboration? Particularly considering different audiences?
No comments:
Post a Comment