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

V>В данном случае знаю. Несколько раз на разных конторах начальство
V>пыталось вводить некие метрики и они срабатывали в первый месяц-два.
V>Затем программисты быстро-быстро под них подстраивались
Это понятно. Все это сто раз обсасывалось. Пришли к выводу, что мерить производительность программеров, а особенно поощрять/наказывать на основе этой производительности нельзя.

V>Это все закономерно, человек не настолько тупой (не робот) и очень
V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легче приспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать.
gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.


V>Фактически, только другой человек (начальник) может быть адекватной
V>метрикой другому человеку (подчиненному) и даже в этом случае люди
V>подстраиваются под метрику.
Люди ошибаются, начальство не всегда компетентно в этих вопросах (именно этим я и пользуюсь работая только 3-4 часа в день), даже если оно компетентно, то должно пройти время, чтобы начальник "просчитал" человека и мог его оценивать.


По поводу резонного замечания "меньше работы за те же деньги -- лучше". Люди у нас работают, в основном, адекватные. И если их не обижать, то и они тебя не обидят. Хотя контроль, конечно же, терять нельзя.
И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над задачами проекта. То же самое я поощряю внутри команды (если человек тянет, конечно). Чем люди будут заниматься в оставшееся время меня не волнует до тех пор пока работа работается. В качестве метрики "работа работается" выступает мое "экспертное мнение" и "реакция заказчика" (мое "экспертное мнение" может тюниться в обе стороны в зависимости от реакции заказчика).

СУВ, Aikin

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

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

G>>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf в этой презентации Gaperton ближе к концу указал эффективный способ.
G>>Самое важное тут оценивать не отдельные задачи, а готовность модуля, в том числе дизайн, разработку, тестирование, деплоймент и вплоть до поставки на production.

A>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>Ты это все на практике применял? Как долго? Как внедрял в команде?
Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.

On 25.02.2013 16:23, Aikin wrote:

> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с
> помощью метрик, а не объем пряников и люлей.
Это да. Причем они считают, и даже имеют некоторые практические
доказательства, что это работает. Я же с ними согласен в применимости
данного только очень похожих повторяемых задачах. В других — обычное
угадывание, называемое экспертной оценкой. И по опыту похожих
повторяемых задач в нашей области мало, обычно каждый раз разная. А если
есть повторяемые и похожие задачи, то их можно автоматизировать.

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

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

> И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над
> задачами проекта. То же самое я поощряю внутри команды (если человек
> тянет, конечно). Чем люди будут заниматься в оставшееся время меня не
> волнует до тех пор пока работа работается.
В связи с моим замечание выше, все одно людей надо немного стимулировать
(именно "стимулом"), иначе потихоньку будут уменьшать выработку сами не
замечая этого. Если некоторая работа "приедается", можно подкинуть на
остальные 3-4 часа чего другого, более интересного подчиненному, чего с
расчетом на будущее.

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

V>On 25.02.2013 16:23, Aikin wrote:

>> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с
>> помощью метрик, а не объем пряников и люлей.
V>Это да. Причем они считают, и даже имеют некоторые практические доказательства, что это работает. Я же с ними согласен в применимости данного только очень похожих повторяемых задачах. В других — обычное угадывание, называемое экспертной оценкой. И по опыту похожих повторяемых задач в нашей области мало, обычно каждый раз разная. А если есть повторяемые и похожие задачи, то их можно автоматизировать.
Я работал по скраму — раздельная оценка объема и усредненная производительность в команде действительно лучше, чем угадывание сроков. Реальных метрик, к сожалению, нет, потому что первый раз скорее интуитивно делал и работало, но проекты были простые, а сейчас хромает из-за оценки объема на сложных проектах.

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

A>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.

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

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

A>>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
A>Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.
Ближе к бизнесу, деньги хорошие платят. И если уметь готовить, то сильно экономит силы.

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

На самый главный посыл моего предыдущего сообщения ты не ответил:

V>Это все закономерно, человек не настолько тупой (не робот) и очень
V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легче приспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать.

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

СУВ, Aikin

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


A>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Спасибо.
Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах

Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

СУВ, Aikin

On 26.02.2013 17:13, Aikin wrote:

