No, I agree; the complexity has gone up immeasurably. Which is *why* it is so important to scope the schedule as much as possible as early as possible & continuously to reduce complexity. And, again, prioritized backlogs doesn't allow for that, but time-estimation scoping does.
-
-
How many engineer-hours does your time think it will take to make the estimates correct? Can you give me an estimate for when your time estimations will be proven correct or not? If they are off, how long will it take to get more correct estimates?
2 antwoorden 0 retweets 0 vind-ik-leuks -
You are arguing against some sort of strawman of your own making. I was very precise when I said "give actual best effort estimates." Nowhere did I say "correct estimates." (It's also why I said "with probability.")
2 antwoorden 0 retweets 1 vind-ik-leuk -
Als antwoord op @ChristerEricson @tom_forsyth en
“How long will this take?” Is not a useful question in my experience. Rather “this is how much this is worth” is better. If it ends up taking any longer stop and cut your losses. Start with Plan B first so you have something to cut losses back to. Manage risk and ROI.
3 antwoorden 2 retweets 26 vind-ik-leuks -
Als antwoord op @mike_acton @tom_forsyth en
Individual estimates are not what are important; the totality is, because that allows you to plan across the whole project where things land (roughly) w.r.t. particular milestones. Now (and only now) can you *show* that terrain-blah won't happen in time, so either replan or cut.
4 antwoorden 0 retweets 4 vind-ik-leuks -
Als antwoord op @ChristerEricson @tom_forsyth en
I’m pretty confident we’re not really disagreeing on the general practice
@ChristerEricson2 antwoorden 0 retweets 0 vind-ik-leuks -
Als antwoord op @mike_acton @tom_forsyth en
I'm pretty sure your suggestion that after-the-fact scoping "is better" isn't compatible with my scope-upfront is the right way stance. I don't see how that would work. After-the-fact scoping is part of why game schedules are hit and miss. I described how to correct that.
1 antwoord 0 retweets 0 vind-ik-leuks -
Als antwoord op @ChristerEricson @tom_forsyth en
I scope by value before-the-fact. There are milestones and deliverables. Plan B is generally low risk and either more reliably estimable or cost-to-discover is low. I am not arguing that you don’t plan deliverables. I’m saying you plan according to their value to meet them.
1 antwoord 0 retweets 1 vind-ik-leuk -
Als antwoord op @mike_acton @tom_forsyth en
"By value before-the-fact" is what engineering always typically try to do, but it's a weak method that cannot ever tell you upfront how you're likely to miss something on milestone N, and that you should replan or cut. For $100M+ projects we should do better.
1 antwoord 0 retweets 0 vind-ik-leuks -
Als antwoord op @ChristerEricson @mike_acton en
My problem with estimates is that they always, no matter what, are wrong, and pretty much every tasks just stretches out to whatever deadline you choose. What I prefer is to do just that: 1/2
2 antwoorden 0 retweets 0 vind-ik-leuks
That independent task estimates are always wrong is completely irrelevant vis-a-vis reasoning about tasks in *totality*. Don't confuse the two.
-
-
Als antwoord op @ChristerEricson @miwanicki en
I think we’ve been not-quite taking about the same things, but this I can totally agree with. It’s got to run in frame. Some things may be faster than expected, some things slower. But as a whole, Make it fit.
0 antwoorden 0 retweets 1 vind-ik-leukBedankt, Twitter gebruikt dit om je tijdlijn te verbeteren. Ongedaan makenOngedaan maken
-
Het laden lijkt wat langer te duren.
Twitter is mogelijk overbelast of ondervindt een tijdelijke onderbreking. Probeer het opnieuw of bekijk de Twitter-status voor meer informatie.