Кармен сидела молча несколько минут, пытаясь понять произошедшее. Одно она знала точно: как только она в качестве оценки назовет число, дальше уже не будет иметь значение "правильное" оно или "неправильное".
Это число мгновенно превратилось бы в "план", и в течении последующих месяцев вся ее работа будет измеряться в соответствии с ним. С другой стороны, если это число будет "слишком большим", компания может потерять контракт, и Кармен будет ответственна за это.
Vasco Duarte "The #NoEstimates Book"
Прошло уже больше года с того момента, как я пообещал Роме написать (тут раньше была ссылочка на умершую соцсеть Google+), что я понимаю под #NoEstimates. Сразу сесть и написать не получилось, потому что решил поизучать, что вообще думает на эту тему мудрый и не очень мудрый интернет. Долго ли, коротко ли, время шло и похоже пришел тот момент, когда я понял, "что ничего не понял".
На самом деле, похоже, что мне нечего особо добавить к написанному тогда, в конце 2014 года: важна прозрачность вашей работы и доверие, которое основано на этой прозрачности.
 |
| Ссылка на твит |
Все дело в том, что оценка состоит из 2-х составляющих:
- сколько времени потребуется сделать нечто идеально проработанное идеальным программистом в идеальных условиях
- то, как на это время влияет окружение.
И если первое еще можно попытаться угадать (по принципу пол-палец-потолок или воспользоваться, например, знаменитой формулой Бобука), то предугадать изменения вызванные окружением просто невозможно.
Попытка получить вторую составляющую через оценку рисков, что часто советуют умные товарищи, всегда приводит к увеличению времени на проект. И все это время, согласно закону Паркинсона, будет благополучно потрачено, это как минимум. И превышено, это как происходит обычно (смотри веселые графики ниже).
 |
