slm>Есть количество рабочих часов в день для программиста (от 4 до 6)
slm>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
slm>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)

Вам ведь уже раза четыре написали, что эти данные годны только в среднестатистическом случае. То есть в среднем — да, от 4 до 6 дней работы. В среднем — от 50 до 75% загрузки полезной работой. В среднем Вася оптимистичен, а Петя пессимистичен.
В среднем
Но вот конкретно на этой неделе все получилось наперекосяк. Всего 2 дня работали, но при этом не отвлекались на срочные баги. А Петя недооценил (оптимистично!) свою работу. На следующей неделе все может быть наоборот. В среднем, однако, опять все будет средне.
Кстати, SCRUM пытается эту проблему нивелировать путём поощрения командной работы и взаимопомощи.

slm>Если не получается оценить в 5-часовых днях, оцените в часах.
slm>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)

В этих оценках нет смысла. От разработчика требуется лишь оценить сложность решения. Перевести это в сроки (и трудоёмкость) может менеджер.

slm>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.

То есть в 99.9999% проектов Вы пытаетесь найти некие причины. Виноватых. И каждый раз будете находить. Причем в новом месте. Но реальность такова, что просто следует эту нелинейность принять. Понять, откуда она берется. И научиться контролировать в определенных рамках.

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, slm, Вы писали:

slm>>>Здравствуйте, gandjustas, Вы писали:

G>>>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.

G>>>>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.

slm>>>Есть количество рабочих часов в день для программиста (от 4 до 6)
slm>>>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
G>>И какой процент запланировать? Он ведь тоже нелинейный.

slm>(50 — 80) подбор методом тыка (другими словами статисика). Главное — предыдущие случаи не забывать.
Дык проект только стартует, на старте будет много совещаний, будет низкий процент, потом будет движение к первому релизу — выскокий процент, после релиза багфикс — низкий процент, потом второй релиз — неопределенный процент.

slm>Да и спросить можно (мэнеджера по поддержке?) чего ожидать.
Если бы все в жизни можно было у кого-то спросить и получить быстрый, точный и правильный ответ, то жить стало бы скучно.


slm>>>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)
G>>А пробовали реально статистику снимать? Я пробовал. Из-за закона паркинсона программист никогда не делает быстрее срока, даже если срок раздут в несколько раз. (отчего от раздут ниже)

slm>Этот закон паркинсоно — в некотором разе -стёб, а не истина в последней инстанции.
Может и стеб, но практикой доказан очень хорошо. Современные модели планирования проектов построены на PERT, который говорит, что оценка задач подчиняется нормальному распредлению.
Но если мы начинаем детализировать задачи до дней, то фактическое распределение получится больше похоже на гамма. По факту выполнения отдельных задач раньше срока почти не наблюдается.
Даже если выделить на задачу очень много времени, то есть еще "синдром студента" — когда вся работа делается в ночь перед экзаменом (перед сдачей).

slm>Если нужно написать 2 класса — 100 строк, то как не вертись, придёт программист на второй-третий день работу просить.
Да ладно. Он будет архитектуру вылизывать или котиков смотреть.


G>>Так всетаки в чем оценивать? В днях или строках кода? Это две принципиально разные величины.

slm>Не понял.
slm>При сложившемся процессе программист пишет в среднем Х строк кода в неделю +- 20-30 %
slm>Оценивать программисту проще и точнее в строках.
slm>Если у вас статистика есть, то можете сами перевести.
slm>Но !!!! Перед этим потребуется дизайн сделать что бы размер оценить.
По строкам кода есть интересная статистика:
Строки кода нелинейны еще хуже, чем остальные параметры. В день программист пишет 50-120 строк (в зависимости от интенсивности). А в неделю больше 200 я не видел ни разу. А в месяц этот показатель еще ниже.
По статистике Windows NT каждый программист в год рожал не более 1200 строк.


slm>>>>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
slm>>>>>Какие проблемы?
G>>>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>>>>Оценка то дается заранее.
slm>>>Он то в 3 дня оценил, а прожект менеджер в сколько ?
G>>А ПМ не оценивает. Он может выполнить преобразования и вписать оценку в план.
G>>Вот я и спрашиваю что какие оценки давать и что с ними потом деалть, чтобы получить реалистичный план и уменьшить эффект паркинсона.


slm>Вообще то как раз ПМ, беря информацию из разных источников и разным образом её преобразуя и получает оценку по проекту.
Ага, "магически преобразуя". Исходный вопрос был — как при оценке срока избавится от эффекта паркинсона? различные идеи про "человеко-дни", "лопато-часы" и прочие величины, линейно преобразующиеся во время не позволяют полностью нивелировать эффект паркинсона.



slm>А эффект Паркинсона уже как то тут совсем мифологизировался.
slm>Нету его на практике если работник не совсем раздолбай.
На практике он как раз есть. Более того, он может вовсе не в одном работнике заключаться.
Ты на практике видел нормальное распределение сроков выполнения задач? Я — нет. Хотя оценка действительно имеет нормальное распределение (элементарно проверяется сбором нескольких оценок сроков одной задачи).


slm>Какие ужасы вы рассказываете
Правда жизни. Это редко замечают, ибо один косяк в управлении ожиданиями заказчика перекроет все ошибки планирования в разы.

slm>Т.е. программист приходит на работу что бы ничего не делать?
Ну почему же ничего? Он может вылизывать архитектуру, чаще перекуривать и больше отвдлекаться на непродуктивные вещи. Человек, который хочет себя занять — всегда найдет чем. Это кстати тоже у паркинсона было.



slm>>>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
G>>Это заблуждение. Нелинейность возникает потому что люди это люди, а не роботы.

slm>Вообще то если нет: дизайн/архитектура/требования
slm>(Т.е. нет чёткого понимания что делать программисту)
slm>То уже без разницы люди или роботы.
А если есть тз\хз, то люди все равно остаются людьми. И если вася сказал что сделает за 3 дня, то это не означает что сделает за 3, а тем более не означает что петя сделает за 3.

Единственный адекватный вариант оценки — в условных попугаях и всей командой (planning poker). А дальше уже мониторить velocity (количество условных попугаев за итерацию).
В остальных случаях можно просто отдавать оценку тимлиду, который "экспертно" оценит любой проект на старте и точность буде не меньше, чем при декомпозиции и тяжелой оценке.

Для отдельных задач есть лишь один адекватный срок — сегодня. Все что нельзя за один день сделать и показать результат — надо разбить на подзадачи. Если задачи мелкие, то можно за сегодня сделать до 4 задач.

G>Я писал о том, что ясная цель и ясное вознаграждение\наказание за недостижение повышает шансы достижения цели.

Позволю добавить — кроме ясности цели, она еще должна быть реалистично достижима.

Здравствуйте, SkyDance, Вы писали:

I>>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.

SD>Позвольте предполжить, что дохнут они не из-за скрама.

Я и говорю — когда всё хорошо, это скрам. А если сдохли, то квалификация не та или менеджмент подкачал.

Здравствуйте, velkin, Вы писали:

V> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?

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

Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

slm>>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>>Инспекции рядом сидящих программеров тут точно не помогут.

G>>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

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

Тем не менее тимлид как раз эффетивен когда у него от 2 до 5 человек в подчинении. Если больше, то тилид уже начинает заниматься планированием больше чем технической работой и отдаляется от команды.
Опытному тимлиду можно еще пару тестеров в помощь дать, а также одного проектировщика UI. Получится полноценная команда, которая может собрать продукт.

G>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
I>Мизер.
По моей практике тулы отлавливали 80% типичных ошибок.

G>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
I>А качество кода с количеством ошибок никак не связано ? Вот чудо !
Качество кода и есть количество (вернее плотность) ошибок. Но "обыдлячивание" это не про качество,а про стиль кода.

I>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.

Позвольте предполжить, что дохнут они не из-за скрама.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

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

G>>Предсказуемый != хороший. Предсказемость результата достигается очень сильным раздутием оценок для перекрытия рисков, причем причины раздутия оценок определить весьма непросто.

I>Предсказуемость может достигаться и раздутием оценок, а может и внятным учетом рисков и толковым проектированием.
I>Можешь внятно пояснить, почему в твоем случае только первый вариант ?

Потому что избежать раздутия оценок крайне сложно, если оценивается срок (напрямую или косвенно). А если оценки раздуты, то все остальное становится малозначительно.

Я наблюдал многократно как это происходит:
1) Есть небольшая команда, которая не гонится за сроками
2) Команда растет, к ней приставляют ПМа.
3) ПМ начинает сверять план\факт и выясняет сто есть серьезная недооценка
4) ПМ, как ты писал выше, начинает разбор полетов.
5) В 95% случаев разборы начинают напрягать програмиистов
6) Сроки раздуваются с целью избежать разборов

Далее два варианта:
7а) ПМ получает разрешение руководителя прогибать команду, команда начинает выстраивать барьеры с менеджером, получается перманентны конфликт
7б) Рентабельность падает, развитие продукта останавливается\новые проекты не приходят, и программисты начинают заниматься УГ

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, slm, Вы писали:

slm>>>При нормальной организации работ:
slm>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
G>>Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?
slm>Сколько он дней будет делать эту задачу. Это чисто — чтобы он знал, какие решения по дизайну он собирается использовать (или сколько строк собирается написать) и не писал лишнего.
Сколько он дней будет делать задачу величина, которую сам программист оценить не сможет. Он может сказать три дня, а у него будет совещание на полдня, потом внезапный критичный баг, который еще день съест, а потом срочная задача починить ченить клиенту. За 3 дня он может и не приступить к задаче.

Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.

slm>>>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
G>>Что значит контроль?
slm>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
Скажет все ок, закончу завтра, трудностей нет.
И будет говорить так в течение недели.


slm>>>4. Программист ни за каким таймером не следит.
G>>А что если не указывается в оценку?

slm>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
См выше про контроль своего времени программистом.

Здравствуйте, slm, Вы писали:

slm>У тимлида команды в 4-5 человек этот самый "микроменеджмент" занимает час, ну в редких случаях 2 в день.
slm>Может это и не микроменеджмент, а нормальный менеджмент?

Вот тут не согласен. SkyDance уже ответил выше, продублирую:

1. Твоя схема управления заточена на упорядоченные, атомарные, взаимозаменяемые задачи, типа личного конвеера: приехал тикет, взял в работу и больше ничем не занимаешься, через фиксированное время отправил дальше.
2. На выходе у тебя в идеальном случае получается сопоставление "тикет-человек-реальные часы" + весьма вероятно, фиговое настроение в команде.
3. Твои "час в день" — это не лично твой час в день, а всей команды. Всё это время тимлид не будет заниматься реальными проблемами команды, а будет натурально страдать фигнёй.

В чём тут подвох:
1. Разработка так не работает. Точнее, поставленный процесс разработки может так выглядеть _внешне_, но только при условии, что до этого мы приложили дофига и больше усилий на грамотное разруливание задач.
2. Твоё сопоставление "человек-время-тикет" никак не помогает этому самому разруливанию задач, зато генерит кучу информационного шума из-за случайных выбросов (примеры уже приводили выше)
3. Чтобы сгладить эти выбросы, придётся усреднять: собирать задачи за всю итерацию и смотреть распределение условных часов по команде.
4. Теперь смысл точного сопоставления вообще теряется, т.к. вся нужная статистика получается из трекера. Число рабочих часов в неделю есть, количество закрытых тикетов есть — что ещё надо?

Собственно вопрос: нафига тратить час-два времени _команды_ каждый день на то, что и так само разруливается?

slm>"Обезьян" проще отсекать на собеседовании.
Так "необезьяны" пошлют такую работу прямым текстом. Поскольку ни им, ни ПМ ты никак не сможешь обосновать, каким чудом "менеджер раздаёт задачи" будет эффективнее стандартного "задачи берутся из очереди на итерацию".

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:


G>>>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
slm>>>Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
G>>Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.

slm>Ээээ
slm>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.".
slm>Похоже на формальную придирку.
В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.

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

slm>>>Да количество "рабочих" часов в трудодне обычно известная в среднем величина.
G>>А вот продуктивность — величина неизвестная и очень даже изменчивая.

slm>>>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.
G>>Так мы про сроки или про трудоемкость? Определись.

slm>Чего не понятного от программиста ждём трудоёмкость.
Как тогда оценить трудоемкость в днях?

slm>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
slm>Какие проблемы?
Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
Оценка то дается заранее.


slm>>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
G>>>>Скажет все ок, закончу завтра, трудностей нет.
G>>>>И будет говорить так в течение недели.
slm>>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
G>>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.

slm>Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю.
slm>Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном.
То есть ты сам не очень понимаешь что же означает "контролировать", про которое ты говорил выше.


slm>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>>>>См выше про контроль своего времени программистом.
slm>>>Я же говорю, разбираться с такими случаями надо.
G>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.

slm>Проблемы с мотивацией ?
slm>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками.
slm>Ну и с "реальной" мотивацие что то делать надо.
В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

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

V>1. Разбивка на максимальное количество подзадач. Мне так думается оценивать по времени несколько маленьких задач проще, чем одну большую состоящую из них. Но чем больше подзадач, тем больше их в трекере, что увеличивает сложность работы с ним.

Только не забудьте засечь время, требуемое на разбиение задач на подзадачи. А то, ВНЕЗАПНО, может оказаться, что вы попросту переносите сюда стадию проектирования. По сути, исключаете из замера время на проектирование. Что может визуально улучшить результаты (теперь на задачи уходит меньше чистого времени), но фактические сроки поедут еще дальше.

V>3. Естественно прокрастинация тоже играет роль. Как же, секундомер работает, а программист нет. Тут или надо отключать секундомер, или начинать работать.

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

Здравствуйте, Sinix, Вы писали:

I>>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.
S>Угу. Только вопрос не в результате на конец итерации, а в том, как распланировать поступившие юз-кейсы на итерацию.

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

