Ответ всё равно придётся умножать на 20
27.10.2018, 13:18
Гоните сцаными тряпками своего скрам-мастера и ПМа! Если в процессе оценки задачи между двумя разработчиками возникли разногласия по времени, то один должен аргументированно убедить другого в своей правоте (например, рассказать свой вариант реализации задачи, который можно сделать быстрее), а если тупо берут меньшую из оценок, а потом еще и урезают - кто-то неадекватно выполняет свою работу.
Разговорились испанец, турок и араб о самых популярных словах их языков, используeмых на работе.
Испанец: У нас очень популярно слово "маньяна". Это значит - сделаем завтра, послезавтра, короче - скоро...
Турок: Мы используем выражение "яваш-яваш". Смысл - сделаем через неделю, через две. Одним словом - не торопитесь...
Араб: А мы говорим "иншалла". Это приблизительно тоже самое, что и "маньяна" и "яваш-яваш", но отсутствует ваш элемент поспешности...
Испанец: У нас очень популярно слово "маньяна". Это значит - сделаем завтра, послезавтра, короче - скоро...
Турок: Мы используем выражение "яваш-яваш". Смысл - сделаем через неделю, через две. Одним словом - не торопитесь...
Араб: А мы говорим "иншалла". Это приблизительно тоже самое, что и "маньяна" и "яваш-яваш", но отсутствует ваш элемент поспешности...
можно добавить тег "на случай важных переговоров"? Что-бы когда понадобиться можно было всегда найти.
Не так давно мне пришла в голову аналогия между гольфом и выполнением задачи разработки. Теоретически можно загнать мяч за один бросок, но фактически приходится делать несколько, последовательно приближающих к лунке. Сказать, сколько именно будет этих "бросков", заранее нельзя. Даже опытный может ошибиться, и даже новичку может повезти. Ошибкой будет показывать время одного броска, как делают многие, но ошибкой же будет показывать среднее или максимальное количество бросков. Количество бросков - это своеобразный "кот шредингера", который определяется только после реализации.
Но ИТ - это нечестный гольф. "Лунки" могут перемещаться, быть ложными, появляться в других местах, или наоборот, игрок может сказать, что вот эта ямка, куда упал мяч - это и есть лунка.
Но ИТ - это нечестный гольф. "Лунки" могут перемещаться, быть ложными, появляться в других местах, или наоборот, игрок может сказать, что вот эта ямка, куда упал мяч - это и есть лунка.
Хорошая аналогия, хочу только добавить, что если работать без нормального ТЗ, то может оказаться, что этой лунки не существует вообще.
Погрешность есть. И есть форс-мажоры.
Но если тебя просят выполнить задачу, и ты не можешь назвать примерный срок выполнения - значит ты никогда не делал эту задачу, и опыта у тебя нет, а твой уровень знаний - "погуглить".
Если опыт у тебя есть, то ты знаешь, сколько минимум времени ты затратишь. Если ты профи - прикинешь основные возможные проблемы, и сроки их устранения.
Но если тебя просят выполнить задачу, и ты не можешь назвать примерный срок выполнения - значит ты никогда не делал эту задачу, и опыта у тебя нет, а твой уровень знаний - "погуглить".
Если опыт у тебя есть, то ты знаешь, сколько минимум времени ты затратишь. Если ты профи - прикинешь основные возможные проблемы, и сроки их устранения.
эт если джун, и ебашишь каждый раз однотипную фигню.
вот тебе контрпример. задача: интегрироваться с новым продуктом. это возможно? конечно. знаешь как? ну, в общих чертах понятно. раньше интегрировался? да. сколько времени надо? хер его знает.
и чем больше у тебя опыта, тем меньше уверенность, что твоя оценка будет ошибочной хотя бы в разы, а не на порядки. потому как видел, как на ровном месте возникают затыки, преодоление которых занимает дольше, чем исходная задача.
вот тебе контрпример. задача: интегрироваться с новым продуктом. это возможно? конечно. знаешь как? ну, в общих чертах понятно. раньше интегрировался? да. сколько времени надо? хер его знает.
и чем больше у тебя опыта, тем меньше уверенность, что твоя оценка будет ошибочной хотя бы в разы, а не на порядки. потому как видел, как на ровном месте возникают затыки, преодоление которых занимает дольше, чем исходная задача.
Хах, в пятницу была задача сделать что-то типа парсера на технопоинте. Был готовый код для днс-шоп на пхп. Оба сайта по функционалу и исполнению практически одинаковы. Ну, дали время до двух дня, взял время до 5 вечера, но так нихера и не сделал - на технопоинте оказалась защита от прямого просмотра товара. В итоге в понедельник только сделаю на ноде жс с помощью puppeteer
Поэтому, именно по этой причине грамотно разбивать проект на два - обследование, чтобы повести анализ, выявить большинство затыков и вообще понять, что за работа предстоит и насколько всё печально. И вторая часть - реализация, уже с примерным пониманием, что тебя ждет, и более адекватным пониманием сроков.
По хорошему, надо вообще отказываться лезть во все тяжкие какого-нибудь сложного проекта без обследования, особенно когда трудозатраты и стоимость оговариваются заранее. Чтобы не было потом мучительно больно.
По хорошему, надо вообще отказываться лезть во все тяжкие какого-нибудь сложного проекта без обследования, особенно когда трудозатраты и стоимость оговариваются заранее. Чтобы не было потом мучительно больно.
Не прочитав, сам подобное же описал.
Есть задачи, оценка времени для которых невозможна из-за недостаточности сведений. Тогда ставится задача на инвестигейшн всех нюансов и выяснения эстимейта для выполнения этой задачи, обычно это пара дней.
На самом деле она уже есть. Просто мы считали ее багом и пару месяцев пытались исправить, но у нас ничего не вышло.
Вариация на тему скрам покера
