Size: a a a

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

2021 January 24

A

Alexey in Архитектура ИТ-решений
Спасибо!
источник

A

Alexey in Архитектура ИТ-решений
Алексей Козлов
CMMI в руки :)
источник

A

Alexey in Архитектура ИТ-решений
http://elrussia.ru/orgmodel.html
Кто-нибудь видел это?
Почему "не взлетело"?
источник

A

Alexey in Архитектура ИТ-решений
Было ещё 2 части отчёта по выбору, навскидку найти не могу...
источник

F

Fagor in Архитектура ИТ-решений
Alexey
http://elrussia.ru/orgmodel.html
Кто-нибудь видел это?
Почему "не взлетело"?
🙈кто знает, но старье, да и еще одна попытка категоризировать категории без явного потребителя этих категорий. Такое всегда еле движется и отмирает.
источник

A

Alexey in Архитектура ИТ-решений
https://www.facebook.com/watch/?v=456389872044011
Максим, Вы участвовали? Что думаете об этом?
источник

A

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

F

Fagor in Архитектура ИТ-решений
Alexey
Если найду живые ссылки, то скину позже - там неплохой обзор существующих на тот момент технологий был. Думаю скорее плохой маркетинг, внедрение и сопровождение
Интересно будет посмотреть, и вы подтвердили мое предположение: маркетинг не донес потребителю, потребитель не уовлетворен имплементацией, потребитель не удовлетворен обновлением/сопровождением. Т.е. нет потребителя и еще добавилось что реагировать не всегда можно успеть (опять таки, потому что нет фидбэка от потребителя наверное).
источник

A

Alexey in Архитектура ИТ-решений
Fagor
Интересно будет посмотреть, и вы подтвердили мое предположение: маркетинг не донес потребителю, потребитель не уовлетворен имплементацией, потребитель не удовлетворен обновлением/сопровождением. Т.е. нет потребителя и еще добавилось что реагировать не всегда можно успеть (опять таки, потому что нет фидбэка от потребителя наверное).
Я умею печь пирожки, лучшие в мире,
Но не умею их продавать.
Это не значит, что мои пирожки плохие.

По-моему бизнес-подход далеко не всегда применим в ГМУ (государственное и муниципальное управление) - разные цели. В первом - деньги, во втором благополучие граждан. Хотя в последнее время бизнес (западный) становится ориентированным на окружение. Возможно поняли, что не перспективен подход "чтобы корова меньше ела и больше давала молока, то её нужно меньше кормить и больше доить". А может опять мягко стелят... Где-то есть статья про то как в РАН интернет заводили, Бабаян с командой, да и в соционет ( https://socionet.ru/idea.htm ) есть любопытные оговорки...

И возвращаясь к теме - похоже стейкхолдеры в последнее время в фокусе, но это не всегда только потребитель, а и например, спонсор...
источник
2021 January 25

АЛ

Алексей Лосев... in Архитектура ИТ-решений
Алексей Козлов
ну да, есть процессы в среде, устоявшиеся, есть частные, прикладные, временные
Я когда рассказываю про проекты/процессы, обычно поясняю, что надо смотреть шире, например, можно на связь процессов и проектов посмотреть вот так:
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
А операционная деятельность - это процессы :)
источник

И

Иван in Архитектура ИТ-решений
Andrei Kharytonenka
просто чем больше неопределенность тем лучше подходит
ну, не только неопределенность, но и горизонт планирования)
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
Иван
ну, не только неопределенность, но и горизонт планирования)
Скрам не дает механизмов для долгосрочного планирования, но никто не мешает их добавить. Да, у вас будет не совсем скрам, вы начнете ограничивать хотелки стейкхолдеров, но в рамках итертивной-инкрементальной модели можно нормально прогнозировать и выполнять проекты выходящие за пару-тройку спринтов. Например, при помощи расширенной диаграммы сгорания делали проект на 8 месяцев, отлично все планировалось и в процессе отслеживалось, а уж как было проще говорить с заказчиком :)
источник

И

Иван in Архитектура ИТ-решений
Алексей Лосев
Скрам не дает механизмов для долгосрочного планирования, но никто не мешает их добавить. Да, у вас будет не совсем скрам, вы начнете ограничивать хотелки стейкхолдеров, но в рамках итертивной-инкрементальной модели можно нормально прогнозировать и выполнять проекты выходящие за пару-тройку спринтов. Например, при помощи расширенной диаграммы сгорания делали проект на 8 месяцев, отлично все планировалось и в процессе отслеживалось, а уж как было проще говорить с заказчиком :)
это никак не противоречит словам) я лишь добавил ремарку как раз что при долгосрочном планировании agile в принципе не работает. Но есть много промежуточных состояний, а не только черное и белое. Бывают как переходные стадии, так и совмещение инструментов
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
как может не работать аджайл? там ведь философия одна? скрам - тот да, не работает, не заточен :)
источник

A

Alex in Архитектура ИТ-решений
Алексей Лосев
как может не работать аджайл? там ведь философия одна? скрам - тот да, не работает, не заточен :)
вот если взять и перевести его как "гибкость", то всё. Не работает.
источник

АЛ

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

PD

Phil Delgyado in Архитектура ИТ-решений
Иван
это никак не противоречит словам) я лишь добавил ремарку как раз что при долгосрочном планировании agile в принципе не работает. Но есть много промежуточных состояний, а не только черное и белое. Бывают как переходные стадии, так и совмещение инструментов
Ну, манифест работает. Конкретные методики - не очень. Но долгосрочное планирование нормально вообще не реально сделать, в любом подходе.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
"Планы – бесполезны, планирование – бесценно". Дуайт Д. Эйзенхауэр.
источник