Size: a a a

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

2020 June 09

F

Fagor in Архитектура ИТ-решений
Далее имплементация SA в тех часть, в виде обоатной связи PM, для управления.
источник

AT

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

Был диалог, сошлись что по бизнесу в связке с BA это зона ответственности PM.
Ага, это как в Boing было недавно: управление требованиями к самолету и требованиями к подготовке пилотов на менеджеров перекинули. 😬
источник

F

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

F

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

F

Fagor in Архитектура ИТ-решений
Вроде все в порядке.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
PM - project или product?
источник

F

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

A

Alex in Архитектура ИТ-решений
/report ban
источник

П

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

Был диалог, сошлись что по бизнесу в связке с BA это зона ответственности PM.
Мы пытаемся не только собирать требования, но и по возможности их прорабатывать и приоритезировать. По моему мнению самая польза от управления требованиями если в процессе работы требования перерабатываются и значительная часть откладывается/отбрасывается.
источник

LV

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

Был диалог, сошлись что по бизнесу в связке с BA это зона ответственности PM.
Хм, управление требованиями, как по мне это вообще история не про то, чтобы принятые требования доходили до нужных людей. Но тут у каждого свои боли, видать.
источник

П

ПашМиш in Архитектура ИТ-решений
А про что по вашему мнению управление требованиями?
источник

S

Sergey in Архитектура ИТ-решений
ПашМиш
А про что по вашему мнению управление требованиями?
в древние времена это то, что делала Doors
источник

П

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

F

Fagor in Архитектура ИТ-решений
Sergey
в древние времена это то, что делала Doors
Репозиторий вроде.
источник

F

Fagor in Архитектура ИТ-решений
Не реклама, была надобность что то "легкое" про RM поплся jama software, демка пойдет.
источник

S

Sergey in Архитектура ИТ-решений
ну требования - это таблички. Главное traceability на артефакты
источник

F

Fagor in Архитектура ИТ-решений
А вот когда RM и CM (configuration managment), вот тут мы встряли, или это отраслевой софт, или конструкторский за оверпрайс
источник

F

Fagor in Архитектура ИТ-решений
Sergey
ну требования - это таблички. Главное traceability на артефакты
+-, но не совсем. Если у вас процесс разработки в активной фазе, то RM много что делает
источник

S

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

F

Fagor in Архитектура ИТ-решений
Хотя по сути отдельно RM нет, все скатывается в LMC
источник