What's that expression again? Luck is what happens when preparation meets opportunity. I was reminded of this cliche recently while reading The Last Lecture by Randy Pausch (a must read). How lucky are you? To be prepared, I think you need to have a plan.
I've been spending a lot of time planning lately. So much that I've had little time to come up for air. In addition to looking at what I'd like to release in the next versions of ER/Studio, ER/Studio Enterprise Portal, and other Embarcadero products in 2009, I've been looking at what will be part of next year's incarnation of MDT as part of the Galileo simultaneous release in June.
Plans for Eclipse projects were due yesterday, and I'm pleased to say that the MDT component leads were able to pull together plans for the MDT components just in time. There's a new, standard format for plans now, which I think is a good thing. One of the nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. Projects like EMF have been doing this for years; I'm glad that more projects will now be able to take advantage of this time-saving approach to planning.
Unfortunately, one of the not-so-nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. I'm cool with the notion that a plan is a "living document", and that using Bugzilla queries allows plan items to transition from "proposed" to "committed" or "deferred" without having to update the document. But this approach also allows bugs to be added and removed from a plan without an easily consumable record of these changes or why such decisions were made. Where's the accountability? In my mind, a plan is not just a document that you can point to at the end of a release to say what you ended up actually doing - that's what release notes are for.
One of the challenges I encountered early on while trying to put together the plans for my MDT components was the desire to view a plan after a release and have it still accurately reflect what was originally planned. Depending on how the Bugzilla queries in a plan are written, it seems that items (particularly ones with version-agnostic target milestones like "M6") which are on the plan for one release could conceivably disappear from that plan and reappear on the plan for a subsequent release. In the absence of the ability to assign multiple target milestones in Bugzilla (one of the features of JIRA that really like) I realized that I needed a way to tag a bug such that it would always be affiliated with the plan for a given release.
I proposed the introduction of a 'galileo' keyword (for bugs that are part of the plan for the Galileo release), but some folks were concerned about the proliferation of keywords (because they are global elements in Bugzilla). Then Denis suggested an even better idea - a 'galileo' flag that could be made available only for projects that wanted/needed it. As it turns out, it's quite a useful thing. Not only can I now tag bugs as being committed (galileo+) or deferred (galileo-) items on my Galileo plan (in perpetuity), I also have a way of marking bugs that get fixed in the Galileo release but weren't originally on my plan (indicated by the absence of the 'plan' keyword). Thanks, Denis!
Subscribe to:
Post Comments (Atom)
Posts
8 comments:
Ken, to get your Frozen Snapshot Plan, one could run the XSLTs in a batch mode for a particular project, and generate the Plans at the beginning, and then at each milestone start so that users can see what is occuring.
One of the things I think that is important to do is to keep track of what is being worked on during a particular Milestone, and what has been completed for a milestone. I'm of the Scrum project management mindset, where there is an overall Product Backlog, and then there is the sprint backlog which are the items planned for that sprint. I've documented this a bit in the XSL Tools project plan page.
In some ways, I wish there was a Burn Down Chart showing progress through the plan, and that Bugs as well as Enhancements are included in the plan. Some groups only include Enhancements, which doesn't show the complete picture.
Dave, thanks for the suggestion. I agree that it may make sense to take regular snapshots of the plan at key intervals (milestones). Hopefully the EMO will provide/adopt some guidance here so that we all do it consistently
I'm of the Scrum mindset as well - we use it extensively here at Embarcadero. Burn-down charts are an indispensable way to track progress and do forecasting. It's almost like you need both a story backlog and a bug backlog, and some way to correlate/combine the two in a consolidated plan and associated burn-down chart...
A definite must have book for this stuff is Mike Cohn's Agile Estamating and Planning. An introduction is here. Hopefully the EMO can adopt some more agile techniques...my fear though is that it's starting to deviate away from the agile roots both in planning and in development.
Here's the link:
http://www.mountaingoatsoftware.com/presentation/85-an-introduction-to-agile-estimating-and-planning
Thanks. I actually have that book sitting right here on my desk. What's lacking is tooling to help doing things the way we do them based on the techniques in the book. :(
Have you checked ScrumWorks out?
http://danube.com/scrumworks
No, but I've been taking a closer look at Rally (http://www.rallydev.com/) lately because of their integrations with issue tracking systems like Bugzilla and JIRA. Have you used any of their tools?
Haven't used those, but they get good reviews. There is also now a Scrumworks connector plugin for working with Mylyn as well.
Post a Comment