- 00:21 - вопрос про скорость выполнения задач и количество невыполненных задач - 02:33 - узкое место в тестировании - 09:45 - F = полнота информации = добытая инфоромация / достаточная информация, F ∈ [0,1] - 10:09 - иногда достаточно набора граничных и проверочных значений - 10:40 - полнота информации между пользователем и разработчиком, возврат при недостатке добытой инфоромации у разработчика - 11:10 - полнота информации между разработчиком и компьютером - 11:40 - E = экспертность разработчика в задаче, E ∈ [0,∞) - 12:50 - R = качество резултата = F * E, R ⩾ 0 - 14:10 - качество - 17:00 - как понять будет ли возврат - 17:49 - если понятно что будет возврат, то добиваемся полноты - 19:46 - для увеличения полноты код почти не требуется - 20:33 - если не хватает экспертности, то можно поменять тип работы на проектирование или - исследовательскую работу - 22:10 - учет требований по срокам - 23:54 - как уменьшить количество возвратов - 26:03 - для исследования требуется другая полнота и экспертность и в результате этой работы увеличится - полнота и экспертность для исходной задачи - 28:30 - заработок на умственном труде - 29:49 - сложности при внедрении задач развивающих экспертность, конфликт с трендом на утилизацию - 31:24 - как эта модель может помочь понять что делать - 32:28 - учет скорости петли обратной связи - 33:00 - учет тестирования, эффект перетестирования - 38:28 - как в этой модели учитывается неидеальность кода разработчика - 41:12 - автоматические тесты окупаются при частых возвратах - 42:48 - учет роли аналитика и как определить где проблема - 45:40 - когда не требуется возврат аналитику - 49:45 - ограничение на производительность, пример когда дешевле убрать аналитика для экономии на - коммуникациях и упрощения горизонтального масштабирования за счет обучения разработчика - 53:20 - когда требуется менять структуру системы, а когда оптимизировать точечно - 58:10 - место доменных знаний команды в этой модели - 59:00 - за чем именно наблюдать в системе, цепочки, обработчики и неизвестные значения - 1:01:55 - резюме от @oleg40a - 1:03:24 - продолжение от @vfabr - если много элементов в системе то меньше качество, так как больше - потерь информации - 1:07:05 - зачем нужно пересечение экспертизы, как обойти проблему необходимости специализации для - уменьшения потерь информации - 1:10:45 - учет сроков при выборе оптимизаций системы - переключение контекстов vs простой системы vs - обучение - 1:13:20 - почему статистика будет работать плохо при изменениях в системе - 1:14:12 - резюмирование от @oleg40a о том почему есть тренд на плоские организационные структуры - 1:15:40 - вариант ответа что конкретно делать - 1:19:46 - аналогия спринтов и bulk insert - 1:20:40 - возражение @oleg40a на аналогию, темпоральные характеристики баз данных vs процесс накопления информации, нелинейность - времени на работу - 1:24:04 - ответ @vfabr на возражение, связь итеративности и bulk - 1:26:00 - прогнозирование на итерацию для того чтобы выбрать правильный тип работы - 1:29:12 - возражение @oleg40a в ответ на возражение от @vfabr, аналогия с заточкой топора, как - менеджмент может мешать реализации изменений, упоминание Kanban Maturity Model - 1:32:30 - типы компаний по реакции на изменения - 1:34:47 - пример неэффективности оптимизации взаимодействия без изменения системы: обнажение - максимальной эффективности системы с work in progress лимитами - 1:37:00 - после обнажения неэффективности остается только менять систему - 1:38:00 - изменение системы на следующих уровнях - 1:41:05 - сложности интеллектуального труда: придумать алгоритм и начать его реализовывать - 1:43:17 - итоги встречи Материалы https://github.com/modernsd/works/blob/master/notes/2021-10-24.md