Современная разработка программного обеспечения

00:00 - @oleg40a почему начали обсуждать jira
02:52 - про jira головного мозга, первый критерий
04:30 - место jira в разработке ПО
06:30 - ticket и его содержимое
08:14 - mindset доставки ценности пользователю
09:07 - дисфункции с момента нарезки задач
09:58 - противорериче принципу autonomy, командная ответственность
11:14 - в каком смысле ситуация в которой приходится использовать jira как knowledge base это симптом дисфункции
14:54 - как jira стала такой
16:38 - отсылка к докладу анти jira
17:08 - аналогия между неправильным использованием тикет систем и заражением вирусом
20:30 - Software Engineering is a learning process, working code a side effect (ссылка 1, ссылка 2)
21:30 - как это связано с теорией X / теорией Y (authoritarian / participative)
23:05 - аналогия с лесным хозяйством и конвейером Ford
25:30 - @vfabr про понимание @modernsd чата, @oleg40a и других участников (понимание @oleg40a тут)
30:46 - заострение проблем при общении в чате для запуска мыслительного процесса
32:33 - какому поведению не рады в этом чате (прим. @materkey - чем-то напомнило статью)
38:40 - jira для фиксации расхождения реализации и спецификации
39:14 - @oleg40a как связаны jira, estimates, incentives и другие процессы
42:24 - @vfabr критерий можно ли перекладывать какую-то ответственность на Jira, как то что упрощает работу программиста приводит к тому что появляются новые проблемы
46:40 - @oleg40a как менеджеры ломают систему
48:04 - буллинг в этом чате как сигнал нарушения негласных правил
53:55 - цель чата с точки зрения @vfabr
01:03:40 - модель познания для инженера, инженерная культура
01:10:58 - вопрос @newyearisamagictime про опыт @vfabr
01:16:30 - позитивный сценарий использования чата @vfabr
01:19:10 - вопрос @materkey про определение энергии в модели @vfabr
01:22:00 - вопрос про методологию познания @vfabr
01:24:46 - вопрос @newyearisamagictime про оценку адекватности моделей (ответы: ссылка 1, ссылка 2)

- 00:21 - почему тема обратной связи важна
- 02:10 - the power of feedback
- 02:20 - что  такое обратная связь
- 03:44 - проблема необъективности мнения при обратной связи между людьми
- 05:49 - 4 вида обратной связи
- 05:56 - вид "ты не прав"
- 07:56 - вид "кто-то не прав"
- 08:12 - вид "правила говорят что это не правильно"
- 08:32 - вид "я не прав"
- 09:20 - обратная связь в обычной жизни
- 11:16 - проблема фиксации правил на работе
- 13:08 - социальная и рабочая части правил
- 14:20 - пример про code review ("что" бизнеса и "что" технической системы)
- 18:00 - специальные правила для каждой задачи
- 26:10 - как донести идею рабочих правил
- 28:13 - добавление от @vitaly19842 про явное описание рабочих договоренностей
- 29:30 - как понять что усвоены рабочие договоренности
- 46:44 -  похожесть синхронизации понимания и тестов в TDD
- 48:47 - что если люди не соглашаются менять процесс, отсылка к докладу работа с инновациями и рацпредложениями

- 00:42 - прикладная цель систем менеджмента
- 01:47 - проблема выбора нужного действия: стиль менеджмента + контекст
- 03:16 - описание стиля который не подходит для работы над качеством, самообразованием, наставничеством, командообразованием, обменом знаниями
- 05:10 - противоречие бэклога спринта и стратегических целей
- 06:38 - как выглядит микроменеджмент
- 08:13 - примеры стилей менеджмента с точки зрения мотивации сделать нужное действие: теория X / теория Y (authoritarian / participative)
- 10:16 - что улучшает мотивацию сотрудника: autonomy, mastery, purpose
- 12:27 - что делать с людьми которые привыкли к микроменеджменту
- 15:06 - доверие
- 16:24 - увольнения при изменениях
- 17:30 - как увеличивать доверие в компаниях
- 21:30 - соотношение практик контроля и гомеостаза
- 23:40 - когда попытка сделать лучше может сделать хуже
- 25:39 - распределение ответственности для выстраивания саморегулирующейся системы
- 27:30 - признак чрезмерного контроля: прозрачность, планирование, предсказуемость
- 28:20 - если touch time непредсказуем, то нет смысла трекать время
- 29:30 - демотивация при внедрении time tracker'а в jira, удар по autonomy
- 30:21 - деструктивная составляющая оценки задач, планирования и предсказуемости
- 30:45 - эффект самоухудшения при чрезмерном контроле
- 33:39 - пример последствий контроля от @vfabr - сложность системы растет быстрее чем экспертиза разработчика
- 36:14 - вместо контроля, время менеджера можно тратить на рост: личный (не Personal Development Plan), команды, компании
- 36:49 - плохие примеры реализации процессов личного роста в компании
- 39:16 - негативная сторона тренда на усреднение навыков сотрудников в компании, польза diversity  - эффект комбинирования сильных сторон
- 41:23 - примеры @vfabr - обмен знаниями при парном программировании
- 42:30 - пример @vfabr - саботирование процессов сотрудниками
- 44:43 - пример @oleg40a - навязывание корпоративов и формирование вражеского отношения к менеджменту
- 45:22 - для командного роста нужен challenge
- 45:40 - инструмент делегирования - delegation poker
- 47:30 - если команда не справлялась с делегированием, а его стало еще меньше то значит у менеджмента чрезмерный контроль, чтобы освободить время менеджера для более важной работы требуется наоборот делать это чаще
- 48:35 - командам важно углублять доменные знания
- 50:25 - рост компании - культура, доверие, степень выгорания, sustainability
- 52:20 - scrum / kanban
- 53:16 - автономны ли на практике команды
- 55:20 - спринты
- 55:37 - общается ли любой член команды именно с заказчиком
- 56:20 - скрам-мастера которые не работают на свою ненужность
- 56:53 - фреймирование kanban'ом
- 59:40 - вывод: можно брать элементы из разных подходов - те что похожи на теорию Y и имеют хорошее обоснование
- 1:00:18 - обратная связь + теория массового обслуживания + учет количества информации для того чтобы задачи гарантированно заканчивались => больше задач получится сделать
- 1:01:20 - отсылка к Extreme Programming, Basecamp / ShapeUp, Zerocracy / Puzzle Driven Development
- 1:03:46 - значит можно проектировать свою систему
- 1:04:16 - trunk based development, no staging
- 1:06:00 - способность менять привычки
- 1:08:10 - ci => отсутствие long lived веток. cd => отсутствие релизов, devops для тимлидов за час
- 1:08:45 - code review
- 1:08:57 - конкретный roadmap: отмена плохих практик, отсылка к Podlodka #132 —Дисфункции организаций
- 1:10:20 - отмена scrum, спринтов, kpi, okr, регламентов, project manager
- 1:12:16 - ротация
- 1:15:10 - к чему можно свести большинство проблем
- 1:19:35 - мысленный эксперимент: как можно ухудшить систему

Материалы
https://github.com/modernsd/works/blob/master/notes/2021-10-31.md

- 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

- 00:00 - @vfabr что/как/результат в приложении к коммуникациям в команде
- 03:30 - что такое коммуникация
- 04:50 - схема коммуникации
- 07:00 - что нужно фиксировать
- 08:20 - где хранится информация/знания и сложность структурирования по положению компании на логистической кривой
- 09:30 - добывание информации -> превращение в знания -> определение горизонта изменений -> фиксация
- 10:40 - знание должно быть получено творческим путем
- 13:48 - сжатие смысла
- 17:14 - фиксация спецификации но не реализации
- 20:00 - как передавать знания
- 39:11 - @oleg40a знания по продукту vs сигналы, цель любой системы менеджмента дать понять человеку что он должен делать или не - делать
- 42:20 - пример более сложной ситуации
- 59:50 - островки разума
- 1:06:05 - формальные/фактические правила
- 1:06:40 - shadow IT, bring your own device
- 1:13:00 - многоканальность vs омниканальность
- 1:21:30 - как синхронизировать людей в одной/разных частях системы
- 1:25:56 - резюме встречи и роль энтузиазма

- 00:00 - когда тимлиду стоит учавствовать в devrel'стве
- 02:10 - польза и вред от incentives в разработке ПО
- 07:15 - партнерский подход в менеджменте труда, уровни доверия в команде
- 09:43 - controversies about principal-agent theory
- 17:10 - corporate social responsibility
- 18:20 - суть devrel'ской практики, примеры групповых динамик, silos в devops 
- 23:20 - можно ли подвести людей к изменениям и как адаптивность может этому мешать 
- 26:00 - прогноз как компании будут отходить от agency theory и/или меняться
- 30:30 - отсылка
- 31:50 - scrum guide продается но часто требуется что то еще
- 34:00 - требуемая степень утилизации разработчиков
- 37:14 - влияние верований групп на восприимчивость к новым идеям
- 39:25 - оценка текущего состояния научного прогресса
- 45:30 - выгорание
- 47:00 - еще варианты развития событий
- 48:50 - непродолжительность эффекта методик, системных подходов в малых группах
- 1:00:00 - истоки внимания к дисфункциям
- 1:04:55 - реферальные программы как лакмусовая бумажка

