2009/Project Management Should be Boring!

From Open Source Bridge Wiki
Jump to: navigation, search

Many people see project management as the art of trying to please everyone and pleasing no one, while trying not to go too far over deadline and too far over budget. It doesn’t have to be that way. Good project management can be so predictable and reliable that it’s almost boring. Here’s what works in real projects.

Speaker: chromatic x

Return to this session's details

Contributed notes

Relentlessly destroy order-dependent and/or intermittently failing tests

Hope is the enemy of reliability in open source development.

Bug trackers = Roach motels built around a black hole. Bugs check in but they don't check out.

Contributed notes (notbenh)

success

first solve your biggest problem, then iterate to solve the rest

boring is good

  • having good processes = boring
  • not having emergencies = boring
  • no crisis mode = boring
  • culture of relentless progress = boring

so how do I make my PM boring

Thing of how to make your project a success, then do that.

risk

Theres tech risk (it doesn't work) and scope risk (it takes 3 months to do but it needs to be done next week)

quality risk (it only installs on one box, it fails every Tuesday)

cost risk (good = expensive)

TDD

>2min iteration

0 write test 1 run test (FAIL) 2 update code 3 run test (goto 0 if SUCCESS else goto 2)

TDD requires discipline and patient but it gives you great gains.

Deliver software

  • if you can time box your work then you restrict by time (not features)
  • starts to build a cycle
  • builds momentum

Thesis: unreleased code does not exist

you release not because the code is good but because you promised to release.

working on a cycle

just like tests you get feedback

if you release every month then you have a space for the customer to give you feedback (like it, hate it, needs this)

Just like testing it makes sure that you stay on task.

This is just applying the scientific method to development, it allows you to validate your theory.

find a way to destroy all sources of uncertainty.

Thesis: many of non-tech problems are rooted in not understanding risk

risk: customer changes priorities

common response:

  • require customer to stay on task
  • stay on point with in the team

!! FAIL you cant predict the future, so why try and restrict?

way to resolve

delay making a decision until the last possible RESPONSIBLE moment.

EX: I'm planning a party in a year, I can't make the menu because I don't know who is going to be here

get really specific when you know everything that you need for a feature, other wise play in broad strokes.

prioritize on broad features (ie we need a shopping cart )

risk: release now might be unstable

common response :

  • feature branch
  • feature freeze

this only delays the next iteration, you end up in QA for ever, you block everyone, its demoralizing and it inhibits your ability to plan.

best solution: always have a trunk that is releasable

if you cant release now then how do you know if you ever could?

risk: low quality

common response :

  • need more QA
  • need for really lock feature freeze

problem is that you are not addressing the root cause, its quality not QA.

more tests? exploratory testing (LOOK IT UP)? if quality is low then why is it bad?

are you really done done? is it schedule pressure? is it skill level?

is the reason because you do not get any feedback.

what if testing takes to long

common response :

  • branch early branch often

every time you have a long lived branch you double your burden.

you need to parallelize QA.

create a way to get as much feedback in to the cycle.

feature branch

there good as long as its a feature that you plan on merging back soon, not in months.

trunk has to be stable and releasable

risk: expectation for deadlines

common response:

  • gantt chart
  • plan an entire release

um, were all optimists, stop trying, break things down in to things that can be estimated.

burn up chart: graph to project based on tasks velocity, but this only works when you know how long a task is and you can project


risk: no one knows the deadline

common response:

  • make a deadline to blow

remove the uncertainty by having a steady release, on a cycle, you no longer have to make the decision on when to release.

all that is left is asking if trunk is releasable? and is this feature going to be in the next release?

if you release on an interval then it really doen't matter if a feature is going to miss the deadline because it will be picked up next time.

again it forced more feedback

risk: we keep getting bugs

unhappy users you've found documentation issues

common response:

  • better but triage (relies on hope, and hope is not repeatable)

your not preventing bugs, your not proactive only reactive.

no bugs

if its an issue that takes you less then 2 minutes, then just do it now.

if it takes more then 2 minutes and its something that needs to be solved then it's really a feature request, add it to the project feature list.

if its not worth doing then skip it


risk: no one knows what to do with this (this design is unsustainable)

you have built barriers to allow your customer solver there problems

common response:

  • grand re-factor

no one is every going to just rewrite everything, theres no need for your employer to spend time to stay in the same place.

theres a three step re-factor process

  • clean your code while you see it
  • take some time, say 2 hours on Friday, clean up stuff gunky bits if you have all your other tasks done.
  • every release spend some time and do a post mort to build out features for your self, (ie I keep mistyping this method because its a plural)

in short every commit should make the code better and easier every time.

deprecation

have a deprecation policy, stick to it.

release Tues 945 am

its the most boring time

what can you negotiate

  • you can talk about scope
  • you can not talk quality
  • NEVER talk about time estimates

how to you improve

ask your self 'why' 5 times and don't repeat your answers. where you end up is probably a good place to start fixing things.

why did we miss the deadline. we didn't run the tests why didn't you run the tests. they take to long. why do they take so long? because we run on the entire customer data set...




QA

how do you deal with expensive releases

if it takes 8 hours to install an upgrade is a weekly cycle good? - you'll have to optimize the upgrade, point out the bottlenecks as features'

how does this work with large systems?

ie if I have a small project, and then we find out that we need a big DB, now we need a schema design....

  • when you know that you have more needs then you can start to plan, you can still address it incrementally.
  • also if you can encapsulate, then do it, you will reduce the risk as you have limited the stuff that will change.