Ну походу ты меня точно нет. Я говорил о том, что из за того что вариации в разработке ПО очень большие, то смыла оценивать прозводительность отдельного разработчика нет, с таким же успехом можно кубики подкидывать, кстати точнее будет. И это основано на эксперементальных данных.  Для этого карточку и привел.

Но менеджерам удобнее думать в разрезе людей. Скорее проще...

А мне как процеснику, этот стиль мышления мешает оптимизировать бизнес процессы таким образом, что бы компания получала МАКСИМУМ  прибыли.

Мне важно что бы скорость генерации дохода была ровной и желательно повышалась, издержки были ровными или уменьшались. А связанный капитал, ну не будем о грустном.

Хотя, я думаю мы друг друга поняли :)

Ну как бы ставка часа или зп/мес у разработчиков зависит от производительности, а производительность от экспы. Они же не одинаково в компании получают и нужны метрики, чтобы вовремя повышать зп, до того как сотрудник пришел к начальнику с просьбой о повышении или бумагой об увольнении. Хотя есть компании, где сколько договорился на собеседовании столько и получаешь - но это бессистемный подход, где еще в нарушение закона запрещают рассказывать о зарплате.

Вы подключились к спору в котором я показывал, что измерять производительность человека или пары программистов в парном программировании важно (а не бессмысленно). И сделали в нем такое утверждение: "Тебе что важно выработка или результат?

Если же нужен результат, то первое, выкидывает тайм шиты в пропасть или говоришь заказчику, что они будут генериться автоматически. А вот мы с тобой займёмся результатами,  и начинаешь с постановки реестра задач.

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

Тут вам приведут аргумент что "в agile людям платят за то, что они стараются". И иногда это очень правильный подход. А иногда он просто не работает (особенно в незрелых командах или некоторых отраслях).

Если речь идет только о парном программировании - то это частный случай, мы не меряли производительность (в скраме). Пара же образуется не постоянно, а на критически важных задачах, особенно на ядрах системы с двумя сильными программистами. И это пара не одни и те же люди постоянно. Еще мы применяли парное программирование, чтобы ввести не особо сильного человека в команду, чтобы поднять его уровень, да получается в этот момент неэффективно, поскольку он не настолько знаком со структурой и фреймворком проекта, но в будущем это дает сильный результат.

Ага. Этим постом я Сергею отвечал. Не поставил цитату, сори. В вашем случае - да, непонятно зачем оценивать производительность пары которая собралась ненадолго с благими намерениями (типа помочь новичку). Тут измерения могут и навредить (профи начнет подгонять новичка, мол, давай, навались, а то у нас скорость низкая).

Тоже не сдержусь.
В Канбане основные метрики не персональные, но процессные и сервисные.
Канбан - не аджайл 😉, он манифесту не стремится соответствовать. Хотя и не отвергает его, если от этого есть польза

Так, давайте будем точнее. Канбан метод не agile. А то я вам сейчас Agile roadmap от Delloite в пример приведу. Про метрики уже обсуждали мантры выше (филологически вы правы). С точки зрения закона Литтла и wip лимитов хотелось бы услышать внятный ответ. Что у вас на практике в колонках на канбан доске в канбан системе? Уж не измеряем ли вы де факто скорость, корректируя  wip лимит? Вот конкретно, а не абстарктно про "накопление знаний доминирующей активности" (Википедию можем цитировать), вопрос реальной практики здесь и сейчас)  :)))

В "Agile roadmap от Delloite" запихнут даже Деминг 😉
Канбан метод - не аджайл, об этом договорились, и это здорово.

Коррекцией wip лимита в колонках мы изменяем скорость, а не измеряем ее. Измеряем мы время цикла и время поставки.

Если говорить конкретно про сервис, которым я прямо сейчас занимаюсь, то для него (увы) важнее четкое попадание в заранее обозначенную дату, чем просто скорость. От этого и пляшем.

Раз уж тут про лимиты и ограничения зашла речь,  то Дмитрйи Егров недавно заметку краткую написал про Барабан-Буфер-Канат

http://egorovde.ru/archives/8333

"В agile roadmap от Delloite запихнут даже Деминг" ну и? И даже waterfall. Так что стоит быть осторожнее с суждениями "что есть agile". Канбан метод сам себя от "agile" отстраивает (понятно почему), можем верить ему на слово. Ну других объективных критериев нет. Или нужно быть готовым спорить с Deloitte.

"Коррекцией wip лимита в колонках мы изменяем скорость, а не измеряем ее. Измеряем мы время цикла и время поставки." Ага.  Нажимая на педаль газа мы меняем скорость, а не измеряем ее. А почему мы стали жать на педаль газа? Что нас подтолкнуло корректировать wip лимит конкретной "колонки"? На что мы ориентировались задавая wip-лимит изначально? То-то! :)

Изначально мы ориентировались на "то, что есть сейчас", задав лимиты по актуальной ситуации.
Дальше мы меняем их для того, чтобы снижать очереди перед узкими звеньями, направляя освобождающиеся силы на расширение узких мест.
Контролируем по времени цикла и времени поставки и другим SLA сервиса, если они есть и важны.

Коллеги, добрый день! Вопрос не профильный, но вы часто работаете с аналитиками =)

Собираю статистику и информацию по использованию систем управления требованиями (СУТ) аналитиками в своих проектах.

Прошу ответить на несколько вопросов.

Переслылайте данный опрос, как можно большему количеству специалистов, больше респондентов лучше статистика! =)

https://forms.gle/ZeV2YQeZJDXYNAhR6

Коллеги, в связи попыткой смешать роль РП и Хозяина Скрама я заметку  написал про роли и их цели и задачи


https://www.facebook.com/groups/spbspm/permalink/3654330134582716/

обсудим?

Манифест со скрам-гайдом перепутаны.  

Наброс хорош. Надо в группы закинуть, собрать отзывы от упомянутых ролей.

Можно и без английского, есть перевод скрам гайда на русский

По мне так толстовато

Особенно про не повышение доходности компании

Ну про манифест ничего нету ;) просто найм на Должность хозяина скрама стала часто попадаться.

Я не верю русской версии, как минимум из-за отсутствия перевода роли. Без него смысл теряется.