| Формула Бобука-Бацека |
Попытка получить вторую составляющую через оценку рисков, что часто советуют умные товарищи, всегда приводит к увеличению времени на проект. И все это время, согласно закону Паркинсона, будет благополучно потрачено, это как минимум. И превышено, это как происходит обычно (смотри веселые графики ниже).
А может на самом деле оценка - это процесс, а не некое значение? Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.
Но вернемся к мудрому интернету. За это время получилось насобирать много интересных материалов, которыми решил поделиться.
Сама тема пошла в 2013 году с хэштега #NoEstimates в твиттере.
Холиварчик получился знатный. И конца ему еще не видно (не было видно в 2016, и в 2023 тоже не видно, но уже реже мелькает).
Статья Джила Зилберфилда "В чем смысл #NoEstimates".
Не осталось в стороне сообщество тестировщиков, цинично-практичное, ну как обычно:
Кроме твитерных 140-символьных лозунгов можно почитать этот вот интересный опыт с ответами на вопросы "#NoEstimates a simple experience report"
Венцом темы считаю эти 2 видео (наткнулся я на них именно в такой последовательности):
Сounting stories is enough for projections, you don't need estimations
No estimates: how you can predict the release date of your project without estimating.
Благодаря им теперь читаю эту книгу: "No Estimates" (первую главу можно получить бесплатно). Думаю, что внутренности не будут сильно отличаться от того, что говорит в своем выступлении Vasco Duarte, но ожидаю больше подробностей. О них обязательно расскажу в следующих статьях. Тут можно почитать мини-интервью с Васко.
Он же собирает ссылки на статьи по теме #NoEstimates.
Немного цитат из первой главы, которую я уже прочитал:
К вопросу о том, что оценка не несет ценности клиенту (и как следствие является waste в терминах Lean):
"Люди, которые находят пользу в оценках, на самом деле видят ценность в этой практике для себя: это планы, комфорт, снижение неопределенности, финансовые прогнозы, коммерческие предложения... Но, во всем этом нет ценности для клиента"
Про желание лучше оценивать:
"К сожалению, люди до сих пор спрашивают про способы улучшения оценки. Это некорректный вопрос. Для меня, это все равно, что спрашивать про лучший способ победы в лотерее, или эффективный способ догадаться про то, какая команда собирается выиграть спортивный матч"
"Помните, что #NoEstimates - это не про то, чтобы не делать оценку. Это про то, чтобы делать ее как можно меньше. А потом, внимательно присмотреться и уменьшить эту потребность еще больше"
Про то, как узнать хорош ли ваш способ оценки:
"Используя хороший способ оценки вы должны завершать свои проекты в пределах 25% от первоначальной оценки в 75% случаев" (1986, Steve McConnell, Software Estimation: Demystifying the Black Art, надо будет тоже почитать)
И что мы имеем на самом деле (все графики из книги Software Estimation: Demystifying the Black Art)
Ну а дальше, вспоминается реклама "если нет разницы, то зачем платить больше"?
Про оценку на базе предыдущего опыта (тут я прямо прослезился, насколько это соответствует тому, как я себе это представляю). И да, возможно это те самые умные слова, которые я не могу красиво сформулировать. Оставлю это тут без перевода, чтобы не вносить погрешность, ну и заодно показать, что книга написана простым английским :)
"every feature or functionality added to an existing project has two cost elements (what you’ll want to estimate):
• Essential complication or g(e): How hard a problem is on its own. For example, implementing tax handling is hard, because the tax code is complex in itself. That is what J.B.Rainsberger calls essential complication or g(e).
• Accidental complication or h(a): The complication that creeps into to the work because – as J.B.Rainsberger puts it – “we suck at our jobs”. Or more diplomatically, the complication that comes from our organizational structures (how long does it take to get the approval for a new test environment?) and from how programs are written (no one is perfect, therefore some things need to be changed to accommodate the new functionality).
In software, estimates of cost are often done by analogy. If features A and B are similar, then if feature A took 3 weeks, feature B will take 3 weeks. But then J.B.Rainsberger asks: “When was the last time that you worked on a perfect code base, where the cost of the accidental complication (how messy the code base was) was either zero or the same multiple of g(e) as when you implemented feature A?”
When we ask someone to estimate how long it will take to develop a feature or project they think about how long it would take hands-on, with perfect hand-off between teams and other staff with the specialist skillsets. This never happens. Work sits in queues; people work on more than one project at a time; people take vacations. We estimate the work, when we need to estimate how long that work takes to go through a complex system given all of its foibles.
Work spends considerable more time idle and blocked by system constraints than progressing towards completion. Given that for inventive knowledge work the hands-on time through a system is considered exceptional at 30%, even if we were PERFECT at estimating that 30% of the time, we would be off by a factor of 70% without compensating.
Even the commonly used doubling what you are told method would still be 20% low.
The delays involved in a complex system are unknowable in advance. Just like travelling to work along the same highway each day, you can't know there is going to be an accident blocking all lanes three weeks from now, you can't know that the test environment will “catch fire” three months from now blocking all testing work. It's these unknowable system delays that make forecasting software projects exceptionally difficult."
Ну и закончим на веселой ноте из книги:
"Написание ПО это так же, как если вы пытаетесь прочистить трубы у себя в ванной, а заканчиваете постройкой еще трех домов, чтобы снова получить работающий туалет"
В общем, всегда думайте, что вы делаете, и для чего вы это делаете. И, думать - это всегда полезно.
Но вернемся к мудрому интернету. За это время получилось насобирать много интересных материалов, которыми решил поделиться.
Холиварчик получился знатный. И конца ему еще не видно (не было видно в 2016, и в 2023 тоже не видно, но уже реже мелькает).
 |
| Ссылка на твит |
 |
| Ссылка на твит |
Зачинателем был Woody Zuill. Немного его хороших комментариев на эту тему:
- "#NoEstimates is not "refuse to do estimates", it's "let's all be open to noticing problems, discussing ideas, and seeking better"(ссылка)
- "No" doesn't mean "Never". #NoEstimates is about cases where no estimates are needed. (ссылка)
- "Alternative to estimates: do the most important thing until either it ships or it is no longer the most important thing @KentBeck" (ссылка)
У него же можно найти хорошую подборку его статей, посвященных #NoEstimates.
Март 2014, AgileDays-2014. Вроде первое русскоязычное видение явления #NoEstimates: выступление Асхата Уразбаева. Рекомендуется к просмотру.
Статья Джила Зилберфилда "В чем смысл #NoEstimates".
Не осталось в стороне сообщество тестировщиков, цинично-практичное, ну как обычно:
 |
