Since I've had a while to digest some lingering thoughts, there are several subtle-but-important changes I'm intending to employ after this week's source release to help get a better handle on our overall development rate and to help scope and prioritize tasks. Basically, I'm looking to adopt even more of the agile process that we already adhere to, but with a few significant changes that should help with release scoping, estimation, and reporting metrics. In brief, I'm proposing that we utilize our TODO file a *lot* more rigorously.
First and foremost, I'm going to add in time estimates to our existing tasks. This is so that we can track our development velocity and normalize effort estimates. We already have a sprint backlog with current and next iteration planning in place. The level of effort estimates, though, haven't been recorded and we've not been strict about adhering to and end-of-sprint (i.e., end of month) release. A two-week release window is simply too flexible and causes us to skip releases, often for several months at a time. I'm a firm believer in the "release early, release often" mantra for a variety of reasons, and I see this as a problem that we really need to work better at. With the backlog velocity being tracked, we should be able to make better estimates of reasonable progress to be feasible within a given month. So what I'm proposing we do differently from current practice are the seven following practices: 1) When adding a TODO item, include best guess estimate of concentrated/uninterrupted time (in days) that it'd take to complete the task. 2) When adding a TODO item, evaluate a priority between 1 (low) and 5 (high) inclusive based on perceived value to users and potential impact. 3) The TODO file backlog will be prioritized according to value and impact potential. 4) No adding items to the current release iteration mid-sprint. Add it to the next release iteration or to the task backlog in TODO. 5) No task on the TODO should take more than 20 days to complete. Break up larger tasks into multiple smaller tasks. 6) Active developers should review the TODO file at the beginning of each month and indicate (by the 7th) any planned tasks to be completed for the current release iteration. 7) Assuming the regression tests pass, a source release will be made within one week after the end of an iteration unless there's a known show-stopper issue. If you don't know what the heck I'm talking about while referring to sprints, velocity, and release iterations, read up on Agile development practices [1] and the scrum process [2]. As you do, keep in mind that (a) we have a 4-week sprint cycle aligned with calendar months, (b) the TODO file is our "project backlog" with two release iterations, (c) we (obviously) don't do daily scrums (we instead engage in daily IRC discussions). Comments and feedback welcome. I'll take a stab at estimates and priorities for existing elements after the next source release. Cheers! Sean [1] http://en.wikipedia.org/wiki/Agile_software_development [2] http://en.wikipedia.org/wiki/Scrum_(development) ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