> Вот это другой вопрос. Ответ на него только неожиданный: *а с чего
> бы человеку было выгоднее и легче приспосабливаться под метрику*?
> Вот это было самое главное, остальное контекст и мои мысли по этому поводу.
Как только метрику начнут использовать прямо или косвенно, неважно, к
оценке труда.
И очень сложно не применить метрику так, даже когда ты оцениваешь объем
работы, основываясь на метриках, что ранее снял по таким проектам.

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

On 26.02.2013 17:13, Aikin wrote:

> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
Только, если убедишь в том, что ты хочешь внедрить топов и они будут
тебя поддерживать.

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

>> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
V>Только, если убедишь в том, что ты хочешь внедрить топов и они будут тебя поддерживать.
Топам можно сказать пофик. У нас почасовка. А у заказчика других проблем хватает, чтобы такой "фигней" заниматься.
Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".
Один из скилов, который хочется прокачать это оценка сроков.


V>Только, если убедишь в том,
Вообще-то теретически вариантов много и без топов: личный пример, убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и выгорит". И это только то что навскидку пришло в голову.
Я как разработчик, уже много раз сталкивался с внедрением практив без поддержки топов. У меня чаще всего прокатывает "личный пример".

СУВ, Aikin

On 26.02.2013 17:53, Aikin wrote:

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

> Вообще-то теретически вариантов много и без топов: личный пример,
> убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и
> выгорит". И это только то что навскидку пришло в голову.
Можно, но затраты личной энергии бешенные. Ибо в этом случае нужно
каждого убеждать, уговаривать, ублажать и т.д.

> Я как разработчик, уже много раз сталкивался с внедрением практив без
> поддержки топов. У меня чаще всего прокатывает "личный пример".
Ты бы лучше свою энергию по делу применил и начал свое что продвигать, а
не на дяде кошелек пополнять. Личная энергия — это все.
А с возрастом ее все меньше и меньше будет.

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

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


A>>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
A>Спасибо.
A>Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах

A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

А чего конкретно хочется добиться? И чем занимаетесь?

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

RH> Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.

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

V>В данном случае знаю. Несколько раз на разных конторах начальство
V>пыталось вводить некие метрики и они срабатывали в первый месяц-два.
V>Затем программисты быстро-быстро под них подстраивались уменьшая
V>внимание непосредственной работе. Еще через 4 месяца начальство забивало
V>на это, ибо по мертикам все красиво, а выхлоп меньше становился.

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

A>gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.

Хочу немножко поправить, идеи сии сформулированы отнюдь не уважаемыми участниками форума, но задолго до них. Собственно, эти идеи и легли в основу Agile-процессов.

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

Совершенно справедливо считать, что это работает. Дело в том, что (вопреки мнению некоторых даже достаточно опытных программистов) подавляющее большинство проектов по разработке ПО является повторяемыми задачами. Кроме, возможно, research-команд. В той же Microsoft очень пиарят эти команды, но мне сложно оценить как их устройство, так и пользу от их работы. Но это именно что капля в море.
Возможно, в силу недостатка опыта, можно считать, что "задачи каждый раз разные". Но это не так, задача каждый раз одинаковая — реализовать то-то и то-то вот в таких условиях. Причем чаще всего решений подобной проблемы существует несколько, требуется лишь выбрать одно. И выбор этот зачастую случаен. По принципу "из двух зол выбирай то, которое еще не пробовал".
С накоплением стажа и опыта участия в разной деятельности понимание схожести задач обязательно приходит.

A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

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

Потому как если начинается "мы наш, мы новый мир построим" — это 100% гарантия натолкнуться на стену непонимания, неприятия и необходимость применения административных мер.

A>Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".

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

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

G>Personal Software Process — несколько книг в открытом доступе. Но без курсов "не взлетит".

G>Краткая выжимка из PSP и опыта.
G>Чтобы научиться прогнозировать срок надо отделить оценку объема от оценки срока.

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

Посоветуй пожалуйста, конкретные книги по Personal Software Process. Наиболее ценные на твой взгляд.
Если читать все подряд что попадается в интернет, то до сути долго придется добираться...
Желательно на русском. Хотя и на английском могу читать. Но на русском читаю быстрее