actually, "it's done when it's done" can be sold in a corporate
environment. it has the unfortunate characteristic of being the closest
thing to truth when modeling software development, and no amount of
pre-planning or chart-making is going to get you a more accurate answer.
some key facts to present to your management when making your case:
* developers are unable to give unbiased time estimates when they know
their performance will be judged by comparison to them later
(it's OK to ask, but never say "but you said...")
* individual feature deadlines encourage either:
- slacking because you know you're head of schedule
- hacking because you know you're behind schedule
both of which are detrimental to quality and productivity
* final performance should be judged via post-game analysis (when the
scope and complexity of a problem are known) and pre-game
preconceptions should be given little-to-no weight
* day-by-day performance can be had by monitoring VCS/bugzilla, with no
performance penalty to the developer. (as long as you enforce
frequent commits - teach them about temp. branches if they're going
to be breaking existing functionality for days on end)
and don't say "but my employer/phb is too conservative for this". i've
run dev teams for telcoms and the us military, two of the most
hard-nosed waterfall-lovin' organizations ever to have existed. it
takes a while to prove it right to them, but given persistence without
dickishness it is possible. (and most PHB's aren't actually evil, just
confused by the mystical beast that is programming, annoyed at being
treated like a moron because they don't the the computing equivalent to
"what's the proper timing sequence for a ford 302 V8", and suspicious of
programmers who have a history of outright lying to them)
btw, why do you think OSS is beating the pants off of closed-source
stuff anyway? we don't have more money. we don't have smarter people.
what we have is a vastly more efficient development model.
anyway, my $.02.
derek
p.s. btw, it's career suicide just walk in and start with "we're going
to abandon everything you trust and go with what is described above".
prerequisites include:
* building strong trust relationships with your superiors, and making
sure that when they don't agree with you, they believe you're truly
arguing in the best interests of the org.
* proving first that you can make *their* preferred development models
work, before you try changing them.
* and don't try to change things wholesale. break them in a piece at a
time, each time starting with "let's try an experiment"
p.p.s. as far as release dates go, it's ok to set them. just have it
be known that the deliverable feature set is an always changing target.
done features are definitely in, in progress features are in flux
between making the release or the next one. and your unknown factor
naturally shrinks as you get closer and closer to the date. with
frequent releases, you'll find the users don't bitch too much when you
tell them "sorry, X didn't make it into this one because it {'took
longer','fell to higher priority work'}"
p.p.p.s. still reading? sorry, this turned into a much longer email
than i anticipated. =p
Stefan Matthias Aust wrote:
> Joe,
>
> 2007/10/1, Joe <[EMAIL PROTECTED]>:
>> [...]
>> And this is the biggest disconnect between Django's team and the
>> business world. If I went to my bosses and told them "It's done when
>> it's done" about our upcoming product releases, I would get fired.
>> Your response should be, "It's really hard to estimate, but here is my
>> best guess and a target for us to shoot for." And, you know what?
>> Most of the time our estimates are pretty close. And by tracking how
>> we do on our estimates, we can make them even more accurate.
>> [...]
>
> You explained my points much better than I could (in plain English at least ;)
>
> Thanks.
>
--
looking to buy or sell anything?
try: http://allurstuff.com
it's a classified ads service that
shows on a map where the seller is
(think craigslist + google maps)
plus it's 100% free :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