I>>То есть, если помогло — значит скрам. Не помогло — значит девелоперы плохие.
S>Да ладно)) Скрам как и любая методология — это просто инструмент. Обвинять инструмент в "мы плохо работаем" или "унас всё ок из-за скрама" — эт инфантилизм чистейшей воды. Если что-то не работает — чинить надо, а не ждать пока загнётся.

У меня сильное ощущение, что скрам годится там, где легко и предсказуемо безо всякого напряга.

Здравствуйте, velkin, Вы писали:

V>Тема относится к управлению временем.
V>

V>Эмпирический закон Паркинсона:
V>Работа заполняет всё время, отпущенное на неё

При нормальной организации работ:
1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач).
3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
4. Программист ни за каким таймером не следит.

Если сроки не совпали с ожидаемыми — должно быть объяснение у программиста, но не более.

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

slm>такая ситуация возникает если программист уровня юниора или мидла работает не в команде, а непосредственно рулится менеджером или другим не-техническим сотрудником. Ну или тимлиду пофигу или некогда.

Хотите заниматься микроменеджментом? Пожалуйста. Только помните — это система с положительной обратной связью. Чем больше микроменеджите, тем больше требуется. И так далее, вплоть до сакраментального "да мне быстрее самому сделать, чем объяснять этим обезьянам".

Здравствуйте, SkyDance, Вы писали:

slm>>такая ситуация возникает если программист уровня юниора или мидла работает не в команде, а непосредственно рулится менеджером или другим не-техническим сотрудником. Ну или тимлиду пофигу или некогда.

SD>Хотите заниматься микроменеджментом? Пожалуйста. Только помните — это система с положительной обратной связью. Чем больше микроменеджите, тем больше требуется. И так далее, вплоть до сакраментального "да мне быстрее самому сделать, чем объяснять этим обезьянам".

Ну это смотря в какой позиции нахожусь.

Если ПМ, то да, пусть программистов пасёт кто то другой.
У тимлида команды в 4-5 человек этот самый "микроменеджмент" занимает час, ну в редких случаях 2 в день.
Может это и не микроменеджмент, а нормальный менеджмент?

"Обезьян" проще отсекать на собеседовании.
Или смирится, что производительность у них будет на уровне "обезьяны".

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

Здравствуйте, SkyDance, Вы писали:

slm>>Этот закон паркинсона — в некотором разе -стёб, а не истина в последней инстанции.

SD>Это не стёб, а отражение реальности.
SD>Дело не в том, что программист ленивый и хочет смотреть котиков.

SD>Обычно работает вот как

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

Здравствуйте, Ikemefula, Вы писали:

I> Сначала было "дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи." и на фоне этого ты предложил уравнять часы Пети и Васи при помощи итераций. Опаньки !


Предлагается не считать индивидуальные часы, а считать командную 'скорость'. Так погрешность намного меньше.

I>И это вполне может работать — пока тимлид будет заниматься суммированием сортов колбасы, рисованием графиков и у него не будет возможности заниматься микроменеджметом, что означает, что команда будет занята делом.

Вполне рабочий вариант. Один из весьма удачных — тим лидер занимается всеми спущеными сверху ЦУ, давая команде шанс просто работать.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
G>>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

G>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

I>Ты наверное хочешь сказать, что 1 кг первого сорта колбасы и 1 кг второго равняются 2 кг третьего.
Я этого не хочу сказать. Это уже твоя фантазия. Не вижу вообще никаких причин проводить аналогии человек-часов с колбасой. Колбаса инвариантна — 1кг у Васи это тоже самое, что 1КГ у Пети. А с человеко-часами не так.

I>Такой результат получается в том случае, если из оценок исключить время. Адепты скрама стесняются это признать, поэтому усиленно маскируют временную оценку под story points и количество продуктивных часов.
Специально для тебя повторю. Человеко-часы не являются инвариантной величиной, хоть и кажется обратное. Чтобы правильно считать в человеко-часах нужно привести их к общему знаменателю. Гораздо проще это делать если взять максимально абстрактную величину, иначе в какой-то момент кто-нибудь обзяательно забудет привести к общему знаменателю.

I>Типичный скрам
I>1. сколько продективных часов планируется на скрам ?
I>2. в прошлый раз было 200, родили 10sp, щас получается 100, нужно ориентироваться на 5
Это ты о чем?

I>Если время исключить совсем, то совершенно непонятно, зачем нужна привязка спринтов ко времени — получается суммирование сортов колбасы.
Время исключить из оценок, а не из процесса. Не путай.
Привязка спринтов ко времени — time-boxing, чтобы избежать эффекта паркинсона и синдрома студента. Тайм-боксинг как методика планирования появилась сильно задолго до того, как появилось само понятие управления проектами. Но странно, что не все методологии используют timeboxing. А еще в скраме надо поланировать задачи под каждую story, задачи тоже ограничены по времени. Я рекомендую всегда не более одного дня на задачу.

I>Время всегда расходовалось нелинейно, во все времена, просто у современного манагера есть много болезней, средни них
I>1 желание привязать количество результата(sp) к моменту времени (в конце спринта)
I>2 приставить к работнику надсмотрщика (дрессура, кнут-пряник и тд)
Почему это болезни? Вполне естественное желание.

I>Аджыле, что характерно, ни к первому, ни ко второму не имеет отношение. А вот планирование оперативной деятельности в разных организациях, ну даж в той же милиции, испокон веков велось достаточно формализовамными методами. И вот эти методы и есть тот самый здравый смысл, который порграммисты назвали Аджыле.
I>Ну так у программистов испокон веков — для любой известной мульки придумывается серьезный звонкий термин.
Что характерно, ты начал разговор про скрам, начал сравнивать человеко-часы с колбасой и работу милиции с разработкой ПО.
При таком уровне "адекватности" не продолжай пжлста.

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, slm, Вы писали:

slm>>>Тут зависит от цели. Если надо добиваться уверенность в том что "программист отработал оптимально" по затратам времени на каждую задачу то да, здравствуй таймер (и микроменеджмент).
G>>А что значит "оптимально"?

slm>Я не знаю чего ТС хочет таймерами и секундомерами добиться.
То есть для начала надо таки с целью определиться, а потом уже думать нужны таймеры или нет.

slm>>>А если надо проекты планировать в одной и той же области и на схожих технологиях, то вроде бы всё уже придумано.
G>>Ага, все придумано и никем не делается...

slm>Почему, где получается преодолеть "рефлекторные" реакции, то получается.
slm>(Например было такое PSP-TSP). Не в одной компании использовалось
Потому что PSP-TSP требует специальной тренировки каждого сотрудника. Не просто опыта, а именно тренировки по программе SEI. Делать такие вложения в программистов никто не готов.

Я кстати изучал PSP\TSP.
Так вот TSP
1) Явно говорит о нелинейности между сотрудниками.
2) Явно запрещает микроменеджмент и мониторинг показателей отдельных сотрудников, только агрегатные оценки по команде.
3) Не описывает методику управления проектом, то есть может быть и скрам, и RUP. Но естественно вытекает скрам — агрегатные метрики и таймбоксинг.

I>Я и говорю — когда всё хорошо, это скрам. А если сдохли, то квалификация не та или менеджмент подкачал.

Что вы имеете в виду под "всё хорошо"?
Скрам — это не когда "всё хорошо", это когда в любой момент времени прозрачно видна ситуация с проектом. Какие с ним проблемы и сколько еще пилить до наступления вот того счастья.
Скрам не делает "всё хорошо". Скрам просто показывает, насколько это "хорошо" хорошо на самом деле.

Здравствуйте, es3000, Вы писали:

E>Здравствуйте, gandjustas, Вы писали:

G>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

E>А в чем же тогда оценивать?
E>Проект ведь все равно планировать надо


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

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

Тема относится к управлению временем.

Эмпирический закон Паркинсона:
Работа заполняет всё время, отпущенное на неё

Типичный алгоритм с таймером:
1. Неким образом происходит оценка, за какой срок программист может выполнить работу.
2. Включается таймер обратного отсчёта.
3. Варианты:
3.а. Задача не выполняется в срок
3.б. Задача выполняется точно в срок
3.в. Задача выполняется до истечения срока

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

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

Варинат "в" произошёл вопреки закону Паркинсона. Может было выделено столько времени, что программист просто не знал, как можно так сильно растянуть задачу. В общем на него закон не подействовал или подействовал в не полную силу.

Против этого выступает алгоритм с секундомером.
1. Изначальное предполагается, что оценивать время на решение задачи, значит попасть на алгоритм с таймером, и в свою очередь на закон Паркинсона, потому время не оценивается.
2. Включается секундомер прямого отсчёта.
3. Варианты:
3.а. Срока нет, программист делает задачу запредельно долго.
3.б. Срока нет, задача выполняется за приемлемое время.
3.б. Срока нет, задача была выполнена на удивления быстро.

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

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

Здравствуйте, slm, Вы писали:

slm>При нормальной организации работ:
slm>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?

slm>2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач).
Откуда знает?

slm>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
Что значит контроль?

slm>4. Программист ни за каким таймером не следит.
А что если не указывается в оценку?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>При нормальной организации работ:
slm>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
G>Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?

Сколько он дней будет делать эту задачу. Это чисто — чтобы он знал, какие решения по дизайну он собирается использовать (или сколько строк собирается написать) и не писал лишнего.

slm>>2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач).
G>Откуда знает?
Забота менеджера или тимлида или прочих элементов процесса разработки.

slm>>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
G>Что значит контроль?
Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.

slm>>4. Программист ни за каким таймером не следит.
G>А что если не указывается в оценку?

Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
и при следующей оценке — не расслабляться, а наоборот сосредоточится.

Если оценку менеджера проекта — значит менеджер проекта плохо спланировал.

Здравствуйте, gandjustas, Вы писали:

G>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

Дрессировка какая-то... А как наказывать собираетесь?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

S>Дрессировка какая-то... А как наказывать собираетесь?

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

А по факту вознаграждение и наказание сильно зависит от системы мотивации и оплаты труда в компании.

ЗЫ. Именно дрессировка, чтобы результат совпадал с ожиданиями не требовал усилий со стороны руководителя.

Здравствуйте, velkin, Вы писали:

V>Против этого выступает алгоритм с секундомером.
Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи. Допустим, у Пети сегодня отходняк после днюхи. Васю штырит с кофе т.к. у него дедлайн, но завтра на работе он будет откровенно дрыхнуть, т.к. вчера работал за пятерых. Вы серьёзно хотите управлять такими мелочами?

Куда проще ограничиться распределением задач по итерациям: все случайные вылеты за сроки успевают нейтрализовать друг друга и остаются только системные проблемы, с которыми и надо разбираться.

V>Идея же секундомера вытекает из гибких методологий. Взять хотя бы тот же скрам. Временное ограничение спринта условность для максимально быстрого получения новой работающей версии, а вовсе не для обратного отсчёта решения задачи по классической модели водопада. Нужно делать как сделается, но делать. Второй вопрос насколько целесообразно использовать секундомеры, так как просто отказаться от подсчёта времени на задачу нельзя?

Это не имеет никакого отношения к скраму. Вот классное описание

Автор: SkyDance
Дата: 21.08.12

от SkyDance, найдите там отслеживание по реальным часам, "делать как делается" и проч.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, slm, Вы писали:

slm>>>>При нормальной организации работ:
slm>>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).

G>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
Да количество "рабочих" часов в трудодне обычно известная в среднем величина.

Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.


slm>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
G>Скажет все ок, закончу завтра, трудностей нет.
G>И будет говорить так в течение недели.

Если будете для "галочки" спрашивать, ответ то же получите для "галочки"

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


slm>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>См выше про контроль своего времени программистом.

Я же говорю, разбираться с такими случаями надо.

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, slm, Вы писали:

slm>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, slm, Вы писали:

slm>>>>>При нормальной организации работ:
slm>>>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).

G>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
slm>Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.

slm>Да количество "рабочих" часов в трудодне обычно известная в среднем величина.
А вот продуктивность — величина неизвестная и очень даже изменчивая.

slm>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.
Так мы про сроки или про трудоемкость? Определись.


slm>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
G>>Скажет все ок, закончу завтра, трудностей нет.
G>>И будет говорить так в течение недели.
slm>Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.




slm>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>>См выше про контроль своего времени программистом.
slm>Я же говорю, разбираться с такими случаями надо.
Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.

Здравствуйте, gandjustas, Вы писали:


G>>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
slm>>Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
G>Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.

Ээээ
Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.".

Похоже на формальную придирку.

slm>>Да количество "рабочих" часов в трудодне обычно известная в среднем величина.
G>А вот продуктивность — величина неизвестная и очень даже изменчивая.

slm>>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.
G>Так мы про сроки или про трудоемкость? Определись.

Чего не понятного от программиста ждём трудоёмкость.
Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
Какие проблемы?


slm>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
G>>>Скажет все ок, закончу завтра, трудностей нет.
G>>>И будет говорить так в течение недели.
slm>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
G>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.

Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю.
Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном.


slm>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>>>См выше про контроль своего времени программистом.
slm>>Я же говорю, разбираться с такими случаями надо.
G>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.

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

Здравствуйте, gandjustas,

slm>>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.".
G>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
G>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>Оценка то дается заранее.

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

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, gandjustas,

slm>>>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.".
G>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
G>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>>Оценка то дается заранее.

V_S>Программисты обычно оценивают трудоемкость в "идеальных днях" (человеко-днях). Перевести трудоемкость в сроки (идеальные дни -> в календарные сроки) с учетом всех совещаний, багфиксов и т.п. — это уже задача менеджера.
Ты забыл добавить "в теории".

Есть еще одна проблема — "идеальные дни", сука, у всех разные.

Здравствуйте, gandjustas, Вы писали:

G>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.

G>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.

