Потреблению трафика (телефон не может качать сотни гигов, у него тупо флешка закончится)
Да ладно, у вас при просмотре YouTube флешка заполняется?) Если смотреть в HD или вообще 4K и много, будет выглядеть как вы описали, но "флешка не закончится".
Может читать и легче, только цель "облегчить вам чтение" не имеет смысла в контексте договора. При чтении договора вам важно понять в полной мере то, что изложено "сложно", а вот понимания в полной мере такое "лёгкое" чтиво вам все равно не даст, если вы не юрист. Вы просто не сможете учесть нюансы, которые вытекают из положений законов или просто в силу сложившейся правоприменительной практики. И тот факт, что вы этого не понимаете в своем комментарии только подтверждает истинность моего утверждения.
У вас какая-то странная получилась история. Вроде бы и есть объяснение странностей, но от этого история не перестает быть странной. Складывается ощущение, что вы не до конца поняли что такое AsyncAPI.
Если для документирования http интерфейсов существует спецификация OpenAPI, то для асинхронного сообщения с использованием брокеров сообщений мы не нашли подобного инструмента.
Увидев текущие проблемы документирования интерфейсов, использующих брокеры сообщений, мы подумали, как их можно решить. Для решения проблемы отсутствия единого формата документирования решили использовать OpenAPI нотацию.
Как мы знаем, OpenAPI - это нотация для описания http интерфейсов. Соответственно, вся инфраструктура вокруг OpenAPI спецификации построена для http. Для использования OpenAPI инфраструктуры необходимы доработки.
AsyncApi - протокол для описания асинхронного общения между приложениями. Протокол позволяет проектировать приложения в Event-Driven Architecture. У OpenAPI и у AsyncAPI есть много общего (например, описание моделей).
Нет, это не "протокол", это "спецификация", аналогичная OpenAPI, но для асинхронных API.
Ну, и еще одно:
Мы его рассматривали. Но у него для нас есть критичные недостатки: инфраструктура вокруг него вся на JS и это еще один DSL.
Но часто приходят люди с нулевыми знаниями, которые даже навыков программирования не имеют – не знают, что такое условие, цикл и прочие штуки, очевидные для многих на старте.
И что происходит с таким студентом? Скорее всего, он просто споткнется где-то на 20% курса, разочаруется и забросит всё. Но это не значит, что не стоит продолжать для него, конечно же нет. Просто такому студенту курсы могут сильно навредить, сломать его самооценку и убить в нем саму идею входа в IT. Это очень серьезная проблема.
Такому студенту нужно идти на курсы, соответствующие его уровню, а не "курсы могут сильно навредить". Курсы разные бывают, если студент, который сразу записывается на курс по строительству межзвездных кораблей, ещё только окончил школу и не является гением от природы, то, проблема тут не в курсе.
Понимаю вас, здесь скорее претензия к тому, что не попробовав сделать правильно то, что проверено и обосновано (в свою очередь потому, что никто не хочет вникать как именно оно должно правильно работать - и это именно так и есть), начинаются попытки изобрести велосипед и подстроить его под свои процессы, вместо того, чтобы изменить, в первую очередь, свое мышление и за ним и выстроить правильный подход. Как говорится, вы даже не попытались сделать правильно, вникнуть и понять, а потом говорите, что оно не работает (это не вам).
Начали вы хорошо про "Изменение потребности или решения в момент реализации", но дальше все равно скатились в кашу. Попробую быть объективным, хотя за такое, да по такой теме здесь обычно отхватывают.
Вы, наверное, раз 20 написали "Agile" — Agile там, здесь, так и эдак. Однако Agile (если быть точным, то Agile-манифест разработки программного обеспечения) — это лишь набор ценностей и принципов, а не что-то, что говорит как именно эти ценности и принципы можно использовать. То есть вы долгое время в статье очень старательно избегаете того, чтобы называть конкретные методологии, которые основаны на этих ценностях и принципах и о которых и должна идти речь здесь, особенно учитывая то, что все они очень отличаются друг от друга. Никакого другого Agile за пределами существующих методологий просто нет, кто бы ни называл свою работу "выполняемой по Agile". Но, давайте я угадаю слово, "которое нельзя называть".
Итак, есть только три методологии, которые можно предполагать для основной части вашей статьи, потому что остальные очень маловероятны. Это Scrum, Kanban и XP (Extreme Programming). Можно было бы добавить Lean, но это вряд ли, особенно с учетом того, что это не совсем методология. Зная ключевые особенности каждой, ищем ключевые признаки в вашем тексте (я не насчитал таких 10 штук, но достаточно, чтобы однозначно идентифицировать преобладающую в вашей статье методологию).
Итак, Scrum — 5, Kanban — 3, XP — 2. Плюс из этих трех вы сами упомянули в конце первые две в примере. Таким образом, статья в основном повествует о Scrum. А теперь давайте пройдемся по некоторым вашим заявлениям, в том числе, с учетом этого.
Индикаторы того самого "недопонятого" Agile 2. Отсутствие менеджмента Недавно я общалась с менеджером продукта, который был недоволен работой системного аналитика.
Отсутствие менеджмента это недопонятый Agile, серьезно? Кто вообще такой этот "менеджер продукта"? В Scrum менеджмента нет. Менеджмент всегда есть в организации и его роль относительно Scrum в том, чтобы устранять препятствия, которые могут мешать Scrum Team to embrace (наверное, по-русски, это скорее принимать и воплощать) эту методологию, поддерживать Product Owner, обеспечивая его информацией о видении, миссии и целях компании, помогая (информацией) расставлять приоритеты (да, в беклоге), и вообще оказывать поддержку в целом и создавать соответствующую культуру. А не "менеджер продукта", который что-то там поручает аналитику.
Концепция самоорганизованности команд настолько привлекает владельцев продуктов, что становится оправданием отсутствия менеджера в команде.
Что? "Владелец продукта" у вас оправдывает (их же привлекает "идея") отсутствие "менеджера в команде", потому что одним из ключевых принципов является самоорганизующаяся команда? Тут даже комментировать нечего.
Пример, знакомый участнику любой IT команды. У вас есть инициативный разработчик, который пишет код, знает систему, распределяет задачи, общается с другими системами по интеграции и заведует техническим долгом и особенностями архитектуры. А потом он увольняется, и команда тратит пол года (хорошо, если столько, а не больше) на реверс-инжиниринг и на налаживание коммуникаций, которые сотрудник “забрал” с собой.
Хочется спросить, а остальные чем все это время занимались? Он что один за всех все делал в вашей "Agile" команде? Не знаю что вы там курите практикуете, но коммуникация и командная работа это то, что вообще в основе лежит. Вы же сами манифест цитировали, давайте еще поцитируем: "Люди и взаимодействие важнее процессов и инструментов", нет? Ну, а на планировании ваших спринтов явно только один инициативный разработчик присутствует, потому он все знает, а остальные написанные им задачи просто выполняют.
Однако, иногда команды попадают в цикл итераций, которые не приносят значимого сколь угодно финального результата с точки зрения ценности. Часто это происходит из-за неправильной декомпозиции требований. Чаще всего неправильная декомпозиция приводит к тому, что потребность клиента будет закрыта, но поздно, либо не закрыта вовсе.
Причем тут декомпозиция? Вы что делать собираетесь? Какую потребность пользователя удовлетворять? Если ваш Product Owner изначально неправильно определил и/или приоритезировал потребности этих самих пользователей, то как бы вы и в каких разрезах не декомпозировали это нечто, результат работы команды все равно никому будет не нужен.
руководитель команды считает, что ретро не нужно
Опять руководитель команды. Вы точно путаете понятия и после этого рассуждаете о том, что не так с Agile.
Индикаторы того самого "недопонятого" Agile 10. Слишком жёсткая привязка к инструментам и методологиям
А, то есть чем более точно вы следуете методологии, тем больше Agile становится недопонятным? Ок, нет смысла обсуждать даже.
Я очень радуюсь, когда слышу, что команда использует нечто под названием “скрамбан”. Для меня это означает, что команда изучила фреймворки, выбрала подходящие практики и адаптировала под свою работу.
Нет, все ровно наоборот. Это значит, что они их вообще не изучали, раз начали следовать непонятно чему, придуманному непонятно зачем. Я искренне пытался понять зачем это было придумано и чего из этого нет в более популярных методологиях, но так и не смог, потому что там нет ответов на этот вопрос. Мало того, за этим термином может скрываться любая непонятная система, придуманная "как смогли".
Я сама работала в команде, в которой мы начали со Scrum с двухнедельными спринтами. Потом мы осознали, что физически не успеваем поставить релиз в такой срок. Тогда мы сначала увеличивали длину спринтов, но всё равно было неудобно. Даже строили сложные конструкции в виде: спринт на разработку + спринт на стабилизацию релиза.
А причины искать не пытались? И устранять их потом? Явно нет, раз первым решением было увеличение "длины" спринтов, да еще и какие-то разные типы этих самых спринтов.
В общем ИМХО, навязываться не буду, минусующим рекомендую курить практиковать скрамбан)
Если вы заботитесь о своей приватности, вам стоит хотя бы отключить весь трекинг в Chrome. Но я решил пойти немного дальше. Я решил поменять браузер. Я пользуюсь хромом с детства, поэтому это решение было довольно тяжелым. Я привык к этому браузеру и мне он нравился. Теперь оставался вопрос: на какой перейти?
Так почему "решили пойти дальше"? Не увидел обоснования такого решения. Чем не устраивает просто отключение этих параметров? Не отключается, не работает должным образом, что? Зачем менять браузер, если можно просто отключить?
Верно то, что самоуправляемые ("self-organizing") команды должны стремиться решать свои проблемы самостоятельно. Но неверно утверждать, что участие Scrum-мастера в устранении препятствий не требуется. Scrum-мастер играет важную роль в выявлении и устранении проблем, возникающих в команде. Если Scrum-мастер игнорирует эти проблемы под предлогом предоставления команде "самостоятельного управления", это может привести к дальнейшим проблемам. Аналогично, например, стейкхолдеры не могут пренебрегать своими обязанностями, такими как предоставление видения по "высокоуровневым" целям или предоставление обратной связи по очередному инкременту (на ревью) и оправдывать это тем, что они предоставляют команде возможность "самоуправляться". Такие действия никак не способствуют самоуправлению команды, а представляют собой отказ от своих обязанностей перед командой.
Коллега, также как и вы планируете это делать из статьи на Хабре) Речь шла про сохранение статьи в PDF в связи с грядущими изменениями в полномочиях некоторых исполнительных органов, которые позволят этим органам блокировать сайты или отдельные ресурсы, содержащие информацию, как в этой статье)
Зачем? Подавляющее большинство людей понятия об этом не имеет, а значит для них (по мнению тех, кто такое придумал), это будет звучать достаточно убедительно.
Вначале удивили минусы самой статье (застал еще в минусах), потом первые комментарии — попробовал переосмыслить, но так и не понял. Прочел легко и быстро, нигде не зацепился, может потому что вникал в смысл, а не в изложение, хотя сам очень критично отношусь к написанию.
Статью подкинул Google в своей новостной ленте, это то, что меня интересует и спасибо автору за своевременную инфу. Особенно за некоторые юридические тонкости. Я все же готовлю презентацию, с пустыми руками не пойду, но если ничего не выйдет, теперь я знаю про еще один акселератор и Intch, за что тоже спасибо ? И вообще, все озвученное откликнулось внутри, потому что все те же вопросы ?
В то же время, хочу заметить, что Y Combinator предлагает лучшие условия — почти 200 тыс. USD за 7% компании и еще чуть более 300 тыс. USD на лучших условиях, на которых стартап привлечет финансирование в следующем раунде, это насколько я разобрался.
Planning Poker, Velocity, относительная оценка, которая выполняется не в часах, а в условных единицах, потому что классический проектный менеджмент в спринтах (которые есть только в Scrum и больше нигде) не работает, нет?
И, конечно, если вдруг вы претендуете на Agile, а похоже, что именно так, раз говорите про спринты, то вам точно следует узнать, что оценка производится командой для команды, а не для менеджмента. Потому что как только менеджмент начинает в это влезать, то получается как в той истории, когда высший менеджер сказал команде больше выполнять поинтов за спринт, а они просто начали оценивать пользовательские истории в других единицах, потому что реальный Velocity не просто так получается (как выше уже сказали).
Согласен со всем. Вот пытаюсь несколько лет продвинуться вперёд методом проб и ошибок и обнаружил, что, да, во-первых, это словарный запас, это первое и главное, во-вторых, это слушать - использую учебные курсы на LinkedIn с английскими субтитрами - складывается ощущение, что понимаю 90%, а что не понял, но понял, что не хватает для понимания контекста, можно остановить и перевести переводчиком, в-третьих, нужна разговорная практика, обязательно нужно говорить, поначалу может быть сложно себя преодолеть, но в какой-то момент стена падает и вы начинаете смело пытаться.
Если бы я получил такое письмо и прочёл бы "Фактические обстоятельства", в которых были бы изложены подобные формулировки, то подумал бы: "Что за идиот это написал?" ?♂️ Но писем я таких не получал ??♂️
Да ладно, у вас при просмотре YouTube флешка заполняется?) Если смотреть в HD или вообще 4K и много, будет выглядеть как вы описали, но "флешка не закончится".
А я думаю что литературу нужно читать в оригинале, тогда ни у кого никаких проблем, проверено лично)
Может читать и легче, только цель "облегчить вам чтение" не имеет смысла в контексте договора. При чтении договора вам важно понять в полной мере то, что изложено "сложно", а вот понимания в полной мере такое "лёгкое" чтиво вам все равно не даст, если вы не юрист. Вы просто не сможете учесть нюансы, которые вытекают из положений законов или просто в силу сложившейся правоприменительной практики. И тот факт, что вы этого не понимаете в своем комментарии только подтверждает истинность моего утверждения.
Похоже, что конвенция позволяет иметь только один коммит на задачу и никакой атомарности, ну, если только коммиты не отличаются компонентом.
У вас какая-то странная получилась история. Вроде бы и есть объяснение странностей, но от этого история не перестает быть странной. Складывается ощущение, что вы не до конца поняли что такое AsyncAPI.
Но это он и есть https://www.asyncapi.com/. Инструмент под названием "спецификация".
Нет, уже есть спецификация — AsyncAPI. Если вы считаете, что она "неполноценна" или что-то подобное, так присоединитесь и помогите https://github.com/asyncapi?type=source#-contribute-to-asyncapi, вместо того, чтобы изобретать велосипед.
Да, они и были сделаны в AsyncAPI https://www.asyncapi.com/docs/tutorials/getting-started/coming-from-openapi, а вы все еще изобретаете велосипед.
Нет, это не "протокол", это "спецификация", аналогичная OpenAPI, но для асинхронных API.
Ну, и еще одно:
Какая еще инфраструктура? О чем вы? Ну и не так все плохо с Java https://www.asyncapi.com/tools?pricing=free&langs=Java, в том числе с генерацией кода из дока на основе этой спецификации https://www.asyncapi.com/tools?pricing=free&langs=Java&categories=Code+Generators.
P.S. А, это я непонял — вы продвигаете "AxenAPI - разработка Axenix". Тогда все понятно)
Такому студенту нужно идти на курсы, соответствующие его уровню, а не "курсы могут сильно навредить". Курсы разные бывают, если студент, который сразу записывается на курс по строительству межзвездных кораблей, ещё только окончил школу и не является гением от природы, то, проблема тут не в курсе.
Эм, чего? Что такое по вашему "пластичность" мозга и почему это автоматически равно аморальности? Обосновать сможете?
Понимаю вас, здесь скорее претензия к тому, что не попробовав сделать правильно то, что проверено и обосновано (в свою очередь потому, что никто не хочет вникать как именно оно должно правильно работать - и это именно так и есть), начинаются попытки изобрести велосипед и подстроить его под свои процессы, вместо того, чтобы изменить, в первую очередь, свое мышление и за ним и выстроить правильный подход. Как говорится, вы даже не попытались сделать правильно, вникнуть и понять, а потом говорите, что оно не работает (это не вам).
Начали вы хорошо про "Изменение потребности или решения в момент реализации", но дальше все равно скатились в кашу. Попробую быть объективным, хотя за такое, да по такой теме здесь обычно отхватывают.
Вы, наверное, раз 20 написали "Agile" — Agile там, здесь, так и эдак. Однако Agile (если быть точным, то Agile-манифест разработки программного обеспечения) — это лишь набор ценностей и принципов, а не что-то, что говорит как именно эти ценности и принципы можно использовать. То есть вы долгое время в статье очень старательно избегаете того, чтобы называть конкретные методологии, которые основаны на этих ценностях и принципах и о которых и должна идти речь здесь, особенно учитывая то, что все они очень отличаются друг от друга. Никакого другого Agile за пределами существующих методологий просто нет, кто бы ни называл свою работу "выполняемой по Agile". Но, давайте я угадаю слово, "которое нельзя называть".
Итак, есть только три методологии, которые можно предполагать для основной части вашей статьи, потому что остальные очень маловероятны. Это Scrum, Kanban и XP (Extreme Programming). Можно было бы добавить Lean, но это вряд ли, особенно с учетом того, что это не совсем методология. Зная ключевые особенности каждой, ищем ключевые признаки в вашем тексте (я не насчитал таких 10 штук, но достаточно, чтобы однозначно идентифицировать преобладающую в вашей статье методологию).
Что у нас есть по ключевым словам / терминам:
Scrum: "самоорганизованной команды" (правильно самоорганизующаяся, а не самоорганизованная); "владельцев продуктов"; "итерации"; "инкременты"; "ретроспективы"
Kanban: "самоорганизованной команды"; "итерации"; "ретроспективы"
XP: "самоорганизованной команды"; "итерации"
Итак, Scrum — 5, Kanban — 3, XP — 2. Плюс из этих трех вы сами упомянули в конце первые две в примере. Таким образом, статья в основном повествует о Scrum. А теперь давайте пройдемся по некоторым вашим заявлениям, в том числе, с учетом этого.
Отсутствие менеджмента это недопонятый Agile, серьезно? Кто вообще такой этот "менеджер продукта"? В Scrum менеджмента нет. Менеджмент всегда есть в организации и его роль относительно Scrum в том, чтобы устранять препятствия, которые могут мешать Scrum Team to embrace (наверное, по-русски, это скорее принимать и воплощать) эту методологию, поддерживать Product Owner, обеспечивая его информацией о видении, миссии и целях компании, помогая (информацией) расставлять приоритеты (да, в беклоге), и вообще оказывать поддержку в целом и создавать соответствующую культуру. А не "менеджер продукта", который что-то там поручает аналитику.
Что? "Владелец продукта" у вас оправдывает (их же привлекает "идея") отсутствие "менеджера в команде", потому что одним из ключевых принципов является самоорганизующаяся команда? Тут даже комментировать нечего.
Хочется спросить, а остальные чем все это время занимались? Он что один за всех все делал в вашей "Agile" команде? Не знаю что вы там
куритепрактикуете, но коммуникация и командная работа это то, что вообще в основе лежит. Вы же сами манифест цитировали, давайте еще поцитируем: "Люди и взаимодействие важнее процессов и инструментов", нет? Ну, а на планировании ваших спринтов явно только один инициативный разработчик присутствует, потому он все знает, а остальные написанные им задачи просто выполняют.Причем тут декомпозиция? Вы что делать собираетесь? Какую потребность пользователя удовлетворять? Если ваш Product Owner изначально неправильно определил и/или приоритезировал потребности этих самих пользователей, то как бы вы и в каких разрезах не декомпозировали это нечто, результат работы команды все равно никому будет не нужен.
Опять руководитель команды. Вы точно путаете понятия и после этого рассуждаете о том, что не так с Agile.
А, то есть чем более точно вы следуете методологии, тем больше Agile становится недопонятным? Ок, нет смысла обсуждать даже.
Нет, все ровно наоборот. Это значит, что они их вообще не изучали, раз начали следовать непонятно чему, придуманному непонятно зачем. Я искренне пытался понять зачем это было придумано и чего из этого нет в более популярных методологиях, но так и не смог, потому что там нет ответов на этот вопрос. Мало того, за этим термином может скрываться любая непонятная система, придуманная "как смогли".
А причины искать не пытались? И устранять их потом? Явно нет, раз первым решением было увеличение "длины" спринтов, да еще и какие-то разные типы этих самых спринтов.
В общем ИМХО, навязываться не буду, минусующим рекомендую
куритьпрактиковать скрамбан)Так почему "решили пойти дальше"? Не увидел обоснования такого решения. Чем не устраивает просто отключение этих параметров? Не отключается, не работает должным образом, что? Зачем менять браузер, если можно просто отключить?
Думаю, вы перегибаете палку в одну сторону.
Верно то, что самоуправляемые ("self-organizing") команды должны стремиться решать свои проблемы самостоятельно. Но неверно утверждать, что участие Scrum-мастера в устранении препятствий не требуется. Scrum-мастер играет важную роль в выявлении и устранении проблем, возникающих в команде. Если Scrum-мастер игнорирует эти проблемы под предлогом предоставления команде "самостоятельного управления", это может привести к дальнейшим проблемам. Аналогично, например, стейкхолдеры не могут пренебрегать своими обязанностями, такими как предоставление видения по "высокоуровневым" целям или предоставление обратной связи по очередному инкременту (на ревью) и оправдывать это тем, что они предоставляют команде возможность "самоуправляться". Такие действия никак не способствуют самоуправлению команды, а представляют собой отказ от своих обязанностей перед командой.
Про запрет GitHub думать не хочется, но при таком подходе когда-то может и дойти.
Коллега, также как и вы планируете это делать из статьи на Хабре) Речь шла про сохранение статьи в PDF в связи с грядущими изменениями в полномочиях некоторых исполнительных органов, которые позволят этим органам блокировать сайты или отдельные ресурсы, содержащие информацию, как в этой статье)
Сохраняю в PDF пока можно. Если будет нужно - пишите, пришлю на почту.
P.S. Вообще шучу, но не смешно.
Зачем? Подавляющее большинство людей понятия об этом не имеет, а значит для них (по мнению тех, кто такое придумал), это будет звучать достаточно убедительно.
Несомненно, главное не забывать для чего и для кого это выполняется)
Вначале удивили минусы самой статье (застал еще в минусах), потом первые комментарии — попробовал переосмыслить, но так и не понял. Прочел легко и быстро, нигде не зацепился, может потому что вникал в смысл, а не в изложение, хотя сам очень критично отношусь к написанию.
Статью подкинул Google в своей новостной ленте, это то, что меня интересует и спасибо автору за своевременную инфу. Особенно за некоторые юридические тонкости. Я все же готовлю презентацию, с пустыми руками не пойду, но если ничего не выйдет, теперь я знаю про еще один акселератор и Intch, за что тоже спасибо ? И вообще, все озвученное откликнулось внутри, потому что все те же вопросы ?
В то же время, хочу заметить, что Y Combinator предлагает лучшие условия — почти 200 тыс. USD за 7% компании и еще чуть более 300 тыс. USD на лучших условиях, на которых стартап привлечет финансирование в следующем раунде, это насколько я разобрался.
Planning Poker, Velocity, относительная оценка, которая выполняется не в часах, а в условных единицах, потому что классический проектный менеджмент в спринтах (которые есть только в Scrum и больше нигде) не работает, нет?
И, конечно, если вдруг вы претендуете на Agile, а похоже, что именно так, раз говорите про спринты, то вам точно следует узнать, что оценка производится командой для команды, а не для менеджмента. Потому что как только менеджмент начинает в это влезать, то получается как в той истории, когда высший менеджер сказал команде больше выполнять поинтов за спринт, а они просто начали оценивать пользовательские истории в других единицах, потому что реальный Velocity не просто так получается (как выше уже сказали).
Согласен со всем. Вот пытаюсь несколько лет продвинуться вперёд методом проб и ошибок и обнаружил, что, да, во-первых, это словарный запас, это первое и главное, во-вторых, это слушать - использую учебные курсы на LinkedIn с английскими субтитрами - складывается ощущение, что понимаю 90%, а что не понял, но понял, что не хватает для понимания контекста, можно остановить и перевести переводчиком, в-третьих, нужна разговорная практика, обязательно нужно говорить, поначалу может быть сложно себя преодолеть, но в какой-то момент стена падает и вы начинаете смело пытаться.
Если бы я получил такое письмо и прочёл бы "Фактические обстоятельства", в которых были бы изложены подобные формулировки, то подумал бы: "Что за идиот это написал?" ?♂️ Но писем я таких не получал ??♂️