Комментарии 46
Однако пытаться при помощи метрик ускорять сам процесс разработки не стоит, по причине отсутствия годных метрик.
Это одно из больших заблуждений, потому что именно метрики заложены в подходе #noestimate и именно этот подход дает возможность ускорить процесс разработки за счет снижения вариаций. Собственно ради этого все и затевается.
С помощью метрик находите узкое звено, оптимизируете его загрузку, радуетесь баблу.
Находить узкие места и оптимизировать можно и без метрик. Метрики, конечно, очень удобны. Но они ведь не являются непременным условием для улучшений
Я не думаю, что получится оптимизировать узкие места. Я более чем уверен, что даже найти не получится, потому как использовать здравый смысл при разработке ПО, та еще идея.
И да метрики являются необходимыми и достаточными, без изменения трех основных вы даже не поймете, делаете вы хуже или лучше.
А мокрый пальчик, такой себе индикатор
И да метрики являются необходимыми и достаточными, без изменения трех основных вы даже не поймете, делаете вы хуже или лучше.
А мокрый пальчик, такой себе индикатор
А может просто признать что задача найти эти магические метрики не имеет решения и сосредоточится на чём-то другом?
Пусть это будет одна из задач тысячелетия типа равенства классов P и NP на которую не найдено решение.
Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству. Значит, есть какие-то существенные отличия, и значит, улучшения должны быть возможны.
Например, они тратят больше денег. И что нам с того, если у нас столько нет? Более того, возможно трата лишних денег не входит в наши цели, и будет для нас неприемлема.
На самом деле, вопрос скорее стоит так — если нет метрики, то вы не можете узнать, как подействовали ваши изменения. Стало ли лучше, или хуже. А так-то конечно, поменять что-нибудь можно всегда, и иногда даже может получиться хорошо. Но проблема в том, что стабильно добиться улучшения таким способом нельзя, так как вы давите на газ, а спидометр еще не придумали.
Узкие места расширить? А откуда вы знаете, где они, если мерять не умеете?
можно ли наладить отношения со своей женой (или родителями, или еще с кем) не имея метрик? А откуда вы знаете, что стало лучше, если метрик нет?
А откуда вы знаете, что такие же действия позволят наладить отношения с другим человеком?
так я и не говорю что одни и те же подходы везде сработают. Я только говорю что метрики не являются обязательным условием для улучшения
При улучшении отношений с людьми обратная связь, как ни странно, существует, но только не в виде циферок. А в виде «стало лучше», «стало хуже». Т.е. результат изменений все-же как-то, но измеряется. Шкала с двумя отметками конечно так себе, но почему вы считаете, что это вообще не метрика?
так конечно, обратная связь есть, я как раз это и пытался доложить :) Но измерений при этом нет, а есть только субъективные оценки, типа, «кажется, стало получше». Можно, конечно, расширить определение метрики и до субъективных неизмеряемых оценок тоже, но мне кажется под «метриками» большинство людей все же понимают что-то измеряемое
Я думаю это просто разный взгляд на вещи. Измерения бывают количественные и качественные (экспертные оценки). Я бы просто считал, что всегда есть хоть какая-то, но метрика. Возможно, плохая (в математическом смысле).
Ну просто потому, что если ее вообще нет, то вот эта ваша фраза: «Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству» — она же просто не имеет смысла. Если мы не умеем мерять время и качество — то откуда мы вообще взяли, что кто-то выпускает софт быстрее, и без потери? Что-то же мы сравниваем? Значит у нас есть метрика, для которой определена как минимум операция >.
Ну просто потому, что если ее вообще нет, то вот эта ваша фраза: «Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству» — она же просто не имеет смысла. Если мы не умеем мерять время и качество — то откуда мы вообще взяли, что кто-то выпускает софт быстрее, и без потери? Что-то же мы сравниваем? Значит у нас есть метрика, для которой определена как минимум операция >.
окей, давайте использовать слово «экспертные оценки». Та фраза являлась примером качественной экспертной оценки, то есть без цифр, но на основании чьего-то субъективного мнения
С финальным продуктом дело проще — в рыночной экономике, общая прибыль от продажи продукта вполне можно считать мерой качества. А вот когда вы руководите командой программистов, и нельзя каждого выставить на рынок, то тут все неоднозначно
А когда вы руководите командой разработчиков кружек, можно ли выставить на рынок отдельно взятого разработчика ручки для кружек и замерить изменения? Автор статьи нам говорит, что в производстве кружек это сделать легко — не то что в программировании.
Если дело идет о дизайне кружек, то там возможно все те же проблемы, что и у программистов и рынок действительно нужен. Если же творческая компонента отсутствует, то рынок оценивает человека по тем же характеристикам (например, процент брака) которые директор завода и сам может померить. И тогда на рынок выставлять не обязательно.
Речь может идти не только о дизайне кружки, а о её функциональности или, например, довнесения в этот простой бытовой предмет какой-либо инновационности. «Программисты ежедневно решают сложные творческие задачи», а производители кружек, по мнению автора, просто считают прибыль.
в рыночной экономике, общая прибыль от продажи продукта вполне можно считать мерой качества.
Каким образом, если продажи некачественного продукта вполне себе могут приносить бОльшую прибыль, чем продажи качественного?
В сильно краткосрочной перспективе, так может быть. Но это все-таки единичные случае, особенно в развитых странах. Под некачественный продукт вам вряд ли дадут финансирование инвесторы
Как в данном случае инвесторы будут оценивать качество продукта, с помощью каких метрик, ведь показателей прибыли от продажи продукта для оценки качества у них на тот момент не будет?
Для этого — для оценивания качества — нужен талант, и он хорошо оплачивается. Если бы можно было бы четко прописать «как будут оценивать», то это бы стало механической работой которую могло бы делать много людей
Это вовсе не подтверждает верность утверждения, что о качестве продукта можно судить по показателям его прибыльности. В конце концов, прибыль от книг Дарьи Донцовой сильно выше, чем прибыль от продаж «Войны и мира» Льва Толстого. И инвесторы Донцовой дадут, а Толстому — нет. При этом второй имеет господдержку в силу того, что входит в школьную программу и его вынуждены покупать всё новые поколения школьников.
Да, значит качество у Донцовой выше. Мы этом треде ведем разговор про бизнес, value, и т.д., а не про ценность искусства и «широкие эпические полотна»
Автор в статье ссылается как раз на «ценность» и «полезность», игнорируя прибыльность от продаж (как метрику) разрабатываемого программного обеспечения.
Не согласен. Если бы один программист делал один программный продукт, то прибыльность была ба отличной метрикой ценности. Как я понял, автор говорит о КОМАНДЕ которая работает над одним продуктом.
Автор говорит о метриках, которыми можно было бы оценивать труд программиста (см. его отсылку к оценке зарплат) с точки зрения привнесённой им «пользы», сознательно игнорируя возможные способы оценки этой пользы в том числе и с привлечением экспертизы. В этих экспертизах к достаточному широкому списку оценочных параметров дополнительно применяют их вес, давая отдельную оценку — почему именно такой вес был применён.
Как по мне, то, очевидно, следует мерить не процесс, а его результат — ПО. Как мерить ПО уже все давно знают, остаётся вопрос как делить ответственность между командой. И вот тут встаёт проблема коммунизма, равенства, братства. Как её решить? Перестать выделять отдельные личности в команде и рассматривать её как функциональную единицу. Но в таком случае приходится заранее договариваться о доли в капитале. И вот мы уже подошли к работе как инвестиции личных ресурсов вместо продажи личного времени, но это уже отдельная тема, этой стране до неё как до Луны…
Как мерить ПО уже все давно знают
а как именно, например?
Если производим под конечного потребителя:
Crash-free users/sessions
Retention, MAU, DAU
Revenue per User (если через ПО что-то продаётся)
Рейтинги в магазинах приложений
Если софт «сферический в вакууме» — есть метрики про code quality, и в конце концов (прости Ктулху) всякие test coverage.
Да «тыщи их»)
часы в освоенном обьеме вполне годно дает метрики в часах.
да и в вашей статье это расклад ничего негативного не дает кроме цены! а вы против платить много за быстро и качественно?
статья выглядит натянутой на глобус, чтобы обьяснить начальнику почему ты не оцениваешь задачи и вообще «творческая личность»
оставьте в покое науку и берите паттерны, шаблоны и плите код!
что, работать не нравится, да?
лучше будем продавать что-то для «улучшения коммуникаций»))
Мда. На самом деле, хотелось бы «контр-статью».
Более опытный программист обычно понимает цену коду, написанному менее опытным коллегой. Устный экзамен даёт преподавателю исчерпывающую картину знаний студента. Что касается учёных, все они имеют адекватное представление о способностях и продуктивности труда своих коллег. По крайней мере в той части, что доступна их собственному пониманию.
Экспертная оценка субъективна, но пока что это самое точное, что у нас есть. Однако, раз мозг человека может решать задачу экспертной оценки — значит, есть надежда построить и автомат, дающий оценку сравнимого качества и без субъективности.
Допустим, нужно оценить коммит программиста. Как это сделать? Я бы действовал примерно так:
1) Понять цель, зачем вносились изменения. Чего хотел добиться автор? При необходимости — расспросить. Соотнести эту цель с актуальными задачами коллектива.
2) Оценить, достигнута ли цель. Решил ли автор задачу, за которую брался? Привело ли это к задуманным улучшениям продукта? Стал ли код чище, лаконичнее, понятнее?
3) Оценить сложность решённых автором задач. Какие трудности он преодолевал? Какого масштаба изобретательность или знания требовались для этого?
4) Оценить внимательность и дальновидность автора, насколько далеко он заглядывал вперёд, просчитывая последствия своих действий? Какие потенциальные будущие проблемы решил?
5) Допустил ли автор явные ошибки? Использовал ли он заведомо неэффективный подход из-за недостатка квалификации? Или, наоборот, показал невиданные доселе трюки?
6) Есть ли несоответствия продукта принятым на фирме стандартам качества программной продукции на данном этапе её производства?
7) Учесть объём проделанной работы (количество изменений)
8) Учесть затраченное время
Может, и ещё что-то учесть можно, сейчас не приходит в голову.
Вот, если какие-нибудь автоматы, адекватно оценивающие элементы работы программистов по приведённым выше критериям 1-6 будут созданы — тогда можно будет говорить про метрики.
Экспертная оценка субъективна, но пока что это самое точное, что у нас есть. Однако, раз мозг человека может решать задачу экспертной оценки — значит, есть надежда построить и автомат, дающий оценку сравнимого качества и без субъективности.
Допустим, нужно оценить коммит программиста. Как это сделать? Я бы действовал примерно так:
1) Понять цель, зачем вносились изменения. Чего хотел добиться автор? При необходимости — расспросить. Соотнести эту цель с актуальными задачами коллектива.
2) Оценить, достигнута ли цель. Решил ли автор задачу, за которую брался? Привело ли это к задуманным улучшениям продукта? Стал ли код чище, лаконичнее, понятнее?
3) Оценить сложность решённых автором задач. Какие трудности он преодолевал? Какого масштаба изобретательность или знания требовались для этого?
4) Оценить внимательность и дальновидность автора, насколько далеко он заглядывал вперёд, просчитывая последствия своих действий? Какие потенциальные будущие проблемы решил?
5) Допустил ли автор явные ошибки? Использовал ли он заведомо неэффективный подход из-за недостатка квалификации? Или, наоборот, показал невиданные доселе трюки?
6) Есть ли несоответствия продукта принятым на фирме стандартам качества программной продукции на данном этапе её производства?
7) Учесть объём проделанной работы (количество изменений)
8) Учесть затраченное время
Может, и ещё что-то учесть можно, сейчас не приходит в голову.
Вот, если какие-нибудь автоматы, адекватно оценивающие элементы работы программистов по приведённым выше критериям 1-6 будут созданы — тогда можно будет говорить про метрики.
Не поверишь, есть это все давно и обычно этим занимаются QA спецы.
Хороший комментарий. Если есть возможность, как у ученых, постоянно читать работы своих коллег, то с качеством все понятно. Но ученых десятки тысяч, и читать работы ученых которые не входят в некий топ просто нет времени. А карьерные решения по ним принимать тем не менее надо. И для этого придумывают метрики, и эти ученые занимаются хакингом этих метрик.
Прокомментирую со стороны учёных. Даже если читать все работы какие можно, всё равно остаётся проблема оценки. Я могу посчитать какую-то статью слабой, а мой коллега (тоже доктор наук по той же самой специальности) — наоборот, решит что это прекрасная публикация. Т.е. при экспертной оценке добавляется проблема — кто и как оценивает экспертов?
Да, можно пытаться и учитывать мнение экспертов и формальные показатели — это типичная ситуация при подаче заявок на грант, когда есть формальные требования к руководителю и коллективу (включая число публикаций в изданиях определённого уровня), и плюс к этому несколько экспертов оценивают саму заявку. Но решать подобную задачу массово нереально
Да, можно пытаться и учитывать мнение экспертов и формальные показатели — это типичная ситуация при подаче заявок на грант, когда есть формальные требования к руководителю и коллективу (включая число публикаций в изданиях определённого уровня), и плюс к этому несколько экспертов оценивают саму заявку. Но решать подобную задачу массово нереально
Экспертная оценка субъективна, но пока что это самое точное, что у нас есть
полностью согласен. После этого комментария и еще нескольких выше я понял, что в статье не хватало упоминания субъективных экспертных оценок. Поэтому могло создаваться впечатление, что я как будто предлагаю совсем отказаться от любых попыток что-то оценивать. Конечно, нет. Добавил очень короткое упоминание об этом в последний абзац статьи.
За день программист может сделать несколько комитов. Как вы себе представляете работу эксперта, который оценивает каждый коммит по 8 критериям? Я это к тому, что время эксперта по определению дороже времени программиста, поскольку он более квалифицированный программист. Соответственно, задача экспертной оценки конечно же решаема, но далеко не всегда игра стоит свеч. Например, в качестве менторства над молодым перспективным сотрудником есть смысл.
>2) Оценить, достигнута ли цель.
Вот даже это уже обычно далеко не тривиальная задача. Ну в смысле не это одно, а любой из пунктов, пожалуй.
Вот даже это уже обычно далеко не тривиальная задача. Ну в смысле не это одно, а любой из пунктов, пожалуй.
Практически день в день в The Overflow Blog: https://stackoverflow.blog/2020/12/07/measuring-developer-productivity/.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему не стоит пытаться ускорять разработку при помощи метрик