Есть количество рабочих часов в день для программиста (от 4 до 6)
Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)

Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке).


G>>>Так мы про сроки или про трудоемкость? Определись.

slm>>Чего не понятного от программиста ждём трудоёмкость.
G>Как тогда оценить трудоемкость в днях?

Если не получается оценить в 5-часовых днях, оцените в часах.
Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)


slm>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
slm>>Какие проблемы?
G>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>Оценка то дается заранее.

Он то в 3 дня оценил, а прожект менеджер в сколько ?


slm>>>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
G>>>>>Скажет все ок, закончу завтра, трудностей нет.
G>>>>>И будет говорить так в течение недели.
slm>>>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
G>>>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.

slm>>Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю.
slm>>Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном.
G>То есть ты сам не очень понимаешь что же означает "контролировать", про которое ты говорил выше.

Действительно, как разговаривать с людьми не "для галочки", научить и объяснить не могу.


slm>>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>>>>>См выше про контроль своего времени программистом.
slm>>>>Я же говорю, разбираться с такими случаями надо.
G>>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.

Что случается постоянно?
оценивает в 3 дня, а делает за 5?
отлично.
с такой стабильностью уже можно планировать.

slm>>Проблемы с мотивацией ?
slm>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками.
slm>>Ну и с "реальной" мотивацие что то делать надо.
G>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
G>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

G>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
Плюс ко всему из за этих проблем становится невозможным адектватное действительности разбиение на задачи.

Здравствуйте, Sinix, Вы писали:

S>Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи. Допустим, у Пети сегодня отходняк после днюхи. Васю штырит с кофе т.к. у него дедлайн, но завтра на работе он будет откровенно дрыхнуть, т.к. вчера работал за пятерых. Вы серьёзно хотите управлять такими мелочами?

Давайте тогда уточним термин секундомеры. Предположим есть очень хорошая разбивка задач на подзадачи. К каждой задаче привязывается тип: моделирование, требование, проектирование, конструирование, испытание, ошибка, документирование, развёртывание, поддержка и так далее. Так же существует жёсткая связь между задачей в трекере и репозиторием. Если программист что-то коммитит, то не от балды исправляя весь проект, а под конкретную подзадачу. Иначе говоря существует некий уровень организации процесса разработки.

И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. Секундомер этот с помощью некоего api связывается с трекером и получает список текущих задач. Далее программист выбирает или меняет в секундомере задачу. Учёт времени происходит автоматически, то есть он пусть хоть сто раз переключается с задачи на задачу, секундомер это просто запишет, и общее время тоже сам посчитает. Речь здесь как раз не о менеджере проекта, а о разработчике, который решает подзадачу.

Иными словами в процессе работы программиста никто не пинает, не спрашивает сколько он работал и что сделал. Мысль отчасти напоминает TDD, когда всё работает, юнит тесты уже писать как-то лень, да и из памяти улетучиваются детали. Так же и тут, с той лишь разницей, что если взять не автоматизированный секундомер, и заставить вручную править трекер, тогда да, разработчику это будет крайне не удобно и времязатратно. Потому речь прежде всего об автоматизированных секундомерах, которые могут записывать всё вплоть до мелочей, и при этом никого не напрягать.

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

Пример не автоматизированных секундомера и таймера.

	секундомер

	таймер

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

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.

G>>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.

slm>Есть количество рабочих часов в день для программиста (от 4 до 6)
slm>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
И какой процент запланировать? Он ведь тоже нелинейный.

slm>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)
А пробовали реально статистику снимать? Я пробовал. Из-за закона паркинсона программист никогда не делает быстрее срока, даже если срок раздут в несколько раз. (отчего от раздут ниже)


slm>Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке).
Хороший план должен оставаться в пределах допустимых значений все время проекта, а не разъезжаться в разы.

G>>>>Так мы про сроки или про трудоемкость? Определись.
slm>>>Чего не понятного от программиста ждём трудоёмкость.
G>>Как тогда оценить трудоемкость в днях?

slm>Если не получается оценить в 5-часовых днях, оцените в часах.
slm>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)
Так всетаки в чем оценивать? В днях или строках кода? Это две принципиально разные величины.


slm>>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
slm>>>Какие проблемы?
G>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>>Оценка то дается заранее.
slm>Он то в 3 дня оценил, а прожект менеджер в сколько ?
А ПМ не оценивает. Он может выполнить преобразования и вписать оценку в план.
Вот я и спрашиваю что какие оценки давать и что с ними потом деалть, чтобы получить реалистичный план и уменьшить эффект паркинсона.

slm>>>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
slm>>>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
G>>>>>>См выше про контроль своего времени программистом.
slm>>>>>Я же говорю, разбираться с такими случаями надо.
G>>>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.

slm>Что случается постоянно?
slm>оценивает в 3 дня, а делает за 5?
slm>отлично.
slm>с такой стабильностью уже можно планировать.
Если бы такая стабильность была всегда, проблем бы не было.
на практике чаще получается так:
1) Программист оценивает задачу в 3 дня, а делает за 5
2) Появляется похожая по объему задача, он снова оценивает в 3 дня, а делает за 5
3) Появляется тертья задача, которая такая же как первая и на 90% может быть скопипащена, она также оценена в 3 дня, но ПМ уже посчитал поправочный коэффициент и поставил 5 дней. А программист за день все скопипастил, и 4 дня смотрел котиков.
Об этом и был пост ТС — если ты начинаешь считать время, то попадаешь на эффект паркинсона.

slm>>>Проблемы с мотивацией ?
slm>>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками.
slm>>>Ну и с "реальной" мотивацие что то делать надо.
G>>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
G>>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

G>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

slm>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
Это заблуждение. Нелинейность возникает потому что люди это люди, а не роботы.

Здравствуйте, velkin, Вы писали:

V> Предположим есть очень хорошая разбивка задач на подзадачи.
Допустим, но это сверхтребование конечно.


V>И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. С
Ну а зачем? Что с этого получит программист, что получит менеджер?
Только чур, про оценку тикетов в часах не писать. Час разработчика сегодня (день тяжёлый) и час завтра — настроение ок, сделал как-бы-невозможный-тикет — могут отличаться по продуктивности в разы.

Оценка тикетов? Тоже мимо.
Если перед итерацией уже провели планёрку и все тикеты на ближайшую итерацию уже размечены в трекере, смысл в дополнительном отслеживании?

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

Автор: Кирилл Лебедев
Дата: 18.11.13

обсуждали.

Вот допустим у меня сейчас в личной очереди висит 7 тикетов (если общая очередь пустая — остальные могут что-то забрать себе), из них 5 ждут исправления других компонентов, над двумя работаю (первый — чисто написать код, второй — погонять и найти проблему в уже написанном). Как по ним автоматически раскидать время и как использовать это время для оценки?

Хинт: по одному тикету из пяти "зависших" нужна пара человекодней работы, остальные 4 висят чисто для формальности, чтобы не забыть проверить после исправления других тикетов (дел на 5 минут). Как усреднять будем?

V>Вопрос в том, какое преимущество даёт та или иная техника и её общая адекватность. Используемые инструменты должны решать проблемы, а не создавать их.
+1.

Встречный вопрос: зачем нам точное время, если процесс поставлен более-меннее правильно?
Достаточно:
1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.
4. Раскидывания задач по итерациям, например, как описано у SkyDance

Автор: SkyDance
Дата: 21.08.12

.
5. При планировании следующей итерации приоритет незакрытых тикетов +1.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>Здравствуйте, gandjustas, Вы писали:

G>>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.

G>>>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.

slm>>Есть количество рабочих часов в день для программиста (от 4 до 6)
slm>>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
G>И какой процент запланировать? Он ведь тоже нелинейный.

(50 — 80) подбор методом тыка (другими словами статисика). Главное — предыдущие случаи не забывать.
Да и спросить можно (мэнеджера по поддержке?) чего ожидать.

slm>>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)
G>А пробовали реально статистику снимать? Я пробовал. Из-за закона паркинсона программист никогда не делает быстрее срока, даже если срок раздут в несколько раз. (отчего от раздут ниже)

Этот закон паркинсоно — в некотором разе -стёб, а не истина в последней инстанции.
Если нужно написать 2 класса — 100 строк, то как не вертись, придёт программист на второй-третий день работу просить.


slm>>Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке).
G>Хороший план должен оставаться в пределах допустимых значений все время проекта, а не разъезжаться в разы.

G>>>>>Так мы про сроки или про трудоемкость? Определись.
slm>>>>Чего не понятного от программиста ждём трудоёмкость.
G>>>Как тогда оценить трудоемкость в днях?

slm>>Если не получается оценить в 5-часовых днях, оцените в часах.
slm>>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)
G>Так всетаки в чем оценивать? В днях или строках кода? Это две принципиально разные величины.

Не понял.
При сложившемся процессе программист пишет в среднем Х строк кода в неделю +- 20-30 %
Оценивать программисту проще и точнее в строках.
Если у вас статистика есть, то можете сами перевести.
Но !!!! Перед этим потребуется дизайн сделать что бы размер оценить.


slm>>>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
slm>>>>Какие проблемы?
G>>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
G>>>Оценка то дается заранее.
slm>>Он то в 3 дня оценил, а прожект менеджер в сколько ?
G>А ПМ не оценивает. Он может выполнить преобразования и вписать оценку в план.
G>Вот я и спрашиваю что какие оценки давать и что с ними потом деалть, чтобы получить реалистичный план и уменьшить эффект паркинсона.


Вообще то как раз ПМ, беря информацию из разных источников и разным образом её преобразуя и получает оценку по проекту.

А эффект Паркинсона уже как то тут совсем мифологизировался.
Нету его на практике если работник не совсем раздолбай.

slm>>Что случается постоянно?
slm>>оценивает в 3 дня, а делает за 5?
slm>>отлично.
slm>>с такой стабильностью уже можно планировать.
G>Если бы такая стабильность была всегда, проблем бы не было.
G>на практике чаще получается так:
G>1) Программист оценивает задачу в 3 дня, а делает за 5
G>2) Появляется похожая по объему задача, он снова оценивает в 3 дня, а делает за 5
G>3) Появляется тертья задача, которая такая же как первая и на 90% может быть скопипащена, она также оценена в 3 дня, но ПМ уже посчитал поправочный коэффициент и поставил 5 дней. А программист за день все скопипастил, и 4 дня смотрел котиков.

Какие ужасы вы рассказываете

Т.е. программист приходит на работу что бы ничего не делать?

Как то всё плохо и с подбором кадров и с мотивацией.
Если человек работать не хочет, надо разбираться почему.

А заставить его программировать из под-палки нормально не получится.

G>Об этом и был пост ТС — если ты начинаешь считать время, то попадаешь на эффект паркинсона.

slm>>>>Проблемы с мотивацией ?
slm>>>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками.
slm>>>>Ну и с "реальной" мотивацие что то делать надо.
G>>>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
G>>>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

G>>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

slm>>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
G>Это заблуждение. Нелинейность возникает потому что люди это люди, а не роботы.

Вообще то если нет: дизайн/архитектура/требования
(Т.е. нет чёткого понимания что делать программисту)
То уже без разницы люди или роботы.

Здравствуйте, Vlad_SP, Вы писали:

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

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

Даже не автоматизированные таймеры должны быть поставлены на оставшееся время, а не на конечную дату, с возможностью паузы, когда программист отвлекается на постороннее дело. Правильнее было бы сказать, я сделаю задачу за 24 часа непрерывной работы, а не за 3 рабочих дня. В противном случае это уже не таймеры с обратным отсчётом, а календарь.

Говорят же, что эффективность умственной работы в сутки всего лишь 4 часа, а не 8. Потому время в днях надо умножать на два при условии, что человек не ленится. А с учётом необходимых во время работы перерывов на три. Впрочем если речь зашла о таймерах, а их ставит и выключает программист, то это опять же мотивирует на что угодно, но не на решение задачи.

Даже если бы менеджер проекта видел через сеть работает таймер у программиста или нет, это бы только осложняло дело с некоторыми сотрудниками. Перефразирую, — "Программист спит, таймер идёт". Из обсуждения же вижу, что вскрылась серьёзная проблема в методике оценки, в которой используются даже не таймеры, а календари.

Сдаётся мне календари ещё больше подвержены закону Паркинсона в растягивании работы на всё отпущенное ей время. К примеру, в трёх сутках 72 часа, это не 24 рабочих часа в них, и тем более не 8-12 реальных часов, в которых человек может выжать себя по максимуму, чтобы не потерять от переутомления последующие после них сутки.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, velkin, Вы писали:

V>> Предположим есть очень хорошая разбивка задач на подзадачи.
S>Допустим, но это сверхтребование конечно.

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

V>>И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. С
S>Ну а зачем? Что с этого получит программист, что получит менеджер?

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

Теперь что касается менеджера. Предположим менеджер проекта это я. У меня установлен ChiliProject (форк Redmine), всякие плагины к нему, типа CodeReview, Hudson, Embedded, включен REST, проведена интеграция с Jenkins, Gitolite. Изначально я ещё и менеджер конфигурации, а если надо, тестировщик, архитектор ПО, системный аналитик, бизнес-аналитик, технический писатель и так далее.

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

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

Автор: Кирилл Лебедев
Дата: 18.11.13

обсуждали.

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

S>Вот допустим у меня сейчас в личной очереди висит 7 тикетов (если общая очередь пустая — остальные могут что-то забрать себе), из них 5 ждут исправления других компонентов, над двумя работаю (первый — чисто написать код, второй — погонять и найти проблему в уже написанном). Как по ним автоматически раскидать время и как использовать это время для оценки?

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

S>Хинт: по одному тикету из пяти "зависших" нужна пара человекодней работы, остальные 4 висят чисто для формальности, чтобы не забыть проверить после исправления других тикетов (дел на 5 минут). Как усреднять будем?

