К основному контенту

Про NoEstimates

Кармен сидела молча несколько минут, пытаясь понять произошедшее. Одно она знала точно: как только она в качестве оценки назовет число, дальше уже не будет иметь значение "правильное" оно или "неправильное". 
Это число мгновенно превратилось бы в "план", и в течении последующих месяцев вся ее работа будет измеряться в соответствии с ним. С другой стороны, если это число будет "слишком большим", компания может потерять контракт, и Кармен будет ответственна за это.
Vasco Duarte "The #NoEstimates Book"



Прошло уже больше года с того момента, как я пообещал Роме написать (тут раньше была ссылочка на умершую соцсеть Google+), что я понимаю под #NoEstimates. Сразу сесть и написать не получилось, потому что решил поизучать, что вообще думает на эту тему мудрый и не очень мудрый интернет. Долго ли, коротко ли, время шло и похоже пришел тот момент, когда я понял, "что ничего не понял".
На самом деле, похоже, что мне нечего особо добавить к написанному тогда, в конце 2014 года: важна прозрачность вашей работы и доверие, которое основано на этой прозрачности.
Ссылка на твит
Оценка, а ее чаще всего понимают, как оценка сроков, - это не более, чем попытка угадать будущее опираясь на ваш предыдущий опыт, или, что еще веселее, предположения. Я не могу объяснить невозможность этого умными словами, но мне кажется, что это несильно отличается от гадания на хрустальном шаре.

Все дело в том, что оценка состоит из 2-х составляющих: 
  1. сколько времени потребуется сделать нечто идеально проработанное идеальным программистом в идеальных условиях
  2. то, как на это время влияет окружение.
И если первое еще можно попытаться угадать (по принципу пол-палец-потолок или воспользоваться, например, знаменитой формулой Бобука), то предугадать изменения вызванные окружением просто невозможно. 
Формула Бобука-Бацека

Попытка получить вторую составляющую через оценку рисков, что часто советуют умные товарищи, всегда приводит к увеличению времени на проект. И все это время, согласно закону Паркинсона, будет благополучно потрачено, это как минимум. И превышено, это как происходит обычно (смотри веселые графики ниже).

А может на самом деле оценка - это процесс, а не некое значение? Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.

Но вернемся к мудрому интернету. За это время получилось насобирать много интересных материалов, которыми решил поделиться.

Сама тема пошла в 2013 году с хэштега #NoEstimates в твиттере.
Холиварчик получился знатный. И конца ему еще не видно (не было видно в 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".

Не осталось в стороне сообщество тестировщиков, цинично-практичное, ну как обычно:
Ссылка на твит
Кроме твитерных 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."

Ну и закончим на веселой ноте из книги:
"Написание ПО это так же, как если вы пытаетесь прочистить трубы у себя в ванной, а заканчиваете постройкой еще трех домов, чтобы снова получить работающий туалет"

В общем, всегда думайте, что вы делаете, и для чего вы это делаете. И, думать - это всегда полезно.

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu