Планирование, основанное на фактах | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- 31% translated in draft.
If you do not want to register an account, you can sign in with OpenID.
Evidence Based Scheduling | ||
Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten. | Разработчики ПО не любят составлять графики и планы. Обычно, они стараются обойтись без них. "Это будет готово тогда, когда будет готово!" — говорят они, ожидая что этот смелый остроумный ответ вызовет улыбку у их боссов, и в следующей беседе графики и планы будут забыты. | |
Most of the schedules you do see are halfhearted attempts. They’re stored on a file share somewhere and completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post mortem, and everyone has a good laugh. “Hey look! We allowed two weeks for rewriting from scratch in Ruby!” | Большинство, виденных вами графиков, — лишь робкие попытки. Они хранятся в каком-нибудь общем каталоге и полностью заброшены. Когда команды закрывают проект, два года спустя, тот причудливый парень со шкафом папок в его кабинете приносит старые распечатки на разбор причин провала, и все как следуют смеются - "Смотрите, мы планировали две недели на переписывание на Ruby с нуля". | |
Hilarious! If you’re still in business. | ||
You want to be spending your time on things that get the most bang for the buck. And you can’t figure out how much buck your bang is going to cost without knowing how long it’s going to take. When you have to decide between the “animated paperclip” feature and the “more financial functions” feature, you really need to know how much time each will take. | Вы хотите тратить ваше время на вещи, которые дают наибольший эффект. Но вы не можете оценить сколько вам будет стоить эта вещь без понимания того, как много времени это займет. Когда вам необходимо сделать выбор между функционалом "анимированная скрепка" и "больше финансовых функций", вам действительно нужно знать сколько времени займет их реализация каждого из них. | |
Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right? | Почему разработчики не будут составлять графики? Две причины. Первая - это занудно. Вторая - никто не верит в его реалистичность. Зачем тратить много сил на создание графика, если он окажется неверным? | |
Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this: | В течении прошлого года или около того, мы в Fog Creek разработали систему, которая настолько проста, что даже наши самые ворчливые разработчики стали ее использовать. И насколько мы можем судить, она выдает достаточно надежный график. Она называется "Планирование на основе фактов", или EBS. Вы накапливаете оценки на основе исторических данных учета рабочего времени, а затем применяете их для своих планов. В итоге вы получаете не просто конечную дату, на самом деле, вы получаете достоверную кривую распределения, показывающую вероятность, того, что вы сделаете поставленную задачу в срок. Она выглядит так: | — Пропущен, сложный для меня участок. — dzlk |
The steeper the curve, the more confident you are that the ship date is real. | Чем круче кривая, тем больше ваша уверенность в том, что конечная дата реальна. | |
Here’s how you do it. | ||
1) Break ‘er down | ||
When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours. | Когда я вижу график измеряемый днями или неделями, я знаю, это не будет работать. Вам нужно разбить график на очень маленькие задачи, которые могут измеряться в часах. Не больше 16 часов. |
© Joel Spolsky.
— it’s a pain in the butt - я не понимаю как это перевести... — dzlk
— it’s a pain in the butt - "это геморой", или "это заноза в заднице". — shine