Hi all,
I'm wondering if I understand the purpose of Feature Team Areas correctly.
Suppose we use TogetherJ, and have created a TogetherJ project containing the overall domain model (ProjectName.tpr).
When starting a DBF process for feature A, do you guys create the design (sequence diagrams, modifications to the overall domain model) in this same TogetherJ project?
Or do you create a separate work area (read: a separate TogetherJ project) for each feature?
Thanks!
Rudy
Same Project
Definitely the same project. I'm sure Paul Szego will have more to say on this.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
I would like to refer to a co
I would like to refer to a comment made by Paul Szego:
The concept of the feature team area is simply a "shared workspace". That's all. We want a way for team members to be able to safely share their work with each other, but not have it impact anyone outside the feature team.
This seems like people do DBF and BBF steps in a separate 'work area', a 'shared directory' e.g. where they don't affect others.
Also suppose some people are busy designing a number of features, of which some will not immediately be implemented. Then the main TogetherJ project will contains impact from several feature designs that have not been inspected/validated and are not yet up for implementation.
Thanks you for your help!
Rudy
Feature Team Areas
Hi Rudy,
yes - you've picked up the most important aspect of the feature team areas here, from my earlier posts. They really are only a mechanism that allows the feature team to share their work without impacting the rest of the development team.
There's a lot of detail in a previous post of mine: here
As I've noted there are various ways you can implement this, ranging from shared directories to more sophisticated use of tools like ClearCase that can provide a "virtual space" the team can all utilise.
The lifetime of the feature team area is the same as the feature team: for one pass through the DBF+BBF for the set of features selected in this work package. Once the features are promoted to build, and the work package is "done", the feature team area goes away.
HTH, Paul.
One vs. Many Projects
Hi Rudy,
on the question of "do you use one TogetherJ project", there's really no one correct way to do this that fits all situations. It depends on a lot of factors, and they're not necessarily implementation level concerns.
I'll give one quick example, and then come back around to the general question.
On a recent project a decision was made to leverage some Oracle technology for the DM layer. It was a basic "buy vs. build" decision, and it made good sense to leverage the technology in order to provide probably 90% of the required functionality for the DM layer. In order to best leverage this technology some of the "wizards" provided by the Oracle JDeveloper product could be used to initially build most of the required DM layer code, effectively kickstarting the DM effort and providing a working DM layer very quickly.
The directory structure and general layout of source files that this tool works with was not necessarily how the development team would have like, or built from scratch themselves. In this case, with the imposed directory structure, it made better sense to create several smaller TogetherJ projects when working within the DM layer.
The key point here is that it was a strategic decision to utilise the Oracle technology (in this case, based on some very specific requirements and constraints). The lower-level concerns about how to best integrate the toolsets was secondary to this, as it should be. There were seval ways this could have been done, but the KISS principle applied here pointed the way towards a particular appraoch that might not be the norm. In this case however it was the best solution, and as it turned out a very good one.
In general you have to work within whatever constraints are imposed on you. Remember that TogetherJ is just a tool - we use it to effect changes to the codebase. It's power comes from its ability to effectively work at the "model" level, i.e. with class and sequence diagrams. SO as long as we don't lose sight of this we're ok. Even if we do carve up the one big project into smaller pieces, there are ways within the tool to provide visibility into the codebase of the other TogetherJ projects, even if we aren't able to modify the resources external to this TogetherJ project.
I've never personally built a seperate project for each DBF+BBF iteration. I cannot see much value in this. Remember that a tool like TogetherJ is not repository based - it works mostly from the source files themselves. What's in the project files are things like default settings for the various features of the tool. Information relating to classes is mostly in the classes themselves, similar for diagrams. So when implementing a feature there are typically no changes to the Together "control" files, all changes are to the resources we're modifying as part of this iteration. On those rare occasions when this file does change the CP can check in the changes.
Another quick example: we typically have a project for each of the layers, as these are often worked on by different teams. It's the same thing - each TogetherJ project focussed on some subset of the source code that will be modified, and possibly giving visibility into other areas of the code that won't be touched.
HTH, Paul.