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

A>Какими методами пользуются чтобы ее оценить?
A>часами мерять — глупо. строками кода — еще глупее (я если захочу могу тот же самый код в 3 раза длиннее написать)

Что касается планирования, то я примерно прикидываю трудоемкость в количестве форм/отчетов для программ с UI или функционально законченных модулей (т.е. которые выполняют конечную задачу, достаточно мелкую, от процесса получения входных воздействий до момента получения отчета о завершении) в серверных приложениях.

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

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

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

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

A>дабы отчитаться перед вышестоящим начальством за всю команду

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

Дисклаймер(на всякий случай): в каждой компании могут быть свои цели, я не претендую на истину, всё выше было просто моим мнением

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

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

Этот вопрос уже не раз обсуждался в форуме "Управление проектами".

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

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

Часами мерять и в самом деле глупо.
"8 часов в день" — действительная глупая метрика про продуктивность программера.

А вот сроки кода реально используют.
http://en.wikipedia.org/wiki/Source_lines_of_code

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

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

Чтобы можно бы делать прогноз хоть на чем то основанный, а не просто "best engineering guess". У человека каждый день разная производительность, но если брать за довольно большой промежуток времени — эта величина довольно стабильна. Если конечно он работает, а не фигней страдает.

AJD>Чтобы можно бы делать прогноз хоть на чем то основанный, а не просто "best engineering guess". У человека каждый день разная производительность, но если брать за довольно большой промежуток времени — эта величина довольно стабильна. Если конечно он работает, а не фигней страдает.

есть, конечно, такая наука software estimation, но она скорее для обезличенной оценки, поэтому это тут врядли сработает. Да и вообще, например, когда я с Windows Security разобрался я добавляю фичу в лёт, но когда мне нужно было сделать что-то с AD занимало недели. Получается есть ещё одна переменная — область знаний. Можно пойти дальше мне не нравится UI делать — посему делаю его медленно, но нравится системное — быстро, разница в разы. Если же задача включает исследования, оценить её вообще не возможно (см. МакКонел Rapid Development)

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


D>есть, конечно, такая наука software estimation, но она скорее для обезличенной оценки, поэтому это тут врядли сработает. Да и вообще, например, когда я с Windows Security разобрался я добавляю фичу в лёт, но когда мне нужно было сделать что-то с AD занимало недели. Получается есть ещё одна переменная — область знаний. Можно пойти дальше мне не нравится UI делать — посему делаю его медленно, но нравится системное — быстро, разница в разы. Если же задача включает исследования, оценить её вообще не возможно (см. МакКонел Rapid Development)

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