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

Про NoEstimates

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



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

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

Сама тема пошла в 2013 году с хэштега #NoEstimates в твиттере.
Холиварчик получился знатный. И конца ему еще не видно.
Ссылка на твит

Ссылка на твит
Зачинателем был 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."

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

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

Update: Статья вызвала некоторый интерес и тут можно почитать небольшое обсуждение с теми, кто считает что все эти "NoEstimates" от лукавого.


Комментарии

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

Mock vs Stub

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

План "Б" или как прикольно провести субботний день

Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а" Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно ча

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после  вчерашнего выступления . Uncle Bob : " Flipping the Bit " Подробнее постараюсь перевести чуть позже, пока только это: Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :) Мантра: Сможете ли вы выполнить работу быстрее используя TDD? ДА Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА В любом случае? ДА Есть ли случаи, когда вам не нужно использовать TDD? НЕТ Представьте себе что вы на звездном корабле Enterprise ( Star track ) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы и