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

00:00 - @oleg40a почему начали обсуждать jira02: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 - отсылка к докладу анти jira17:08 - аналогия между неправильным использованием тикет систем и заражением вирусом20:30 - Software Engineering is a learning process, working code a side effect (ссылка 1, ссылка 2)21:30 - как это связано с теорией X / теорией Y (authoritarian / participative)23:05 - аналогия с лесным хозяйством и конвейером Ford25: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 - цель чата с точки зрения @vfabr01:03:40 - модель познания для инженера, инженерная культура01:10:58 - вопрос @newyearisamagictime про опыт @vfabr01:16:30 - позитивный сценарий использования чата @vfabr01:19:10 - вопрос @materkey про определение энергии в модели @vfabr01:22:00 - вопрос про методологию познания @vfabr01: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 - вопрос на следующий раз про реализацию работы архитектораМатериалыСтатья про изъян со средними числами