Size: a a a

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

2019 August 22

P

Pavel in Архитектура ИТ-решений
А зачем вообще обсуждать такие вопросы на собеседовании? Время убить?
источник

DK

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

PD

Phil Delgyado in Архитектура ИТ-решений
Юрий
Кажется после ваших слов я заметил у себя  профессиональную деформацию от agile 😅. За производственную часть владелец продукта в agile. А в waterfall это и правда ПМ. А вообще в целом идеи и деньги - заказчика. Он отвечает перед акционером.
А при чем тут Agile? При любой методологии нужно как-то вырабатывать процессы создания и доставки value (т.е., фактически, выстраивать конкретную методологию по всему жизненному циклу). Тут не важно, для нас важен Agile-манифест или не важен.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
(Кстати, противопоставление Agile и Waterfall выдает не очень хорошее знакомство с предметом...)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И нет такой вещи в agile, как "владелец продукта". В Скраме есть, но Скрам - это просто набор практик, далеко не всегда совместимых с Agile-манифестом.
источник

Ю

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

Ю

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

ТЯ

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

Ю

Юрий in Архитектура ИТ-решений
Phil Delgyado
Я во всех этих обсуждениях все равно не вижу, а процессы-то откуда берутся? Сквозные?
А то все хорошие занимаются своими вещами в своих башнях - а толку-то?
Так, с тем, что у нас есть совокупность процессов каждой роли с зафиксированными артефактами на каждом шаге мы разобрались. Это хорошо. Далее кто отвечает за то, что бы входы выходы совпадали? Ну как правило пишется методология методологами. Либо каждый исполнитель своего подпроцесса следит за этим. Либо за экземпляром процесса может следить экземпляр ПМ, или экземпляр ВП. Вариантов то много. Но в конечном случае целиком целиком контролирует все заказчик при приемке результатов работы/их отсутствии.
источник

Ю

Юрий in Архитектура ИТ-решений
В описанном случае артефакт аналитика как бы не очень. Вот он его в итоге и будет переделывать.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Юрий
Так, с тем, что у нас есть совокупность процессов каждой роли с зафиксированными артефактами на каждом шаге мы разобрались. Это хорошо. Далее кто отвечает за то, что бы входы выходы совпадали? Ну как правило пишется методология методологами. Либо каждый исполнитель своего подпроцесса следит за этим. Либо за экземпляром процесса может следить экземпляр ПМ, или экземпляр ВП. Вариантов то много. Но в конечном случае целиком целиком контролирует все заказчик при приемке результатов работы/их отсутствии.
Нет никаких "методологов", так как нет никаких законченных методологий (ну, кроме RUP, но там тоже необходима доработка по месту напильником)
Нет никаких "зафиксированных артефактов" на каждом шаге, если эти артефакты не описаны в конкретной методологии для конкретного проекта.
И даже если входы и выходы совпадают - это ничего не говорит о эффективности подхода.
И, кстати, все в процитированном сообщении - это сплошное противоречие аджайлу...
источник

Ю

Юрий in Архитектура ИТ-решений
Phil Delgyado
Нет никаких "методологов", так как нет никаких законченных методологий (ну, кроме RUP, но там тоже необходима доработка по месту напильником)
Нет никаких "зафиксированных артефактов" на каждом шаге, если эти артефакты не описаны в конкретной методологии для конкретного проекта.
И даже если входы и выходы совпадают - это ничего не говорит о эффективности подхода.
И, кстати, все в процитированном сообщении - это сплошное противоречие аджайлу...
Жизнь не справедлива 😂 http://yasdelie.ru
источник

LV

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

Ю

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

PD

Phil Delgyado in Архитектура ИТ-решений
Какую именно? Процесса формирования ценностей? Нормального документооборота между несколькими силосами?
Нет, не решит )
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
шикарно, спасибо)
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Это новый продукт Яндекса?)
источник

Ю

Юрий in Архитектура ИТ-решений
Daria Kaftan
Это новый продукт Яндекса?)
Не сочтите за рекламу, просто попался забавный сайт.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Юрий
Не сочтите за рекламу, просто попался забавный сайт.
прекрасное)) вот пример отличного лендинга.
источник

Ю

Юрий in Архитектура ИТ-решений
Phil Delgyado
Какую именно? Процесса формирования ценностей? Нормального документооборота между несколькими силосами?
Нет, не решит )
Все началось в этого поста:

"Необходимо решение, чтобы документировать изменения структуры (модели) базы данных. Обычно от аналитика приходит огромный документ Word с таблицей внутри, когда его спрашиваешь что изменилось в документе, описывающем БД - он говорит не знаю, вот моя постановка читай ищи. Расскажите свой опыт." ©Andrey Kharintsev
источник