Интересно, а уже выпустил кто-нибудь книгу по DDD, но не для программистов, а для руководителей проектов/продуктов/аналитиков? Если есть такая - киньте ссылку пожалуйста, очень-очень надо.
Мы часто сталкиваемся с "неизвестным" в своей жизни и я согласен с автором, что не надо пасовать в таких ситуациях. НО! Почему автор после первого препятствия не составил список всех возможных препятствий и их параметров? Почему все препятствия не были решены за один поход в магазин или за один поход к "эксперту"? Вот тут он зря продолжал идти "Водопадом" шаг-за-шагом, нужно было сменить стратегию.
Если функция, вызывающая generateInvoice, не знает, какой должна быть taxRate, то я добавляю во входные данные этой функции taxRate и продолжаю выполнение вверх по стеку вызовов. Рано или поздно я достигну функции, способной подтянуть необходимый контекст
Разве это правильный подход протаскивать taxRate через весь стек вызовов? Меня это место в вашей статье смутило.
Мое частное мнение: Германия начала процедуру деиндустриализации через повышение цен на электроэнергию, карбоновые налоги и т.п. Соответственно все производства будут медленно, но уверенно выноситься из Германии под экономическим давлением. Куда? Китай, Инодензия и т.п. Взамен, будут создаваться благоприятные условия для пост-индустриальной экономики - ИТ, электромобили, генная медицина и т.п. Но "грязные" производства этих продуктов будут наниматься в третьих странах. Таким образом создание продуктов и их продажа - в Германии, производство - в иных странах. Да, компаниям все заводы придется переносить. Да, компании должны понести расходы за это. Проблема Volkswagen в том, что они не успевают перестроиться в пост-индустриальную и терпят дополнительные убытки в попытке удержаться в гонке. А еще в этой гонке США решили тормознуться и немного откатиться и защитить свои индустриальные/промышленные компании, попутно немного погромив ближайших конкурентов.
Вынужден не согласиться с автором. Всегда воспринимал Scrum как чуть ли не единственную методологию, которая позволяет работать с «неизвестное неизвестное». Это когда непонятно даже какой вопрос задать. Т.е. квадрат «запутанное» в модели Кеневин. Например, выпуск нового продукта, но непонятно еще какого.
Если проект в целом понятно как делать или хотя бы понятно на какие вопросы надо найти ответ, то Канбан и другие методологии прекрасно работают.
А как сервисный DevOps отдел узнает о проблемах, если он находится вне контекста этих проблем? Соответственно следующий вопрос - как этот отдел выберет правильное решение из множества? Если будет советоваться с руководством и тимлидами - так это не у них проблемы...
Почитал что пишут вокруг этого инцидента - нигде никакой конкретики. Никаких деталей, никаких пруфов...
Очень похоже либо на попытку обвалить anonfiles, либо наброс на сайт московских госуслуг. Ну и заодно испачкать федеральные госуслуги, т.к. картинку крепят от федерального сервиса.
Все прекрасно, солидарен с автором по поводу его философии.
Где же найти ту замечательную программу, в которой можно воплотить эту философию?
Из просмотренных мною:
— Roam Research — интересный стратап, пожалуй сымый близкий ко этой философии. Но пока система слишком сырая, чтобы ее использовать.
— TheBrain — нормально работает только как десктоп-приложение, строится граф, но не поддерживает статьи целиком, только отдельные мысли. И в целом далек от этой методики
— Notion — тоже может подойти к реализации этой философии, — сохраняются статьи, есть выделение, но… там не очень понятная навигация по статьям, Можно делать под-статьи и это еще страннее… Ну и редактор так себе…
Только-только еле выбрались из клещей эко-системы Azure. В новые замкнутые на себя эко-системы уже не хочется попадать, т.к. подобные платформы настойчиво мешают не выходить за их границы и не использовать сторонние решения. Это как черная дыра, — потом не выберешься. Разве я не прав?
Я тот самый дебильный менеджер, и даже менеджер над менеджерами. Статья, понравилась. Спасибо, взял в избранное.
Но не могу пройти мимо этой фразы: Он хочет работать по согласованным требованиям. <...> А потому, что он понимает, что требования определяют архитектуру и сроки реализации, и смена их может привести к тому, что архитектуру нужно будет подпирать костылями, так как время на изменение никто не даст.
И вот тот самый управленец (правда из бывших разрабов), не понимаю откуда взять эти чертовые согласованные требования. Не встречал заказчиков, которые четко знают чего хотят. Им все покажи тут, покажи там, а вот тут не так, а вот там вообще вы нифига не поняли… переделывайте…
Я перестал верит в гениальных аналитиков и проджектов, которые способны четко просчитать требования и высчитать сроки. Не встречал их на своем пути, ни в своей компании, ни у конкурентов. А значит приходится с этим жить. А раз не будет согласованных требюований, то будет макет, полу-прототип, прототип, доделанный прототип, прототип читающий, прототип сохраняющий… И каждый раз есть риск выкинуть в корзину и начать сначала.
И времени на изменение архитектуры, переписывания с нуля и пр. я не дам. Это не нужно ни мне, ни заказчику — для меня это чистые убытки, для заказчика срыв госзадания.
Но что я могу дать?
Могу дать только возможность постоянного рефакторинга и изменения архитектуры. Каждый день/неделю/месяц… Но чтобы без остановок бизнеса!
А что это за архитектура такая — да. хрен знает. Решайте сами.
Интересно, а уже выпустил кто-нибудь книгу по DDD, но не для программистов, а для руководителей проектов/продуктов/аналитиков? Если есть такая - киньте ссылку пожалуйста, очень-очень надо.
Мы часто сталкиваемся с "неизвестным" в своей жизни и я согласен с автором, что не надо пасовать в таких ситуациях.
НО!
Почему автор после первого препятствия не составил список всех возможных препятствий и их параметров? Почему все препятствия не были решены за один поход в магазин или за один поход к "эксперту"?
Вот тут он зря продолжал идти "Водопадом" шаг-за-шагом, нужно было сменить стратегию.
Если функция, вызывающая generateInvoice, не знает, какой должна быть taxRate, то я добавляю во входные данные этой функции taxRate и продолжаю выполнение вверх по стеку вызовов. Рано или поздно я достигну функции, способной подтянуть необходимый контекстРазве это правильный подход протаскивать taxRate через весь стек вызовов? Меня это место в вашей статье смутило.
В таких местах нам потребовалось вмешаться в код и сделать рефакторинг, чтобы эти слоёные пироги отражали суть.Поясните пожалуйста этот момент. Что вы сделали?
Мое частное мнение:
Германия начала процедуру деиндустриализации через повышение цен на электроэнергию, карбоновые налоги и т.п. Соответственно все производства будут медленно, но уверенно выноситься из Германии под экономическим давлением. Куда? Китай, Инодензия и т.п.
Взамен, будут создаваться благоприятные условия для пост-индустриальной экономики - ИТ, электромобили, генная медицина и т.п. Но "грязные" производства этих продуктов будут наниматься в третьих странах. Таким образом создание продуктов и их продажа - в Германии, производство - в иных странах.
Да, компаниям все заводы придется переносить.
Да, компании должны понести расходы за это.
Проблема Volkswagen в том, что они не успевают перестроиться в пост-индустриальную и терпят дополнительные убытки в попытке удержаться в гонке.
А еще в этой гонке США решили тормознуться и немного откатиться и защитить свои индустриальные/промышленные компании, попутно немного погромив ближайших конкурентов.
Что такое метка job?
Вынужден не согласиться с автором. Всегда воспринимал Scrum как чуть ли не единственную методологию, которая позволяет работать с «неизвестное неизвестное». Это когда непонятно даже какой вопрос задать. Т.е. квадрат «запутанное» в модели Кеневин. Например, выпуск нового продукта, но непонятно еще какого.
Если проект в целом понятно как делать или хотя бы понятно на какие вопросы надо найти ответ, то Канбан и другие методологии прекрасно работают.
А как сервисный DevOps отдел узнает о проблемах, если он находится вне контекста этих проблем? Соответственно следующий вопрос - как этот отдел выберет правильное решение из множества? Если будет советоваться с руководством и тимлидами - так это не у них проблемы...
Может быть команда такая, потому что микроменеджмент? )
Мы в 2020 году перешли на https://kaiten.ru
Заходило тяжело.
Сейчас крайне довольны выбором.
Так что же это за экологичные процессы в крупной компании?
Почитал что пишут вокруг этого инцидента - нигде никакой конкретики.
Никаких деталей, никаких пруфов...
Очень похоже либо на попытку обвалить anonfiles, либо наброс на сайт московских госуслуг. Ну и заодно испачкать федеральные госуслуги, т.к. картинку крепят от федерального сервиса.
Сейчас медленно перехожу с Notion на Roam Research. Последний очень сырой, но концепция сильно связанных параграфов зацепила
Пользуемся Kaiten.io, эту карточную систему тоже можно добавить в список
Где же найти ту замечательную программу, в которой можно воплотить эту философию?
Из просмотренных мною:
— Roam Research — интересный стратап, пожалуй сымый близкий ко этой философии. Но пока система слишком сырая, чтобы ее использовать.
— TheBrain — нормально работает только как десктоп-приложение, строится граф, но не поддерживает статьи целиком, только отдельные мысли. И в целом далек от этой методики
— Notion — тоже может подойти к реализации этой философии, — сохраняются статьи, есть выделение, но… там не очень понятная навигация по статьям, Можно делать под-статьи и это еще страннее… Ну и редактор так себе…
Только-только еле выбрались из клещей эко-системы Azure. В новые замкнутые на себя эко-системы уже не хочется попадать, т.к. подобные платформы настойчиво мешают не выходить за их границы и не использовать сторонние решения. Это как черная дыра, — потом не выберешься. Разве я не прав?
А меня в последнее время чаты стали раздражать. Как с этим бороться-то?
А так: +2.5-5% к прибыли?
Но не могу пройти мимо этой фразы:
Он хочет работать по согласованным требованиям. <...> А потому, что он понимает, что требования определяют архитектуру и сроки реализации, и смена их может привести к тому, что архитектуру нужно будет подпирать костылями, так как время на изменение никто не даст.
И вот тот самый управленец (правда из бывших разрабов), не понимаю откуда взять эти чертовые согласованные требования. Не встречал заказчиков, которые четко знают чего хотят. Им все покажи тут, покажи там, а вот тут не так, а вот там вообще вы нифига не поняли… переделывайте…
Я перестал верит в гениальных аналитиков и проджектов, которые способны четко просчитать требования и высчитать сроки. Не встречал их на своем пути, ни в своей компании, ни у конкурентов. А значит приходится с этим жить. А раз не будет согласованных требюований, то будет макет, полу-прототип, прототип, доделанный прототип, прототип читающий, прототип сохраняющий… И каждый раз есть риск выкинуть в корзину и начать сначала.
И времени на изменение архитектуры, переписывания с нуля и пр. я не дам. Это не нужно ни мне, ни заказчику — для меня это чистые убытки, для заказчика срыв госзадания.
Но что я могу дать?
Могу дать только возможность постоянного рефакторинга и изменения архитектуры. Каждый день/неделю/месяц… Но чтобы без остановок бизнеса!
А что это за архитектура такая — да. хрен знает. Решайте сами.
Я.Такси только что заработал. Прогрузилось. Заказ прошел, жду машину.