> > For us, several software modules are shared across several projects. > > Business projects have a shorter lifespan than software projects. > > Consequently a software module may be improved several different > > times, each as a result of different business projects. So we may > > want to see the entire timeline when looking at a software module, but > > when looking at the effort for a business project we may only want to > > see the timeline during the begin/end period for that business > > project. I guess that's why using the Hackystat projects the way I > > described earlier makes sense to me. How could we use the projects > > differently, and what benefit would this new templating setup bring to > > us? > > If I understand you correctly, you're using projects correctly, in the > sense that you use projects to: > > (a) define a short-term increment of work over a set of workspaces. (a > "business" project). > (b) represent the long-term history of one or more workspaces (the > 'lifespan' of a functional unit) > > And, of course, these projects can overlap, both in terms of the time > interval and the set of workspaces involved in them.
OK. That makes sense. I guess it's a bit hard for me to think in workspaces. :-) But it sounds like we're on the right track. > In answer to your question regarding the utility of the templating setup, > the first thing to note is that all telemetry occurs at the level of an > individual project; there are no facilities to support, for example, a > telemetry report consisting of three charts, each reporting the size of a > different project. In other words, in any given telemetry report, all of > the charts are going to provide values regarding a single project. > > In our case, the hackystat project consists of a couple dozen workspaces > and a dozen developers. Let's say that we are interested in, for example, > the active time by each developer on each workspace. Right away, that's > 288 distinct telemetry streams. Templating allows us to avoid having to > manually define and name all 288 streams. It would seem to me that you > will soon hit a similar point with your current setup, where you find that > the number of streams you want becomes a multiplicative relationship > between components, developers, and an analysis. As soon as you start > thinking, "This is going to be a ridiculous number of telemetry streams to > define", templating will hopefully come to your rescue. I'm still not quite getting it. Sorry to be slow on the uptake, but I guess this is where I'm missing something. If we have a "business" project that spans 15 workspaces, then I'd setup one Hackystat project that looked at all 15 workspaces, and 15 projects that looked at each individual workspace. Then I can just browse to the Hackystat project at the granularity level that I'd like and see the MemberActive time telemetry stream for that project. One view gives me how much time each developer has put in on the single workspace, and one view shows how much time across all workspaces for the project. So we've got a bunch of projects for software components, a few for "business" projects, and an overall one that shows how much active time everyone has anywhere. With this setup, I couldn't look at the combined effort of individuals for workspaces 3, 7, and 15. If I wanted to I'd have to setup a phony "business" project. I guess since I'm seeing it so hierarchically (I only care about certain branches at a time, or aggregates of those branches), I'm having trouble seeing a time when there's a multiplicative explosion. That seems like something that would happen if you're looking at it differently, and so I think I'm missing both that perspective and the idea of what types of information I could get from it that I can't get from the hierarchical view. Does that make sense? Thanks for your help! Tim
