Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hello! Hi, everybody! Everybody still have energy at the end of the day? We're still here attending. I'm sorry, what? (chuckles) So, all right, I want to start this with what is going to seem like possibly an unrelated question. How far do you live from an airport? Think about what you were going to.
. . Think about what you would say about that. You could say it out loud or not or, you know, just think about it. When this question comes up, I have no problem saying that I live 20 minutes from an airport. That's basically factual, as far as I'm concerned, like I will drop that in the conversation.
But, of course, that's not really true. That's dependent on a series of assumptions. It assumes, for example, that I'm in a car. Walking to the airport, in my case, O'Hare, would take a lot longer. It assumes the weather is good, which, in Chicago, is dicey for about half the year.
It assumes that it's not rush hour, which means that's dicey for another, like, 10% of the day, nothing untoward happens, like blowing up a tire. On my way here yesterday, I learned another assumption which is the assumption that the cab driver takes the optimal route to the airport.
If the cab driver messes around in the back roads of my suburb, it takes a couple of minutes longer. Despite that, despite the fact that all of these factors would conspire to make my trip longer, okay, I'd still say that my trip to the airport takes 20 minutes, even though there's no way you could possibly take less than 20 minutes, unless I went.
. . Unless I teleported. And, and all kinds of ways for it to take longer. In other words. . . And I still find this 20-minute estimate, for lack of a better term, to be so valuable that I use it, and I don't even know the actual distance that I live from the airport in miles.
I only know it in minutes, even though it's problematic. So, my name is Noel Rappin. This talk is 20. . . 30 minutes. I realized I had more time in the slot, so it's 30 minutes, give or take 10. It's going to be very embarrassing when I go over at the end, so I'll get that out of the way right now.
I work for Table XI, which is a consulting firm in Chicago. If you need consultants in Chicago or you want to be a consultant in Chicago, come find me at some point over the next couple of days, or if you just want a nice green circle sticker with an XI on it, I have a bunch of those as well.
You can also follow me on Twitter, @noelrap, if you want to say something about this talk or just say hi in general. My qualifications for talking about estimates, well, once upon a time, I gave an entire full-day workshop that ended exactly at four o'clock on the dot, as scheduled, as evidenced by this one tweet from one guy sometime.
And since I actually got an estimate right once, I think I'm very qualified to talk about estimates. I'm also, I'm also slightly idiosyncratic about this. You will probably disagree with some of this. Many people do. People are somehow successful, even if they do estimates a different way than I do.
I don't know how that works, but apparently they are. And that's fine. This is, this is a way that works for me, and it's a method that works for me, and you may do something different or have different opinions, and that's fine. So, one thing that you hear about estimates is that developers are bad at them.
I think that's something that almost everybody in this room has probably heard, that estimates suck, developers are bad at them, we can't do it right. And sometimes your question is, like: are software developers uniquely bad at estimates? Sometimes you hear phrases like we are so bad that we have problems that no other industry has because of our estimates.
And the only thing I can say to something like that is that people who say something like that have obviously never been involved in any kind of home remodeling or a construction project or involving any kind of home contractor, because that is an entire industry that is dedicated to time overruns and cost overruns, and has an entire vocabulary dedicated basically to scope creep.
And it has a lot of similarities to software in that a lot of times, you don't really understand the problem until you try to solve it. You don't really know what's behind the wall until you tear the wall down. And it has very similar pressures in terms of a pressure to deliver an initial estimate that's low, for obvious reasons, to make a sale or for other reasons.
Or, I can point you to this. This is Boston's Big Dig. Are there people here who live in Boston, near Boston? I lived in Boston for a pretty good chunk of this. This was the most ambitious public works project in America in the 2000s. It was an attempt, a successful attempt, to replace the North South Overpass Highway through Boston with a series of North South tunnels.
It occurred to me as I was putting this together that in reference to the airport analogy, it also involved an exciting game of "How will we get to the airport "this week?" for about two years as the access roads got messed up. The Big Dig was originally estimated at $5.
8 billion, which is a lot of money. It came in a tiny bit over that at a mere $21. 93 (laughter) and counting, because they're still fixing a couple of things that weren't installed correctly the first time. So, estimation is not just our problem. There are other industries and there are other kinds of engineering that have similar issues when trying to come up with a time or a money estimate for the work that they do.
But software, we have, we have a slightly more unique solution because it's, at least in theory, easier to change software estimates and move software around than it is to move walls or giant tunnels underneath Boston or things like that. So, potentially, there's something that we can do about it.
Some people, sometimes you will hear now the suggestion, people who think about agile projects, that we don't estimate, that software estimates are so bad that they're actually a negative to project success or project happiness. And so you can find these people sometimes with no estimates, sometimes a hashtag or a sort of rallying blog post or whatever.
And they suggest that we don't estimate, and that we just do stuff and get paid. The ideal world here is that you continue on a very tight feedback cycle where you take the highest priority task remaining, you do it until you're done or the client runs out of money or gets mad or some combination of all of those things.
So you can just do stuff and get paid. And I can imagine this working in maybe a startup environment, a product environment, where you don't really have a deadline or customers or clients, and there is enough money to cover all of this. But I'm a consultant working with clients with tight budgets, and it feels somewhat similar to me saying, like, "We're just going to tear up your kitchen, "and you just keep writing me $15,000 checks, "and eventually you'll probably get your kitchen back.
" It is not effective. It's not, it's not useful to our customers. Customers, I think, reasonably expect to have some kind of idea of what they're getting into before they start a project, and it is on us to give them some sort of good faith plan to do that.
You sometimes hear that projects don't fail for technical reasons. Projects fail, in part, for communication reasons. And I think estimates are a very important piece of communication between the team that's doing the work and the team that is paying for the work, managing the work, covering the work.
But you have to be careful with it because it's communication that has dollar signs attached. Anything that gets a number attached suddenly requires a certain weight and a certain gravity in discussion, and it's had to move it, and especially, once you put a dollar sign on something, no matter how crazy or how fast your process was to get to that dollar sign, once you put a dollar sign on it, in the mind of the person that you are talking to, that is a real thing, and you need to take that into account in future discussions.
[ ... ]
Nota: se han omitido las otras 4.004 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.