Никак не будем усреднять. Потому и введено условие о достаточности разбиения. Если задача занимала 1 минуту 25 секунд, то так и пишем.

S>Встречный вопрос: зачем нам точное время, если процесс поставлен более-меннее правильно?

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

S>Достаточно:
S>1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).

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

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

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

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

V>И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. Секундомер этот с помощью некоего api связывается с трекером и получает список текущих задач. Далее программист выбирает или меняет в секундомере задачу. Учёт времени происходит автоматически, то есть он пусть хоть сто раз переключается с задачи на задачу, секундомер это просто запишет, и общее время тоже сам посчитает. Речь здесь как раз не о менеджере проекта, а о разработчике, который решает подзадачу.

Для чего?
Для создания ощущения "дамоклова меча"? Или чтобы ровно в 17:00 (или когда там рабочий день у вас заканчивается) программист блокировал машину и уходил домой?

Тайм-трекинг осуществляется без секундомеров. Притом есть разные варианты, как это организовать. В одном месте, помнится, прямо в commit message системы контроля версий можно было вставить тег типа @hr:4, что означало "работал над этим коммитом 4 часа". В сочетании с тегом "#331123" (который есть номер issue в трекере) это давало достаточно данных для анализа времени выполнения задач.

В саппорте чаще принимают другой метод — в начале работы над тикетом assign'ят его на себя. Если уходят на совещание или еще что-то такое, ставят на hold, по возвращению продолжают. Когда тикет закрывают, время автоматически учитывается. Секундомер, кстати, там тоже есть, на веб-странице с тикетом прямо.

Но для чего его иметь программисту в трее? Чтобы просто напоминать "не прокрастинируй"?

slm>Этот закон паркинсоно — в некотором разе -стёб, а не истина в последней инстанции.

Это не стёб, а отражение реальности.
Дело не в том, что программист ленивый и хочет смотреть котиков.

Обычно работает вот как: программист, если вправду сделал раньше срока, начинает пытаться усовершенствовать решение. Зачастую это выливается в очень полезную (в дальнейшем) работу — например, добавляются на первый взгляд ненужные автотесты (которые потом сэкономят кучу времени), модифицируется система билда.
В общем, время, которое на первый взгляд потрачено на "котиков", на самом деле не такое уж и бесполезное.

V>Даже не автоматизированные таймеры должны быть поставлены на оставшееся время, а не на конечную дату, с возможностью паузы, когда программист отвлекается на постороннее дело. Правильнее было бы сказать, я сделаю задачу за 24 часа непрерывной работы, а не за 3 рабочих дня. В противном случае это уже не таймеры с обратным отсчётом, а календарь.

Посмотрите на всякие ticket-системы для саппорта. Там всё украдено до нас.
Включая планирование и предсказание времени закрытия. С учётом приоритетов, статусов партнёров и т.п.

Здравствуйте, SkyDance, Вы писали:

SD>Но для чего его иметь программисту в трее? Чтобы просто напоминать "не прокрастинируй"?

И, для этого тоже.

1. Разбивка на максимальное количество подзадач. Мне так думается оценивать по времени несколько маленьких задач проще, чем одну большую состоящую из них. Но чем больше подзадач, тем больше их в трекере, что увеличивает сложность работы с ним.
2. Даже при этом скорость программирования не линейна, но секундомер и не пытается что-то предсказать. Работа будет закончена, когда будет закончена. Однако если человек не работал, то секундомер это просто запишет как есть.
3. Естественно прокрастинация тоже играет роль. Как же, секундомер работает, а программист нет. Тут или надо отключать секундомер, или начинать работать.

Кстати, раз уж тема зашла о менеджере проекта и Паркинсоне:

Жизненный цикл кабинета состоит из нескольких стадий:

1. Идеальное число членов — пять человек. При таком численном составе кабинет непременно приживётся. Два его члена смогут всегда отсутствовать по болезни или по иной причине. Пятерых легко собрать, а собравшись, они способны действовать быстро, умело и тихо. Четверым из них можно поручить финансы, иностранные дела, оборону и правосудие. Пятый, не сведущий в этих предметах, станет председателем или премьером.

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

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

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

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

Прежде всего, очень трудно собрать столько народу.
Лишь немногие из членов отбирались с расчётом на то, что они будут или могут приносить пользу. Большую часть скорее ввели, чтобы угодить какой-нибудь внешней группировке, и задача их — сообщать своим, как идут дела. С секретностью покончено.
Чем крепче утверждаются ненужные члены, тем громче требуют обойдённые группы, чтобы ввели их представителей. Число членов переползает в третий десяток. И кабинет вступает в четвёртую, последнюю стадию.

Здравствуйте, gandjustas, Вы писали:

slm>>>>При нормальной организации работ:
slm>>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
G>>>Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?
slm>>Сколько он дней будет делать эту задачу. Это чисто — чтобы он знал, какие решения по дизайну он собирается использовать (или сколько строк собирается написать) и не писал лишнего.
G>Сколько он дней будет делать задачу величина, которую сам программист оценить не сможет. Он может сказать три дня, а у него будет совещание на полдня, потом внезапный критичный баг, который еще день съест, а потом срочная задача починить ченить клиенту. За 3 дня он может и не приступить к задаче.

Поэтому я все называю не реальное, а "чистое" время, т.е. сколько точно буду потратить ) на разработку...

Здравствуйте, SkyDance, Вы писали:

slm>>Этот закон паркинсоно — в некотором разе -стёб, а не истина в последней инстанции.

SD>Это не стёб, а отражение реальности.
SD>Дело не в том, что программист ленивый и хочет смотреть котиков.

SD>Обычно работает вот как: программист, если вправду сделал раньше срока, начинает пытаться усовершенствовать решение. Зачастую это выливается в очень полезную (в дальнейшем) работу — например, добавляются на первый взгляд ненужные автотесты (которые потом сэкономят кучу времени), модифицируется система билда.
SD>В общем, время, которое на первый взгляд потрачено на "котиков", на самом деле не такое уж и бесполезное.

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

Тогда да. В армии без сержантов та же фигня случается.

Здравствуйте, SkyDance, Вы писали:

slm>>Есть количество рабочих часов в день для программиста (от 4 до 6)
slm>>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
slm>>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)

SD>Вам ведь уже раза четыре написали, что эти данные годны только в среднестатистическом случае. То есть в среднем — да, от 4 до 6 дней работы. В среднем — от 50 до 75% загрузки полезной работой. В среднем Вася оптимистичен, а Петя пессимистичен.
SD>В среднем
SD>Но вот конкретно на этой неделе все получилось наперекосяк. Всего 2 дня работали, но при этом не отвлекались на срочные баги. А Петя недооценил (оптимистично!) свою работу. На следующей неделе все может быть наоборот. В среднем, однако, опять все будет средне.
SD>Кстати, SCRUM пытается эту проблему нивелировать путём поощрения командной работы и взаимопомощи.

А цель оценки какая?
— составить адекватный план проекта и при изменениях условий править этот план и согласовывать изменения с смежниками?
— дать "крайнюю" оценку для бизнеса и постараться не нарушить? — Надо перезакладываться + волевые решения типа "Вася и Петя поддержкой не занимаются, вся поддержка на Феде".
— быть уверенным что программисты работали? Тогда средние цифры — это нормально + информация о случаях отклонений от средних.

slm>>Если не получается оценить в 5-часовых днях, оцените в часах.
slm>>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)

SD>В этих оценках нет смысла. От разработчика требуется лишь оценить сложность решения. Перевести это в сроки (и трудоёмкость) может менеджер.

slm>>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.

SD>То есть в 99.9999% проектов Вы пытаетесь найти некие причины. Виноватых. И каждый раз будете находить. Причем в новом месте. Но реальность такова, что просто следует эту нелинейность принять. Понять, откуда она берется. И научиться контролировать в определенных рамках.

Цель — не поиски виноватых, а понимание — можно ли изменениями процесса предотвратить такие проблемы (на дизайн данного разработчика обращать отдельное внимание. Или для инспекции дизайна в незнакомом коде привлекать кого то из другой команды)
А если процесса нет и дизайн/архитектура/требования отсутствуют, то о чём вообще говорить? только маленькие задачи можно делать, а чуть побольше и всё катится в ....
никакие таймеры не помогут

Здравствуйте, gandjustas, Вы писали:

V>> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?

G>Я так понимаю вопрос в том, что дедлайн по времени помогает работе или нет. На практике конечно помогает. Большинство программистов недостаточно дисциплинированны и очень любят любят заниматься "архитектурным творчеством", не остигая реальных целей.

G>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

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

Здравствуйте, gandjustas, Вы писали:

G>А по факту вознаграждение и наказание сильно зависит от системы мотивации и оплаты труда в компании.

G>ЗЫ. Именно дрессировка, чтобы результат совпадал с ожиданиями не требовал усилий со стороны руководителя.

https://www.youtube.com/watch?v=TLF-fDQKZ_g

Здравствуйте, Sinix, Вы писали:

S>Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи. Допустим, у Пети сегодня отходняк после днюхи. Васю штырит с кофе т.к. у него дедлайн, но завтра на работе он будет откровенно дрыхнуть, т.к. вчера работал за пятерых. Вы серьёзно хотите управлять такими мелочами?

человеко-день это простатистику, а не про единичные случаи.

S>Куда проще ограничиться распределением задач по итерациям: все случайные вылеты за сроки успевают нейтрализовать друг друга и остаются только системные проблемы, с которыми и надо разбираться.

А еще итерациями очень удобно распил вести.

Здравствуйте, gandjustas, Вы писали:

G>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
G>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.

G>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

Ты наверное хочешь сказать, что 1 кг первого сорта колбасы и 1 кг второго равняются 2 кг третьего.
Такой результат получается в том случае, если из оценок исключить время. Адепты скрама стесняются это признать, поэтому усиленно маскируют временную оценку под story points и количество продуктивных часов.
Типичный скрам
1. сколько продективных часов планируется на скрам ?
2. в прошлый раз было 200, родили 10sp, щас получается 100, нужно ориентироваться на 5

Если время исключить совсем, то совершенно непонятно, зачем нужна привязка спринтов ко времени — получается суммирование сортов колбасы.

Время всегда расходовалось нелинейно, во все времена, просто у современного манагера есть много болезней, средни них
1 желание привязать количество результата(sp) к моменту времени (в конце спринта)
2 приставить к работнику надсмотрщика (дрессура, кнут-пряник и тд)

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

Здравствуйте, Ikemefula, Вы писали:

S>>Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи.
I>человеко-день это простатистику, а не про единичные случаи.
[кэп]
Топикстартер предлагает следить как раз за единичными случаями, почитай стартовое сообщение
[/кэп]

S>>Куда проще ограничиться распределением задач по итерациям: все случайные вылеты за сроки успевают нейтрализовать друг друга и остаются только системные проблемы, с которыми и надо разбираться.
I>А еще итерациями очень удобно распил вести.
Правило Годвина. Упомянул распил — слил.
Покажи мне плиз, какое отношение к распилу имеют стандартные итерации в одну-две недели, в конце каждой из которых получается _полностью_ рабочий и готовый к отправке клиентам продукт?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

S>>>Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи.
I>>человеко-день это простатистику, а не про единичные случаи.
S>[кэп]
S>Топикстартер предлагает следить как раз за единичными случаями, почитай стартовое сообщение
S>[/кэп]

ТС по моему интересует мотивацией, а не эстимейтами.

S>>>Куда проще ограничиться распределением задач по итерациям: все случайные вылеты за сроки успевают нейтрализовать друг друга и остаются только системные проблемы, с которыми и надо разбираться.
I>>А еще итерациями очень удобно распил вести.
S>Правило Годвина. Упомянул распил — слил.
S>Покажи мне плиз, какое отношение к распилу имеют стандартные итерации в одну-две недели, в конце каждой из которых получается _полностью_ рабочий и готовый к отправке клиентам продукт?

Раз ты уже упомянул Годвина, то я упомяну Гитлера: "А Гитлер ведь художником был !!!!1111расрас"

Сначала было "дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи." и на фоне этого ты предложил уравнять часы Пети и Васи при помощи итераций. Опаньки !

Здравствуйте, Ikemefula, Вы писали:

I>ТС по моему интересует мотивацией, а не эстимейтами.
А вот фиг поймёшь. Он там начал за здравие ("Тема относится к управлению временем"), закончил за упокой ("Идея же секундомера вытекает из гибких методологий" и проч альтернативщина). Я отвечал именно на последнее утверждение. Правило Штирлица (запоминается последняя фраза) в действии

С мотивацией он тоже не особо угадал.
Если сотрудника не мотивирует вид пустой очереди тикетов и классное качество продукта — его вообще мало что сможет мотивировать. Если у нас затык с очередью/качеством — надо проблемы лечить, а не разработчиков мотивировать.


I>Сначала было "дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи." и на фоне этого ты предложил уравнять часы Пети и Васи при помощи итераций. Опаньки !
Про уравнять речи не было, разговор шёл о оценке задачи по таймеру/секундомеру, предварительно или постфактум — неважно.
Засада в том, что помимо времени для адекватной оценки нужно знать ещё кучу деталей, которые никакого отношения к самой проблеме могут и не иметь. Ну, или переходить к оценке в попугаях, но тогда нам точное время ничего не даст.

Здравствуйте, Dziman, Вы писали:

I>> Сначала было "дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи." и на фоне этого ты предложил уравнять часы Пети и Васи при помощи итераций. Опаньки !

D>Предлагается не считать индивидуальные часы, а считать командную 'скорость'. Так погрешность намного меньше.

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

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

И это вполне может работать — пока тимлид будет заниматься суммированием сортов колбасы, рисованием графиков и у него не будет возможности заниматься микроменеджметом, что означает, что команда будет занята делом.

Здравствуйте, Sinix, Вы писали:

