Size: a a a

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

2020 June 03

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Вики по всем "частям"(назовем это так), да, ее соберет кто то другой. Информацию для вики, передает проектный офис. Если офис это не делает, то ему просто плевать, а руководство это устраивает.
Воот. Т.е. внедрением в компании единого информационного поля в виде wiki - занимается не проектный офис (вернее, скорее всего он - но как проект от другого заказчика, не изнутри проектного офиса).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я про это и говорю, инициатор появления wiki в компании - обычно не проджект, а продакт или архитектор
источник

F

Fagor in Архитектура ИТ-решений
Вот мы и пришли к пониманию. Классическая проблема когда мы говорили про разные уровни, я имел в виду вики в проекте.
источник

PD

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

AL

Alexander Luchkov in Архитектура ИТ-решений
Phil Delgyado
(Вообще, обычно из PMов не очень хорошие "организаторы информации", так что и в проекте вики или была занесена раньше или заносится кем-то из технарей. Но есть исключения, конечно).
Вики в проекте может быть делом команды, если вся команда и ест ьцеликом компания.
Если это команда в  составе компании, то вики - это дело компании. Очевидно же вроде. Это разные действительно разные уровни принятия решения, иногда сливающиеся в одних и тех же людей как исполнителей кучи ролей.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, да )
источник

P

Pavel in Архитектура ИТ-решений
Phil Delgyado
(Вообще, обычно из PMов не очень хорошие "организаторы информации", так что и в проекте вики или была занесена раньше или заносится кем-то из технарей. Но есть исключения, конечно).
Системным аналитиком, конечно же. Куда же без него. 🙂
источник
2020 June 04

ST

Stanislav Takt in Архитектура ИТ-решений
Eugene Istomin
» в аджйле не разделяют на слои
Давай обсуждать, так как в Agile разделяют на слои.

Интерсубъективность Альфреда Шюца, понятие view в инженерной школе и "separation of concerns" в том виде, как его описывает Дейкстра в 57100 - это вполне конкретная практическая психология. Ролевые позиции в команде - аналогично.
Спасибо, отрефлексировал, что в аджайл -парадигме _требование_ к разработчикам - умение мыслить "вертикально", на нескольких уровнях, от архитектуры и бизнес-требований, до реализации в коде. Это скромно называется "кросс-функциональность".

Это кстати одна из причин, почему у нас только карго-аджайл идет - ни разработчики не умеют мыслить "из бизнеса", ни аналитики "в коде". А при каждой передаче информация искажается, как мы знаем.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Такой подход требует наличия компактного коллектива профессионалов. Он плохо совмещается с традиционными подходами организаций, в части глубокого разделения ролей и ответственности, узкой специализации и массового найма “среднего по рынку”.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
С традиционных подходом, расслоение ролей, а за ними и орг.юнитов неизбежно.
источник

RT

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

RT

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

F

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

RT

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Бизнес категорически не готов менять свои привычки.
источник

RT

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Рискну сделать ставку на то что средние и крупные организации все постепенно придут к SAFe как reference модели организации
источник

DK

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Daria Kaftan
Хороший конвейер в работоспособными юнитами - вещь рабочая же. Зачем обязательно делать команду условных "универсалов"? (которые на самом деле нифига не универсалы, но тем не менее)
Удобно переставлять клеточки в экселе и не думать о специфике. Пусть эффективность ниже, зато планы прозрачнее.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
Удобно переставлять клеточки в экселе и не думать о специфике. Пусть эффективность ниже, зато планы прозрачнее.
Это в ситуации конвейера или команды?
источник