Комментарии 6
Мне не нравится это:
Разве не бывает, что история не затрагивает два и более приложений? А если затрагивает, то где синхронизация? В случае с дизайном я так понял, что просто совпало, что все команды выкатили доработку вовремя.
Наверное, в вашем случае будет правильнее сказать «бизнес-заказчики». Или вы реально клиентов банка приглашали?
Причем команды берут в работу истории только для своих приложений, что позволяет им сохранять и накапливать экспертизу в определенном сервисе конечного продукта.
Разве не бывает, что история не затрагивает два и более приложений? А если затрагивает, то где синхронизация? В случае с дизайном я так понял, что просто совпало, что все команды выкатили доработку вовремя.
Раз в две недели на общий обзор спринта приглашаются реальные пользователи.
Наверное, в вашем случае будет правильнее сказать «бизнес-заказчики». Или вы реально клиентов банка приглашали?
Разве не бывает, что история не затрагивает два и более приложений? А если затрагивает, то где синхронизация? В случае с дизайном я так понял, что просто совпало, что все команды выкатили доработку вовремя.
В случае с дизайном история затрагивала все приложения. Поэтому на общем планинге команды договорились взять эту задачку в спринт. Одновременно. В результате к концу спринта дизайн всех приложений был изменен. Подобных кейсов было много. И в каждом случае команды синхронизировались.
Вместе с тем реализация общих историй в рамках отдельных приложений в большинстве случаев ложилась на плечи команды. В упомянутом кейсе с дизайном переводом всех приложений на новый сетку занимался не один выделенный разработчик. В каждой команде был фронтовик, который за неделю реализовал новый дизайн в своем приложении.
Наверное, в вашем случае будет правильнее сказать «бизнес-заказчики». Или вы реально клиентов банка приглашали?
Мы привлекали реальных клиентов банка
Привет. Можешь рассказать про роль специалистов по автоматизированному в Scrum? У вас бывают ситуации, что несколько SQUAD используют одно решение для автотестов или каждый раз кастомное?
У нас есть собственный фреймворк для автоматизации тестирования. Фактически большинство тестов собирается из готовых шагов. Однако бывают редкие кейсы, в которых команде приходится дописывать собственные шаги, т.к. они отсутствуют во фреймворке
Спасибо за ссылку, я пока только ваш colibri-ui фреймворк для мобильных приложений смотрел.
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации (как я понял — это решение для многих проектов) в разрезе scrum? Например, одной команде нужны какие-то кастомные методы для их приложения, они отправляют pull-request в общий репозиторий, то другие squads тоже принимают участие в review? Или, например, если нужно сделать рефакторинг структуры фреймворка, то как распределяется эта задача между squads?
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации (как я понял — это решение для многих проектов) в разрезе scrum? Например, одной команде нужны какие-то кастомные методы для их приложения, они отправляют pull-request в общий репозиторий, то другие squads тоже принимают участие в review? Или, например, если нужно сделать рефакторинг структуры фреймворка, то как распределяется эта задача между squads?
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?
Можешь подробно рассказать как у вас построен процесс доработки фреймворка автоматизации
По доработке фреймворка лучше ответят ребята, которые занимаются его развитием. Он выложен в открытый доступ и на самом деле любой желающий может сделать pull-request.
В нашем кейсе под каждое приложение создавался проект с автотестами. Тесты разрабатывались с использованием фреймворка. При необходимости тестировщик дописывал шаги для конкретного приложения.
Ревью тестов изначально проходило на уровне команды. Аналитик чекал сценарий, а разработчик код, лежащий под каждым его шагом. В такой модели тестировщик мог написать тест неоптимально, либо автоматизировать шаг, который уже автоматизирован во фреймворке, либо что-то упустить. Подключение к ревью тестировщика из другой команды, знающего фреймворк, позволило сократить эти риски и повысить качество тестов.
Также у вас автоматизаторы в squad атомарны или всё-таки есть плотное взаимодействие с автоматизаторами из других squads?
У нас проходят регулярные встречи тестировщиков и автоматизаторов, на которых ребята делятся опытом.
Не думали сделать squad только из автоматизаторов (команду автоматизации), которые бы приходили в конкретный проект что-то делали бы и уходили?
Этот вопрос я бы переадресовал лидам профильных направлений. Не возьмусь на него ответить
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы Scrum масштабировали