S>С мотивацией он тоже не особо угадал.
S>Если сотрудника не мотивирует вид пустой очереди тикетов и классное качество продукта — его вообще мало что сможет мотивировать. Если у нас затык с очередью/качеством — надо проблемы лечить, а не разработчиков мотивировать.

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

I>>Сначала было "дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи." и на фоне этого ты предложил уравнять часы Пети и Васи при помощи итераций. Опаньки !
S>Про уравнять речи не было, разговор шёл о оценке задачи по таймеру/секундомеру, предварительно или постфактум — неважно.
S>Засада в том, что помимо времени для адекватной оценки нужно знать ещё кучу деталей, которые никакого отношения к самой проблеме могут и не иметь. Ну, или переходить к оценке в попугаях, но тогда нам точное время ничего не даст.

Если оценки не дают ожидаемого эффекта, это вовсе не значит, что от них надо отказываться. Это значит, что надо тренироваться
1. искать риски и управлять ими
2. замерять фактически затраченое время
3. делать разбор полетов

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

V>>> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?

G>>Я так понимаю вопрос в том, что дедлайн по времени помогает работе или нет. На практике конечно помогает. Большинство программистов недостаточно дисциплинированны и очень любят любят заниматься "архитектурным творчеством", не остигая реальных целей.

G>>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

I>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении. В случае неосязаемого результата крайне сложно определить насколько о близок к цели. Дизайн еще можно обсуждать в категории нравится\не нравится, а с программным кодом чаще всего непонтяно будет ли он реально работать или надо еще 100500 раз переписать.

Здравствуйте, Ikemefula, Вы писали:

I>Если оценки не дают ожидаемого эффекта, это вовсе не значит, что от них надо отказываться. Это значит, что надо тренироваться
I>1. искать риски и управлять ими
I>2. замерять фактически затраченое время
I>3. делать разбор полетов

Странно то, что эту мантру повторяют уже лет 30, но все равно качество оценок в среднем по индустрии не улучшилось.

Типичный сценарий:
1) Берем оценку программиста, в человекочасах, данную в начале.
2) Программист не укладывается, фактически затраченное время на 50% больше.
3) Проводим разбор полетов, который вызывает почти 100% чувство вины программиста, даже если его вины никакой нет.
4) На следующей оценке программист увеличивает оценку на 50%.
5) Менеджер, вспомнив про управление рисками, накидывает к оценке еще 50%. Оценка выросла более чем в два раза.
6) Программист начинает делать и срабатывает синдром студнета. Времени много, задача известная можно применить новую технологию или повылизывать архитектуру. Внезапно срок задачи подходит к концу и в "ночь перед экзаменом" программист фигачит код. Естественно это приводит к невысокому качеству и возможному вылету по срокам.
7) Тут менеджер думает, что неплохо было бы замерять время. Но как? Трекер — там часы списываются номинально. Появляются жесткие методы контроля, типа снимки экрана\статус-репорты раз в 4 часа. (ты кстати сам был против них)

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Ikemefula, Вы писали:

I>>Если оценки не дают ожидаемого эффекта, это вовсе не значит, что от них надо отказываться. Это значит, что надо тренироваться
I>>1. искать риски и управлять ими
I>>2. замерять фактически затраченое время
I>>3. делать разбор полетов

G>Странно то, что эту мантру повторяют уже лет 30, но все равно качество оценок в среднем по индустрии не улучшилось.

G>Типичный сценарий:
G>1) Берем оценку программиста, в человекочасах, данную в начале.
G>2) Программист не укладывается, фактически затраченное время на 50% больше.
G>3) Проводим разбор полетов, который вызывает почти 100% чувство вины программиста, даже если его вины никакой нет.
G>4) На следующей оценке программист увеличивает оценку на 50%.
G>5) Менеджер, вспомнив про управление рисками, накидывает к оценке еще 50%. Оценка выросла более чем в два раза.
G>6) Программист начинает делать и срабатывает синдром студнета. Времени много, задача известная можно применить новую технологию или повылизывать архитектуру. Внезапно срок задачи подходит к концу и в "ночь перед экзаменом" программист фигачит код. Естественно это приводит к невысокому качеству и возможному вылету по срокам.
G>7) Тут менеджер думает, что неплохо было бы замерять время. Но как? Трекер — там часы списываются номинально. Появляются жесткие методы контроля, типа снимки экрана\статус-репорты раз в 4 часа. (ты кстати сам был против них)


Тут зависит от цели. Если надо добиваться уверенность в том что "программист отработал оптимально" по затратам времени на каждую задачу то да, здравствуй таймер (и микроменеджмент).

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

Здравствуйте, gandjustas, Вы писали:

I>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении.

Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

Здравствуйте, slm, Вы писали:

slm>Тут зависит от цели. Если надо добиваться уверенность в том что "программист отработал оптимально" по затратам времени на каждую задачу то да, здравствуй таймер (и микроменеджмент).
А что значит "оптимально"?

slm>А если надо проекты планировать в одной и той же области и на схожих технологиях, то вроде бы всё уже придумано.
Ага, все придумано и никем не делается...

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении.

I>Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

С чего ты взял, что иной? Были исследования, которые показали, что увеличение денежного вознаграждения не влияет на показатели продуктивности интеллектуального труда.
Грубо говоря за 100тыр и за 150тыр программист будет работать примерно одинаково, поэтому нет смысла платить сильно выше рынка.
Но это совершенно не означает, что нет других способов поощрения и\или наказания.

Здравствуйте, gandjustas, Вы писали:

G>>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

I>>Ты наверное хочешь сказать, что 1 кг первого сорта колбасы и 1 кг второго равняются 2 кг третьего.
G>Я этого не хочу сказать. Это уже твоя фантазия. Не вижу вообще никаких причин проводить аналогии человек-часов с колбасой. Колбаса инвариантна — 1кг у Васи это тоже самое, что 1КГ у Пети. А с человеко-часами не так.

Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
Сортов а не килограммов, внимание !

I>>Такой результат получается в том случае, если из оценок исключить время. Адепты скрама стесняются это признать, поэтому усиленно маскируют временную оценку под story points и количество продуктивных часов.
G>Специально для тебя повторю. Человеко-часы не являются инвариантной величиной, хоть и кажется обратное. Чтобы правильно считать в человеко-часах нужно привести их к общему знаменателю. Гораздо проще это делать если взять максимально абстрактную величину, иначе в какой-то момент кто-нибудь обзяательно забудет привести к общему знаменателю.

Вот эта максимально абстрактная величина и есть сорта колбасы. Сколько единиц в неделе ?

I>>Типичный скрам
I>>1. сколько продективных часов планируется на скрам ?
I>>2. в прошлый раз было 200, родили 10sp, щас получается 100, нужно ориентироваться на 5
G>Это ты о чем?

О том.

I>>Если время исключить совсем, то совершенно непонятно, зачем нужна привязка спринтов ко времени — получается суммирование сортов колбасы.
G>Время исключить из оценок, а не из процесса. Не путай.

Оценки без времени == сорта колбасы. Не нравится колбаса, можно взять шкалу Роквела, шкалу Бофорта, шкалу Рихтера — что угодно. Результат будет тот же.

G>Привязка спринтов ко времени — time-boxing, чтобы избежать эффекта паркинсона и синдрома студента. Тайм-боксинг как методика планирования появилась сильно задолго до того, как появилось само понятие управления проектами. Но странно, что не все методологии используют timeboxing. А еще в скраме надо поланировать задачи под каждую story, задачи тоже ограничены по времени. Я рекомендую всегда не более одного дня на задачу.

Чудеса, в оценках время исключили, и приходим к главному — сколько единиц в неделе ?

I>>Время всегда расходовалось нелинейно, во все времена, просто у современного манагера есть много болезней, средни них
I>>1 желание привязать количество результата(sp) к моменту времени (в конце спринта)
I>>2 приставить к работнику надсмотрщика (дрессура, кнут-пряник и тд)
G>Почему это болезни? Вполне естественное желание.

В случае интеллектуального труда это не дает результата. Эта простая мысль пережевывается в самых разных источниках
Peopleware
Design of Design

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, gandjustas, Вы писали:

V>>>> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?

G>>>Я так понимаю вопрос в том, что дедлайн по времени помогает работе или нет. На практике конечно помогает. Большинство программистов недостаточно дисциплинированны и очень любят любят заниматься "архитектурным творчеством", не остигая реальных целей.

G>>>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

I>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении. В случае неосязаемого результата крайне сложно определить насколько о близок к цели. Дизайн еще можно обсуждать в категории нравится\не нравится, а с программным кодом чаще всего непонтяно будет ли он реально работать или надо еще 100500 раз переписать.

Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
Инспекции рядом сидящих программеров тут точно не помогут.

Здравствуйте, gandjustas, Вы писали:

G>Странно то, что эту мантру повторяют уже лет 30, но все равно качество оценок в среднем по индустрии не улучшилось.

В основном потому, что
1 забивают на риски
2 мотивацию (вместо неё метод кнута и пряника)
3 складывают сорта колбасы (исключают время из оценок)

G>Типичный сценарий:
G>1) Берем оценку программиста, в человекочасах, данную в начале.

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

>Тут менеджер думает, что неплохо было бы замерять время. Но как? Трекер — там часы списываются номинально. Появляются жесткие методы контроля, типа снимки экрана\статус-репорты раз в 4 часа. (ты кстати сам был против них)

В своём сценарии ты показал
1 вместо оценки рисков угадайка с накидыванием процентов
2 забить мотивацию — использование чувства вины и жесткого прессинга
3 сумму сортов колбасы — результат у манагера

Здравствуйте, gandjustas, Вы писали:

I>>>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>>>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении.

I>>Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

G>С чего ты взял, что иной? Были исследования, которые показали, что увеличение денежного вознаграждения не влияет на показатели продуктивности интеллектуального труда.

Покажи эти исследования, а то Peopleware и Design of Design с тобой не согласны. Я, правда, давно не перечитывал их, но сильно вряд ли авторы этих книг отказались от своих позиций в последних изданиях

G>Грубо говоря за 100тыр и за 150тыр программист будет работать примерно одинаково, поэтому нет смысла платить сильно выше рынка.

А ты найди людей в своей конторе, у кого ЗП 150 и обрежь до 100. Ну и результаты сюда не забудь сообщить.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>Тут зависит от цели. Если надо добиваться уверенность в том что "программист отработал оптимально" по затратам времени на каждую задачу то да, здравствуй таймер (и микроменеджмент).
G>А что значит "оптимально"?

Я не знаю чего ТС хочет таймерами и секундомерами добиться.

slm>>А если надо проекты планировать в одной и той же области и на схожих технологиях, то вроде бы всё уже придумано.
G>Ага, все придумано и никем не делается...

Почему, где получается преодолеть "рефлекторные" реакции, то получается.
(Например было такое PSP-TSP). Не в одной компании использовалось

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

I>>>Ты наверное хочешь сказать, что 1 кг первого сорта колбасы и 1 кг второго равняются 2 кг третьего.
G>>Я этого не хочу сказать. Это уже твоя фантазия. Не вижу вообще никаких причин проводить аналогии человек-часов с колбасой. Колбаса инвариантна — 1кг у Васи это тоже самое, что 1КГ у Пети. А с человеко-часами не так.

I>Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
I>Сортов а не килограммов, внимание !
Да пожалуйста, суммируй сорта колбасы. У тебя с этим проблемы?
Или ты думаешь раз ты написал про сорт колбасы, то это теперь имеет хоть какое-то отношение к реальной колбасе?

I>>>Такой результат получается в том случае, если из оценок исключить время. Адепты скрама стесняются это признать, поэтому усиленно маскируют временную оценку под story points и количество продуктивных часов.
G>>Специально для тебя повторю. Человеко-часы не являются инвариантной величиной, хоть и кажется обратное. Чтобы правильно считать в человеко-часах нужно привести их к общему знаменателю. Гораздо проще это делать если взять максимально абстрактную величину, иначе в какой-то момент кто-нибудь обзяательно забудет привести к общему знаменателю.

I>Вот эта максимально абстрактная величина и есть сорта колбасы. Сколько единиц в неделе ?
Сколько единиц в неделе — надо считать, причем для команды в целом. Это и есть та самая непостоянная, ненелинейная и не инвариантная величина. Определить её заранее можно только по опыту. Если команда новая и проект совершенно новый, то тупо угадать (по науке называется "экспертная оценка")

I>>>Типичный скрам
I>>>1. сколько продективных часов планируется на скрам ?
I>>>2. в прошлый раз было 200, родили 10sp, щас получается 100, нужно ориентироваться на 5
G>>Это ты о чем?
I>О том.
Гениальный ответ.

I>>>Если время исключить совсем, то совершенно непонятно, зачем нужна привязка спринтов ко времени — получается суммирование сортов колбасы.
G>>Время исключить из оценок, а не из процесса. Не путай.

I>Оценки без времени == сорта колбасы. Не нравится колбаса, можно взять шкалу Роквела, шкалу Бофорта, шкалу Рихтера — что угодно. Результат будет тот же.
Именно, бери что угодно, а потом считай реальную velocity. Только так будет понимание когда можно делать релизы.

G>>Привязка спринтов ко времени — time-boxing, чтобы избежать эффекта паркинсона и синдрома студента. Тайм-боксинг как методика планирования появилась сильно задолго до того, как появилось само понятие управления проектами. Но странно, что не все методологии используют timeboxing. А еще в скраме надо поланировать задачи под каждую story, задачи тоже ограничены по времени. Я рекомендую всегда не более одного дня на задачу.
I>Чудеса, в оценках время исключили, и приходим к главному — сколько единиц в неделе ?
См выше.
Вообще выключай дурачка. Про velocity разве что ленивый не писал, а читали уж точно все.

