Alternative process scenarios for parallel development
Hi guys,
I'm trying to solve the next scenario: In one Project Area there will be 2 kinds of development: There will be approximately 100 - 120 Main developments per year on this project area and maybe 40 will be concurrent. I can create a dev line for maintenance activities and create a phase per year. But my thought is that creating an independent dev line for each main development has no sense (to much dev lines!!) I don't know if this alternative could have sense (I know it looks strange). I created these process iterations trying to show a possible solution: --Main developments (dev_line) There are 2 main development lines. One of them is for maintenance activities and the other one for all the main developments. The point here is that the main developments dev line has N iterations representing N big developments (Dev01, Dev02, Dev03,.., Dev110 ) and these developments are executed in parallel. In addition I can say that these developments are owned by the same set of teams. On the other hand we are studying the possibility of using releases as the version in which a concrete requirement will be deployed (different case for bugs where the release shown makes reference to the version where the bug is found ). So Iteration is the WHEN will be developed and the version (release) WHERE a feature will be delivered. I know that dev line has an implicit sense of time flow. There is an active iteration at a time. In addition to the evident philosophical problem, Is there any other technical problem with this solution? Am I right thinking that dev lines are harder to maintain and have a higher cost than iterations?. Any feedback will be appreciated Thanks a lot Best regards Andres |
One answer
Jared Burns (4.5k●2●9)
| answered Mar 27 '09, 3:16 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On Tue, 24 Mar 2009 11:59:47 +0000, jaguerrero wrote:
Am I right thinking that dev lines are harder to maintain and have a The biggest overhead cost of multiple development lines is the fact that each development line has a separate hierarchy of team areas. For situations where you have an identical structure of 10 teams working on 2 concurrent development lines, this means you'd need 20 team areas which can be inconvenient. However, in your case I'm guessing this isn't a problem. You said that you've got 40 separate schedules going concurrently, which can't possibly be handled by the same teams. So in your case, I would guess that the separate team area hierarchies would be a feature. For each of your concurrent development lines, you'll have an accurate representation of which teams are actually doing the work. -- Jared Burns Jazz Process Team |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.