Спасибо за комментарий. Любопытный подход с генерацией скриншотов автотестами и их получением по URL.
Мы в своё время смотрели в сторону генерации фронтовой документации полностью в автоматическом режиме с использованием собственной BDD-библиотеки Akita. Но всё же не пошли в эту историю ввиду существенных ограничений в части представления информации
В идеале артефакты работы аналитика должны появляться вместе с артефактами работы разработчика. Т.е. выкатили в бой функционал. А он в свою очередь покрыт документацией. Если функционал выкатился без появления/ актуализации документации, возникает техдолг аналитики на этот конкретный функционал.
Внимания заслуживает ситуация автоматического закрытия техдолга. Хороший пример - проект миграции, когда аналитики не актуализируют документы на старую систему. В этом нет смысла, т.к. скоро ей на замену придёт новая со своей документацией
Функциональному сопровождению проектная документация нужна для разбора инцидентов. Сотрудники саппорта не полезут в код смотреть реализацию. Они работаю с документами.
Solution-архитекторы используют архитектурные документы на систему для проектирования новых решениях, в которых эта система будет использоваться.
Эксперты по информационной безопасности также смотрят документацию и проводят на её основе экспертизу системы в своей области.
В Банке у документации множество потребителей. Они не читают код. И поэтому документация должна соответствовать реализации. А несоответствие документации и реализации - это проблема, которую надо решать
Сейчас есть понимание объёма техдолга и начата работа по его контролируемому устранению. Безусловно, если Бизнес не будет вовлечён в эту работу и в отсутствии лидеров процесс заглохнет. Но коммуникация с первыми есть, лидеры также имеются (техлиды аналитики). Поэтому есть шанс на успех
Денис, не хочу уходить в полемику, но насколько я помню, на первом митапе Альфы не было утверждения, что это первый митап для системных аналитиков. Был тезис о том, что подобных мероприятий не так много, и поэтому Альфа решила организовать свой митап. А также был призыв к аудитории поделиться информацией об аналогичных мероприятиях. Благо запись осталась https://www.youtube.com/watch?v=v8PojEZaiLk.
По поводу твоего проекта. Насколько я вижу, он называется "Школа системного анализа и проектирования". Название отличается от "Школа системного анализа Альфа-Банка". Поэтому вряд ли можно обвинять Альфу в использовании твоего бренда
Спасибо за вопрос. Удалённые каналы — это наши фронтальные системы (например, мобильный- и интернет-банк). Аналитик удалённых каналов — это системный аналитик, который входит в команду развития фронтальных систем
Аналитик участвует в разрешении дефектов прода, в т.ч. за счёт анализа логов, воспроизведения ошибок на тестовых стендах и написания постановок на их устранение.
SQL на самом деле много где может пригодиться, в т.ч. 1) в процессе проектирования, когда нужно изучить существующую систему и проанализировать возможность её переиспользования; 2) в процессе приёмки разработанного решения, удостовериться, что данные пишутся корректно; 3) когда возникает потребность выгрузить данные, например, для владельца продукта.
В процессе проектирования разный софт используем. Начиная от PlantUML в IntelliJ IDEA (часть документов в Git ведётся) и Confluence и заканчивая схемами в Visio.
Насчёт проектных решений. У нас аналитик позиционируется как мини-архитектор в контексте своего продукта. Поэтому занимается в т.ч. разработкой архитектурных и проектных решений.
Под тех.спецификацией я понимаю постановку на разработку. Постановки обычно аналитики пишут. Так или иначе, у нас отсутствуют тех.писатели :)
Опрос стоило проводить, как минимум, чтобы понять текущее подожение дел.
Доверять результатам этого опроса можно также, как результатам любого другого. Ответ — это субъективная оценка каждого конкретного респондента. Результат — среднее всех полученных оценок.
По поводу количества участников. В опросе приняло участие больше 80% аналитиков конкретного канала. Поэтому, на мой взгляд, охват более чем достаточный
Цифры отражают степень согласия респондентов с утверждениями. Ноль — состояние неопределённости, не могу согласиться, но и несогласиться тоже не могу, где-то посередине. Единица — согласен. Двойка — полностью согласен.
Ребята выразили большее согласие с утверждениями относительно понимания и соблюдения процесса работы с документами, чем с утверждениями относительно качества самих документов. Почему так? Это отдельный разговор
В большинстве случаев отсутствие запланированное. Однако сейчас столкнулись с ситуацией, когда в команде нет тестировщика. Отсутствие стараемся компенсировать как собственными силами, так и за счет привлечения тестировщика другой команды.
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации
По доработке фреймворка лучше ответят ребята, которые занимаются его развитием. Он выложен в открытый доступ и на самом деле любой желающий может сделать pull-request.
В нашем кейсе под каждое приложение создавался проект с автотестами. Тесты разрабатывались с использованием фреймворка. При необходимости тестировщик дописывал шаги для конкретного приложения.
Ревью тестов изначально проходило на уровне команды. Аналитик чекал сценарий, а разработчик код, лежащий под каждым его шагом. В такой модели тестировщик мог написать тест неоптимально, либо автоматизировать шаг, который уже автоматизирован во фреймворке, либо что-то упустить. Подключение к ревью тестировщика из другой команды, знающего фреймворк, позволило сократить эти риски и повысить качество тестов.
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
У нас проходят регулярные встречи тестировщиков и автоматизаторов, на которых ребята делятся опытом.
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?
Этот вопрос я бы переадресовал лидам профильных направлений. Не возьмусь на него ответить
У нас есть собственный фреймворк для автоматизации тестирования. Фактически большинство тестов собирается из готовых шагов. Однако бывают редкие кейсы, в которых команде приходится дописывать собственные шаги, т.к. они отсутствуют во фреймворке
Разве не бывает, что история не затрагивает два и более приложений? А если затрагивает, то где синхронизация? В случае с дизайном я так понял, что просто совпало, что все команды выкатили доработку вовремя.
В случае с дизайном история затрагивала все приложения. Поэтому на общем планинге команды договорились взять эту задачку в спринт. Одновременно. В результате к концу спринта дизайн всех приложений был изменен. Подобных кейсов было много. И в каждом случае команды синхронизировались.
Вместе с тем реализация общих историй в рамках отдельных приложений в большинстве случаев ложилась на плечи команды. В упомянутом кейсе с дизайном переводом всех приложений на новый сетку занимался не один выделенный разработчик. В каждой команде был фронтовик, который за неделю реализовал новый дизайн в своем приложении.
Наверное, в вашем случае будет правильнее сказать «бизнес-заказчики». Или вы реально клиентов банка приглашали?
Вопрос текущей ценности и потенциала нового бизнеса. На разработку нужно время, за которое рынок может серьезно измениться — появятся конкуренты, альтернативы, продукт морально устареет и потеряет свою аудиторию. А если есть готовый бизнес, приносящий реальный доход, почему бы и не проинвестировать в него?
Ваши публикации посмотрю. Расширю свой кругозор :)
А если серьезно, Вы говорите по большей части правильные вещи, но у меня создается впечатление, что всячески стараетесь меня задеть. Поверьте, за свои 6 лет работы на рынке построения корпоративных систем управления проектами я многое видел. О гибких подходах вне ИТ всерьез заговорили после выхода PMBoK 5, в котором появились элементы итеративномти в УП. Но удобство и польза от их использования вне ИТ еще не доказаны. Если есть ссылки на конкретные кейсы, буду рад, если поделитесь. А пока другого объяснения кроме как «модно» к желанию внедрить гибкие подходы везде и вся я не вижу.
Что касается best practice, не путайте концепцию с ее конкретной реализацией. У MSP есть множество альтернатив. Но все они построены на базе сетевых моделей, которые и являются лучшей практикой
Спасибо за комментарий. Любопытный подход с генерацией скриншотов автотестами и их получением по URL.
Мы в своё время смотрели в сторону генерации фронтовой документации полностью в автоматическом режиме с использованием собственной BDD-библиотеки Akita. Но всё же не пошли в эту историю ввиду существенных ограничений в части представления информации
В этом плане у нас легче. Внешние сотрудники преимущественно на аутстаффе. Поэтому они также вовлечены в работу с техдолгом, как и штатные сотрудники
В идеале артефакты работы аналитика должны появляться вместе с артефактами работы разработчика. Т.е. выкатили в бой функционал. А он в свою очередь покрыт документацией. Если функционал выкатился без появления/ актуализации документации, возникает техдолг аналитики на этот конкретный функционал.
Внимания заслуживает ситуация автоматического закрытия техдолга. Хороший пример - проект миграции, когда аналитики не актуализируют документы на старую систему. В этом нет смысла, т.к. скоро ей на замену придёт новая со своей документацией
Рассматривали. Есть наработки. Но текущие возможности OpenAPI не удовлетворяют всем потребностям для ведения документации по банковским продуктам
Функциональному сопровождению проектная документация нужна для разбора инцидентов. Сотрудники саппорта не полезут в код смотреть реализацию. Они работаю с документами.
Solution-архитекторы используют архитектурные документы на систему для проектирования новых решениях, в которых эта система будет использоваться.
Эксперты по информационной безопасности также смотрят документацию и проводят на её основе экспертизу системы в своей области.
В Банке у документации множество потребителей. Они не читают код. И поэтому документация должна соответствовать реализации. А несоответствие документации и реализации - это проблема, которую надо решать
Сейчас есть понимание объёма техдолга и начата работа по его контролируемому устранению. Безусловно, если Бизнес не будет вовлечён в эту работу и в отсутствии лидеров процесс заглохнет. Но коммуникация с первыми есть, лидеры также имеются (техлиды аналитики). Поэтому есть шанс на успех
Денис, не хочу уходить в полемику, но насколько я помню, на первом митапе Альфы не было утверждения, что это первый митап для системных аналитиков. Был тезис о том, что подобных мероприятий не так много, и поэтому Альфа решила организовать свой митап. А также был призыв к аудитории поделиться информацией об аналогичных мероприятиях. Благо запись осталась https://www.youtube.com/watch?v=v8PojEZaiLk.
По поводу твоего проекта. Насколько я вижу, он называется "Школа системного анализа и проектирования". Название отличается от "Школа системного анализа Альфа-Банка". Поэтому вряд ли можно обвинять Альфу в использовании твоего бренда
По нашему кейсу цифры есть. Однако хочется, чтобы и читатели поделились своим опытом
Спасибо за вопросы. Здесь слово правильнее предоставить самой Даше. Подумаем, как это сделать. Возможно, попросим рассказать об этом на митапе
Опрос стоило проводить, как минимум, чтобы понять текущее подожение дел.
Доверять результатам этого опроса можно также, как результатам любого другого. Ответ — это субъективная оценка каждого конкретного респондента. Результат — среднее всех полученных оценок.
По поводу количества участников. В опросе приняло участие больше 80% аналитиков конкретного канала. Поэтому, на мой взгляд, охват более чем достаточный
Цифры отражают степень согласия респондентов с утверждениями. Ноль — состояние неопределённости, не могу согласиться, но и несогласиться тоже не могу, где-то посередине. Единица — согласен. Двойка — полностью согласен.
Ребята выразили большее согласие с утверждениями относительно понимания и соблюдения процесса работы с документами, чем с утверждениями относительно качества самих документов. Почему так? Это отдельный разговор
По доработке фреймворка лучше ответят ребята, которые занимаются его развитием. Он выложен в открытый доступ и на самом деле любой желающий может сделать pull-request.
В нашем кейсе под каждое приложение создавался проект с автотестами. Тесты разрабатывались с использованием фреймворка. При необходимости тестировщик дописывал шаги для конкретного приложения.
Ревью тестов изначально проходило на уровне команды. Аналитик чекал сценарий, а разработчик код, лежащий под каждым его шагом. В такой модели тестировщик мог написать тест неоптимально, либо автоматизировать шаг, который уже автоматизирован во фреймворке, либо что-то упустить. Подключение к ревью тестировщика из другой команды, знающего фреймворк, позволило сократить эти риски и повысить качество тестов.
У нас проходят регулярные встречи тестировщиков и автоматизаторов, на которых ребята делятся опытом.
Этот вопрос я бы переадресовал лидам профильных направлений. Не возьмусь на него ответить
В случае с дизайном история затрагивала все приложения. Поэтому на общем планинге команды договорились взять эту задачку в спринт. Одновременно. В результате к концу спринта дизайн всех приложений был изменен. Подобных кейсов было много. И в каждом случае команды синхронизировались.
Вместе с тем реализация общих историй в рамках отдельных приложений в большинстве случаев ложилась на плечи команды. В упомянутом кейсе с дизайном переводом всех приложений на новый сетку занимался не один выделенный разработчик. В каждой команде был фронтовик, который за неделю реализовал новый дизайн в своем приложении.
Мы привлекали реальных клиентов банка
Вопрос текущей ценности и потенциала нового бизнеса. На разработку нужно время, за которое рынок может серьезно измениться — появятся конкуренты, альтернативы, продукт морально устареет и потеряет свою аудиторию. А если есть готовый бизнес, приносящий реальный доход, почему бы и не проинвестировать в него?
А если серьезно, Вы говорите по большей части правильные вещи, но у меня создается впечатление, что всячески стараетесь меня задеть. Поверьте, за свои 6 лет работы на рынке построения корпоративных систем управления проектами я многое видел. О гибких подходах вне ИТ всерьез заговорили после выхода PMBoK 5, в котором появились элементы итеративномти в УП. Но удобство и польза от их использования вне ИТ еще не доказаны. Если есть ссылки на конкретные кейсы, буду рад, если поделитесь. А пока другого объяснения кроме как «модно» к желанию внедрить гибкие подходы везде и вся я не вижу.
Что касается best practice, не путайте концепцию с ее конкретной реализацией. У MSP есть множество альтернатив. Но все они построены на базе сетевых моделей, которые и являются лучшей практикой