| Ссылка на твит |
Венцом темы считаю эти 2 видео (наткнулся я на них именно в такой последовательности):
Сounting stories is enough for projections, you don't need estimations
No estimates: how you can predict the release date of your project without estimating.
Благодаря им теперь читаю эту книгу: "No Estimates" (первую главу можно получить бесплатно). Думаю, что внутренности не будут сильно отличаться от того, что говорит в своем выступлении Vasco Duarte, но ожидаю больше подробностей. О них обязательно расскажу в следующих статьях. Тут можно почитать мини-интервью с Васко.
Он же собирает ссылки на статьи по теме #NoEstimates.
Немного цитат из первой главы, которую я уже прочитал:
К вопросу о том, что оценка не несет ценности клиенту (и как следствие является waste в терминах Lean):
"Люди, которые находят пользу в оценках, на самом деле видят ценность в этой практике для себя: это планы, комфорт, снижение неопределенности, финансовые прогнозы, коммерческие предложения... Но, во всем этом нет ценности для клиента"
Про желание лучше оценивать:
"К сожалению, люди до сих пор спрашивают про способы улучшения оценки. Это некорректный вопрос. Для меня, это все равно, что спрашивать про лучший способ победы в лотерее, или эффективный способ догадаться про то, какая команда собирается выиграть спортивный матч"
"Помните, что #NoEstimates - это не про то, чтобы не делать оценку. Это про то, чтобы делать ее как можно меньше. А потом, внимательно присмотреться и уменьшить эту потребность еще больше"
Про то, как узнать хорош ли ваш способ оценки:
"Используя хороший способ оценки вы должны завершать свои проекты в пределах 25% от первоначальной оценки в 75% случаев" (1986, Steve McConnell, Software Estimation: Demystifying the Black Art, надо будет тоже почитать)
И что мы имеем на самом деле (все графики из книги Software Estimation: Demystifying the Black Art)
Ну а дальше, вспоминается реклама "если нет разницы, то зачем платить больше"?
Про оценку на базе предыдущего опыта (тут я прямо прослезился, насколько это соответствует тому, как я себе это представляю). И да, возможно это те самые умные слова, которые я не могу красиво сформулировать. Оставлю это тут без перевода, чтобы не вносить погрешность, ну и заодно показать, что книга написана простым английским :)
"every feature or functionality added to an existing project has two cost elements (what you’ll want to estimate):
• Essential complication or g(e): How hard a problem is on its own. For example, implementing tax handling is hard, because the tax code is complex in itself. That is what J.B.Rainsberger calls essential complication or g(e).
• Accidental complication or h(a): The complication that creeps into to the work because – as J.B.Rainsberger puts it – “we suck at our jobs”. Or more diplomatically, the complication that comes from our organizational structures (how long does it take to get the approval for a new test environment?) and from how programs are written (no one is perfect, therefore some things need to be changed to accommodate the new functionality).
In software, estimates of cost are often done by analogy. If features A and B are similar, then if feature A took 3 weeks, feature B will take 3 weeks. But then J.B.Rainsberger asks: “When was the last time that you worked on a perfect code base, where the cost of the accidental complication (how messy the code base was) was either zero or the same multiple of g(e) as when you implemented feature A?”
When we ask someone to estimate how long it will take to develop a feature or project they think about how long it would take hands-on, with perfect hand-off between teams and other staff with the specialist skillsets. This never happens. Work sits in queues; people work on more than one project at a time; people take vacations. We estimate the work, when we need to estimate how long that work takes to go through a complex system given all of its foibles.
Work spends considerable more time idle and blocked by system constraints than progressing towards completion. Given that for inventive knowledge work the hands-on time through a system is considered exceptional at 30%, even if we were PERFECT at estimating that 30% of the time, we would be off by a factor of 70% without compensating.
Even the commonly used doubling what you are told method would still be 20% low.
The delays involved in a complex system are unknowable in advance. Just like travelling to work along the same highway each day, you can't know there is going to be an accident blocking all lanes three weeks from now, you can't know that the test environment will “catch fire” three months from now blocking all testing work. It's these unknowable system delays that make forecasting software projects exceptionally difficult."
Ну и закончим на веселой ноте из книги:
"Написание ПО это так же, как если вы пытаетесь прочистить трубы у себя в ванной, а заканчиваете постройкой еще трех домов, чтобы снова получить работающий туалет"
В общем, всегда думайте, что вы делаете, и для чего вы это делаете. И, думать - это всегда полезно.
Комментарии
Отправить комментарий