Personal tools
  • We're Hiring!

You are here: Home Community Minutes Conference Calls 2010 2010-01-19 Tuesday Meeting

2010-01-19 Tuesday Meeting

Discussion on project management by Donald

  • Mtg w/ Cat

    • work with 14 nographic masters students
    • break into 3-4 groups
    • no funding
    • 11-12 weeks
    • plan of investigation is not yet clear
    • not necessarily technical
      • e.g. digesting of ethnographic info we have
  • proj mgmt background

    • improving for a distributed team
    • our process v. tools out there
      • we're not agile
      • agile is a principle
      • process is different types of systems around agile
      • centered around short iterations
    • Donald: "shouldn't take any more than 4 weeks"
    • our process:
      • 4-6 months releases with bug fixes after
      • tight spiral
      • Chris: depends on what you define as a release
    • cF. features we promise to provide somewhere
      • multiple (streams of) requirements
    • was previously more agile (as we were smaller)
    • because of bad scheduling ("clumsy" not "agile")
      • more likely to throw things out then add them in
    • we are responsive ways to user
      • need another way to document that than tickets
    • we don't use process/tools to best advantage
    • Chris: lot of decisions made on back of not releasing often
      • has to be balanced against users
      • Josh: but acceptance tests should pass
      • Donald: have to change if we want to take advantage of it
    • agile vs planning
      • Chris: worry about more active planning of release
        • can't change as much
        • Donald: either way have to buy into process
      • Donald: where in the middle of plan- and agile-driven
      • Scott: agile doesn't advocate cowboy coding
        • trying to reform that
  • proj mgmt tools

    • trac
      • dead pool of tickets sitting in "unscheduled"
      • everything in trac is a sea of tickets
      • lots of tickets we missed
      • no way to visualize all the tickets
      • no scheduling, strictly milestone based
      • Chris: communication component of trac
        • "here Donald, please ..."
        • Jean-Marie: cF. QA also reporting to the user
        • Dev2Dev communication and to user
    • graffle
      • use for scheduling, gantt-chart replacement
      • works because it highlights what tickets should be done
      • doesn't work with svn or trac (Will: could just add ticket #)
      • no metrics
      • Donald: We could do something more, but it doesn't do it for you
      • Will: to see "that overrun" you'll have to more information
      • Chris: visualization is great
      • Donald: not good at hierarchies or showing whole roadmap or "future"
      • Donald: Could change how we use trac & graffle to get history
    • requirements
      • sent an email, a few comments
      • 2 parts
        • process * commitment!
        • practices * coding, style, docs, etc. * not breaking trunk, etc. * refactoring * training
      • planning
        • more than ticket writing
        • we could formalize with "weak" / "strong" reqs
        • have done it before with planning poker, but didn't for 4.2
        • we don't schedule at all
        • going back to iterations! with demo.
      • tools
        • simple: shouldn't bog down the process
        • visible to the community
        • planning/scheduling/prediction
        • visualizing what's in the system and not just as tickets
        • prioritizing: we've basically ignored this
        • provided list were the most sophisticated
        • Josh: adjusting our existing tools has a non-trivial cost
        • Donald: we still haven't defined a process
      • adapting current system
        • trac * we're really lazy * we could do a better job of breaking down tasks * have docs, commits, demo code, etc.
        • graffle * use it as we currently do
        • example of "UploadMask" as a task * time allocated * a number of things that you have to do for any tasks
        • Chris: formalizes the way you work with version control * big commits v. small commits * goal of all of us working in a similar way
      • fog bugz
        • Chris: trac on steroids
        • Donald: several advantages
        • Donald: missing some svn integration *- jira
        • grasshopper for using swimlanes to schedule
        • most of the systems take trac and add in visualization * Chris: we could do the same with trac but we'd have to build it * Donald: trac has some plugins, but not the same integration
      • acunote
        • clumsy visualization
        • but sits on top of trac
        • doesn't give us very much
      • agilo
        • whiteboards, estimates, costs, etc.
        • whiteboard is more sophisticated than acutnote
      • mingle
        • most sophisticated, end-to-end solution
        • free for open source
        • whiteboard
        • full breakdown of tasks (subtasks) connected story
        • unit-tests if integrated
        • metrics
        • Chris: encourage task-driven ticket creation * would end up with thousand of tickets in a single list
        • proper training
        • professional solution
  • proj mgmt summary

    • have to commit to a process
    • what are our goals?
    • and then decide on the tool
    • rewriting may not be the worst idea (house cleaning)
    • Donald: use what we have or go big
    • Jean-Marie: better usage of the people we have
      • number of people vs. how we plan them, expectations of funders
      • honesty about tasks. 2 days v. 1 week v. ...
      • all need the same basis of comparison
    • Scott: some of the tools adhere more to mgmt
      • Donald: all the tools are agile. some are looser
      • Chris: if you only write one ticket, the tool won't help
      • Jean-Marie: the tool helps your efficiency, but if there's no agreement on process...
    • Jean-Marie: as team grows, can't spend hours talking to everyone
    • Josh: hope was that the tool should help to get info in and out
      • have everyone know what's going on
      • need buy-in from everyone
      • can everyone speak?
      • Will: that means everyone has to put data in
    • Will: like the idea of what Donald said, to try it out
      • key changes in the process
      • deciding what the goals are
    • Scott: (won't really be using the tool)
      • looking over devs' shoulders
      • trying to make conversations happen
      • promoting conversations
      • Jean-Marie: e.g. seeing someone working on a task
        • "investigation with google"
        • see that it's planned for a week
        • spare time for doing research
    • Colin
      • nice ideas in the tools
      • if we all decided "mingle", none of us know how much time it'll take
      • how to gather more information?
      • Donald: even using our own system would cost time
        • may be quicker to just jump in
        • tried, other people are using it
      • buy into a tool
    • Brian
      • like the whiteboard idea, columns concept
      • agree with Josh, seeing others' dependenciese. not clear on what others are doing
      • like the 2 day cycle. (mon. & thurs.) would keep tickets flowing
      • Donald: 2 week tickets then get broken down to 2 day tickets
      • Chris: important thing is visibility
    • Ola:
      • like agilo and especially mingle
      • how much effort to get some information out
      • if we can get more than we put in, worth something
      • Chris: do we agree that what we have now is not working?
        • we're let down by tools not making it easy to plan
        • we can do it, but it's work. not using tool in most effective way
        • one way or the other we need to spend more time to plan effectively
        • assuming 1-2 hours now, then we'll need double in the future
        • we all do process in our own way
      • Donald: doesn't seem any more difficult than trac (all with whiteboard)
      • Donald: migle, only one with nice dependencies
    • Andrew
      • need dependencies! drop anything without
      • that's been the bad gotchas
      • saying what you're doing on a daily basis is not arduous (simple!)
      • recording every 15 minutes
      • Jean-Marie: it's not about tracking when you work, though
      • having an overview of others' ACTIVE tasks
      • when was last status update
      • Chris: critical thing about agile which works is:
        • if you can get your people to think about what we're coding and how in the same way
        • documeting it, making it available
        • if we don't do that, it won't matter
        • it helps development
        • cF. mingle, if you know "maintain groups" --> "1) add 2) delete ..." * easier to structure your work and your commits. it's helpful!
    • melissa
      • via IM: I have to run
      • my $0.02 is that Mingle looks really nice, but maybe we should wait to switch until after 4.2.
    • chris
      • didn't talk about: how we have the code structured.
      • multiple SVN instances
      • been an advocate of in the past
      • an over-arching tool won't work well with that
      • Donald: several have multipl project mgmts
    • carlos
      • only touch marginal parts
      • not satisfied at all
      • confusing for "outsider"
      • don't have any experience though
      • don't know what would best fit our problem
    • josh
      • would hope that a new tool would get us to grow together
      • Jean-Marie: trac doesn't allow us to see bodies of work (cF. graffle)
  • Decisions

    • Jean-Marie: evaluate for a week or too, and then agree and buy in
    • Andrew: how will it work with Glencoe?
      • have to make a decision on which tools we want to try
      • then we look at the integration
      • we have a huge CI overhead
      • i.e. a migration plan
    • Jean-Marie: also evolution of our working style
      • start a better usage of the trac
      • breaking down tasks
    • Brian
      • not just a matter of getting a better tool
      • should be looking at how agile is doing it's thing
      • also look at processes that go along with the tool
    • Donald
      • the tool is driven by a process
      • we have no formal process
      • e.g. mingle training
    • Chris
      • is a good way to go about this to take some of the things that are outlined...
      • (i.e. what it should do)
      • Donald: was hoping people would do that
      • Chris: have to be very, very specific
      • Chris: have to know what the process should achieve (and when CI should run, etc.)
      • Chris: got a good idea that we want to change and what we don't like
        • but what are we going to change?
        • "are we going to force javadoc on every method?"
    • Chris
      • What are we going to DO now?
      • Donald: does everyone buy in? Brian: I don't know what it is
      • Jean-Marie: have to take the whole list
      • Will: everyone's agreed that when we know what it is
      • Donald: previously 2 week iterations died after 1 week
      • Donald: see benefit of several processes
      • Chris: we currently don't do it because we don't see the worth
      • Chris: defining the playbook of how we do things
      • Chris: the whole thing is about confidence
      • Donald: buying into an external package gets us moving together
    • Josh
      • Could Scott turn our bullet points into a survey?
        • all of our ideas and then we vote
        • Jean-Marie: good idea
      • Donald: prefer the idea of buying into a process
      • Josh: but no process will define everything (svn, which process, etc.)
      • Scott: processes have no appreciation of the academic context
        • cF. mingle has lots of companies as customers
        • cF. what happened to editor?
      • Andrew: just a result of being grant driven?
        • happens in commercial software as well
    • Chris
      • pick tool, look at it for a while and see how that works
      • we'll have to decide our iteration times, etc.
      • see what doesn't fit into the tool
      • Brian: evaluators have to choose tool & the process with it
      • Jean-Marie: we should see if tool(s) cover all the surveys' checkpoints
      • Chris: will install mingle, jira, agilo, acunote
        • will report on what process they can enforce
        • trac has talked about these things, but still not released
        • but we don't have people to do proj mgmt (task wranglers)
      • scott will do the survey
      • Jean-Marie: wiki page minimum like Donald proposed
        • @he will do a wiki template
Document Actions