А на плохих менеджеров мне все=

Пусть хоть психоз

Так какой смысл давать рандомную оценку? На что это повлияет?

На то что этот самый манагер отвяжется от тебя на этот самый эстимейт

То есть это прям кристалльное "работа на от**ись"

вместо рандомного эстимейта должен быть эстимейт на эстимейт, и он может быть точным.

На примере кейса с таймаутом - в течение не более чем пары-тройки часов можно разобрать причины и предложить план решения, например (точная цифра зависит от деталей проекта)

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

> в течение не более чем пары-тройки часов можно разобрать причины Можно так, но срок то просят назвать ДО начала работы

А по факту получается что два часа потратил, чтобы выяснить что фикс займет 5 часов - эту задачу переложили на следующий спринт, но баг не пофикшен.

Поэтому в скраме оценивается не время на решение задачи, а сложность задачи

Выше кто-то писал, что при планировании спринта оценивают в часах. Оценивайте в сторипойнтах

Воот это уже не поспоришь ;)

>Можно так, но срок то просят назвать ДО начала работы — адекватный менеджер согласится со сроком на ресерч. Ну или на выбор можно давать большой срок и срок на ресерч с точной оценкой, возможно срок на костыльное решение с фиксированной длительностью

Ну и понимаешь что все эти оценки +-30 минут не очень то имеют смысл :)

Я к тому, что если разработка ведется по ТДД, а тесты пишутся по БДД, то это некий методологический коллапс.

Так, в этом предложении обнаружена рекурсия! В этот раз без штрафа, но впредь будьте осторожны! Как ты планируешь писать тесты по тдд? Тесты для тестов, а для них ещё тесты и так далее...

И как они обычно пишутся?

Синдром поиска глубинной рекурсии?)

Многое зависит от планируемого срока жизни проекта от старта до продакшена

То что хорошо для догиз пректах, где есть спринты итерацци, сложно пременить, в проектах котрые живут в разработке месяц, два.

Опять же если клиент платит за часы разработки, то подход оценки сложности особо не пременешь.

Так какой смысл давать рандомную оценку? На что это повлияет?

Тут давайте осторожнее с логикой вещей. Важна не рандомная оценка, а оценка как таковая. Оценка вносит измеряемость в процесс. Вы даёте оценку, проходит период времени, проверяем как оценка соотносится с делами, корректируем оценки, идём дальше. Без оценок проект так и останется на позиции "не знаю" в ответе на вопрос "когда?". С оценками ответ будет "знаю + знаю почему не успели".

Сложность оценки той или иной задачи не означает невозможность проведения этой оценки. Как тут отмечались авторы выше - оцените то, что можете, например исследование проблемы. Со временем этот путь приведёт к все более точной оценке.

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

Управление проектом не стоит также мешать с бюджетированием. Это разные процессы и друг на друга часто совсем не влияющие.

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

Я просто пытаюсь донести, что оценка с точностью до 30 минут зачастую не имеет смысла, и можно порог в 3-4 часа сделать.

А чем сложнее проект тем меньше разработчики пишут код. Больше времени тратят на построение моделей, рисование схем, обсуждение с коллегами

Это нормально.

Я просто пытаюсь донести, что оценка с точностью до 30 минут зачастую не имеет смысла, и можно порог в 3-4 часа сделать.

Про 30 минут - это не ко мне, я такого в трезвом уме не писал

Но лучше ляпнуть "30 минут", чем сказать "не знаю". Про такое я писал, да.

Но еще лучше сказать 1-2 часа, чем 30 минут ;)

Я просто пытаюсь донести, что оценка с точностью до 30 минут зачастую не имеет смысла, и можно порог в 3-4 часа сделать.

любые абсолютные цифры - это фейл сами по себе 30 мину на 4 часовой таск - неадекватная точность, на 8-ми - нормальная, на 16-и часовой - избыточная и маловероятная, но всегда возникает вопрос - а нам нужны таски по 16+ часов?

Не, таск на 16 часов это тоже неадекват

если вы хотите сказать, что вы что-то сделаете за 30 минут - говорите всегда час минимум, но это уже вопрос не точности оценки, а вопрос рисков недооценки

16+ таски есть вне зависимости от того нужны они кому-то или нет

16+ таски есть вне зависимости от того нужны они кому-то или нет

из опыта (огромного по факту) должен сказать, что любой таск на 16 часов может стать 2-мя на 8 часов без всяких рисков