- 0:00 - @vitaly19842 про результаты процессов обучения сотрудников
- 01:05 - про книгу "Записки педагога" про гармоничное развитие личности и доказательную педагогику
- 02:30 - кружок выступающих для эффективного донесения артефактов работы сотрудниками
- 03:18 - как организовать финансирование кружка внутри компании для выступлений 
- 10:30 - ценность, стоимость ценности для одного человека, а потом уже стоимость на всех
- 14:00 - измерять обучение в штуках; если нужен ИП, то обязательно указывать ОКВЭД'ы главных трат
- 17:20 - туториал от @vfabr ориентированный на менеджеров в IT, под призмой теории массового обслуживания, теории информации, кибернетики и тп.
- 22:40 - удобная продолжительность занятия, упоминание андрагогики 
- 26:10 - апроприация знания
- 28:50 - сложность работы, нелинейность людей, проблема оценки задач, непрогнозируемость ⇒ задача менеджера чтобы мир был на отрезке был стабилен чтобы работа людям была под силу ⇒ линейность людей при выполнении задачи ⇒ предсказуемость, прогнозируемость
- 42:50 - Dr. Alistair Cockburn - Characterizing people as non­linear, first­order components in softwaredevelopment, этнография в приложении к IT
- 50:50 - @oleg40a "менеджеры как носители эффектов"
- 51:30 - отсылка к выпуску ПУСКИ ЛИЦ
- 52:10 - эффект "медленное сползание в унылое ***но"
- 58:30 - проблемы больших компаний
- 59:40 - коллективная выученная беспомощность
- 01:02:50 - слепое копирование, внедрение ради KPI без замены неэффективных элементов рабочей системы; если такое поощряется компанией то это трудно остановить
- 01:05:00 - ситуации когда язык маскирует смысл (цель, задача, релиз) пример релиз как процесс, релиз как дата, релиз как артефакт
- 01:06:00 - пример когда упоминание модного слова заменяет аргументацию
- 01:08:38 - пример когда полезное из scrum'а выкидывается
- 01:10:10 - совещания
- 01:10:50 - эффект "делегирование некомпетентности"
- 01:12:05 - люди "вижу цель не вижу препятствий"
- 01:14:58 - эффект "глупость толпы"
- 01:23:16 - эффект "коллективный Даннинг — Крюгер"
- 01:26:28 - эффект "Spotify", эффект "Авито"
- 01:29:00 - эффект поленницы
- 01:31:50 - технологические приемы развития глупости
- 01:33:22 - the stupidity paradox (book preview), book review
- 01:46:52 - как менеджер может делать сотрудников глупее
- 01:49:48 - перспективы

- 0:00 - заявленная тема - как организовать обучение в it компании, сначала фундаменатьные вещи, а потом конкретная реализация
- 2:30 - начало про психологию на основе черновика книги от @vfabr
- 4:30 - экстренные решения
- 5:30 - как связаны мыслительный процесс и эмоции
- 12:00 - переход от зоопсихологии на людей
- 13:00 - про зоны актуального и ближайшего развития
- 17:00 - акт изобретения
- 21:00 - результат сравнения систем обучение в нескольких странах
- 26:00 - имплицитное и эксплицитное научение
- 28:20 - любопытство
- 33:00 - зачем нужно обучение
- 34:11 - инновации
- 36:55 - problem solving
- 39:50 - пример когда окупилось время на обучение
- 41:40 - что требуется для начала построения обучения в компании
- 42:40 - пример того как можно начать обучение в компании
- 47:30 - выбор количества человек в группе используя сравнение детского сада, школы и вуза
- 50:30 - как понять есть ли у сотрудников мотивация к началу такого процесса обучения
- 52:00 - пример начала с фундаментальной темы в которой большинство сотрудников на одном уровне понимания
- 53:00 - вариант организации домашней работы
- 56:00 - описание цикла для реализации дальнейших шагов
- 1:00:00 - обратная связь от автора вопроса про обучение
- 1:02:40 - ответ на вопрос про то на сколько привязывать обучение к конкретным задачам
- 1:07:00 - вопрос про то является ли задачей обучения отказ от убеждений
- 1:09:20 - ответ
- 1:14:17 - чат прервался
- 1:14:51 - чат продолжился
- 1:15:33 - от чего зависит мотивация людей делать рационализаторское предложение
- 1:17:10 - аналогия со станком, закон Йеркса — Додсона
- 1:22:40 - что если никто из участников не направляет обучение
- 1:30:30 - вопрос от @oleg40a про то на сколько нужно обучение похожее на сертификации в it
- 1:37:00 - вопрос про перечень технологий в описании вакансий и то как это согласуется с принципами инженерной работы

