Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Why Root Cause Analysis doesn't work in Complex Systems
Главная идея Root Cause Analysis — у каждой проблемы существует причина. Поймете причину — проблема больше не повториться. Звучит логично, но для «сложных» систем причины не явно связаны между собой, о чем рассказывает автор в статье выше.
Текст начинается с объяснения идей и подходов из Root Cause Analysis. Тут найдете упоминание диаграмм Исикавы (если видели диаграммы в виде скелета рыбы — это оно). А также описываются «5 why?» и другие методы. Далее описываются недостатки RCA: наличие проблем возникающих из суммы причин, а RCA в такие проблемы не умеет. Эта мысль раскрывается через feedback loops, где изменения в одном месте, усиливает/ослабляет эффекты в других частях системы.
В качестве альтернативного подхода, к анализу проблем, автор предлагает рассмотреть теорию ограничений (которую автор называет протосистемным подходом), flow diagrams и карты feedback loops. А в последней части текста автор предлагает 3 подхода к улучшающему вмешательству (PDSA и эксперименты)
#system_analysis #system_thinking
—————————————
Anti-patterns in event modelling - Passive-Aggressive Events
Отсутствие событий — ситуация, с которой сталкиваюсь в каждом первом проекте, где реализуют асинхронную коммуникацию. Под «отсутствием событий» подразумевается то, что сообщения, которые передаются либо являются данными (
UserEvent), либо командами (CalculatePrice), а не событием (фактом того, что что-то произошло). Статья выше о «скрытых» командах, т.е. «событиях», которые автор называет пассивно-агрессивными.Начинает автор с аналогий из реального мира, где встречается пассивно-агрессивный тон. Далее подводится идея, что подобный тон в событиях говорит о «скрытых командах», т.е. сообщение передает информацию, но ждет, что будет что-то сделано. Подобное поведение, автор, сократил до следующей фразы: «я свою работу выполнил, теперь твоя очередь». Далее возникает утверждение, что если передаем команду, а не событие, то придется делать синхронный вызов. На что приводятся мысли Сэма Ньюмана (написал книгу о микросервисах), что синхронная от асинхронной коммуникации отличается только блокировкой. После чего появляется еще один вид сообщений — документ (если курсы проходили, то это репликация). Ну и в конце рассказывается где использовать события, команды и документы.
#event_driven
—————————————
Why scrum is stressing you out
Модели жизненного цикла принято критиковать за то, что модели перестали быть тем, что изначально закладывали авторы. Такая судьба постигла waterfall, аджайл и другие подходы. По ссылке выше, автор решил описать собственные мысли, почему скрам вызывает столько стресса. Важный момент: в тексте описывается не «каноничный» скрам, а то, что сейчас называют скрамом.
В тексте найдете четыре причины почему скрам вызывает стресс:
- спринты не кончаются. Т.е. нет периодов нагрузки и отдыха, как в том же waterfall;
- отсутствие контроля у команд с какой скоростью надо деливерить и работать;
- игнорирование подготовительной работы (обдумывание, обучение, отдых, рефакторинг и так далее);
- создание scrumfall, гибрида scrum со спринтами и нагрузки из waterfall в «важный» дедлайн (релиза).
Русский перевод
#ppl_managment