Size: a a a

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

2019 October 04

AS

Andrey Slepitsky in Архитектура ИТ-решений
Alexey Pryanishnikov
Continious architecture, имхо, это самообман. Либо у тебя таки есть хоть приблизительная картинка будущего в голове, либо ты ежедневно с командой находишься в ситуации "ляяя, ничего не заработает, пока всё к хренам не переделать!!", это создание неопределённости там, где её не было и перерасход ресурсов.
Ядро должно быть, никто не спорит. Но полностью продумать всю архитектуру не получится imho. Поэтому, откладываем пока можно...
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Dmitry Lebedev
Привет. Подскажите, как в Agile/Scrum решается проблема невозможности проектирования архитектуры с учетом всех требований (чтобы потом не переделывать), если требования сразу неясны и меняются - или это не считается проблемой,и архитектура потом спокойно переделывается, если нужно, по мере развития продукта? плюс, вероятно, приоритетом является использование минимальных компонентов изначально, и т.д.

*задавал вопрос в Agile чате - интересно сравнить ответы
Зависит от сложности предметной области.
Это это стартап и эксперименты на пустом месте, все отлично работает без архитекторов.
Если предметная область сложная, в ней несколько доменов, уже сложившаяся экосистема рынка, плюс юристы, безопасность, разное законодательство,
то скрам-команда становится небоеспособна.
Чтобы просто понять что надо сделать по такой задаче, нужно несколько дней копаться в документах.

Архитекторы/аналитики тут вне команды,
они разбираются в предметной области и готовят постановку задачи,
затем отдают ее в команду.
А команда уже там сама планирует работу и реализует по скраму.
Так это работает у нас)
источник

DL

Dmitry Lebedev in Архитектура ИТ-решений
Roman Tsirulnikov
Зависит от сложности предметной области.
Это это стартап и эксперименты на пустом месте, все отлично работает без архитекторов.
Если предметная область сложная, в ней несколько доменов, уже сложившаяся экосистема рынка, плюс юристы, безопасность, разное законодательство,
то скрам-команда становится небоеспособна.
Чтобы просто понять что надо сделать по такой задаче, нужно несколько дней копаться в документах.

Архитекторы/аналитики тут вне команды,
они разбираются в предметной области и готовят постановку задачи,
затем отдают ее в команду.
А команда уже там сама планирует работу и реализует по скраму.
Так это работает у нас)
Интересная модель
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Roman Tsirulnikov
Зависит от сложности предметной области.
Это это стартап и эксперименты на пустом месте, все отлично работает без архитекторов.
Если предметная область сложная, в ней несколько доменов, уже сложившаяся экосистема рынка, плюс юристы, безопасность, разное законодательство,
то скрам-команда становится небоеспособна.
Чтобы просто понять что надо сделать по такой задаче, нужно несколько дней копаться в документах.

Архитекторы/аналитики тут вне команды,
они разбираются в предметной области и готовят постановку задачи,
затем отдают ее в команду.
А команда уже там сама планирует работу и реализует по скраму.
Так это работает у нас)
Да, это именно так и работает)
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
В любой сложной области без экспертов никуда,
просто agile уже не работает.
источник

RK

Roman Kalashnikov in Архитектура ИТ-решений
Roman Tsirulnikov
Зависит от сложности предметной области.
Это это стартап и эксперименты на пустом месте, все отлично работает без архитекторов.
Если предметная область сложная, в ней несколько доменов, уже сложившаяся экосистема рынка, плюс юристы, безопасность, разное законодательство,
то скрам-команда становится небоеспособна.
Чтобы просто понять что надо сделать по такой задаче, нужно несколько дней копаться в документах.

Архитекторы/аналитики тут вне команды,
они разбираются в предметной области и готовят постановку задачи,
затем отдают ее в команду.
А команда уже там сама планирует работу и реализует по скраму.
Так это работает у нас)
А что по поводу взаимодействия команд с клиентами?
источник

GK

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

GK

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

RT

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

il

ivan luzinov in Архитектура ИТ-решений
Gennadiy Kruglov
Да, это именно так и работает)
Если вкратце, то это WaterScrumFall :)
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Чтобы продать что-то новое, сначала нужно грамотно обо#рать старое. Поэтому нам рассказывают страшные сказки про плохой Waterfall. Методологий и подходов существует множество, не надо так упрощать: когда все сводится к бело-черному то вам вешают лапшу на уши.
источник

il

ivan luzinov in Архитектура ИТ-решений
Roman Tsirulnikov
Чтобы продать что-то новое, сначала нужно грамотно обо#рать старое. Поэтому нам рассказывают страшные сказки про плохой Waterfall. Методологий и подходов существует множество, не надо так упрощать: когда все сводится к бело-черному то вам вешают лапшу на уши.
А что было раньше WaterFall или Agile/Scrum ?
источник

VB

Vitaly B. in Архитектура ИТ-решений
ivan luzinov
А что было раньше WaterFall или Agile/Scrum ?
А waterfall'а не было.

Практики 60х годов в какой-то момент презентовали процесс на сферическом в вакууме примере, где все этапы идут последовательно и нет необходимости возвращаться к прошлым.

Американским военным так понравилась идея, что waterfall быстро появился в стандартах военных программ. И хотя авторы исходной презентации почти сразу оговорились, что на практике регулярны возвращения к прошлым этапам итд. Ещё лет 10-15 waterfall был рекомендованным процессом у военных.
И только потом сменился на пачку более гибких методологий.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Здесь уместно упомянуть, что спиральную разработку придумали как раз американские военные, конкретно Barry Boehm.

А уже потом на этом появились все эти RUP и Agile..
источник
2019 October 05

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Ну это же всё просто инструменты. Вообще, управление проектами или разработкой похоже на выстраивание архитектуры. Тоже есть набор решений или практик, которые можно в разной комбинации применить в разных условиях и получить в результате изменение нужного свойства системы в нужную сторону. Просто язык другой и уровень формализации и достоверности предсказания результата оставляет желать лучшего.
источник

C

Crazy Art in Архитектура ИТ-решений
Maxim Bendin
ну, скорее не на планнинге, а на груминге.
Камрад, скрум - вопль обиженного программиста: отвалите от меня, я сам все сделаю... в некоторых ситуациях имеет право на жизнь ... А архитектуру, ранжирование и сбор требований он вынес за скобки ...
источник
2019 October 06

MS

Maxim Smirnov in Архитектура ИТ-решений
источник

S

Stanislav in Архитектура ИТ-решений
Тогда удаляю
источник
2019 October 07

NK

Nikita Kiselev in Архитектура ИТ-решений
Deployment - Deploy as container и K8s есть разница?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Nikita Kiselev
Deployment - Deploy as container и K8s есть разница?
Нет, это одно и тоже, надо поправить
источник