У меня, в двух компаниях была такая штука как груминг, это встреча где аналитик погружает всю команду в контекст, показывает задачи, по каждой задаче описание и документацию. Разработчики получаю минимально контекст, могут задать вопросы, и если им не нравится то, как что-то спроектировано они могут на это указать
Как раз аналитик смотрит, что нужно сделать, чтобы отправить данные о налогах и описывает это в формате контрактов, схемы бд, диаграмм и прочего. Если этого не будет делать аналитик, то кто?
Ттм сокращается за счёт того, что аналитик начинает работу над проектом первым. Когда разработчики делают одни задачи, аналитик работает уже над другой, формируя беклог. Разработчики в свою очередь не тратят львиную долю времени, чтобы превратить бт в схемы и контракты
Дело двух минут когда сразу понятно, что надо. Swagger не даёт всех описаний, ограничений по rps и т.д. в конфле ты можешь зафиксировать любую информацию, которую вас постоянно спрашивают при желании интегрироваться. И да бывает не только rest. Kafka, jrpc, graphQl и т.д.
Нет ни у одного человека весь контекст, но весь контекст разработчику передавать, проще его на все встречи таскать, тогда он будет сидеть на созвонах, которые он так не любит
В рамках бизнес процесса могут появляться новые данные. Новые данные - новая отгрузка, нужно понимать что должно отливаться, чтобы не занимать лишнее место в хранилищах, поэтому процесс меняется.
Есть какие то аргументы почему системный аналитик не должен этого делать?
У меня вот есть почему должен
Уменьшение тайм ту маркет, разработчик делает задачу меньше т.к. она уже запроектирована, задачи декомпозированы, их можно брать параллельно
У аналитика чаще всего больше бизнес контекста, понимая бизнес домен, проще понимать как хранить данные, что ещё рядом с ними может лечь в будущем
Реализация документируется, да! любой человек может придти и глянуть, а чё эндпоинт делает, что у него под коробкой, где в базе данные искать, выгружается ли это потом в olap. Если задачи проходят через аналитика, то документация устаревать не будет
Я работаю в финтехе, и тут dbaна каждую команду конечно нет, но есть отделы dba на бизнес линию. Привлекать их к простым задачам смысла нет. Тут речь о простых индексах, которые перестраиваются при вставке данных в бд. Dba же привлекают когда индексы огромные, нужно настроить процессы пересоздания и вакуумирования индексов.
Насчёт оптимизации, это скорее к тому, чтобы понимать, что предлагаемое аналитиком решение может работать и работать быстро.
Выглядит немного не раскрыто. Сам я работаю так же системным аналитикоми хотел бы подсветить пару моментов: 1. Например проектирование БД включает в себя не только проектирование схемы, а так же продумывание необходимых индексов, прикидывания какие данные будут лежать и сколько, иногда вплоть до продумывания оптимального SQL запроса для каких-либо операций. 2. Проектирование API почему-то сразу рассматривается REST, а не рассматриваются разные варианты в рамках задачи. Почему REST для чата с ботом, а как подгружать новые сообщения от бота? Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет) 3. Ну и еще куча есть стадий, например какие инструменты использовать, нужен ли КЭШ и где, в каком виде хранить, как инвалидировать, какие узкие места, как от них защищаться, например если пользователь начнет кликать 100500 раз, какие ошибки запрос должен возвращать.
У меня, в двух компаниях была такая штука как груминг, это встреча где аналитик погружает всю команду в контекст, показывает задачи, по каждой задаче описание и документацию. Разработчики получаю минимально контекст, могут задать вопросы, и если им не нравится то, как что-то спроектировано они могут на это указать
Без аналитика разработчик это перекладывать фантазий заказчика в код. Аналитик просто это формализует в понятные разрабу артефакты.
Очевидно профстандарт приплели, потому что по факту аналитик должен заниматься проектированием, это его работа
Как раз аналитик смотрит, что нужно сделать, чтобы отправить данные о налогах и описывает это в формате контрактов, схемы бд, диаграмм и прочего. Если этого не будет делать аналитик, то кто?
Ттм сокращается за счёт того, что аналитик начинает работу над проектом первым. Когда разработчики делают одни задачи, аналитик работает уже над другой, формируя беклог. Разработчики в свою очередь не тратят львиную долю времени, чтобы превратить бт в схемы и контракты
Дело двух минут когда сразу понятно, что надо. Swagger не даёт всех описаний, ограничений по rps и т.д. в конфле ты можешь зафиксировать любую информацию, которую вас постоянно спрашивают при желании интегрироваться. И да бывает не только rest. Kafka, jrpc, graphQl и т.д.
Нет ни у одного человека весь контекст, но весь контекст разработчику передавать, проще его на все встречи таскать, тогда он будет сидеть на созвонах, которые он так не любит
В рамках бизнес процесса могут появляться новые данные. Новые данные - новая отгрузка, нужно понимать что должно отливаться, чтобы не занимать лишнее место в хранилищах, поэтому процесс меняется.
Есть какие то аргументы почему системный аналитик не должен этого делать?
У меня вот есть почему должен
Уменьшение тайм ту маркет, разработчик делает задачу меньше т.к. она уже запроектирована, задачи декомпозированы, их можно брать параллельно
У аналитика чаще всего больше бизнес контекста, понимая бизнес домен, проще понимать как хранить данные, что ещё рядом с ними может лечь в будущем
Реализация документируется, да! любой человек может придти и глянуть, а чё эндпоинт делает, что у него под коробкой, где в базе данные искать, выгружается ли это потом в olap. Если задачи проходят через аналитика, то документация устаревать не будет
Я работаю в финтехе, и тут dbaна каждую команду конечно нет, но есть отделы dba на бизнес линию. Привлекать их к простым задачам смысла нет. Тут речь о простых индексах, которые перестраиваются при вставке данных в бд. Dba же привлекают когда индексы огромные, нужно настроить процессы пересоздания и вакуумирования индексов.
Насчёт оптимизации, это скорее к тому, чтобы понимать, что предлагаемое аналитиком решение может работать и работать быстро.
Выглядит немного не раскрыто. Сам я работаю так же системным аналитиком и хотел бы подсветить пару моментов:
1. Например проектирование БД включает в себя не только проектирование схемы, а так же продумывание необходимых индексов, прикидывания какие данные будут лежать и сколько, иногда вплоть до продумывания оптимального SQL запроса для каких-либо операций.
2. Проектирование API почему-то сразу рассматривается REST, а не рассматриваются разные варианты в рамках задачи. Почему REST для чата с ботом, а как подгружать новые сообщения от бота? Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет)
3. Ну и еще куча есть стадий, например какие инструменты использовать, нужен ли КЭШ и где, в каком виде хранить, как инвалидировать, какие узкие места, как от них защищаться, например если пользователь начнет кликать 100500 раз, какие ошибки запрос должен возвращать.
Крутая статья, жаль слепые не увидят