Size: a a a

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

2020 August 06

PD

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

DK

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

PD

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

PD

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

F

Fagor in Архитектура ИТ-решений
Вообще состав работ (читай доков) РП должен с вами прописывать.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Fagor
Вообще состав работ (читай доков) РП должен с вами прописывать.
Это если есть РП)
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Благодарю!
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Fagor
Вообще состав работ (читай доков) РП должен с вами прописывать.
А, по опыту это все равно делает или архитектор или руководитель разработки.
РП другими вещами занимается.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Fagor
Вообще состав работ (читай доков) РП должен с вами прописывать.
Состав отчетной документации - да. А остальное - как получится. Тем более помимо перечня этих доков нужно подбирать инструменты. РП не занимается подбором инструментов для каждой практики. Для автогенерации доков, для организации тесткейсов, для управления требованиями. Этим занимаются лиды направлений. Менеджер по качеству, тимлид, и т.д.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
РП составляет план работ не сам по себе.
источник

PD

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

AT

Alexander Teterkin in Архитектура ИТ-решений
Roman Tsirulnikov
за ссылку спасибо. MVP это быстрый прототип из подручных материалов, который, если гипотеза успешна, выбрасывается. Далее делается полноценное решение.
Головной боли архитектору доставляет желание быстро накостылять в рабочих core-системах, чтобы попробовать новую фичу продукта.
Потом такие костыли живут десятилетиями, отравляя жизнь многим людям.
Правило инженера: у тебя есть только один шанс сделать как следует
Кстати, про один шанс –  интересно. Спасибо!
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Олег Игонин
С определённого момента (обычно хорошо видно в банках), сложность возрастает сильно из-за ограничений сервисов (скорость выполнения запросов, качество данных, отказоустойчивость, прочая нефункциональщина). И сам сервис становится тяжеловесным с кучей юз-кейсов и сложной логикой. Вот тут появляется НЕОБХОДИМОСТЬ нового уровня абстракции над документацией в виде Archimate, который ужесточает правила ведения документации, дополняет и объединяет её.
Добавил в избранное.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Fagor
Документ не самоцель. По моему тут ошибка в уровне. Документ это подтверждение проведения работ. Исследование? Документ исследования, изменеия в процессе? Документ фиксации изменений. Я склоняюсь к этому. Если не было проведено обследование но "выплевывается" документ ТЗ потому что так надо, то грошь цена этому документу.
Не только подтверждение работ. Как на счет фиксации намерений? Как на счет общего понимания задач? В одном из исследований показали, что 60% всех проблем с ПО вызвано некорректным пониманием требований. Как быть если требования не зафиксированы?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Alexander Teterkin
Не только подтверждение работ. Как на счет фиксации намерений? Как на счет общего понимания задач? В одном из исследований показали, что 60% всех проблем с ПО вызвано некорректным пониманием требований. Как быть если требования не зафиксированы?
+
источник

ОИ

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

ОИ

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

DK

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

ОИ

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

ОИ

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