или 3-мя по 6

если вы хотите сказать, что вы что-то сделаете за 30 минут - говорите всегда час минимум, но это уже вопрос не точности оценки, а вопрос рисков недооценки

В нормальной ситуации исполнитель не должен бояться сказать 30 минут. А корректировка должна централизованно выполняться на уровне менеджера.

А вдруг это такс на 15 часов 30 минут...

В нормальной ситуации исполнитель не должен бояться сказать 30 минут. А корректировка должна централизованно выполняться на уровне менеджера.

в нормальной ситуации менеджер ваще не должен вмешиваться в оценку продолжительности выполнения тасков

в нормальной ситуации код пишется без багов.

А вдруг это такс на 15 часов 30 минут...

значит это таск на 16. используйте части от рабочего дня

в нормальной ситуации код пишется без багов.

не совсем корректное сравнение, речь не о том, что менеджер не может, а речь о том, что если сотрудник говорит 30 минут, то вот тут как раз менеджер должен заподозрить, что его на***, в общем обманывают и провести переоценку вместе с сотрудником. но дефолтный стейт - сотрудник должен понимать, что за 30 минут нельзя гарантировать ничего и должен сразу учитывать хотя бы базовые риски, что что-то не взлетит

в нормальной ситуации менеджер ваще не должен вмешиваться в оценку продолжительности выполнения тасков Это у вас извините идеальная ситуация

а не реальная

в нормальной ситуации код пишется без багов.

Правильно, а тестеры не нужны.

Правильно, а тестеры не нужны.

ну это само собой

Правильно, а тестеры не нужны.

Ну да.

в нормальной ситуации менеджер ваще не должен вмешиваться в оценку продолжительности выполнения тасков Это у вас извините идеальная ситуация

микроменеджмент - зло, время выполнения тестирования в каждом конкретном моменте, а не в целом на все части проекта, за которую он отвечает - это задача непосредственно того, кто будет выполнять работу, менеджер может саппортить в том, чтобы не упустить важные части оценки, но лезть в зону своей некомпетентности - это фейл. то есть ты перестал быть тестировщиком/девом и стал менеджером - перестань думать, что ты разбираешься в тестировании/программировании и начни разбираться в менеджменте

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

Пожалуй, плюсану.

-Сколько вам надо на тесты? -18 часов. -Много. -Ну 15...

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

да он должен сказать "команда может выполнить эту работу за столько времени". аргументированно - это как? показать заказчику ненаписанные кейсы? показать им внутренние результаты анализа и матрицы трассировки требований?

Да обычно в таких случаях прдумывают любые причины да так чтобы звучало сурово

Типа "разработчикам нужно воспроизвести это на тестовой среде, накатить миграции и построить модель", поэтому 15 часов.

дада

"А давайте без построения модели?" - "Тогда 18 часов"

и 5 патчей с фиксами

есть 2 варианта - у нас есть допустим 2 месяца на сдать проект. считаем всё, что можем сделать, собрали все цифры, финализировали командно, потом смотрим - можем ли мы в 2 месяца вложить всё, без чего проект сдать нельзя - всё лишнее выкидываем, всё нужное - делаем. Если 2 месяца нереально - тогда берём вот такие аргументы, как написал Павел (максимально реальные - это всегда лучше, чем с потолка) и доносим, что нужно 2.5 месяца

и ещё 20 часов на рефакторинг.

и 5 патчей с фиксами

мы релизили версии в таком виде: 2.4.0, 2.4.1, 2.4.1.1, 2.4.1.2, 2.4.2, 2.4.2.1, сча 2.4.6 в каком-то из релизов

красота )))

"А давайте я вам поставлю 5 бутылок вискаря и вы сделаете это за 10 часов" - "Хм ок, идет"

не вариант.

Ещё колу надо.

"А давайте я вам поставлю 5 бутылок вискаря и вы сделаете это за 10 часов" - "Хм ок, идет"

вискарь мотивирует - гадом буду )))

колой портить виски? ну разве что всякий бленд, а я вот только на односолодовый бы соглашался, авось не дешёвка какая-то

Дело вкуса.

Или его отсутствия.

Кола+Виски - это последствия неудачной попытки Американцев зафигачить хороший ирландский вискарь

Хех

в нормальной ситуации менеджер ваще не должен вмешиваться в оценку продолжительности выполнения тасков