I>>>Время всегда расходовалось нелинейно, во все времена, просто у современного манагера есть много болезней, средни них
I>>>1 желание привязать количество результата(sp) к моменту времени (в конце спринта)
I>>>2 приставить к работнику надсмотрщика (дрессура, кнут-пряник и тд)
G>>Почему это болезни? Вполне естественное желание.

I>В случае интеллектуального труда это не дает результата. Эта простая мысль пережевывается в самых разных источниках
I>Peopleware
I>Design of Design
Обе книжки про планирование и контроль почти ничего не пишут. А если почитать дедлайн того же ДеМарко, то в нем менеджеру удалось на месяц отжать сроки без потери качества.

Здравствуйте, gandjustas, Вы писали:

I>>Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
I>>Сортов а не килограммов, внимание !
G>Да пожалуйста, суммируй сорта колбасы. У тебя с этим проблемы?

Сколько будет первый сорт плюс второй ?

G>Или ты думаешь раз ты написал про сорт колбасы, то это теперь имеет хоть какое-то отношение к реальной колбасе?

Ты не отвлекайся — сколько ?

I>>Вот эта максимально абстрактная величина и есть сорта колбасы. Сколько единиц в неделе ?
G>Сколько единиц в неделе — надо считать, причем для команды в целом. Это и есть та самая непостоянная, ненелинейная и не инвариантная величина. Определить её заранее можно только по опыту. Если команда новая и проект совершенно новый, то тупо угадать (по науке называется "экспертная оценка")

А сотня это больше чем неделя ? А тысяча ? А миллион ? А килограм ?

I>>Оценки без времени == сорта колбасы. Не нравится колбаса, можно взять шкалу Роквела, шкалу Бофорта, шкалу Рихтера — что угодно. Результат будет тот же.
G>Именно, бери что угодно, а потом считай реальную velocity. Только так будет понимание когда можно делать релизы.

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

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

I>>Чудеса, в оценках время исключили, и приходим к главному — сколько единиц в неделе ?
G>См выше.
G>Вообще выключай дурачка. Про velocity разве что ленивый не писал, а читали уж точно все.

Если сложно про неделю, тогда давай про твой ремень. Сколько в нём единиц ?

I>>В случае интеллектуального труда это не дает результата. Эта простая мысль пережевывается в самых разных источниках
I>>Peopleware
I>>Design of Design
G>Обе книжки про планирование и контроль почти ничего не пишут. А если почитать дедлайн того же ДеМарко, то в нем менеджеру удалось на месяц отжать сроки без потери качества.

" book on the social side of software development, specifically managing project teams"

Аджыле по gandjustas:
— Петька, приборы ?
— Приборы двести !
— Спасибо !

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Ikemefula, Вы писали:

I>>>Здравствуйте, gandjustas, Вы писали:

V>>>>> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?

G>>>>Я так понимаю вопрос в том, что дедлайн по времени помогает работе или нет. На практике конечно помогает. Большинство программистов недостаточно дисциплинированны и очень любят любят заниматься "архитектурным творчеством", не остигая реальных целей.

G>>>>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).

I>>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении. В случае неосязаемого результата крайне сложно определить насколько о близок к цели. Дизайн еще можно обсуждать в категории нравится\не нравится, а с программным кодом чаще всего непонтяно будет ли он реально работать или надо еще 100500 раз переписать.

slm>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>Инспекции рядом сидящих программеров тут точно не помогут.

1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.
2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Странно то, что эту мантру повторяют уже лет 30, но все равно качество оценок в среднем по индустрии не улучшилось.

I>В основном потому, что
I>1 забивают на риски
I>2 мотивацию (вместо неё метод кнута и пряника)
I>3 складывают сорта колбасы (исключают время из оценок)
Как раз наоборот. Каждый первый менеджер проектов ведет учет рисков, строит диаграммы гантта с оценками по времени и без учета продуктивности и долго рассуждают о нематериальной мотивации, потому что 90% ПМов бюджетом не распоряжаются.
И у них всех проблемы с оценками.
А в скраме както проблем таких нет. Парадокс?

G>>Типичный сценарий:
G>>1) Берем оценку программиста, в человекочасах, данную в начале.

I>А кто тебе сказал, что эта оценка и есть срок сдачи ?
А кто сказал что это не так?

I>Эта оценка всего лишь наименьший срок, когда появится шанс получить результат.
А наибольший какой? Бесконечность? А что тогда пойдет в план?


>>Тут менеджер думает, что неплохо было бы замерять время. Но как? Трекер — там часы списываются номинально. Появляются жесткие методы контроля, типа снимки экрана\статус-репорты раз в 4 часа. (ты кстати сам был против них)

I>В своём сценарии ты показал
I>1 вместо оценки рисков угадайка с накидыванием процентов
Это и есть угадайка, какими теориями не обкладывай.

I>2 забить мотивацию — использование чувства вины и жесткого прессинга
А думаешь кто-то умеет проводить разбор полетов не вызывая чувство вины у просрочивших сроки?

I>3 сумму сортов колбасы — результат у манагера
Не понял о чем ты.

Здравствуйте, gandjustas, Вы писали:

slm>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>Инспекции рядом сидящих программеров тут точно не помогут.

G>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

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

G>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.

Мизер.

G>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.

А качество кода с количеством ошибок никак не связано ? Вот чудо !

Здравствуйте, Ikemefula, Вы писали:


G>>Грубо говоря за 100тыр и за 150тыр программист будет работать примерно одинаково, поэтому нет смысла платить сильно выше рынка.

I>А ты найди людей в своей конторе, у кого ЗП 150 и обрежь до 100. Ну и результаты сюда не забудь сообщить.

о том и разговор — де мотивировать посредством неаккуратных телодвижений с пряником/кнутом очень легко.
А вот наоборот — ни разу не видел такого что бы прибавка денег выше рынка (Или обещание премии) какой то долговременный эффект имела. Только — "Засуньте в #@#@# свою премию" (это когда обещавшее начальство ушло).

Едиственный вариант повышения мотивации — опосредованный: добавка денег как подтверждение повышения статуса (сотрудника/проекта/работы), но с кнутом это уже не вяжется.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>>>Этот идеальный вариант является устаревшей концепцией кнута и пряника, хорошо работает на землекопах, сварщиках и совершенно не работает в случае интеллектуального труда.

G>>>>Он прекрасно работает в случае интеллектуального труда. Но проблема не в методе, а в измерении.

I>>>Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

G>>С чего ты взял, что иной? Были исследования, которые показали, что увеличение денежного вознаграждения не влияет на показатели продуктивности интеллектуального труда.

I>Покажи эти исследования, а то Peopleware и Design of Design с тобой не согласны. Я, правда, давно не перечитывал их, но сильно вряд ли авторы этих книг отказались от своих позиций в последних изданиях

https://hbr.org/2013/04/does-money-really-affect-motiv/
В Peopleware больше написано про создание комфортных условий работы и повышение продуктивности, а про мотивацию там мало. В Design of Design только вскользь упоминаются эти вопросы, книжка то о другом.

G>>Грубо говоря за 100тыр и за 150тыр программист будет работать примерно одинаково, поэтому нет смысла платить сильно выше рынка.

I>А ты найди людей в своей конторе, у кого ЗП 150 и обрежь до 100. Ну и результаты сюда не забудь сообщить.
Этот бред ты придумал. Я лишь сказал, что нет смысла платить сильно выше рынка. Причем это касается только вопросов мотивации. А продуктивность и мотивация связаны очень слабо.

Здравствуйте, gandjustas, Вы писали:



slm>>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>Инспекции рядом сидящих программеров тут точно не помогут.

G>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

Тимлид сидит рядом и точно так же в сроках заинтересован. Конфликт интересов получается. Да "тупить" программисты начнут насчёт замечаний. Замучаешься на путь истинный наставлять если интерес другой.

G>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
G>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.

Если сначала разложить много граблей, то потом получим много ошибок.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
I>>>Сортов а не килограммов, внимание !
G>>Да пожалуйста, суммируй сорта колбасы. У тебя с этим проблемы?
I>Сколько будет первый сорт плюс второй ?

G>>Или ты думаешь раз ты написал про сорт колбасы, то это теперь имеет хоть какое-то отношение к реальной колбасе?
I>Ты не отвлекайся — сколько ?

Третий логично. Но к реальной колбасе не имеет отношения.

I>>>Вот эта максимально абстрактная величина и есть сорта колбасы. Сколько единиц в неделе ?
G>>Сколько единиц в неделе — надо считать, причем для команды в целом. Это и есть та самая непостоянная, ненелинейная и не инвариантная величина. Определить её заранее можно только по опыту. Если команда новая и проект совершенно новый, то тупо угадать (по науке называется "экспертная оценка")
I>А сотня это больше чем неделя ? А тысяча ? А миллион ? А килограм ?
Накурился?

I>>>Оценки без времени == сорта колбасы. Не нравится колбаса, можно взять шкалу Роквела, шкалу Бофорта, шкалу Рихтера — что угодно. Результат будет тот же.
G>>Именно, бери что угодно, а потом считай реальную velocity. Только так будет понимание когда можно делать релизы.
I> Понимание придет тогда, когда ты начнешь складывать значения имеющие одинаковую размерность. Сорта колбасы не складываются. Сумма чисел в такой шкале не имеет ни математического, ни физического смысла.
Пока ты пытаешься привязать абстрактные величины к физическим то не будут складываться. Когда ты уходишь от физики — все прекрасно складывается.
А если еще и шкала нелинейная, то вообще прекрасно..

I>Отсюда и растет хаос в Аджыле, когда из оценко пытаются исключить время.

I>>>Чудеса, в оценках время исключили, и приходим к главному — сколько единиц в неделе ?
G>>См выше.
G>>Вообще выключай дурачка. Про velocity разве что ленивый не писал, а читали уж точно все.
I>Если сложно про неделю, тогда давай про твой ремень. Сколько в нём единиц ?
42. А что тебе это дает?
Если бы мы делали проект, то сели бы и договорились сколько единиц будет в ремне. А пока это значение вообще не имеет смысла.

I>>>В случае интеллектуального труда это не дает результата. Эта простая мысль пережевывается в самых разных источниках
I>>>Peopleware
I>>>Design of Design
G>>Обе книжки про планирование и контроль почти ничего не пишут. А если почитать дедлайн того же ДеМарко, то в нем менеджеру удалось на месяц отжать сроки без потери качества.

I>" book on the social side of software development, specifically managing project teams"
Managing teams != Managing projects
Внезапно

I>Аджыле по gandjustas:
I>- Петька, приборы ?
I>- Приборы двести !
I>- Спасибо !
Ну если ты не знаешь что такое приборы и что означает 200, то можешь посмеяться.
А ведь анегдот, который ты корявенько перефразировал, не на пустом месте родлся. В боевой ситуации пилоты действительно общались так, что человек со стороны мешанину слов не поймет. Именно потом что у них есть общий базис.

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:



slm>>>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>>Инспекции рядом сидящих программеров тут точно не помогут.

G>>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

slm>Тимлид сидит рядом и точно так же в сроках заинтересован. Конфликт интересов получается. Да "тупить" программисты начнут насчёт замечаний. Замучаешься на путь истинный наставлять если интерес другой.
Тимлид своим делом занимается, иначе тимлидов не напасешься сидеть рядом с каждым программистом.

G>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
G>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
slm>Если сначала разложить много граблей, то потом получим много ошибок.
Раскладывание граблей — осозданный процесс. Самый правильный код обычно самый простой. Любое усложнение сверх необходимого создает грабли. Если у человека есть ограниченный срок, то он будет писать самый простой код. Не сразу, но такой результат быстро наступает.

Здравствуйте, gandjustas, Вы писали:

I>>В основном потому, что
I>>1 забивают на риски
I>>2 мотивацию (вместо неё метод кнута и пряника)
I>>3 складывают сорта колбасы (исключают время из оценок)
G>Как раз наоборот. Каждый первый менеджер проектов ведет учет рисков, строит диаграммы гантта с оценками по времени и без учета продуктивности и долго рассуждают о нематериальной мотивации, потому что 90% ПМов бюджетом не распоряжаются.
G>И у них всех проблемы с оценками.
G>А в скраме както проблем таких нет. Парадокс?

В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.

I>>А кто тебе сказал, что эта оценка и есть срок сдачи ?
G>А кто сказал что это не так?

Азы управления рисками

I>>Эта оценка всего лишь наименьший срок, когда появится шанс получить результат.
G>А наибольший какой? Бесконечность? А что тогда пойдет в план?

waltzing with bears tom demarco

I>>В своём сценарии ты показал
I>>1 вместо оценки рисков угадайка с накидыванием процентов
G>Это и есть угадайка, какими теориями не обкладывай.

Ога

I>>2 забить мотивацию — использование чувства вины и жесткого прессинга
G>А думаешь кто-то умеет проводить разбор полетов не вызывая чувство вины у просрочивших сроки?

Именно

I>>3 сумму сортов колбасы — результат у манагера
G>Не понял о чем ты.

Всё ты понял

Здравствуйте, slm, Вы писали:

slm>о том и разговор — де мотивировать посредством неаккуратных телодвижений с пряником/кнутом очень легко.
slm>А вот наоборот — ни разу не видел такого что бы прибавка денег выше рынка (Или обещание премии) какой то долговременный эффект имела. Только — "Засуньте в #@#@# свою премию" (это когда обещавшее начальство ушло).

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

slm>Едиственный вариант повышения мотивации — опосредованный: добавка денег как подтверждение повышения статуса (сотрудника/проекта/работы), но с кнутом это уже не вяжется.

Вариантов много, например предоставление свободы сотруднику, повышение по должностной лестнице и тд и тд и тд

Здравствуйте, gandjustas, Вы писали:

I>>>>Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

G>>>С чего ты взял, что иной? Были исследования, которые показали, что увеличение денежного вознаграждения не влияет на показатели продуктивности интеллектуального труда.

