G>>>>2) Автоматические инспекции тоже есть и они могут огромное число проблем отловить. I>>>Мизер. G>>По моей практике тулы отлавливали 80% типичных ошибок. I>Слабо верится, глядя на успех динамических языков.
Успех с натяжкой. Например я увеличил продуктивность в команде внедрив typescript.
Да и динамические языки поддаются статическому анализу.
Большинство же ошибок довольно банальные, вызванные невнимательностью и копипастой. Логических ошибок на порядки меньше.
G>>>>3) Обыдлячивание codebase вовсе не проблема. Проблема когда ошибок много. I>>>А качество кода с количеством ошибок никак не связано ? Вот чудо ! G>>Качество кода и есть количество (вернее плотность) ошибок. Но "обыдлячивание" это не про качество,а про стиль кода.
I>1 Вообще то ты сам привел ссылку, где говорится что внутренняя мотивация лучше внешней. I>2 деньги, как и кнут с пряником = внешняя мотивация. I>3 Демотивация проявляется в ухудшении качества всего результата — во всех аспектах, от сроков, до количества багов и объеме исполнения. В запущеных случаях до морального состояния всей команды.
Да ты прям мыслитель.
Только откуда ты взял вывод что внешняя мотивация связана со внутренней?
Внутренняя она на то и внутренняя, что внешними воздействиями её за короткое время не поменяешь.
А если внешняя слабо воздействует, то это вовсе не означает, что она отрицательно воздействует.
По ссылке говорится о продуктивности, но я о продуктивности не говорил.
Реально похоже что ты разговариваешь с голосами в голове.
Re[9]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, 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>"Извини что пишу длинно. не было времени написать коротко." (С)
Писать коротко, как и писать длинно — это привычка. Надо развивать её в ту сторону, которая больше нужна.
Re[12]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas, Вы писали:
I>>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы. G>И какие же это проблемы? Может проблема не в скраме? А в нихкой квалификаии и дисциплине? G>Скрам же не волшебная пилюля от всего.
Намекаешь, что если всё хорошо, то это скрам, а если плохо, то квалификация не та ?
I>>Азы управления рисками G>А при чем тут азы? Ты когда своему менеджеру гоовришь оценку в днях, он не воспринимает это как срок?
Именно.
I>>>>Эта оценка всего лишь наименьший срок, когда появится шанс получить результат. G>>>А наибольший какой? Бесконечность? А что тогда пойдет в план? I>>waltzing with bears tom demarco G>И? Срок и тоге какой?
Там написано.
I>>>>3 сумму сортов колбасы — результат у манагера G>>>Не понял о чем ты. I>>Всё ты понял
G>Ты сформулируй по русски мысль.
А ты перечитай про суммирование сортов.
Re[10]: Закон Паркинсона: секундомеры против таймеров
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>Ты не в курсе, что я не говорил о продуктивности?
"вознаграждение\наказание за недостижение"
И это не о продуктивности ?
Re[10]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, 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>Писать коротко, как и писать длинно — это привычка. Надо развивать её в ту сторону, которая больше нужна.
Если надо быстро — буду писать в духе "что вижу то и пишу". Если есть время отойти от клавы. подумаю над используемыми абстракциями.
Вообще то весь коп-паст который я видел в качестве отмазки использовал "сроки, дедлайны, кнут" итд.
Re[17]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, 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>Я могу что угодно суммировать. Пока это что угодно никак не соответствует физическим величинам.
Прямо как в скраме со сторипоинтами и велосити.
Re[10]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas, Вы писали:
G>>>По моей практике тулы отлавливали 80% типичных ошибок. I>>Слабо верится, глядя на успех динамических языков. G>Успех с натяжкой. Например я увеличил продуктивность в команде внедрив typescript.
А мы увеличили продуктивность отказавшись от C# в пользу js
I>>1 Вообще то ты сам привел ссылку, где говорится что внутренняя мотивация лучше внешней. I>>2 деньги, как и кнут с пряником = внешняя мотивация. I>>3 Демотивация проявляется в ухудшении качества всего результата — во всех аспектах, от сроков, до количества багов и объеме исполнения. В запущеных случаях до морального состояния всей команды.
G>Да ты прям мыслитель. G>Только откуда ты взял вывод что внешняя мотивация связана со внутренней?
Ты снова хочешь приписать мне чтото взятое с соседней вкладки твоего браузера. Но вообще связь есть. В частности долгий период демотивации заканчивается очень часто и депрессией и личностными изменениями.
G>А если внешняя слабо воздействует, то это вовсе не означает, что она отрицательно воздействует.
Внешняя как раз сильно воздействует, но на продуктивности сказывается слабо.
Скажем, если тебя ктото будет бить, сильно вряд ли напишешь код и быстрее и качественнее.
В пряником ровно то же.
Что бы принципиально ускорить и улучшить качество, нужно вкладываться во внутреннюю мотивацию.
G>По ссылке говорится о продуктивности, но я о продуктивности не говорил.
Да, я в курсе, результат есть, а продуктивности нет.
Re[18]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Ikemefula, Вы писали: G>>Я могу что угодно суммировать. Пока это что угодно никак не соответствует физическим величинам. I>Прямо как в скраме со сторипоинтами и велосити.
Ну блин. Давай на пальцах:
Методом палецвнебо идеальная неделя команды в 240 человекочасов оценена в 100 попугаев. При планировании выясняется, что реальная неделя будет ближе к 200 часам (кто-то болеет, деньрождения, обучение, совещания и тыды и тыпы), урезаем попугаев до 80. Смотрим статистику по прошлым периодам, понимаем, что 100 попугаев — это 25 средних тикетов. Волевым усилием назначаем 1 мелкий тикет == 1 попугай, в планниг покере набираем тикетов на 80 попугаев, запускаем итерацию.
Вышло лучше — забираем дела из общей очереди. Вышло хуже — вводим поправочный коэффициент для налажавшего и перекидываем на следующую итерацию с повышенным приоритетом (хотя по факту задержки становятся ясны к середине и закрываются остальными сотрудниками).
Здравствуйте, Sinix, Вы писали:
S>Где ты тут видишь складывание сортов колбасы?
Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
Я знаю целую кучу проектов и даже контор, где бурндаун никогда ни разу не сходился. Ты почему то хочешь такие проекты игнорировать, а по моему их надо учитывать.
Re[20]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Ikemefula, Вы писали:
I> S>Где ты тут видишь складывание сортов колбасы?
I> Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
Как это нет привязки? А что же тогда velocity (попугаев в спринт)?
Здравствуйте, Ikemefula, Вы писали:
S>>Где ты тут видишь складывание сортов колбасы? I>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.
I>Я знаю целую кучу проектов и даже контор, где бурндаун никогда ни разу не сходился. Ты почему то хочешь такие проекты игнорировать, а по моему их надо учитывать.
Ну значит, или у них была _очень_ непредсказуемая нагрузка, или вообще отсутствовал буфер в виде очереди входящих тикетов, или ещё какая причина, например, команде не подходит работа по итерациям. Я ж в самом начале давал дисклаймер,
Достаточно:
1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.
Если этого ещё нет — нафиг натягивать скрам на команду?
Re[21]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Dziman, Вы писали:
I>> S>Где ты тут видишь складывание сортов колбасы?
I>> Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо" D>Как это нет привязки? А что же тогда velocity (попугаев в спринт)?
Если ты поделишь сорт колбасы на время спринта, что же ты получишь ?
Привязка ко времени должны быть унутре попугая, а её как раз и нет. Тут великие скрамщики выдают серьёзную идею — все задачи должны быть максимум на один день. Чудо — внезапно появилось время. Теперь не ясно, почему надо считать в попугаях, если можно оценить время и выяснить, требует ли каждая из задач времени больше чем день или нет.
Re[21]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Sinix, Вы писали:
I>>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо" S>Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.
Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.
I>>Я знаю целую кучу проектов и даже контор, где бурндаун никогда ни разу не сходился. Ты почему то хочешь такие проекты игнорировать, а по моему их надо учитывать.
S>Ну значит, или у них была _очень_ непредсказуемая нагрузка, или вообще отсутствовал буфер в виде очереди входящих тикетов, или ещё какая причина, например, команде не подходит работа по итерациям.
То есть, если помогло — значит скрам. Не помогло — значит девелоперы плохие.
S>
S>Достаточно:
S>1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
S>2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
S>3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.
S>Если этого ещё нет — нафиг натягивать скрам на команду?
Вопрос в том, почему дохнут проекты-конторы, в которых есть не только это, но и скрам
Re[8]: Закон Паркинсона: секундомеры против таймеров
I>Для того, что бы велосити давала внятный эффект, стори-поинты должны быть привязаны ко времени, эстимейты должны быть привязаны ко времени.
Оно работает в обратном направлении.
Оценки делаются в story points. Уже на основании сделанного в итерациях менеджмент может прогнозировать привязки ко времени. Во времена стародавние, когда мы еще Backlog вели в Excel'е, у нас была колонка "Estimated Sprint" для каждого сценария в бэклоге.
Re[22]: Закон Паркинсона: секундомеры против таймеров
I>Привязка ко времени должны быть унутре попугая, а её как раз и нет. Тут великие скрамщики выдают серьёзную идею — все задачи должны быть максимум на один день. Чудо — внезапно появилось время. Теперь не ясно, почему надо считать в попугаях, если можно оценить время и выяснить, требует ли каждая из задач времени больше чем день или нет.
Вы случайно не спутали "сценарий" и "задачу"?
В бэклоге нет "задач", там только сценарии. Задачи появляются только внутри спринта, и нужны для внутренней статистики (sprint burndown), чтобы было видно, где затыки, и все ли в порядке со здоровьем спринта.
Re[22]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sinix, Вы писали:
I>>>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо" S>>Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.
I>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.
Предсказуемый != хороший. Предсказемость результата достигается очень сильным раздутием оценок для перекрытия рисков, причем причины раздутия оценок определить весьма непросто.
Re[12]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, SkyDance, Вы писали:
I>>В скраме есть проблемы и похуже. На скраме дохнут не просто проекты, а целые конторы.
SD>Позвольте предполжить, что дохнут они не из-за скрама.
Я и говорю — когда всё хорошо, это скрам. А если сдохли, то квалификация не та или менеджмент подкачал.
