- 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