I>>Покажи эти исследования, а то Peopleware и Design of Design с тобой не согласны. Я, правда, давно не перечитывал их, но сильно вряд ли авторы этих книг отказались от своих позиций в последних изданиях

G>https://hbr.org/2013/04/does-money-really-affect-motiv/
G>В Peopleware больше написано про создание комфортных условий работы и повышение продуктивности, а про мотивацию там мало. В Design of Design только вскользь упоминаются эти вопросы, книжка то о другом.

Ловкач, начал с кнута-пряника а пришел прямо к противоположному выводу. Ты сам то читал свою ссылку ? У тебя в ней прямо написано — "Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "

Перевожу — метод кнута-пряника работает хуже внутренней мотивации (сиречь интерес).

I>>А ты найди людей в своей конторе, у кого ЗП 150 и обрежь до 100. Ну и результаты сюда не забудь сообщить.
G>Этот бред ты придумал. Я лишь сказал, что нет смысла платить сильно выше рынка. Причем это касается только вопросов мотивации. А продуктивность и мотивация связаны очень слабо.

"Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "

Ты в курсе, что метод кнута и пряника это внешняя мотивация ?

Здравствуйте, gandjustas, Вы писали:

I>>>>Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
I>>>>Сортов а не килограммов, внимание !
G>>>Да пожалуйста, суммируй сорта колбасы. У тебя с этим проблемы?
I>>Сколько будет первый сорт плюс второй ?

G>>>Или ты думаешь раз ты написал про сорт колбасы, то это теперь имеет хоть какое-то отношение к реальной колбасе?
I>>Ты не отвлекайся — сколько ?

G>Третий логично. Но к реальной колбасе не имеет отношения.

Ничего не логично. В первых, в шкале нет никакого третьего сорта. Шкала заканчивается вторым. Но все интереснее.
Вот положил ты в ящик 1 кг первого сорта и кг второго. Откуда там взять 2кг третьего, если изначально ящик был пуст ?
Полагаю, уже здесь у тебя ответа нет и не будет

Но мы вообще то про сложение сортов, а не колбас. Фактически сорта колбасы суть названия. Как складывать названия — не ясно, может ты конкатенацию предложил бы ? И как по результату велосити считать ?

I>>А сотня это больше чем неделя ? А тысяча ? А миллион ? А килограм ?
G>Накурился?

Ты же хочешь получить абстрактные числа.

G>>>Именно, бери что угодно, а потом считай реальную velocity. Только так будет понимание когда можно делать релизы.
I>> Понимание придет тогда, когда ты начнешь складывать значения имеющие одинаковую размерность. Сорта колбасы не складываются. Сумма чисел в такой шкале не имеет ни математического, ни физического смысла.
G>Пока ты пытаешься привязать абстрактные величины к физическим то не будут складываться. Когда ты уходишь от физики — все прекрасно складывается.

Если теряется физический смысл, то нет оснований ждать физического смысла от результата.

G>А если еще и шкала нелинейная, то вообще прекрасно..

Если один это кухня, а два это контрабас, сколько будет один плюс два поделить на три часа ?
Физика говорит что херня, а у тебя — велосити.

G>>>Вообще выключай дурачка. Про velocity разве что ленивый не писал, а читали уж точно все.
I>>Если сложно про неделю, тогда давай про твой ремень. Сколько в нём единиц ?
G>42. А что тебе это дает?

Показывает количество смысла в скраме.

G>Если бы мы делали проект, то сели бы и договорились сколько единиц будет в ремне. А пока это значение вообще не имеет смысла.

Смысла будет ровно столько же. Только в скраме ты этими числа еще и складываешь и велосити считаешь.

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

I>>" book on the social side of software development, specifically managing project teams"
G>Managing teams != Managing projects
G>Внезапно

Вообще то изначально, с самого первого сообщения здесь речь про команды.

I>>Аджыле по gandjustas:
I>>- Петька, приборы ?
I>>- Приборы двести !
I>>- Спасибо !
G>Ну если ты не знаешь что такое приборы и что означает 200, то можешь посмеяться.
G>А ведь анегдот, который ты корявенько перефразировал, не на пустом месте родлся. В боевой ситуации пилоты действительно общались так, что человек со стороны мешанину слов не поймет. Именно потом что у них есть общий базис.

Главное что в анекдоте все как у тебя. Ты ведь смог сорта колбасы суммировать

Здравствуйте, gandjustas, Вы писали:

I>>Это значит, что тимлид в команде из 5 человек только и будет ревьюить, ни на что больше времени не останется. А еще нужно мержить, планировать, обсуждать и тд и тд и тд.
G>Не значит, потому что программисты пишут код от силы половину времени. А остальное время они как раз будут с тимлидом обсуждать какой код писать, обсуждать итп.

Это интересное обоснование для микроменеджмента.

G>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
I>>Мизер.
G>По моей практике тулы отлавливали 80% типичных ошибок.

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

G>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
I>>А качество кода с количеством ошибок никак не связано ? Вот чудо !
G>Качество кода и есть количество (вернее плотность) ошибок. Но "обыдлячивание" это не про качество,а про стиль кода.

1 Вообще то ты сам привел ссылку, где говорится что внутренняя мотивация лучше внешней.
2 деньги, как и кнут с пряником = внешняя мотивация.
3 Демотивация проявляется в ухудшении качества всего результата — во всех аспектах, от сроков, до количества багов и объеме исполнения. В запущеных случаях до морального состояния всей команды.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>В основном потому, что
I>>>1 забивают на риски
I>>>2 мотивацию (вместо неё метод кнута и пряника)
I>>>3 складывают сорта колбасы (исключают время из оценок)
G>>Как раз наоборот. Каждый первый менеджер проектов ведет учет рисков, строит диаграммы гантта с оценками по времени и без учета продуктивности и долго рассуждают о нематериальной мотивации, потому что 90% ПМов бюджетом не распоряжаются.
G>>И у них всех проблемы с оценками.
G>>А в скраме както проблем таких нет. Парадокс?

I>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.
И какие же это проблемы? Может проблема не в скраме? А в нихкой квалификаии и дисциплине?
Скрам же не волшебная пилюля от всего.

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

I>>>Эта оценка всего лишь наименьший срок, когда появится шанс получить результат.
G>>А наибольший какой? Бесконечность? А что тогда пойдет в план?
I>waltzing with bears tom demarco
И? Срок и тоге какой?

I>>>3 сумму сортов колбасы — результат у манагера
G>>Не понял о чем ты.
I>Всё ты понял

Ты сформулируй по русски мысль.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>>>Не работает. Для интеллектуального труда нужна принципиально иной подход к мотивации. А у тебя просто желание приставить к программисту надсмотрщика и изрека бросать печеньки.

G>>>>С чего ты взял, что иной? Были исследования, которые показали, что увеличение денежного вознаграждения не влияет на показатели продуктивности интеллектуального труда.

I>>>Покажи эти исследования, а то Peopleware и Design of Design с тобой не согласны. Я, правда, давно не перечитывал их, но сильно вряд ли авторы этих книг отказались от своих позиций в последних изданиях

G>>https://hbr.org/2013/04/does-money-really-affect-motiv/
G>>В Peopleware больше написано про создание комфортных условий работы и повышение продуктивности, а про мотивацию там мало. В Design of Design только вскользь упоминаются эти вопросы, книжка то о другом.

I>Ловкач, начал с кнута-пряника а пришел прямо к противоположному выводу. Ты сам то читал свою ссылку ? У тебя в ней прямо написано — "Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "
I>Перевожу — метод кнута-пряника работает хуже внутренней мотивации (сиречь интерес).
Смешались в кучу кони, люди...
Я писал о том, что ясная цель и ясное вознаграждение\наказание за недостижение повышает шансы достижения цели.
К продуктивности это отношения не имеет. Потому что можно иметь сверхпродуктивного сотрудника, который занимается не тем и к цели он не придет.
Ты же подумал что речь о внешней мотивации, которая вроде как должна увеличивать продуктивность. А оказалось что внешняя мотивация не увеличивает продуктивность.
То есть ты сам придумал причинно-следственные связи и доблестно их опроверг.


I>>>А ты найди людей в своей конторе, у кого ЗП 150 и обрежь до 100. Ну и результаты сюда не забудь сообщить.
G>>Этот бред ты придумал. Я лишь сказал, что нет смысла платить сильно выше рынка. Причем это касается только вопросов мотивации. А продуктивность и мотивация связаны очень слабо.
I>"Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "
I>Ты в курсе, что метод кнута и пряника это внешняя мотивация ?
Ты не в курсе, что я не говорил о продуктивности?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>>>Ты плохо прочитал. Если исключить время, как тебе хочется, получится суммирование сортов колбасы.
I>>>>>Сортов а не килограммов, внимание !
G>>>>Да пожалуйста, суммируй сорта колбасы. У тебя с этим проблемы?
I>>>Сколько будет первый сорт плюс второй ?

G>>>>Или ты думаешь раз ты написал про сорт колбасы, то это теперь имеет хоть какое-то отношение к реальной колбасе?
I>>>Ты не отвлекайся — сколько ?

G>>Третий логично. Но к реальной колбасе не имеет отношения.

I>Ничего не логично. В первых, в шкале нет никакого третьего сорта.

I>Но мы вообще то про сложение сортов, а не колбас. Фактически сорта колбасы суть названия. Как складывать названия — не ясно, может ты конкатенацию предложил бы ? И как по результату велосити считать ?

К реальной колбасе это не имеет никакого отношения. Все остальное — твои фантазии.


I>>>А сотня это больше чем неделя ? А тысяча ? А миллион ? А килограм ?
G>>Накурился?
I>Ты же хочешь получить абстрактные числа.
Абстрактные не означает случайные.


G>>>>Именно, бери что угодно, а потом считай реальную velocity. Только так будет понимание когда можно делать релизы.
I>>> Понимание придет тогда, когда ты начнешь складывать значения имеющие одинаковую размерность. Сорта колбасы не складываются. Сумма чисел в такой шкале не имеет ни математического, ни физического смысла.
G>>Пока ты пытаешься привязать абстрактные величины к физическим то не будут складываться. Когда ты уходишь от физики — все прекрасно складывается.

I>Если теряется физический смысл, то нет оснований ждать физического смысла от результата.
С чего бы? Куча математических теорий, оперируя абстрактными цифрами, описывают реальный мир.


G>>А если еще и шкала нелинейная, то вообще прекрасно..

I>Если один это кухня, а два это контрабас, сколько будет один плюс два поделить на три часа ?
I>Физика говорит что херня, а у тебя — велосити.
Точно обкурился.

G>>>>Вообще выключай дурачка. Про velocity разве что ленивый не писал, а читали уж точно все.
I>>>Если сложно про неделю, тогда давай про твой ремень. Сколько в нём единиц ?
G>>42. А что тебе это дает?
I>Показывает количество смысла в скраме.
А 42 это много или мало?

G>>Если бы мы делали проект, то сели бы и договорились сколько единиц будет в ремне. А пока это значение вообще не имеет смысла.
I>Смысла будет ровно столько же. Только в скраме ты этими числа еще и складываешь и велосити считаешь.
Ты с голосами в своей голове разговариваешь?

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

I>>>" book on the social side of software development, specifically managing project teams"
G>>Managing teams != Managing projects
G>>Внезапно

I>Вообще то изначально, с самого первого сообщения здесь речь про команды.
Но речь то про scrum, который об управлении проектами.

I>>>Аджыле по gandjustas:
I>>>- Петька, приборы ?
I>>>- Приборы двести !
I>>>- Спасибо !
G>>Ну если ты не знаешь что такое приборы и что означает 200, то можешь посмеяться.
G>>А ведь анегдот, который ты корявенько перефразировал, не на пустом месте родлся. В боевой ситуации пилоты действительно общались так, что человек со стороны мешанину слов не поймет. Именно потом что у них есть общий базис.

I>Главное что в анекдоте все как у тебя. Ты ведь смог сорта колбасы суммировать
Я могу что угодно суммировать. Пока это что угодно никак не соответствует физическим величинам.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>Здравствуйте, gandjustas, Вы писали:



slm>>>>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>>>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>>>Инспекции рядом сидящих программеров тут точно не помогут.

G>>>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

slm>>Тимлид сидит рядом и точно так же в сроках заинтересован. Конфликт интересов получается. Да "тупить" программисты начнут насчёт замечаний. Замучаешься на путь истинный наставлять если интерес другой.
G>Тимлид своим делом занимается, иначе тимлидов не напасешься сидеть рядом с каждым программистом.

Разговор про то что ревью тимлидом не помогает в этой ситуации. И возможно никакое ревью не поможет когда программистам создали конфликт интересов.

G>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
G>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
slm>>Если сначала разложить много граблей, то потом получим много ошибок.
G>Раскладывание граблей — осозданный процесс. Самый правильный код обычно самый простой. Любое усложнение сверх необходимого создает грабли. Если у человека есть ограниченный срок, то он будет писать самый простой код. Не сразу, но такой результат быстро наступает.

Это о какой то сферичесокй жизни в ваккуме. Я этой абстракции не понимаю.
В жизни всё немного не так.

Если у человека ограниченный срок, оно даже не будет задумываться. Он будет фигачить не задумываясь и копи-пастить.
Ну и углы срезать.
Неочевидными проверками не заморачиваться. Не будет переделывать структуру под новые требования.

Вместо добавления нового класса будет в старые всё лепить...

"Извини что пишу длинно. не было времени написать коротко." (С)

Здравствуйте, Ikemefula, Вы писали:


G>>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
I>>>Мизер.
G>>По моей практике тулы отлавливали 80% типичных ошибок.
I>Слабо верится, глядя на успех динамических языков.
Успех с натяжкой. Например я увеличил продуктивность в команде внедрив typescript.
Да и динамические языки поддаются статическому анализу.
Большинство же ошибок довольно банальные, вызванные невнимательностью и копипастой. Логических ошибок на порядки меньше.

