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
-
Chris: worry about more active planning of release
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
-
trac
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
-
Could Scott turn our bullet points into a survey?
-
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