I agree with both of these suggestions.
Indeed, I think that there is a huge design space when it comes to the question of how issue data gets connected to other process and product data, and that over time we will probably come up with a palette of approaches, each one suited to different organizational contexts and different analysis requirements. There won't be any single solution to the issue of issues. :-)
Cheers, Philip
--On Friday, December 3, 2004 11:54 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]> wrote:
Hey All,
Looks like I had another idea... Here it goes.
With the introduction of JIRA into our development process and Burt's great work with the JIRA sensor, we now can begin to tie-together issues and all the other Hackystat data. For example, we could potentially know how much active time is required for a bug fix or an enhancement. This would be a really cool project management improvement. And I believe JPL is now interested in this sort of connection (and until now I don't believe anyone else could accomplish this).
To accomplish this, I propose a development process that requires two steps; (1) lets change our development process slightly and (2) connect issue data with other Hackystat data.
Step 1: We've already began to use JIRA to manage our development activities. Essentially, we are currently supposed to be logging any Hackystat defect fix, enhancement, or improvement into Jira. My proposal will make this process a little more "strict"; but this can be done before or even after (if a developer forgets) coding begins. One way to make this more strict would be to require developers to add a more detailed workspace string. So, instead of just "hackyKernel" we should put "hackyKernel/src/org/hackystat/admin/". I know that I'm the only one that adds detailed workspaces to an issue, because of my work in Priority Ranked Inspection. But I think it is a good practice to adopt, because when I read other peoples issues I have no idea where they have been working or where the bug is. When issues get reassigned or even re-opened this detailed workspace field will help developers understand where to look. I also don't think it will take that much more effort to provide the package since the assigned developer will know where he/she is working anyway. In addition, if we forget to add a new issue to JIRA and start working on something there will be a Hackystat Alert that notifies use that there are no current Issues that is associated with the Active Time you just sent to the server.
Step 2: Implement an analysis that connects the Issue data to the other Hackystat data. This should be relatively easy to do. By doing this I imagine a Hackystat analysis that displays an issue, the amount of active time that was recorded during the time between the issue being open and closed (and only for the developer that is the assignee), the amount of code churn, etc. In addition, there should be an Alert that is triggered when Active Time is sent to Hackystat that it can't find an Issue to connect it with. (By the way, when I say connected, I of course mean at analysis time and not in the raw sensor data).
The advantages of this are: (1) analyze work versus rework, (2) analyze the average amount of time required to fix a defect a major defect, (3) by adding this dev process change and new Issue analyses, our JIRA Issue management will be more representative of what we are actually working on. (4) and a lot more...
What are the down sides to this: (1) Sometimes developers just hack code that doesn't really need to have an associated Issue. That is fine.. The data just won't be connected. (2) Sometimes developers hack in so many different packages and modules that its hard to specify all the workspaces.. That is ok.. The data won't be connected. No biggie. I'm not saying that this connection is always necessary. But, it seems for most our issues it is possible and why not make that connection. (3) I can't think of anything else!
Here are some thoughts about the connection that is required for the analysis: 1. Get Issue X. 2. If X's trigger = Open, then access the DailyProjectActiveTime and get the active time with a FilePattern that matches X's workspace field. Do the same for other DailyProjectData. 3. If X's trigger = Start Progress, then do the same as 2. 4. All other triggers are ignored.
Here are some thoughts about the No Issue Alert, which works on a timer task;: 1) Every night, the alert processes all the activity data sent to Hackystat during that Day. 2) Look up Issue data and make sure we can find an Open or Start Progress Issue with the same FilePattern/Workspace*. Else, we send an alert notifying the developer of the missing Issue * It seems that a Snap Shot Issue sensor best supports this look up.
Here are some thoughts about the Analysis: - Required Selectors: Project and Interval: - It should process all Issues that we have data for in that given interval. Again, a snap shot Jira Sensor is required. - Make the connection and report with a Table similar to the Adoption Analysis, which provides sortable columns. Columns should include; Issue Summary, Workspace, Issue Status (open, closed, etc), Assignee/Developer, Issue Type (defect, enhancement, etc), Number of Days Open, Active Time, File Active Time, Churn, Review Issues, Review Active Time and some others.
I really don't think this will be hard to do. In fact, it seems really simple. What do you guys think?
thanks, aaron
ps.. Something totally unrelated - I just found a really good Jazz Radio Show in Hawaii. 89.3 FM - 8pm-12am . Its pretty good music to Hack to.
