Size: a a a

Архитектура ИТ-решений

2020 August 05

F

Fagor in Архитектура ИТ-решений
Rms это на аналитиков бизнес, с интеграцией в фитчи таск трекера и к тестерам в итоге. Тогда будет поддерживаться в естественном порядке.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Но с этим быстрым переключением контекста между задачами и выдачей решений я себя чувствую вот так:
https://youtu.be/4SDN8TYaCIY
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Олег Игонин
Я попытался возродить это движение, но очень быстро забил, т.к. только я и архитектор разбирались в Archimate.
Работает, если можно в терминах Archimate выражать условные "квадратики" и "стрелочки" с диаграмм в Визио)
источник
2020 August 06

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Если архимейт понятен только посвященным, то вам пора менять подход. Делать частичные представления, упрощать нотацию.
Для меня сейчас важнее стало качество “понятно” чем “правильно”.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Популярная отмазка современности на любую работу которую не хочется делать: “у нас MVP”
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Roman Tsirulnikov
Популярная отмазка современности на любую работу которую не хочется делать: “у нас MVP”
Возможно надо менять понимание MVP? У Instagram MVP был сделан за пару дней. Прототип оптической мышки сделали за послеобеденное время и потратили пару баксов на зап. части.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Интересные примеры успешных MVP:
https://softwarebrothers.co/blog/15-examples-of-successful-mvps/

Хотя, конечно, это не значит, что скопировав, будет такой же успех.
Но просто для примера и вдохновения, мне кажется, полезно.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Roman Tsirulnikov
Если архимейт понятен только посвященным, то вам пора менять подход. Делать частичные представления, упрощать нотацию.
Для меня сейчас важнее стало качество “понятно” чем “правильно”.
Я считаю, что необходимость в archimate появляется с момента преодоления определённого уровня сложности системы и рабочего окружения.
При этом, границу можно отодвигать разбиением архитектуры на микросервисы, хорошей документацией правильного уровня абстракции, уменьшением ротации специалистов.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Т.е. сложность растёт, а мы стараемся её упростить - схемами, структурами хранения требований, общим осознанием архитектуры и решаемых проблем.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
С определённого момента (обычно хорошо видно в банках), сложность возрастает сильно из-за ограничений сервисов (скорость выполнения запросов, качество данных, отказоустойчивость, прочая нефункциональщина). И сам сервис становится тяжеловесным с кучей юз-кейсов и сложной логикой. Вот тут появляется НЕОБХОДИМОСТЬ нового уровня абстракции над документацией в виде Archimate, который ужесточает правила ведения документации, дополняет и объединяет её.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Я к тому, что пока необходимости нет, Archimate - это 5-е колесо в машине.
Это как случай, когда вы можете сделать сервис со своей командой в знакомом языке, но вы решаете попробовать что-то новое просто потому, что захотелось.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Alexander Teterkin
Возможно надо менять понимание MVP? У Instagram MVP был сделан за пару дней. Прототип оптической мышки сделали за послеобеденное время и потратили пару баксов на зап. части.
за ссылку спасибо. MVP это быстрый прототип из подручных материалов, который, если гипотеза успешна, выбрасывается. Далее делается полноценное решение.
Головной боли архитектору доставляет желание быстро накостылять в рабочих core-системах, чтобы попробовать новую фичу продукта.
Потом такие костыли живут десятилетиями, отравляя жизнь многим людям.
Правило инженера: у тебя есть только один шанс сделать как следует
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
С определённого момента (обычно хорошо видно в банках), сложность возрастает сильно из-за ограничений сервисов (скорость выполнения запросов, качество данных, отказоустойчивость, прочая нефункциональщина). И сам сервис становится тяжеловесным с кучей юз-кейсов и сложной логикой. Вот тут появляется НЕОБХОДИМОСТЬ нового уровня абстракции над документацией в виде Archimate, который ужесточает правила ведения документации, дополняет и объединяет её.
Кстати, у меня давно в голове сидит вопрос - как определить степень формализованности (жесткости правил ведения документации) для конкретного проекта. В том числе при различиях продуктового и проектного подхода. На что ориентироваться? На текущий уровень зрелости? И как определить, если текущий уровень явно "слабоват"
источник

F

Fagor in Архитектура ИТ-решений
Документ не самоцель. По моему тут ошибка в уровне. Документ это подтверждение проведения работ. Исследование? Документ исследования, изменеия в процессе? Документ фиксации изменений. Я склоняюсь к этому. Если не было проведено обследование но "выплевывается" документ ТЗ потому что так надо, то грошь цена этому документу.
источник

F

Fagor in Архитектура ИТ-решений
Провели планирование - вот вам план проведения работ на месяц вперед. А условное качество зависит от и рисков и ресурсов.
источник

F

Fagor in Архитектура ИТ-решений
Roman Tsirulnikov
за ссылку спасибо. MVP это быстрый прототип из подручных материалов, который, если гипотеза успешна, выбрасывается. Далее делается полноценное решение.
Головной боли архитектору доставляет желание быстро накостылять в рабочих core-системах, чтобы попробовать новую фичу продукта.
Потом такие костыли живут десятилетиями, отравляя жизнь многим людям.
Правило инженера: у тебя есть только один шанс сделать как следует
Не везде, иногда mvp это грамотное решение, которое обладает минимальным набором для удовлетворения. Тут вопрос ожиданий. А то у вас mvp как демо выходит.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Fagor
Документ не самоцель. По моему тут ошибка в уровне. Документ это подтверждение проведения работ. Исследование? Документ исследования, изменеия в процессе? Документ фиксации изменений. Я склоняюсь к этому. Если не было проведено обследование но "выплевывается" документ ТЗ потому что так надо, то грошь цена этому документу.
Документ и связанные с ним инструменты и процессы документирования - это инструмент для снятия рисков и уменьшения трудозатрат. Вопрос в методике определения инструментов, требуемых в конкретном проекте.
Тот же самый план проведения работ можно сделать очень по-разному. Требования можно писать в тексте задачи в джира или в чатике с разрабом, "все все поймут" и "сделаем в лучшем виде". В каких-то ситуциях это прокатывает, в каких-то - приводит к возвратам, к недовольству заказчика, срыву сроков и прочему.
Где-то есть методики, как снимать риски и снижать трудозатраты с помощью документирования?
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Может, у кого опыт есть.
источник

F

Fagor in Архитектура ИТ-решений
В чатике это не документ, это процесс. Пока нет ссылки постояной и версионности документа нет, а значит три часа в чате были потеряны. Да обеспечили процесс но не провели работы. Это как в стройке, здание может стоять, но пока акт не подписан, наряды не выданы, для проекта здания, конечного продукта илм работ не существует. Есть что то, на что потрачены ресурсы и запущены процессы.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Daria Kaftan
Кстати, у меня давно в голове сидит вопрос - как определить степень формализованности (жесткости правил ведения документации) для конкретного проекта. В том числе при различиях продуктового и проектного подхода. На что ориентироваться? На текущий уровень зрелости? И как определить, если текущий уровень явно "слабоват"
А матрица Коуберна не поможет?
источник