G>>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
I>>>А качество кода с количеством ошибок никак не связано ? Вот чудо !
G>>Качество кода и есть количество (вернее плотность) ошибок. Но "обыдлячивание" это не про качество,а про стиль кода.

I>1 Вообще то ты сам привел ссылку, где говорится что внутренняя мотивация лучше внешней.
I>2 деньги, как и кнут с пряником = внешняя мотивация.
I>3 Демотивация проявляется в ухудшении качества всего результата — во всех аспектах, от сроков, до количества багов и объеме исполнения. В запущеных случаях до морального состояния всей команды.

Да ты прям мыслитель.
Только откуда ты взял вывод что внешняя мотивация связана со внутренней?
Внутренняя она на то и внутренняя, что внешними воздействиями её за короткое время не поменяешь.
А если внешняя слабо воздействует, то это вовсе не означает, что она отрицательно воздействует.
По ссылке говорится о продуктивности, но я о продуктивности не говорил.

Реально похоже что ты разговариваешь с голосами в голове.

Здравствуйте, slm, Вы писали:

slm>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, slm, Вы писали:

slm>>>Здравствуйте, gandjustas, Вы писали:



slm>>>>>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>>>>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>>>>Инспекции рядом сидящих программеров тут точно не помогут.

G>>>>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

slm>>>Тимлид сидит рядом и точно так же в сроках заинтересован. Конфликт интересов получается. Да "тупить" программисты начнут насчёт замечаний. Замучаешься на путь истинный наставлять если интерес другой.
G>>Тимлид своим делом занимается, иначе тимлидов не напасешься сидеть рядом с каждым программистом.

slm>Разговор про то что ревью тимлидом не помогает в этой ситуации. И возможно никакое ревью не поможет когда программистам создали конфликт интересов.
Откуда конфликт? Из головы? В чем суть конфликта?

G>>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
G>>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
slm>>>Если сначала разложить много граблей, то потом получим много ошибок.
G>>Раскладывание граблей — осозданный процесс. Самый правильный код обычно самый простой. Любое усложнение сверх необходимого создает грабли. Если у человека есть ограниченный срок, то он будет писать самый простой код. Не сразу, но такой результат быстро наступает.

slm>Это о какой то сферичесокй жизни в ваккуме. Я этой абстракции не понимаю.
slm>В жизни всё немного не так.
В жизни все именно так. Я такую методу применил и программисты начали писать ровно три строчки там, где нужно три строки. А когда у них было время, то писали абстрактные фабрики фасадов, получая на одну строку логики 40 строк "архитектуры".

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

slm>Вместо добавления нового класса будет в старые всё лепить...
А потом рефакторить, ибо "слишком длинный метод" скажут как тулы, так и ревью.

slm>"Извини что пишу длинно. не было времени написать коротко." (С)
Писать коротко, как и писать длинно — это привычка. Надо развивать её в ту сторону, которая больше нужна.

Здравствуйте, gandjustas, Вы писали:

I>>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.
G>И какие же это проблемы? Может проблема не в скраме? А в нихкой квалификаии и дисциплине?
G>Скрам же не волшебная пилюля от всего.

Намекаешь, что если всё хорошо, то это скрам, а если плохо, то квалификация не та ?

I>>Азы управления рисками
G>А при чем тут азы? Ты когда своему менеджеру гоовришь оценку в днях, он не воспринимает это как срок?

Именно.

I>>>>Эта оценка всего лишь наименьший срок, когда появится шанс получить результат.
G>>>А наибольший какой? Бесконечность? А что тогда пойдет в план?
I>>waltzing with bears tom demarco
G>И? Срок и тоге какой?

Там написано.

I>>>>3 сумму сортов колбасы — результат у манагера
G>>>Не понял о чем ты.
I>>Всё ты понял

G>Ты сформулируй по русски мысль.

А ты перечитай про суммирование сортов.

Здравствуйте, gandjustas, Вы писали:


I>>Ловкач, начал с кнута-пряника а пришел прямо к противоположному выводу. Ты сам то читал свою ссылку ? У тебя в ней прямо написано — "Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "
I>>Перевожу — метод кнута-пряника работает хуже внутренней мотивации (сиречь интерес).
G>Смешались в кучу кони, люди...
G>Я писал о том, что ясная цель и ясное вознаграждение\наказание за недостижение повышает шансы достижения цели.

Цель и вознаграждение-наказание — это все внешняя мотивация.
По твоей ссылке написано "Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "

G>Ты же подумал что речь о внешней мотивации, которая вроде как должна увеличивать продуктивность. А оказалось что внешняя мотивация не увеличивает продуктивность.

Правильно. Только про внешнюю мотивацию именно ты и писал.

I>>"Intrinsic motivation is also a stronger predictor of job performance than extrinsic motivation "
I>>Ты в курсе, что метод кнута и пряника это внешняя мотивация ?
G>Ты не в курсе, что я не говорил о продуктивности?

"вознаграждение\наказание за недостижение"

И это не о продуктивности ?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, slm, Вы писали:

slm>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, slm, Вы писали:

slm>>>>Здравствуйте, gandjustas, Вы писали:



slm>>>>>>Ну я бы и на сварщиках/сантехниках/электриках побоялся так экспериментировать. Вставят побыстрее скрутку многожильного провода с алюминием. Узнаешь об этом по факту через пару лет.

slm>>>>>>А у программистов это приводит к обыдлячиванию codebase. Тоже первые год — два может быть не заметно.
slm>>>>>>Инспекции рядом сидящих программеров тут точно не помогут.

G>>>>>1) Зачем рядом сидящих? Весь код, написанный программистами под оьязательное review тимлида. Скорость ревью примерно в 4 раза выше скорости написания. То есть один тимлид вполне может ревьювить 4 человек.

slm>>>>Тимлид сидит рядом и точно так же в сроках заинтересован. Конфликт интересов получается. Да "тупить" программисты начнут насчёт замечаний. Замучаешься на путь истинный наставлять если интерес другой.
G>>>Тимлид своим делом занимается, иначе тимлидов не напасешься сидеть рядом с каждым программистом.

slm>>Разговор про то что ревью тимлидом не помогает в этой ситуации. И возможно никакое ревью не поможет когда программистам создали конфликт интересов.
G>Откуда конфликт? Из головы? В чем суть конфликта?

Конфликт: сроки(для команды) с кнутом против качества кода. В результате в репозитарий проскакивает копи-паста. "Ну ведь срочно надо. Не успеваем."

G>>>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить.
G>>>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много.
slm>>>>Если сначала разложить много граблей, то потом получим много ошибок.
G>>>Раскладывание граблей — осозданный процесс. Самый правильный код обычно самый простой. Любое усложнение сверх необходимого создает грабли. Если у человека есть ограниченный срок, то он будет писать самый простой код. Не сразу, но такой результат быстро наступает.

slm>>Это о какой то сферичесокй жизни в ваккуме. Я этой абстракции не понимаю.
slm>>В жизни всё немного не так.
G>В жизни все именно так. Я такую методу применил и программисты начали писать ровно три строчки там, где нужно три строки. А когда у них было время, то писали абстрактные фабрики фасадов, получая на одну строку логики 40 строк "архитектуры".

У меня наверно совсем другой опыт. Но когда не было кнута в виде "успевания в каждую задачу" то и код нормальный писался.
А где было постоянное давление, там шёл валом копи-паст и странный дизайн с оправданием "у нас же сроки"

slm>>Если у человека ограниченный срок, оно даже не будет задумываться. Он будет фигачить не задумываясь и копи-пастить.
slm>>Ну и углы срезать.
slm>>Неочевидными проверками не заморачиваться. Не будет переделывать структуру под новые требования.
G>Если при этом контроль качества увеличить за счет тулов, формальных ревью, а возможно и внешнего аудита, то будет потрясающий результат.

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

slm>>Вместо добавления нового класса будет в старые всё лепить...
G>А потом рефакторить, ибо "слишком длинный метод" скажут как тулы, так и ревью.

slm>>"Извини что пишу длинно. не было времени написать коротко." (С)
G>Писать коротко, как и писать длинно — это привычка. Надо развивать её в ту сторону, которая больше нужна.

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

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

Здравствуйте, gandjustas, Вы писали:

I>>Но мы вообще то про сложение сортов, а не колбас. Фактически сорта колбасы суть названия. Как складывать названия — не ясно, может ты конкатенацию предложил бы ? И как по результату велосити считать ?

G>К реальной колбасе это не имеет никакого отношения. Все остальное — твои фантазии.

Не фантазии, а самая обыкновенная физика с математикой.

I>>>>А сотня это больше чем неделя ? А тысяча ? А миллион ? А килограм ?
G>>>Накурился?
I>>Ты же хочешь получить абстрактные числа.
G>Абстрактные не означает случайные.

Абстрактные числа это например натуральные. Сколько натуральных чисел в неделе ты так и не ответил.

G>>>Пока ты пытаешься привязать абстрактные величины к физическим то не будут складываться. Когда ты уходишь от физики — все прекрасно складывается.

I>>Если теряется физический смысл, то нет оснований ждать физического смысла от результата.
G>С чего бы? Куча математических теорий, оперируя абстрактными цифрами, описывают реальный мир.

Это чушь. Всегда в явном виде делается привязка ко времени/пространству.

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

I>>Показывает количество смысла в скраме.
G>А 42 это много или мало?

Это отсутствие смысла.

I>>Вообще то изначально, с самого первого сообщения здесь речь про команды.
G>Но речь то про scrum, который об управлении проектами.

Тогда продолжаю цитировать "Peopleware is a popular book about project management."

Ну, ты понял

I>>Главное что в анекдоте все как у тебя. Ты ведь смог сорта колбасы суммировать
G>Я могу что угодно суммировать. Пока это что угодно никак не соответствует физическим величинам.

Прямо как в скраме со сторипоинтами и велосити.

Здравствуйте, gandjustas, Вы писали:

G>>>По моей практике тулы отлавливали 80% типичных ошибок.
I>>Слабо верится, глядя на успех динамических языков.
G>Успех с натяжкой. Например я увеличил продуктивность в команде внедрив typescript.

А мы увеличили продуктивность отказавшись от C# в пользу js

I>>1 Вообще то ты сам привел ссылку, где говорится что внутренняя мотивация лучше внешней.
I>>2 деньги, как и кнут с пряником = внешняя мотивация.
I>>3 Демотивация проявляется в ухудшении качества всего результата — во всех аспектах, от сроков, до количества багов и объеме исполнения. В запущеных случаях до морального состояния всей команды.

G>Да ты прям мыслитель.
G>Только откуда ты взял вывод что внешняя мотивация связана со внутренней?

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

G>А если внешняя слабо воздействует, то это вовсе не означает, что она отрицательно воздействует.

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



G>По ссылке говорится о продуктивности, но я о продуктивности не говорил.

Да, я в курсе, результат есть, а продуктивности нет.

Здравствуйте, Ikemefula, Вы писали:

G>>Я могу что угодно суммировать. Пока это что угодно никак не соответствует физическим величинам.
I>Прямо как в скраме со сторипоинтами и велосити.
Ну блин. Давай на пальцах:

Методом палецвнебо идеальная неделя команды в 240 человекочасов оценена в 100 попугаев. При планировании выясняется, что реальная неделя будет ближе к 200 часам (кто-то болеет, деньрождения, обучение, совещания и тыды и тыпы), урезаем попугаев до 80. Смотрим статистику по прошлым периодам, понимаем, что 100 попугаев — это 25 средних тикетов. Волевым усилием назначаем 1 мелкий тикет == 1 попугай, в планниг покере набираем тикетов на 80 попугаев, запускаем итерацию.

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

Где ты тут видишь складывание сортов колбасы?

Да, прочитай хорошее интро от SkyDandce

Автор: SkyDance
Дата: 21.08.12

. Такое впечатление, ты споришь о том, что сам не щупал

P.S. Маленькая просьба всем в этой ветке

	Скрытый текст
	УБИРАЙТЕ ОВЕРКВОТИНГ

Здравствуйте, Sinix, Вы писали:

S>Где ты тут видишь складывание сортов колбасы?

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

Здравствуйте, Ikemefula, Вы писали:

I> S>Где ты тут видишь складывание сортов колбасы?

I> Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
Как это нет привязки? А что же тогда velocity (попугаев в спринт)?

Здравствуйте, Ikemefula, Вы писали:

S>>Где ты тут видишь складывание сортов колбасы?
I>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.

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

Ну значит, или у них была _очень_ непредсказуемая нагрузка, или вообще отсутствовал буфер в виде очереди входящих тикетов, или ещё какая причина, например, команде не подходит работа по итерациям. Я ж в самом начале давал дисклаймер,

Достаточно:
1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.

Если этого ещё нет — нафиг натягивать скрам на команду?

Здравствуйте, Dziman, Вы писали:

I>> S>Где ты тут видишь складывание сортов колбасы?

I>> Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
D>Как это нет привязки? А что же тогда velocity (попугаев в спринт)?

Если ты поделишь сорт колбасы на время спринта, что же ты получишь ?

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

Здравствуйте, Sinix, Вы писали:

I>>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
S>Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.

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

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

S>Ну значит, или у них была _очень_ непредсказуемая нагрузка, или вообще отсутствовал буфер в виде очереди входящих тикетов, или ещё какая причина, например, команде не подходит работа по итерациям.

То есть, если помогло — значит скрам. Не помогло — значит девелоперы плохие.

S>

S>Достаточно:
S>1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
S>2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
S>3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.

S>Если этого ещё нет — нафиг натягивать скрам на команду?

Вопрос в том, почему дохнут проекты-конторы, в которых есть не только это, но и скрам