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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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