Мне кажется, что если дать развёрнутый комментарий к статье, то он будет больше самого текста.
Поэтому напишу кратко:
Автору спасибо за затронутую тему — тема интересная и актуальная, надеюсь серия будет продолжена.
Согласен с тезисом, что давать читателю ту информацию, которая соответствует области его интересов наиболее корректно. Только, как мне кажется, это относится в первую очередь к специализированным stakeholders, а часто бывает запрос от топ-а или какого-нить заказчика такой «дайте, пожалуйста, информацию про систему одной картинкой, ну максимум двумя — чтобы всё ключевое было отражено» — и такая bullshit диаграмма как раз должна быть очень полезна (возможно, что делать её нужно не архитектору, а команде из архитектора, дизайнера и т.п.) — делают же инфографику по сложным всяким штукам. Так что и такие диаграммы нужны. То, что не удалось автору на первой диаграмме показать все аспекты – ну что ж, есть куда развиваться .
Касательно примеров. Текст примеров и вопросы, которые должны быть отражены на соответствующих диаграммах вполне понятны, тогда как сами диаграммы получения ответов на вопросы требуют усилия. Например, деплоймент — из него должно быть понятно, что, где и как размещено.
Ок, что мы видим на диаграмме:
браузер
Протокол HTTPs
Google Cloud Platform
Регион – Европа (уже надо приложить усилия, чтобы понять – а зачем здесь регион?)
Сеть по-умолчанию (зачем она нужна здесь?)
Вычислительный узел (что это?)
Cloud IAM
И три пиктограммы – шестиугольники – два побольше, один поменьше (и опять непонятно, что это)
А что должна показать диаграмма по мнению автора
« В основном она отвечает на вопрос, сколько денег примерно стоит решение (20-30 долларов в месяц в зависимости от региона и размера виртуальной машины), видно, что оно плохо масштабируется и требует перепроектирования в случае резкого увеличения нагрузки. Кроме того, нет резервной копии БД.».
Давайте разберём:
Из диаграммы не следуют стоимость — просто потому, что там она не указана. Скорее стоимость будет указана не на диаграмме, а документедокументе с расчётом общей стоимости владения системой или стоимостью её обслуживания (именно это будет интересно спонсору, а не диаграмма развёртывания), где будут расписаны все статьи расходов — инфраструктура, лицензии, саппорт и т.п… Напротив, из самой первой диаграммы хотя бы можно понять, что это именно виртуальная машина GCP, что какие специалисты возможно потребуются для обслуживания
Из диаграммы не очевидно, плохо или хорошо может быть масштабируемо решение (так как не понятно, что такое вычислительный узел и что он в себя включает) и скорее всего для понимания этого, нужно указать в явном виде, что вычислительный узел только один или же наоборот их может быть несколько.
Из диаграммы не видно не то, что нет резервной копии БД, а даже что такая БД есть. Зато это видно из первой диаграммы, которая приведена в качестве примера «как не стоит делать».
Ну и уж конечно не видно (на мой, разумеется, взгляд), что решение требует перепроектирования в случае резкого увеличения нагрузки.
В общем, здорово, что статья написана, и несколько досадно, что здравая мысль ( о том, что информация должна быть адресной — каждому читателю свой срез системы) была несколько небрежно проиллюстрирован и тем самым может быть подвергнута сомнению в своей полезности. Надеюсь, в следующей статье автор сосредоточиться и приведёт более наглядные примеры и не будет без связи со статьёй упоминать свой блог.
P.S.
А причём здесь hub GCP? нет ни слова, связанного с какими-то аспектами работы GCP (с тем же успехом, здесь можно оставить любого облачного провайдера, предоставляющего IaaS).
У меня три вопроса: один к автору и два ко всем.
К автору: вы пишите
«Принципиальный момент состоит в том, что даты релизов впоследствии не меняются. Если версия запланирована на какую-то дату, то мы должны разбиться в лепешку, но выдержать запланированный срок.»
как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).
Ко всем:
Уважаемые коллеги, понимаю, что тема острая, но есть ли что-то по сути статьи сказать? Можно вычеркнуть при прочтении «ГИС ЖКХ» и читать как «Большие/маленькие/средние проекты/системы» (кому-что нравится). Вот мне понравился вопрос
«Но мне было бы интереснее узнать от пользователей с опытом работы в вашей системе повлияли ли на них как-либо частые релизы ГИС ЖКХ… »
. Правда, на мой взгляд, основная идея статьи о том, как упорядочить хаос в процессе разработке и сделать процесс предсказуемым.
Примеряя на себя статью, появилась мысль (наверняка, не новая — как и многое в этом мире) — а если релизы ранжировать по сложности изменений: мелочь — раз в неделю, среднее — раз в месяц, а совсем большое — квартал или реже? Кто-то подход такое реализовывал и можно ли кратко поделиться результатами?
Спасибо за комментарий.
Диаграммы классов мы используем – они на картинке с метамоделью в её правой части. Просто отображены без атрибутов и методов.
Вопрос наполнения репозитория согласно метамодели – вопрос конкретного проекта.
Но, как правило, тот, кто реализует постановки (а не ставит их или проектирует каркас приложения – базовые классы, интерфейсы, правила взаимодействия – словом, формирует дизайн ПО), не изменяет наполнения репозитория и соответствующие диаграммы.
Встречный вопрос: какие из функций EA мы, на ваш взгляд, недоиспользовали?
Вопрос — если не секрет, а вы как считаете бюждеты — из Jira данные в Payroll-систему идут? Или выгрузки загрузки руками ПМов?
Отвечу кратко, потому что эта тема достойна отдельной заметки. Мы ведём учёт трудозатрат по проектам. Уровень гранулярности, правила списания трудозатрат от проекта и инструменты учёта от проекта к проекту могут различаться. В итоге они все «сливаются» в одну систему учёта, фиксированную для проекта. Наверняка, это происходит автоматически (сам никогда не интересовался, но, поскольку мы в принципе стараемся избегать ручных операций в своей работе, я вряд ли ошибусь). Имея трудозатраты и ставки, мы можем получить всё остальное – текущие расходы, сопоставления плана и факта, учесть при необходимости в бухгалтерских расчётах.
P.S. прошу прощения, случайно ответил не тот комментарий — пока не очень опытный пользователь хабра в части комментариев и статей.
Только на уровне «почитать», в практическом плане не рассматривали – все потребности закрыты текущей схемой работы. Возможно, в будущем, в качестве эксперимента попробуем применить.
Про презентации и заказчиков: Да, согласны, заказчики не любят сложные презентации. Мы такие и не делаем. Но когда речь идёт про обоснование трудозатрат и сроков, показать матрицу зависимостей бывает полезно, это помогает показать масштаб потенциальных изменений. Собственно, вопрос «Почему не за один день?" (утрирую, конечно), уже ставится не ребром, и возникает более конструктивное обсуждение. Заказчик становится причастным к деталям и причинно-следственных связям, что всем полезно, на наш взгляд.
Про инструменты: В своей работе мы используем разного рода инструменты — зависит от специфики проекта, масштаба, команды и т.п. EA больше про то, чтобы сложить в одном месте большинство артефактов жизненного цикла системы — требования, архитектуру, дизайн, постановки и т.п. Если говорить про закрытие договора, то зачастую результаты работ явно описаны – как правило, это набор документов + ПО. Документы (часть документов – проектные решения, спецификации, ТЗ – мы можем выгрузить из EA) должны быть проверены соответствующими специалистами заказчика. ПО должно быть проверено в ходе ряда испытаний. То есть ЕА мы используем как источник части отчётных документов.
Про задачи: Задачи мы ставим через jira. В задаче (кроме обычного описания, версий и прочего) указывается путь (просто как текст) в проект EA к постановке (2.2.4. Про постановки) или её части (если задача для конкретного разработчика более мелкая, чем постановка). Интеграции из jira в EA, к сожалению, у нас нет: нельзя кликнуть на путь и открыть проект или его часть.
Спасибо за заметку. А можно показать явно, где описан «опыт внедрения, поддержки и удержания предметной модели в концептуальных контурах»? И заодно пояснить, что такое предметная модель — или это модель предметной области?
Поэтому напишу кратко:
Ок, что мы видим на диаграмме:
А что должна показать диаграмма по мнению автора Давайте разберём:
В общем, здорово, что статья написана, и несколько досадно, что здравая мысль ( о том, что информация должна быть адресной — каждому читателю свой срез системы) была несколько небрежно проиллюстрирован и тем самым может быть подвергнута сомнению в своей полезности. Надеюсь, в следующей статье автор сосредоточиться и приведёт более наглядные примеры и не будет без связи со статьёй упоминать свой блог.
P.S.
А причём здесь hub GCP? нет ни слова, связанного с какими-то аспектами работы GCP (с тем же успехом, здесь можно оставить любого облачного провайдера, предоставляющего IaaS).
К автору: вы пишите как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).
Ко всем:
Диаграммы классов мы используем – они на картинке с метамоделью в её правой части. Просто отображены без атрибутов и методов.
Вопрос наполнения репозитория согласно метамодели – вопрос конкретного проекта.
Но, как правило, тот, кто реализует постановки (а не ставит их или проектирует каркас приложения – базовые классы, интерфейсы, правила взаимодействия – словом, формирует дизайн ПО), не изменяет наполнения репозитория и соответствующие диаграммы.
Встречный вопрос: какие из функций EA мы, на ваш взгляд, недоиспользовали?
Отвечу кратко, потому что эта тема достойна отдельной заметки. Мы ведём учёт трудозатрат по проектам. Уровень гранулярности, правила списания трудозатрат от проекта и инструменты учёта от проекта к проекту могут различаться. В итоге они все «сливаются» в одну систему учёта, фиксированную для проекта. Наверняка, это происходит автоматически (сам никогда не интересовался, но, поскольку мы в принципе стараемся избегать ручных операций в своей работе, я вряд ли ошибусь). Имея трудозатраты и ставки, мы можем получить всё остальное – текущие расходы, сопоставления плана и факта, учесть при необходимости в бухгалтерских расчётах.
P.S. прошу прощения, случайно ответил не тот комментарий — пока не очень опытный пользователь хабра в части комментариев и статей.
Спасибо за комментарии – учту на будущее.
Теперь к ответам и ремаркам:
Про презентации и заказчиков: Да, согласны, заказчики не любят сложные презентации. Мы такие и не делаем. Но когда речь идёт про обоснование трудозатрат и сроков, показать матрицу зависимостей бывает полезно, это помогает показать масштаб потенциальных изменений. Собственно, вопрос «Почему не за один день?" (утрирую, конечно), уже ставится не ребром, и возникает более конструктивное обсуждение. Заказчик становится причастным к деталям и причинно-следственных связям, что всем полезно, на наш взгляд.
Про инструменты: В своей работе мы используем разного рода инструменты — зависит от специфики проекта, масштаба, команды и т.п. EA больше про то, чтобы сложить в одном месте большинство артефактов жизненного цикла системы — требования, архитектуру, дизайн, постановки и т.п. Если говорить про закрытие договора, то зачастую результаты работ явно описаны – как правило, это набор документов + ПО. Документы (часть документов – проектные решения, спецификации, ТЗ – мы можем выгрузить из EA) должны быть проверены соответствующими специалистами заказчика. ПО должно быть проверено в ходе ряда испытаний. То есть ЕА мы используем как источник части отчётных документов.