Я думаю, что ваша идея брать прогноз вполне здравая, но датчик температуры, встроенный в поверхность, поможет не тратить на нагрев больше, чем необходимо.
По скрамовски - это поднять этот вопрос на ретро. Где один из вариантов - уменьшить длину спринта.
Не по скрамовски - забить.
Но если покопаться, то в типичном Scrum-like проекте атомарной задачей на 2 дня делают типа добавить кнопку на фронте, после чего фронтендер отдыхает, пока бэкендер доделает свою часть, девопс поставит релиз, а тестировщик протестирует. Ах да, кнопке на фронте предшествует еще правка макета и требований, пока их не будет, фронтендер не начнет работу.
RnD задачи разбиваются не полностью на мелкие атомарные части, а только выделяются те части, которые можно взять в ближайший спринт. Перед следующим спринтом задача целиком пересматривается и делается следующее выделение. Зачастую то, что вы делали в предыдущем спринте, полностью выбрасывается, и это нормально, поскольку в этот момент вы лучше понимаете, что надо делать, чтобы вывести фичу.
Вот как-то так сейчас выглядит и айти, и любой рекрутинг квалифицированных специалистов. Дефицит кадров ужасный, потому что вот эта "очередь за забором" состоит из лиц, идентифицирующих себя как специалистов, но на деле они даже на младшего стажера не тянут.
Полагаю, что в тысяче откликов на входе воронки были, как минимум, достаточно квалифицированные водители. Но их отсеяли "с диким трудом, смехом и матами", потому что они не подошли "по формальным признакам".
Иногда мне кажется, что шутки о том, что руководство внедряет Agile, чтобы успеть больше при меньших затратах, не так уж и далеки от истины
Шутки? Так это все было шуткой?!
Бизнесу кажется, что ему нужно всё. На самом деле это не так, но ему кажется что нужно.
Это не так, но объяснить это бизнесу если не невозможно, то очень трудно. Проще забить и двигаться по вновь намеченному плану.
Следует исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами и предоставить ему полномочия для самостоятельного согласования этих требований на основе диалога с командой.
Всего-то? Дать номинальному "владельцу продукта" все полномочия по созданию продукта? Эх, мечты...
Обозвать RTTI рефлексией это мощно, молодёжно, современно.
Еще есть библиотека, которая RTTR позволяет регистрировать и манипулировать свойствами и методами классов во время выполнения.
Читать так: Есть сторонняя библиотека RTTR (https://github.com/rttrorg/rttr), которая регистрирует свойства, методы и классы, после чего ими можно манипулировать. Что не было зарегистрировано, тем манипулировать нельзя. Что в целом не похоже на рефлексию в той же Java.
Видимо, осталось сделать простой шаг - определить для разработчиков две похожие метрики для расчета эффективности - воронку и конверсию. Первая, наверное, будет SLOC?
Подводя итог, стоит сказать, что производительность разработчиков действительно можно измерить.
Еще бы добавить альтернативные ответы, который дал Кент Бек в отдельной статье
Measure developer productivity? Not possible. There are too many confounding factors, network effects, variance, observation effects, and feedback loops to get sensible answers to questions like, “How many times more profit did Joan create than Harry?” or, “How much better (or worse) is Harry doing this quarter than last?” You can measure activity, but not without directing that activity away from the ends you care about. And your customers. And your investors.
Я, конечно, не архитектор, и статья не о том, но не стоит делать один общий микросервис для сотрудника и для клиента. Небезопасненько это. Например, DDоS по клиентскому каналу сломает UI для сотрудников.
Не помню, где прочитал. Вроде недавно было на Хабре в каком-то комментарии, но сейчас не нашел.
Короче, такой кейс. Один сотрудник всем окружающим занижал оценку, тем самым снижая средний уровень оценки. Понятно, что на общем среднем уровне его оценки выглядели лучше. Чуть-чуть, конечно, но стабильно лучше. Поэтому он всегда становился претендентом на следующее повышение в грейде и в должности.
Вообще-то есть статья 18.1 закона "О занятости", которая разрешает предоставление персонала. Но я согласен, большинство этих "предоставлений" за гранью.
При этом, у компаний-заказчиков обычно нет времени на найм или недостаточно своих рекрутеров для привлечения новых сотрудников в штат или на контракты.
А еще у топов заказчиков есть требование, непонятное даже линейным менеджерам, что сотрудники должны сидеть в офисах. Поэтому куда проще взять аутстафф, который с полным правом может работать удаленно, чем найти сотрудника, согласного на опенспейс.
Аналитика очень упрощённо можно считать переводчиком требований с бизнесового языка на технический. Поэтому аналитику неплохо иметь познания в обоих языках.
И опять вы меня не поняли. Ну и ладно.
Я думаю, что ваша идея брать прогноз вполне здравая, но датчик температуры, встроенный в поверхность, поможет не тратить на нагрев больше, чем необходимо.
@Kallyanbl4 обратите внимание, 8 тысяч против ваших восемнадцати https://habr.com/ru/companies/wirenboard/articles/793790/
А всё потому, что датчик температуры есть.
По скрамовски - это поднять этот вопрос на ретро. Где один из вариантов - уменьшить длину спринта.
Не по скрамовски - забить.
Но если покопаться, то в типичном Scrum-like проекте атомарной задачей на 2 дня делают типа добавить кнопку на фронте, после чего фронтендер отдыхает, пока бэкендер доделает свою часть, девопс поставит релиз, а тестировщик протестирует. Ах да, кнопке на фронте предшествует еще правка макета и требований, пока их не будет, фронтендер не начнет работу.
Аутентификации. Авторизация - это другое
RnD задачи разбиваются не полностью на мелкие атомарные части, а только выделяются те части, которые можно взять в ближайший спринт. Перед следующим спринтом задача целиком пересматривается и делается следующее выделение. Зачастую то, что вы делали в предыдущем спринте, полностью выбрасывается, и это нормально, поскольку в этот момент вы лучше понимаете, что надо делать, чтобы вывести фичу.
Собственно, это и есть суть Скрама.
Сразу видно, когда профессиональный аналитик данных анализирует данные вакансий. Отделила мух от котлет.
Полагаю, что в тысяче откликов на входе воронки были, как минимум, достаточно квалифицированные водители. Но их отсеяли "с диким трудом, смехом и матами", потому что они не подошли "по формальным признакам".
Да, но тоже с ограничениями
классы являются наследниками QObject
проперти, слоты и сигналы объявлены через ключевые слова или макросы
обычные методы недоступны в рантайм по имени
Так что это также не сильно похоже на рефлексию в Java, где можно найти любой метод или поле любого класса.
Шутки? Так это все было шуткой?!
Это не так, но объяснить это бизнесу если не невозможно, то очень трудно. Проще забить и двигаться по вновь намеченному плану.
Всего-то? Дать номинальному "владельцу продукта" все полномочия по созданию продукта? Эх, мечты...
Обозвать RTTI рефлексией это мощно, молодёжно, современно.
Читать так: Есть сторонняя библиотека RTTR (https://github.com/rttrorg/rttr), которая регистрирует свойства, методы и классы, после чего ими можно манипулировать. Что не было зарегистрировано, тем манипулировать нельзя. Что в целом не похоже на рефлексию в той же Java.
Видимо, осталось сделать простой шаг - определить для разработчиков две похожие метрики для расчета эффективности - воронку и конверсию. Первая, наверное, будет SLOC?
И вам тот же комментарий
Еще бы добавить альтернативные ответы, который дал Кент Бек в отдельной статье
Я, конечно, не архитектор, и статья не о том, но не стоит делать один общий микросервис для сотрудника и для клиента. Небезопасненько это. Например, DDоS по клиентскому каналу сломает UI для сотрудников.
Не помню, где прочитал. Вроде недавно было на Хабре в каком-то комментарии, но сейчас не нашел.
Короче, такой кейс. Один сотрудник всем окружающим занижал оценку, тем самым снижая средний уровень оценки. Понятно, что на общем среднем уровне его оценки выглядели лучше. Чуть-чуть, конечно, но стабильно лучше. Поэтому он всегда становился претендентом на следующее повышение в грейде и в должности.
Вообще-то есть статья 18.1 закона "О занятости", которая разрешает предоставление персонала. Но я согласен, большинство этих "предоставлений" за гранью.
Скорее одно из значений, синоним бодишопа.
Галерами также иногда называют консалтинговые конторы, выполняющие разработку на заказ, из-за очень жесткого графика на проектах.
А еще у топов заказчиков есть требование, непонятное даже линейным менеджерам, что сотрудники должны сидеть в офисах. Поэтому куда проще взять аутстафф, который с полным правом может работать удаленно, чем найти сотрудника, согласного на опенспейс.
Аналитика очень упрощённо можно считать переводчиком требований с бизнесового языка на технический. Поэтому аналитику неплохо иметь познания в обоих языках.