- 00:00 - @vitaly19842 о школе кадрового резерва
- 01:30 - про соревновательность в обучении
- 03:00 - перерывы 
- 04:00 - выбор времени старта работы
- 04:40 - про разминку перед работой
- 06:30 - про разнообразие оборудования у обучающихся
- 07:24 - про стеснение, смущение и психологический комфорт у студентов
- 08:40 - theory first vs practice first
- 09:35 - понятие рациональности, когда лучше не делать если можно не делать
- 13:33 - @vfabr про вариант понимания задач психологии и triune brain гипотетическая модель мозга (судя по wiki отвергнута)
- 19:40 - рефлекс, эмоция, мышление для адаптации к внешнему миру
- 20:50 - основные эмоции которые позволяют долго что-то делать и гармоны для вызова эмоций
- 25:08 - иллюстрация того что описывал ранее @vitaly19842
- 26:30 - финская модель обучения
- 29:27 - сравнение с другими системами
- 31:30 - идея силы стимула и качества педагога
- 37:00 - обсуждение мотивации у студентов вуза
- 40:00 - доказательная педагогика или ее отсутствие
- 43:17 - edu scrum
- 49:00 - еще немного про разницу российского и финского образования
- 51:00 - тенденции вокруг международной программы по оценке образовательных достижений учащихся
- 57:46 - смена темы: вопрос об эффективности процессов, заваливание проблем временем и метрики эффективности
- 1:02:08 - начало ответа от @dphil
- 1:07:40 - нужна ли в командах постоянная оценка для улучшения качества оценки
- 1:10:00 - иллюстрация того как выглядит идеальная эффективность
- 1:11:40 - дополнительные элементы в процесс для синхронизации в разработке
- 1:14:30 - негативные изменения в поведении людей при внедрении метрик влияющих на incentives, не влияющих на то доволен или нет конечный пользователь, пример про змей
- 1:17:00 - критерий для sustainable business - счастье пользователей, выстраивание целей от этого
- 1:18:20 - проблема okr
- 1:21:00 - девятки в SLA, DORA метрики
- 1:22:00 - стоймость обучения сотрудника, среднее время работы в компании
- 1:25:20 - еще раз про необходимость физического обоснования того как клиенту (внутреннему или внешнему) будет лучше от внесения чего-то нового в систему
- 1:29:30 - про STATIK (видео, статья, книга (eng), книга (rus)) и создание дискомфорта, стрессора для внесения изменений в компанию

- 1:34:20 - скорость культурных сдвигов в обществе

Материалы

https://github.com/modernsd/works/blob/master/notes/2021-05-11.md

- 00:00 - начало про платформенные команды
- 02:05 - проблемы при стандартизациях в разработке, effectiveness vs efficacy vs efficiency
- 10:00 - применение little's law к платформенным командам или почему платформенная команда это костыль
- 11:00 - выделение команды vs использование slack time для обучения окружающих
- 16:30 - о статье фаулера про внутренний SaaS
- 18:00 - про core team (не SaaS)
- 19:30 - групповые динамики - илитаризм, социальное расслоение
- 20:30 - иллюстрация негативных групповых динамик scala сообщества - сорта программистов
- 23:00 - проблема с обучением других
- 23:30 - устаревание представления о контектсе продуктовой разработки у платформенных команд
- 25:45 - проблема предварительного обобщения; как автономность перечеркивается зависимостью на команды
- 29:04 - комбинаторный взрыв при выделении общего
- 31:00 - обилие конфигурационных параметров -> программирования больше а не меньше
- 32:39 - компетенций команды часто не хватает на инфру
- 34:10 - configuration as code
- 34:40 - платформенных гильдий, команд будет становится все больше так как компетенций продуктовых команд будет все меньше и меньше
- 36:20 - проблема организационных и процессных решений архитектурных проблем
- 38:34 - системы для программистов сложно делать из-за требовательности
- 43:30 - необходимость оставлять возможность
- 45:42 - платформенная (внутренний SaaS) vs core (распил целого продукта) vs интеграционая команды
- 46:52 - критерий конкурентности
- 52:59 - больше контекста от автора вопроса
- 57:10 - неявное финансирование, как прояснить целесообразность платформенной команды - ответить на вопрос получиться ли сделать стартапом, по lean стартап методологии; другие компании могли бы этим воспользоваться? неверифицируемость окупаемости приводит к паразитизму, job security
- 1:00:30 - временное решение vs системное решение; проблема отсутствия обучения других или его замедление при создании таких "костылей"
- 1:04:10 - conway law под вопросам для некоторых общих частей
- 1:12:00 - система генерирующая задачи vs система выполняющая задачи и все ли задачи нужно делать
- 1:15:30 - расширение трассы -> больше пробок
- 1:17:00 - подведение итогов
- 1:21:00 - вопрос на следующий раз про реализацию работы архитектора

Материалы
Статья про изъян со средними числами