Здравствуйте, Vzhyk, Вы писали:
V>В данном случае знаю. Несколько раз на разных конторах начальство V>пыталось вводить некие метрики и они срабатывали в первый месяц-два. V>Затем программисты быстро-быстро под них подстраивались
Это понятно. Все это сто раз обсасывалось. Пришли к выводу, что мерить производительность программеров, а особенно поощрять/наказывать на основе этой производительности нельзя.
V>Это все закономерно, человек не настолько тупой (не робот) и очень V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легчеприспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать. gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.
V>Фактически, только другой человек (начальник) может быть адекватной V>метрикой другому человеку (подчиненному) и даже в этом случае люди V>подстраиваются под метрику.
Люди ошибаются, начальство не всегда компетентно в этих вопросах (именно этим я и пользуюсь работая только 3-4 часа в день), даже если оно компетентно, то должно пройти время, чтобы начальник "просчитал" человека и мог его оценивать.
По поводу резонного замечания "меньше работы за те же деньги -- лучше". Люди у нас работают, в основном, адекватные. И если их не обижать, то и они тебя не обидят. Хотя контроль, конечно же, терять нельзя.
И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над задачами проекта. То же самое я поощряю внутри команды (если человек тянет, конечно). Чем люди будут заниматься в оставшееся время меня не волнует до тех пор пока работа работается. В качестве метрики "работа работается" выступает мое "экспертное мнение" и "реакция заказчика" (мое "экспертное мнение" может тюниться в обе стороны в зависимости от реакции заказчика).
СУВ, Aikin
Re[3]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf в этой презентации Gaperton ближе к концу указал эффективный способ. G>>Самое важное тут оценивать не отдельные задачи, а готовность модуля, в том числе дизайн, разработку, тестирование, деплоймент и вплоть до поставки на production.
A>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю A>Ты это все на практике применял? Как долго? Как внедрял в команде?
Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Re[6]: Как научится определять сроки на выполнение задания / проекта
On 25.02.2013 16:23, Aikin wrote:
> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с > помощью метрик, а не объем пряников и люлей.
Это да. Причем они считают, и даже имеют некоторые практические
доказательства, что это работает. Я же с ними согласен в применимости
данного только очень похожих повторяемых задачах. В других — обычное
угадывание, называемое экспертной оценкой. И по опыту похожих
повторяемых задач в нашей области мало, обычно каждый раз разная. А если
есть повторяемые и похожие задачи, то их можно автоматизировать.
> Люди ошибаются, начальство не всегда компетентно в этих вопросах (именно > этим я и пользуюсь работая только 3-4 часа в день), даже если оно > компетентно, то должно пройти время, чтобы начальник "просчитал" > человека и мог его оценивать.
Да. Но выбора нет. Причем, начальник может прекрасно это видеть (про 3-4
часа), но есть много причин, по которым он и не требует от тебя большего.
> По поводу резонного замечания "меньше работы за те же деньги -- лучше". > Люди у нас работают, в основном, адекватные. И если их не обижать, то и > они тебя не обидят. Хотя контроль, конечно же, терять нельзя.
А тут мы попадаем в обычную физиологию. Вне зависимости от адекватности,
если человек может меньше затратить сил, то он это и сделает.
> И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над > задачами проекта. То же самое я поощряю внутри команды (если человек > тянет, конечно). Чем люди будут заниматься в оставшееся время меня не > волнует до тех пор пока работа работается.
В связи с моим замечание выше, все одно людей надо немного стимулировать
(именно "стимулом"), иначе потихоньку будут уменьшать выработку сами не
замечая этого. Если некоторая работа "приедается", можно подкинуть на
остальные 3-4 часа чего другого, более интересного подчиненному, чего с
расчетом на будущее.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, Vzhyk, Вы писали:
V>On 25.02.2013 16:23, Aikin wrote:
>> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с >> помощью метрик, а не объем пряников и люлей. V>Это да. Причем они считают, и даже имеют некоторые практические доказательства, что это работает. Я же с ними согласен в применимости данного только очень похожих повторяемых задачах. В других — обычное угадывание, называемое экспертной оценкой. И по опыту похожих повторяемых задач в нашей области мало, обычно каждый раз разная. А если есть повторяемые и похожие задачи, то их можно автоматизировать.
Я работал по скраму — раздельная оценка объема и усредненная производительность в команде действительно лучше, чем угадывание сроков. Реальных метрик, к сожалению, нет, потому что первый раз скорее интуитивно делал и работало, но проекты были простые, а сейчас хромает из-за оценки объема на сложных проектах.
Re[4]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, gandjustas, Вы писали:
A>>Ты это все на практике применял? Как долго? Как внедрял в команде? G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.
Re[5]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, avgur, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Ты это все на практике применял? Как долго? Как внедрял в команде? G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач. A>Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.
Ближе к бизнесу, деньги хорошие платят. И если уметь готовить, то сильно экономит силы.
Re[7]: Как научится определять сроки на выполнение задания / проекта
На самый главный посыл моего предыдущего сообщения ты не ответил:
V>Это все закономерно, человек не настолько тупой (не робот) и очень
V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легче приспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать.
Вот это было самое главное, остальное контекст и мои мысли по этому поводу.
СУВ, Aikin
Re[4]: Как научится определять сроки на выполнение задания / проекта
A>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю A>>Ты это все на практике применял? Как долго? Как внедрял в команде? G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Спасибо.
Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах
Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
СУВ, Aikin
Re[8]: Как научится определять сроки на выполнение задания / проекта
On 26.02.2013 17:13, Aikin wrote:
> Вот это другой вопрос. Ответ на него только неожиданный: *а с чего > бы человеку было выгоднее и легче приспосабливаться под метрику*? > Вот это было самое главное, остальное контекст и мои мысли по этому поводу.
Как только метрику начнут использовать прямо или косвенно, неважно, к
оценке труда.
И очень сложно не применить метрику так, даже когда ты оцениваешь объем
работы, основываясь на метриках, что ранее снял по таким проектам.
Я же уже не раз объяснял свое видение метрик, в програмерской работе они
не применимы, потому что у нас не конвейер, по опредлению. И даже на тех
участках работы, где появляется конвейер, он быстро заканчивается,
потому как эта работа автоматизируется тут же.
Но это моя точка зрения и не более.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Как научится определять сроки на выполнение задания / проекта
On 26.02.2013 17:13, Aikin wrote:
> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
Только, если убедишь в том, что ты хочешь внедрить топов и они будут
тебя поддерживать.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, Vzhyk, Вы писали:
>> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт? V>Только, если убедишь в том, что ты хочешь внедрить топов и они будут тебя поддерживать.
Топам можно сказать пофик. У нас почасовка. А у заказчика других проблем хватает, чтобы такой "фигней" заниматься.
Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".
Один из скилов, который хочется прокачать это оценка сроков.
V>Только, если убедишь в том,
Вообще-то теретически вариантов много и без топов: личный пример, убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и выгорит". И это только то что навскидку пришло в голову.
Я как разработчик, уже много раз сталкивался с внедрением практив без поддержки топов. У меня чаще всего прокатывает "личный пример".
СУВ, Aikin
Re[7]: Как научится определять сроки на выполнение задания / проекта
On 26.02.2013 17:53, Aikin wrote:
> Топам можно сказать пофик. У нас почасовка. А у заказчика других проблем > хватает, чтобы такой "фигней" заниматься. > Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает > текущее положение. В котором у меня есть свободное время и я "хочу > что-то улучшить". > Один из скилов, который хочется прокачать это оценка сроков.
Пойми, что как только ты начнешь народ вокруг напрягать, получишь
сопротивление и чем сильне напрягать будешь,тем больше сопротивление
будет. И фактически единственный способ его сломать, или хотя бы
уменьшить — это дополнительное давление с самого верха.
Например, простейший TDD я внедрял таким образом и убеждением и
давлением со стороны топа.
> Вообще-то теретически вариантов много и без топов: личный пример, > убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и > выгорит". И это только то что навскидку пришло в голову.
Можно, но затраты личной энергии бешенные. Ибо в этом случае нужно
каждого убеждать, уговаривать, ублажать и т.д.
> Я как разработчик, уже много раз сталкивался с внедрением практив без > поддержки топов. У меня чаще всего прокатывает "личный пример".
Ты бы лучше свою энергию по делу применил и начал свое что продвигать, а
не на дяде кошелек пополнять. Личная энергия — это все.
А с возрастом ее все меньше и меньше будет.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю A>>>Ты это все на практике применял? Как долго? Как внедрял в команде? G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач. A>Спасибо. A>Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах
A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
А чего конкретно хочется добиться? И чем занимаетесь?
V>В данном случае знаю. Несколько раз на разных конторах начальство V>пыталось вводить некие метрики и они срабатывали в первый месяц-два. V>Затем программисты быстро-быстро под них подстраивались уменьшая V>внимание непосредственной работе. Еще через 4 месяца начальство забивало V>на это, ибо по мертикам все красиво, а выхлоп меньше становился.
И как начальство замечало это самое "выхлоп меньше становился"? Стало быть, у начальства таки есть вполне конкретные метрики "выхлопа". Просто в силу каких-либо причин начальство не в состоянии их квантифицировать и формализовать.
Или, как вариант, начальство руководствуется не реальным "выхлопом", а неким своим иллюзорным восприятием действительности. В таком варианте никакие метрики не помогут, т.к. начальство продолжит думать "обманывают, опять обманывают!" — и это не проблема метрик, а проблема доверия руководства к сотрудникам (почти всегда обоюдная).
Re[6]: Как научится определять сроки на выполнение задания / проекта
A>gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.
Хочу немножко поправить, идеи сии сформулированы отнюдь не уважаемыми участниками форума, но задолго до них. Собственно, эти идеи и легли в основу Agile-процессов.
Re[7]: Как научится определять сроки на выполнение задания / проекта
V>Это да. Причем они считают, и даже имеют некоторые практические V>доказательства, что это работает. Я же с ними согласен в применимости V>данного только очень похожих повторяемых задачах. В других — обычное V>угадывание, называемое экспертной оценкой. И по опыту похожих V>повторяемых задач в нашей области мало, обычно каждый раз разная. А если V>есть повторяемые и похожие задачи, то их можно автоматизировать.
Совершенно справедливо считать, что это работает. Дело в том, что (вопреки мнению некоторых даже достаточно опытных программистов) подавляющее большинство проектов по разработке ПО является повторяемыми задачами. Кроме, возможно, research-команд. В той же Microsoft очень пиарят эти команды, но мне сложно оценить как их устройство, так и пользу от их работы. Но это именно что капля в море.
Возможно, в силу недостатка опыта, можно считать, что "задачи каждый раз разные". Но это не так, задача каждый раз одинаковая — реализовать то-то и то-то вот в таких условиях. Причем чаще всего решений подобной проблемы существует несколько, требуется лишь выбрать одно. И выбор этот зачастую случаен. По принципу "из двух зол выбирай то, которое еще не пробовал".
С накоплением стажа и опыта участия в разной деятельности понимание схожести задач обязательно приходит.
Re[5]: Как научится определять сроки на выполнение задания / проекта
A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
С моей стороны могу лишь дать одну рекомендацию: не торопиться. Не добавлять ни одну новую практику до тех пор, пока старые не вошли в привычку, не стали рафинированными и удобными для всех членов команды. Как пример: если вы решили вести учёт часов, потраченных на решение тикета в саппорт-системе, не внедряйте новые практики до тех пор, пока эта не будет принята и используема всеми. Например, вам может потребоваться интеграция тикет-системы с системой версионного контроля, чтобы разработчик, выполняя commit (push, иное публикационное действие), мог не только автоматически закрывать (передавать в тестирование, ...) тикет, но и указывать количество потраченного времени, скажем, тегом в commit message.
Потому как если начинается "мы наш, мы новый мир построим" — это 100% гарантия натолкнуться на стену непонимания, неприятия и необходимость применения административных мер.
Re[7]: Как научится определять сроки на выполнение задания / проекта
A>Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".
Это не самая удачная причина для внедрения каких бы то ни было практик. Возможно, вам следует сменить должность на что-нибудь более подходящее вашим интересам. Потому как работодателю обычно интересна не "прокачка скиллов на рабочем месте", а выполнение проектов в срок и без сбоев.
Может, попробуете уговорить руководство официально оформить вас как, например, "советника по процессам", дабы ваши рекомендации могли иметь некий вес и смысл. И не выглядели как инициатива по изучению чего-то нового, но на работе не нужного.
Re[2]: Как научится определять сроки на выполнение задания / проекта
Здравствуйте, gandjustas, Вы писали:
G>Personal Software Process — несколько книг в открытом доступе. Но без курсов "не взлетит".
G>Краткая выжимка из PSP и опыта. G>Чтобы научиться прогнозировать срок надо отделить оценку объема от оценки срока.
G>Объем должен считаться формально, то есть должен учитывать конкретные параметры. Например количество строк кода или количество "входов" и "выходов" модуля, помноженное на коэффициент сложности для типа модуля. Единица измерения не важна, главное чтобы она была одинаковая в команде.
Посоветуй пожалуйста, конкретные книги по Personal Software Process. Наиболее ценные на твой взгляд.
Если читать все подряд что попадается в интернет, то до сути долго придется добираться...
Желательно на русском. Хотя и на английском могу читать. Но на русском читаю быстрее