Это очень плохая книга. Она подменяет проектирование прохождением собеседований. Если на собеседовании помогает книжка Сью, то это говорит о больших проблемах и у нанимателя и у нанимаемого. Скорее всего, оба уровнем где-то middle, не выше.
И да, проектирование любой реальной системы и близко не похоже на книжку Сью.
Ну, по хорошему, для подобных задач только сбор НФТ занимает несколько часов. Так что все это - профанация архитектурной деятельности, для проведения плохих собеседований.
Хм, а не смотрели на какие-то промышленные логеры, типа log4j/logback (из мира Java). Там достаточно хорошо проработаны подходы к организации логов, работа с пайплайном и так далее. Например, время жизни логов - не часть логики логики логгера, а часть логики системы хранения логов. Обычно выделяют логгер (часть системы, которая публикует логи), форматтер (преобразование логов к нужному формату), лог-коллектор, лог-транспорт, хранилище логов.
Во-первых, нужно ждать начало спринта. Во-вторых, нужно уже постановка на начала спринта (иначе как команда решит, что она простая). Ну и, заметим, ты потерял обратную связь с заказчиком )
Ну, можно назвать скрамом что-то, где задачу планируем где-то в середине спринта, сразу показываем бизнесу, вносим исправления и выкладываем. Но тогда там не будет ни планинга, ни демо ни, собственно, спринтов (что, впрочем, сделает процесс только лучше). Но это будет уже не по гайду
С чего бы PO был лидером команды? В скраме это просто роль, никакого лидерства не предполагающая. PO просто отвечает за бэклог, не больше. Перечитайте скрамгайд.
Или наоборот, за счет нормального проектирования сэкономите 90% бюджета и сделаете продукт быстрее. Такое тоже очень даже бывает и особенно на конкурентных рынках.
Угу, я и говорю, скрам - для понятной предметной области и простых типовых задач. Ну и для средних команд и плохих менеджеров.
Именно потому, что задача в канбане легко реализуемая за неделю (день на обсуждение, три дня на реализацию, день на правки), в скраме потребует 6 недель.
Ну и agile - вообще не про "попытка воспроизвести дух и преимущества успешных стартапов, которые превзошли корпорации и которые не только драйвовые, но в которых нет места слабости", откуда это взялось? Agile manifesto - это попытка нескольких коучей и менеджеров вывести несколько простых советов по улучшению управления. И, собственно, все, что там изучать-то?
И с чего решили, что успех Spotify хоть как-то связан с тем, что рассказывают (а не просто с тем, что первые вышли на рынок стриминга или просто повезло)? Это на конкурентных рынках многое зависит от эффективности команды. А для стартапов, создающих новые рынки - больше от случайности. Ну тот же Facebook - ничем не лучше ни в управлении, ни в команде, ни в технологиях.
Нет, гораздо больше, чем спринт, обычно три спринта (в одном груминг и анализ, в другом разработка, в третьем доработка после демо). И это очень долго (
И? Где там в Spotify эффективность разработчиков? Spotify отличается именно количеством контента, который определяется просто бизнес-схемой. У Гугла подобных продуктов я вообще не помню, Эппл сильно ограничен платформой (но на своей платформе вполне себе конкурирует с Spotify). Так что я не очень понимаю, а при чем тут такой восторг? Можно сравнить Spotify c конкурентами (Tidal, например) и там как раз заметно, что как продукт Tidal лучше.
Эээ, доходность компании крайне редко связана с эффективностью разработки. В случае спотифая - вообще не связана. Где тут сверхэффективность команды (и какой команды? Основа роста спотифая - в договорах с поставщиками контента и в юристах, при чем тут IT?)
Ну, это как раз про то, что у скрама очень плохо с t2m. И если нужна быстрая реакция на изменения - то скрам категорически не подходит, нужны другие методики.
Скрам - это для неторопливой простой работы в хорошо известной области. Если нужно за год написать 1000 похожих отчетов, тогда скрам замечательно подходит.
Э, когда это спринт стал единицей времени для управления? И вообще, мы про скрам говорим или про что-то другое? В скраме нет запрета на изменение состава спринта, запрещено только изменение цели спринта (и это вполне логично).
Опять передергивания ) Цели спринта - очень часто не нужны (и даже вредны), особенно в исследовательских задачах в сложных предметных областях. Есть много одновременных эпиков, над которыми нужно работать. И, заметим, одновременная работа над одной задачей нескольких человек обычно снижает эффективность.
Про product owner я вообще ничего не говорил, причем тут он? И роль PO в скраме предполагает только управление бэклогом, к общению с клиентами она не имеет никакого отношения (может лицо, играющее роль PO этим занимается, может нет - скраму на это пофиг).
Использование каких-то левых ресурсов для подтверждения неверного мнения про скрам - довольно странное. Скрам определяется скрамгайдом и только )
Это очень плохая книга. Она подменяет проектирование прохождением собеседований. Если на собеседовании помогает книжка Сью, то это говорит о больших проблемах и у нанимателя и у нанимаемого. Скорее всего, оба уровнем где-то middle, не выше.
И да, проектирование любой реальной системы и близко не похоже на книжку Сью.
Ну, по хорошему, для подобных задач только сбор НФТ занимает несколько часов. Так что все это - профанация архитектурной деятельности, для проведения плохих собеседований.
Увы, статья не про System Design, а про прохождение плохих собеседований.
Хм, а не смотрели на какие-то промышленные логеры, типа log4j/logback (из мира Java).
Там достаточно хорошо проработаны подходы к организации логов, работа с пайплайном и так далее.
Например, время жизни логов - не часть логики логики логгера, а часть логики системы хранения логов.
Обычно выделяют логгер (часть системы, которая публикует логи), форматтер (преобразование логов к нужному формату), лог-коллектор, лог-транспорт, хранилище логов.
Да, но нормальность проектирования зависит от тщательного сбора требований и их обдумывания
Да, но это уже ничуть не будет походить на скрам по гайду. Просто на потоковое выполнение задач (что и хорошо).
Во-первых, нужно ждать начало спринта.
Во-вторых, нужно уже постановка на начала спринта (иначе как команда решит, что она простая). Ну и, заметим, ты потерял обратную связь с заказчиком )
Ну, можно назвать скрамом что-то, где задачу планируем где-то в середине спринта, сразу показываем бизнесу, вносим исправления и выкладываем. Но тогда там не будет ни планинга, ни демо ни, собственно, спринтов (что, впрочем, сделает процесс только лучше).
Но это будет уже не по гайду
С чего бы PO был лидером команды? В скраме это просто роль, никакого лидерства не предполагающая. PO просто отвечает за бэклог, не больше. Перечитайте скрамгайд.
Или наоборот, за счет нормального проектирования сэкономите 90% бюджета и сделаете продукт быстрее. Такое тоже очень даже бывает и особенно на конкурентных рынках.
Угу, я и говорю, скрам - для понятной предметной области и простых типовых задач. Ну и для средних команд и плохих менеджеров.
Именно потому, что задача в канбане легко реализуемая за неделю (день на обсуждение, три дня на реализацию, день на правки), в скраме потребует 6 недель.
Ну и agile - вообще не про "попытка воспроизвести дух и преимущества успешных стартапов, которые превзошли корпорации и которые не только драйвовые, но в которых нет места слабости", откуда это взялось?
Agile manifesto - это попытка нескольких коучей и менеджеров вывести несколько простых советов по улучшению управления. И, собственно, все, что там изучать-то?
И с чего решили, что успех Spotify хоть как-то связан с тем, что рассказывают (а не просто с тем, что первые вышли на рынок стриминга или просто повезло)?
Это на конкурентных рынках многое зависит от эффективности команды. А для стартапов, создающих новые рынки - больше от случайности. Ну тот же Facebook - ничем не лучше ни в управлении, ни в команде, ни в технологиях.
Нет, гораздо больше, чем спринт, обычно три спринта (в одном груминг и анализ, в другом разработка, в третьем доработка после демо). И это очень долго (
И? Где там в Spotify эффективность разработчиков? Spotify отличается именно количеством контента, который определяется просто бизнес-схемой. У Гугла подобных продуктов я вообще не помню, Эппл сильно ограничен платформой (но на своей платформе вполне себе конкурирует с Spotify).
Так что я не очень понимаю, а при чем тут такой восторг?
Можно сравнить Spotify c конкурентами (Tidal, например) и там как раз заметно, что как продукт Tidal лучше.
Эээ, доходность компании крайне редко связана с эффективностью разработки. В случае спотифая - вообще не связана. Где тут сверхэффективность команды (и какой команды? Основа роста спотифая - в договорах с поставщиками контента и в юристах, при чем тут IT?)
Ну, это как раз про то, что у скрама очень плохо с t2m. И если нужна быстрая реакция на изменения - то скрам категорически не подходит, нужны другие методики.
Скрам - это для неторопливой простой работы в хорошо известной области. Если нужно за год написать 1000 похожих отчетов, тогда скрам замечательно подходит.
Э, когда это спринт стал единицей времени для управления?
И вообще, мы про скрам говорим или про что-то другое?
В скраме нет запрета на изменение состава спринта, запрещено только изменение цели спринта (и это вполне логично).
Так скрам никак не поможет в планировании будущих релизов. Канбан, стабильная команда и много статистики помогут гораздо лучше.
Опять передергивания )
Цели спринта - очень часто не нужны (и даже вредны), особенно в исследовательских задачах в сложных предметных областях. Есть много одновременных эпиков, над которыми нужно работать. И, заметим, одновременная работа над одной задачей нескольких человек обычно снижает эффективность.
Про product owner я вообще ничего не говорил, причем тут он? И роль PO в скраме предполагает только управление бэклогом, к общению с клиентами она не имеет никакого отношения (может лицо, играющее роль PO этим занимается, может нет - скраму на это пофиг).
Использование каких-то левых ресурсов для подтверждения неверного мнения про скрам - довольно странное. Скрам определяется скрамгайдом и только )