В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

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

2377 membersпожаловаться на группу
2020 July 26

GK

Gennadiy Kruglov in Архитектура ИТ-решений
К вопросу о документировании архитектуры.

Без документирования не понятно "как именно", как-то.

При этом задачи можно "вытащить из требований", наскрести по трекеру, если нет требований и т.д.
источник
16:57пожаловаться#1
2020 July 27

П

ПашМиш in Архитектура ИТ-решений
Gennadiy Kruglov
Вот, да.

Сложнее всего добиться постановки целей. Потому что нужно ответить на вопрос "Зачем ?".

Хочется сразу ответить на вопрос "Что ?".

Вопрос "Как ?" опять вызывает трудности, потому что это "дизайн + документирование"

Поэтому, часто есть ответ только на вопрос "Что ?". При этом - не важно как и не понятно зачем.
А у вас не получалось применять практики в духе "N вопросов почему?", чтобы выяснить истинную мотивацию?
источник
14:26пожаловаться#2

GK

Gennadiy Kruglov in Архитектура ИТ-решений
ПашМиш
А у вас не получалось применять практики в духе "N вопросов почему?", чтобы выяснить истинную мотивацию?
Поясню. Я говорил о проектах которые находятся в предкоматозном состоянии на момент прихода туда архитектора. Все новые проекты не стоит даже начинать без формулировки целей и задач верхнеуровневых. Нужно продавливать их формулирование. Практики могут быть разные. Мне нравятся мозговые штурмы и воркшопы.
источник
14:28пожаловаться#3

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Иными словами, когда в проектах начинаются серьёзные проблемы со временем поставки (TTM), производительностью, отказоустойчивостью, оказывается, что разработчики более или менее могут ответь на вопрос "Что делали?", но не могут ответить на вопросы "Зачем?" и "Как?".
источник
14:32пожаловаться#4

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Вот часто в эджайлных проектах думают только про то, что нужно делать в ближайшие две-три недели, но редко думают зачем именно, и почти никогда не думают как именно это делать, чтобы не наращивать TTM (тех долг в т.ч.), не деградировать надёжность и производительность, не снижать безопасность.
источник
14:36пожаловаться#5

DK

Daria Kaftan in Архитектура ИТ-решений
Подписываюсь под каждым словом Геннадия
источник
14:51пожаловаться#6

П

ПашМиш in Архитектура ИТ-решений
Gennadiy Kruglov
Вот часто в эджайлных проектах думают только про то, что нужно делать в ближайшие две-три недели, но редко думают зачем именно, и почти никогда не думают как именно это делать, чтобы не наращивать TTM (тех долг в т.ч.), не деградировать надёжность и производительность, не снижать безопасность.
Люблю кстати таких товарищей. По моему опыту они довольно быстро наскакивают на проблемы которые сами же и создали. Например отсутствие описанной архитектуры мешает поставлять инкремент в срок или в новых выпусках выявляются недостатки. В такие момент они становятся более сговорчивыми, если выбрать правильный подход.
источник
14:58пожаловаться#7

GK

Gennadiy Kruglov in Архитектура ИТ-решений
ПашМиш
Люблю кстати таких товарищей. По моему опыту они довольно быстро наскакивают на проблемы которые сами же и создали. Например отсутствие описанной архитектуры мешает поставлять инкремент в срок или в новых выпусках выявляются недостатки. В такие момент они становятся более сговорчивыми, если выбрать правильный подход.
Или разработчики просто тотально закрываются и при отсуствии механизмов давления на них ничего сделать невозможно. Просто пожар дривен разработка, где пожарные привыкли к поощрению их героизма.
источник
15:01пожаловаться#8

П

ПашМиш in Архитектура ИТ-решений
Давить можно не самому, в случае честного аджайла довольно быстро становится видно, что что-то не так. В таком случае можно пробовать предлагать команде варианты решения и она может соглашаться мотивированная желанием поделиться ответственностью.
источник
15:07пожаловаться#9

DK

Daria Kaftan in Архитектура ИТ-решений
Gennadiy Kruglov
Или разработчики просто тотально закрываются и при отсуствии механизмов давления на них ничего сделать невозможно. Просто пожар дривен разработка, где пожарные привыкли к поощрению их героизма.
И увольняются пачками
источник
16:17пожаловаться#10

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Daria Kaftan
И увольняются пачками
Да
источник
16:38пожаловаться#11

AL

Alexander Luchkov in Архитектура ИТ-решений
Gennadiy Kruglov
Да
Я кстати вспоминаю на эту тему тезис @mxsmirnov  на тему того, что архитекттор - это такой "сбоку припёка" для команды, который ничего не решает, но активно консультирует, и если "архитектор не нравится команде, то она его игнорирует".

Я последнее время часто от разработчиков слышу тезис слежующего толка:
" Мы тут деньги зарабатываем, а не продукт делаем".
источник
17:39пожаловаться#12

AL

Alexander Luchkov in Архитектура ИТ-решений
Что собственно на мой взгляд отлично отражает сложившуюся ситуацию. Люди "зарабатывают деньги" при этом не считаясь ни с какими последствиями своего "зарабатывания". И если кто-то приходит и говорит "мы тут вообще-то делаем самолёты/банк/магазин" - ему говорят "мы разработчики, нам виднее, иди в дупу, сами всё знаем. Но бабки плати" )\
источник
17:41пожаловаться#13

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Luchkov
Я кстати вспоминаю на эту тему тезис @mxsmirnov  на тему того, что архитекттор - это такой "сбоку припёка" для команды, который ничего не решает, но активно консультирует, и если "архитектор не нравится команде, то она его игнорирует".

Я последнее время часто от разработчиков слышу тезис слежующего толка:
" Мы тут деньги зарабатываем, а не продукт делаем".
Немного не так. Архитектор участвует в формировании команды и если команда не нравится, меняются лидеры этой команды.
источник
17:41пожаловаться#14

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Luchkov
Что собственно на мой взгляд отлично отражает сложившуюся ситуацию. Люди "зарабатывают деньги" при этом не считаясь ни с какими последствиями своего "зарабатывания". И если кто-то приходит и говорит "мы тут вообще-то делаем самолёты/банк/магазин" - ему говорят "мы разработчики, нам виднее, иди в дупу, сами всё знаем. Но бабки плати" )\
Да
источник
17:42пожаловаться#15

AL

Alexander Luchkov in Архитектура ИТ-решений
Gennadiy Kruglov
Немного не так. Архитектор участвует в формировании команды и если команда не нравится, меняются лидеры этой команды.
Это мне кажется более конструктивной позицией. Если нашли лидеров, которые могут вести нужные изменения на местах - это хорошая команда. Если нет - нафиг команду.
источник
17:43пожаловаться#16

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Или архитектор приходит в уже почти про...ный проект, то тоже меняются лидеры команды.
источник
17:43пожаловаться#17

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Luchkov
Это мне кажется более конструктивной позицией. Если нашли лидеров, которые могут вести нужные изменения на местах - это хорошая команда. Если нет - нафиг команду.
Да
источник
17:43пожаловаться#18

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если разработчики с чем-то не согласны и повлиять на них невозможно, пусть дальше раздувают щёки и пилят как пилили.
источник
17:44пожаловаться#19

П

ПашМиш in Архитектура ИТ-решений
Вы описываете совсем патологический антогонизм между командой и архитектором
источник
17:46пожаловаться#20