On Sat, Aug 8, 2009 at 2:30 PM, Lyle<[email protected]> wrote: > Hi, > How does your company deal with project management? Specifically with > the creation of project plans and the associated diagrams charts. I've > head Microsoft project mentioned quite a bit in the past. But I'm sure > the people here use viable open source alternatives, or maybe a > different approach all together? > > Project scheduling is always a pain, I've always struggled to give > accurate estimates on the time needed to complete a project/module. How > do you deal with this? >
Within my team, we use Scrum. It's worth bearing in mind that our work is on in-house products rather than commercial client projects, but I've used the same techniques for client projects. We do all of the following using twiki pages - making heavy use of the EditTablePlugin, ChartPlugin and SpreadsheetPlugin. The latter is pretty awful, but we've found a way to make it work for what we need. We keep a product backlog, containing User Stories representing individual requirements. Each item on the backlog is given a high-level, relative estimate, using Story Points. We organise our work in 3-week sprints - for each one, we select stories from the backlog based on how many story points we achieved last time (Velocity) and what our staffing level is. Within a sprint, we break stories down into tasks and track progress on those tasks using a Sprint Backlog and Burndown Chart. If the sprint goes really well, we might add an extra story, if it goes badly we might remove one or agree a cut-down version that will be acceptable. So, to plan a project, we'd create the initial product backlog. We'd add story point estimates and our Product Owner would prioritise the backlog. We'd pick a sensible initial velocity and work out how many sprints that would mean we'd need to finish the majority of the backlog and that would be our initial timescale. After each sprint, we'd update a project burndown chart with the results of that sprint. This would show how we're progressing towards the end of the project and whether our expected end date has changed. Caveats aplenty! Working this way with clients requires one of two things. Ideally, your client is aware that project management is not an exact science and is happy to take the benefits of a Scrum-like process (openness and honesty, ability to steer the project part way through, ability to end the project early if the initial functionality turns out to be all they need) and live with the lack of concrete "legally binding" promises to deliver X by Y at a cost of Z. If your clients aren't there yet, the alternative is to insulate them from the process while exposing some of the subtler benefits. The insulation part includes adding a lot of padding to the plan and creating semi-fake Gantt charts. The benefits you can still expose include early visibility of working software and being flexible about changes to "the spec". Links: * Scrum overview: http://www.mountaingoatsoftware.com/scrum * User stories: http://www.agilemodeling.com/artifacts/userStory.htm * Planning poker (we use this for estimating): http://www.planningpoker.com/detail.html * Scrum with fixed contracts: e.g. http://stackoverflow.com/questions/265319/using-scrum-in-fix-length-fix-priced-projects (google "scrum fixed price" for more) Hope that helps Alex _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
