И очень много интересных вопросов вы отправили для Александры из Т-Банка. Ну что ж, амиго, отвечаем! 🎩 1️⃣Тест кейсы обязательны для 3 Амиго? Тест кейсы являются вспомогательным инструментом, но на мой взгляд это важная часть практики, поскольку они помогают: обеспечить покрытие проверки всех критериев приемки, сократить дальнейшее время на тестирование задач, послужить основой для дальнейшей автоматизации тестирования. + Практика подразумевает включение тестировщика, а это его основные артефакты работы, так что можно назвать их обязательным. Но повторюсь, что практика может быть адаптирована и под ваши процессы, у нее нет четкого регламента. 2️⃣ Как быть если в команде нет тестировщика? Кем можно заменить? Его может заменить человек, который занимается тестированием/приемкой реализации вашего продукта. Это может быть, например, разработчик/продакт. 3️⃣ Бывает ли формат «Три Амиго» избыточен? В каких случаях он больше тормозит процесс? И в каких случаях он не применим совсем? На мой взгляд можно выделить следующие случаи: — для простых задач, где вы работаете с очевидными требованиями, условно «Добавить кнопку, по которой должен происходить редирект по ссылке». В таких случаях вы просто потратите зря время на обсуждения того, что уже понятно — также в случае, когда у вас не выстроен процесс поставки бизнес-требований, и они могут хаотично меняться в процессе разработки. Вы тогда погрязнете не только в рутине изменений спецификации, но и в череде этих встреч — для технических задач, рефакторинга — что не влияет на бизнес — эта практика также может стать избыточной. 4️⃣ Какой инсайт у вас был в последнее время, которым хотите поделиться? Встречи проходят продуктивнее, когда снижаешь градус формальности и общаешься с коллегами, как со своими друзьями, не боясь сказать глупость :) 5️⃣ И есть ли вообще в 3 Амиго какие-то минусы и подводные камни? Вы можете потратить много времени на встрече, если не зададите четкий регламент. Важно следить за объемом встречи и количеством обсуждаемых сторей, иначе вы уйдете в бесконечную череду обсуждений. 6️⃣ Не совсем понятна роль разработчика в данной практике? Разработчик участвует в подготовке ко встрече: анализирует спецификацию и кейсы, тем самым он подключается заранее к обсуждениям, замечает нюансы технической реализации, участвует в согласовании критериев приемки и кейсов. 7️⃣ В указанном примере не увидела БА, участвует ли он или эту роль выполняет СА? БА может также принимать участие во встрече, но его участие предусмотрено раньше, на этапе, когда вам поступают бизнес-требования, а вы по ним готовите спецификацию 8️⃣ От каких проблем удалось избавить при применении метода, а какие проблемы остались (но может минимизировались)? Какие инструменты использовали для подготовки? Лично я избавилась от траты времени на актуализацию документации, сократили время на обсуждения требований во время разработки. Сократили количество аксептанс багов на задачу. Периодически могут возникать проблемы с таймингами и обсуждениями лишних вопросов, но это вопрос притирки участников команды друг к другу и процессам. По инструментам: мы использовали confluence для спецификации + внутренний инструмент компании, который помогает подготавливать доски с карточками. Вы можете использовать Miro/draw.io для визуализации. 9️⃣ А что-то кроме 3 Амиго удалось еще опробовать, прежде чем остановились на этом методе? В Банке только эта практика была. Ранее были дискавери-встречи, на которых команда просто смотрела макеты от дизайнера.