Евгений, это был большой труд. Но нажав "минус", мне нужно бы объясниться.
Очень неравномерный набор требований. Есть и из организации работы (CI/CD), есть из архитектуры, а есть и глубокие частности (модальное окно). Это рассчитано на одного читателя?
Но главное - все определения правильные и отличные с точки зрения человека, кто уже знает. Я прочитал - да, правильно, отлично. И что? Это как взять хеш от моих знаний и от Ваших и сравнить: сошлось - зачёт (как на экзамене в ВУЗе). Но статья для новичков. Прочитав эталонные описания, умеют они понять? Сам ежедневно решаю эту проблему и не знаю, правильно ли. Иногда получается :)
И тем не менее, статья - лучше, чем её отсутствие :)
контент, который «неточно отображает местоположение или продукт, о котором идёт речь»,
Ха, неточно отображает продукт :)
Я на Авито искал дачные участки. На фото у 99% предложений в обязательном морядке: монастырь/храм; берег озера; магазин Пятёрочка (всё это - в 15 км) ; въездные ворота в поселок; детская площадка; грибы, ягоды. Фото самого участка - ну в половине случаев. Извините, наболело
Вы думаете, "конструктивно критика" - это только указание на конкретные ошибки? Увы, иногда "низкий уровень материала" - это тоже конструктивно критика.
Если Вы писали этот текст, чтобы зафинализировать собственное исследование в теме наличных, безналичный и цифровых денег - это здорово. И здорово что написали такой дисклеймер в начале.
Но если этот текст попадётся человеку не из отрасли, который захочет за десять минут разобраться в теме - то это будет грех дезинформации, увы
Из треугольника функциональность-деньги-время в водопадных проектах обычно ограничивается функциональность и деньги, поэтому сдвинуться (а сдвигается всегда в одну сторону) могут только сроки, но тут возникает желание их ограничить - вот и горячка в конце проекта.
В случае инкоементально-итеративного подхода сроки могут быть ограничены, верно, но функциональность может плавать. В любом случае к дедлайну (который определён планом, рынком, конференцией, договором с партнёрами..) основная функциональность будет поставлена и уже работать.
qRPC - конкретный фреймворк и протокол. А паттерн интеграции - RPC
Паттернов интеграции, видимо, всего 4: файлообмен; shared db, RPC, message.
А HTTP(s) - это конкретный протокол (на котором построено множество разных RPC). Использование HTTP не ограничивается передачей веб-странички браузеру и вообще не ограничивается "передачей данных в сети Интернет". Компоненты одной системы вполне себе могут быть интегрированы по какому-нибудь RPC и взаимодействовать по HTTP внутри своего интранета.
Push-каналы - асинхронная модель событийной передачи данных
При http-request в ответе возвращается верстка. Т.е. мы зависим от форматирования, от тегов, от стилей. Соответственно, если поставщик данных поменяет верстку, все поломается.
При использовании HTTP всегда в ответе передаётся веб-страница? Мой вам ответ на это:
267 Сомнительно, но окей
И еще: HTTP и push вы считаете отдельными типами интеграции. Они не укладываются в паттерн RPC/API?
С одной стороны, мне неудобно устраивать бесцеремонную критику статьи прямо в первых комментариях, но, @moneta_team , я не согласен. Пример с походом в магазин - это антипример работы с беклогом, работы в инкрементально-итеративном подходе.
Беклог - отсортированный список полезных вещей, которые нужно сделать. Каждый элемент беклога а) имеет ценность сам по себе б) достаточно маленького размера, чтобы успеть сделать за итерацию и в) состоит из одной фичи, а не набора; это сделано для концентрации команды и возможности "поставлять на прод чаще". Беклог сортируется не обязательно по принципу Must Have сверху. Сверху - "имеющее наибольшую ценность для клиента сейчас" по мнению Владельца продукта.
Так вот, вылазка в магазин - это ОДИН элемент беклога. А список продуктов - результат планирования спринта, когда вы сформулировали сабтаски. Набор покупок (сабтасков) можно определить перед началом спринта, взяв в задачу только важные вещи, которые успеем купить (хватит денег, сумеем вывезти, ...), а другие хотелки выделить в новый элемент беклога (поход в магазин).
Так что беклог на бытовом примере выглядит так:
Купить важные продукты (и внутри список от Must Have до Should Have, например)
Купить стол и кресло
Купить сладости и вкусности (и внутри список Could Have, например)
Починить тормоза у машины
Оплата ЖКУ
Допэлектрика у машины (парктроник, камера)
Вы рассматриваете лимит только на один ресурс - деньги, и "берете в работу" только те покупки, на которые хватит бюджета. Отлично, а как же время? Производительность команды? Ограничения по компетенциям команды? Если спринт у вас сегодня кончается в 13:00 и цель спринта - пообедать хоть чем-то?
Элементы 1, 2, 3 выполняются в одном магазине и есть соблазн их затащить в одну работу. Но идея беклога и инкрементально-итеративного подхода в том, что если вы сольёте в одну покупку и жизненно-важные крупы, и сладости, и мебель - у вас может не хватить ресурсов и лучше делать эти три нужные вещи поодиночке, хотя в сумме выйдет больше времени и денег. Есть ведь ограничения:
денег. Ну тут все понятно, вы их сразу увидите. Предположим даже, что денег много;
времени на выполнение: дорога туда-обратно, хождение по магазину, оплата, упаковка, поднять домой, сварить макароны;
места в машине: может быть, вместятся (пакеты с макаронами И пакеты со сладостями) ИЛИ (вместится мебель) и потребуется две поездки - это производительность;
компетенций (сил носить): приехав домой, обнаружите, что стол в одиночку донести на этаж не сможете, а уйти с пакетами варить макароны и оставить стол привязанным к багажнику (незавершенное производство) нельзя: украдут.
И вы не сделаете обед к 13:00, как планировали. Перепрыгните большую пропасть, но на 75%
Вам смешно, а пока я читал статью пришли ценные указания от жены: "калину посадим в метре от дорожки на уровне дальнего края малины". Не удержался и процитировал в ответ Стивенсона из комментария ниже. Готовлюсь ночевать на диване.
Я увидел newton в каком-то фильме и тут же понял, как будет выглядеть моё будущее: офис не обязателен для работы, где я - там и мой офис. В 2000 купил первый Palm и все так и случилось. А Ньютона, кадр которого меня вдохновилась, у меня так никогда и не было :(
Евгений, я как раз имел в виду обратное.
Но это моё видение.
И если Ваши глоссарии работают - рад, что я ошибаюсь (практика - критерий истинности)
Евгений, это был большой труд. Но нажав "минус", мне нужно бы объясниться.
Очень неравномерный набор требований. Есть и из организации работы (CI/CD), есть из архитектуры, а есть и глубокие частности (модальное окно). Это рассчитано на одного читателя?
Но главное - все определения правильные и отличные с точки зрения человека, кто уже знает. Я прочитал - да, правильно, отлично. И что? Это как взять хеш от моих знаний и от Ваших и сравнить: сошлось - зачёт (как на экзамене в ВУЗе). Но статья для новичков. Прочитав эталонные описания, умеют они понять? Сам ежедневно решаю эту проблему и не знаю, правильно ли. Иногда получается :)
И тем не менее, статья - лучше, чем её отсутствие :)
Переводчик / копирайтер был не инженер :(
Ха, неточно отображает продукт :)
Я на Авито искал дачные участки. На фото у 99% предложений в обязательном морядке: монастырь/храм; берег озера; магазин Пятёрочка (всё это - в 15 км) ; въездные ворота в поселок; детская площадка; грибы, ягоды. Фото самого участка - ну в половине случаев. Извините, наболело
Вы думаете, "конструктивно критика" - это только указание на конкретные ошибки? Увы, иногда "низкий уровень материала" - это тоже конструктивно критика.
Если Вы писали этот текст, чтобы зафинализировать собственное исследование в теме наличных, безналичный и цифровых денег - это здорово. И здорово что написали такой дисклеймер в начале.
Но если этот текст попадётся человеку не из отрасли, который захочет за десять минут разобраться в теме - то это будет грех дезинформации, увы
Из треугольника функциональность-деньги-время в водопадных проектах обычно ограничивается функциональность и деньги, поэтому сдвинуться (а сдвигается всегда в одну сторону) могут только сроки, но тут возникает желание их ограничить - вот и горячка в конце проекта.
В случае инкоементально-итеративного подхода сроки могут быть ограничены, верно, но функциональность может плавать. В любом случае к дедлайну (который определён планом, рынком, конференцией, договором с партнёрами..) основная функциональность будет поставлена и уже работать.
Купили мы с друзьями несколько ящиков пива (по 20 бутылок) и, открывая двадцатую бутылку, говорим: ооо, второй ящик начали
История из тех же лет, кстати )
Я все же еще побрюзжу
qRPC - конкретный фреймворк и протокол. А паттерн интеграции - RPC
Паттернов интеграции, видимо, всего 4: файлообмен; shared db, RPC, message.
А HTTP(s) - это конкретный протокол (на котором построено множество разных RPC). Использование HTTP не ограничивается передачей веб-странички браузеру и вообще не ограничивается "передачей данных в сети Интернет". Компоненты одной системы вполне себе могут быть интегрированы по какому-нибудь RPC и взаимодействовать по HTTP внутри своего интранета.
паттерн Message?
При использовании HTTP всегда в ответе передаётся веб-страница? Мой вам ответ на это:
И еще: HTTP и push вы считаете отдельными типами интеграции. Они не укладываются в паттерн RPC/API?
Увы, не смог понять ваш ответ
С одной стороны, мне неудобно устраивать бесцеремонную критику статьи прямо в первых комментариях, но, @moneta_team , я не согласен. Пример с походом в магазин - это антипример работы с беклогом, работы в инкрементально-итеративном подходе.
Беклог - отсортированный список полезных вещей, которые нужно сделать. Каждый элемент беклога а) имеет ценность сам по себе б) достаточно маленького размера, чтобы успеть сделать за итерацию и в) состоит из одной фичи, а не набора; это сделано для концентрации команды и возможности "поставлять на прод чаще".
Беклог сортируется не обязательно по принципу Must Have сверху. Сверху - "имеющее наибольшую ценность для клиента сейчас" по мнению Владельца продукта.
Так вот, вылазка в магазин - это ОДИН элемент беклога. А список продуктов - результат планирования спринта, когда вы сформулировали сабтаски. Набор покупок (сабтасков) можно определить перед началом спринта, взяв в задачу только важные вещи, которые успеем купить (хватит денег, сумеем вывезти, ...), а другие хотелки выделить в новый элемент беклога (поход в магазин).
Так что беклог на бытовом примере выглядит так:
Купить важные продукты (и внутри список от Must Have до Should Have, например)
Купить стол и кресло
Купить сладости и вкусности (и внутри список Could Have, например)
Починить тормоза у машины
Оплата ЖКУ
Допэлектрика у машины (парктроник, камера)
Вы рассматриваете лимит только на один ресурс - деньги, и "берете в работу" только те покупки, на которые хватит бюджета. Отлично, а как же время? Производительность команды? Ограничения по компетенциям команды? Если спринт у вас сегодня кончается в 13:00 и цель спринта - пообедать хоть чем-то?
Элементы 1, 2, 3 выполняются в одном магазине и есть соблазн их затащить в одну работу. Но идея беклога и инкрементально-итеративного подхода в том, что если вы сольёте в одну покупку и жизненно-важные крупы, и сладости, и мебель - у вас может не хватить ресурсов и лучше делать эти три нужные вещи поодиночке, хотя в сумме выйдет больше времени и денег.
Есть ведь ограничения:
денег. Ну тут все понятно, вы их сразу увидите. Предположим даже, что денег много;
времени на выполнение: дорога туда-обратно, хождение по магазину, оплата, упаковка, поднять домой, сварить макароны;
места в машине: может быть, вместятся (пакеты с макаронами И пакеты со сладостями) ИЛИ (вместится мебель) и потребуется две поездки - это производительность;
компетенций (сил носить): приехав домой, обнаружите, что стол в одиночку донести на этаж не сможете, а уйти с пакетами варить макароны и оставить стол привязанным к багажнику (незавершенное производство) нельзя: украдут.
И вы не сделаете обед к 13:00, как планировали. Перепрыгните большую пропасть, но на 75%
Готов обсудить
Прочитал и поругал себя, зачем я полез на пикабу с утра. А стоп! Это на Хабре?!
Именно
Потому что через СП пытаемся решить проблему (якобы) невозможности планировать сроки
Вам смешно, а пока я читал статью пришли ценные указания от жены: "калину посадим в метре от дорожки на уровне дальнего края малины". Не удержался и процитировал в ответ Стивенсона из комментария ниже. Готовлюсь ночевать на диване.
Я увидел newton в каком-то фильме и тут же понял, как будет выглядеть моё будущее: офис не обязателен для работы, где я - там и мой офис. В 2000 купил первый Palm и все так и случилось. А Ньютона, кадр которого меня вдохновилась, у меня так никогда и не было :(
Когда комментарий полезнее статьи (и написан лучше)
... как системная аналитика вместо анализа ;)
Верно, не всё пользовательская история, что написано по шаблону "я, как А, хочу Б...".
"задача требует простого как таракан решения", дальше серьезно читать не смог