Именно так. Вмешиваться не должен. Должен пассивно получать, корректировать и складывать в общую картину. Например, программист энергичный занижает начальный эстимейт в два раза относительно фактических затрат. Хороший менеджер помножит на 2 словА именно этого человека. Всё.

-Сколько вам надо на тесты? -18 часов. -Много. -Ну 15...

Слово "много" тут неправильное. Право менеджера сказать что-то типа "есть только 15", команда ответит - "лады, убираем это и это из скоупа и делаем за 15"

не помножит, а сначала задаст вопросы, чтобы оценить - занижение или же реально можно вложиться и если занижение - попросит переуточнить оценку программистом

Вы как то всё усложнили

Менеджер не может здесь и сейчас лучше программиста-исполнителя дать оценку. Никто кроме исполнителя не имеет права давать эту оценку. Менеджер только может спустя время и ряд фактов скорректировать оценку для своих расчетов.

Слово "много" тут неправильное. Право менеджера сказать что-то типа "есть только 15", команда ответит - "лады, убираем это и это из скоупа и делаем за 15"

да

Менеджер не может здесь и сейчас лучше программиста-исполнителя дать оценку. Никто кроме исполнителя не имеет права давать эту оценку. Менеджер только может спустя время и ряд фактов скорректировать оценку для своих расчетов.

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

хотя кнеш ситуации бывают разные - иногда нужно просто сказать "будет так" и всё

http://radio-qa.com/spetsvypusk-t-800-testirovshhik-iz-budushhego/

Чёт у вас картина мира, один косячит - другой исправляет, но при этом никто ничему не учится. Ситуация повторяется каждый раз, а иначе откуда он знает, что умножать надо именно на 2?

Когда задача завершена, то расхождение предсказания с фактом становится очевидным. Отсюда 2. Цифра 2 тут для примера. Не надо идти сейчас на работу и умножать все на два. Во-вторых, неточная начальная оценка - это НЕ косяк. Об этом я выше писал. Эстимейты не бывают плохие или хорошие.

Вам, как исполнителю, дали задачу. На основе имеющихся фактов, применяя, например, метод экспертной оценки вы даёте начальный эстимейт и приступаете к выполнению задачи. Как только возникают новые факты, влияющие на оценку, вы её обновляете. При обновлении может быть принято решение: продолжать выполнение, приостановить и отложить, изменить скоуп и т.д. С другой стороны менеджер корректирует выдаваемую исполнителем оценку, если тот систематически её занижает или завышает.

вот это обсуждение! на 2 дня затянулось! читать не перечитать

:)

а потом через месяц зададут тот же вопрос

а мы такие: используйте search )

кстати, за СИСТЕМАТИЧЕСКОЕ (то есть если это реально системные фейлы из-за характера, привычки, но не из-за саботажа - это отдельно) занижение/завышение эстимейтов или фейлы со своевременным апдейтом тасков рекомендую систематически давать по башке. Всё равно если это такой характерец рассеянно-бессовестный ))), то решить проблему надёжно вы не сможете, а если спец хороший - увольнять его только за это = глупость, но зато вы хоть моральное удовольствие получите ?

один раз я попращался с работой из-за андерэстимейтов лида

так все тут не святые

андерэстимейты - это недооценка по времени?

Йес

кстати, за СИСТЕМАТИЧЕСКОЕ (то есть если это реально системные фейлы из-за характера, привычки, но не из-за саботажа - это отдельно) занижение/завышение эстимейтов или фейлы со своевременным апдейтом тасков рекомендую систематически давать по башке. Всё равно если это такой характерец рассеянно-бессовестный ))), то решить проблему надёжно вы не сможете, а если спец хороший - увольнять его только за это = глупость, но зато вы хоть моральное удовольствие получите ?

Систематические неточные прогнозы - это не проблема, если они стабильные. Решается автоподстройкой на уровне менеджера легко. Проблема - это когда прогнозы каждый раз разные, то с завышением, то с занижением, и без функции повышения точности со временем. Но и в этом случае бить никого не надо. В этом случае оценку можно делегировать коллегам или в крайнем случае давать самостоятельно.

Кто-нибудь знает с конфы Гейзенбаг будут записи без покупки билета (в том числе онлайн)?

я не знаю, но могу щас спросить у орга

я не знаю, но могу щас спросить у орга

присоединяюсь к вопросу. было бы здорово)

@lesyasmailik @Bakrisss @msmolyakov отвечают орги "будет платная трансляция"