we migrating towards tfs , have decided based on online commentary structure tfs 1 project per team, each "real project" being area (and each release iteration).
this means our tfs structure like:
apps team - winforms project - wpf project - embedded project - wpf project 2 web team - admin site - client site - client site 2 db team - general scripts - db 1 - db 2 however, management perspective tedious review each team's reports individually.
i wondering experience using structure, which of these options (or other option) have used?
1) move teams same project
- pro: no report changes
- pro: cross-team awareness
- con: clutter
- con: perhaps security
2) change reports cross-team
- pro: teams can still have own projects
- con: have change , synchronise reports across projects
- con: reports become less useful individual teams (can still customise copies)
- con: teams should share same process template (a non-issue me)
3) setup tfs project management containing cross-team reports
- pro: have change 1 tfs project
- pro: maintain current team-focused reports
- pro: reduced risk of management breaking work items in team projects.
- con: teams should use same process template (a non-issue me).
i have set projects you've defined above. , i've configured tfs reporting both #2 , #3. thought of forcing teams re-org reports work out makes option #1 severe me. #3 appealing, in similar way number 1, limits individual teams sharing same work item types , process templates. invariably end in 2 state. particularly if teams evolve processes independently. i've been able mitigate "reports become less useful" problem investing in customizing reports (non-trivial know).
Comments
Post a Comment