Очередной скептик

Немного некорректно использование термина actor, потому что оно употребляется при использование use cases. User story не просто так названа, мы говорим именно про пользователя, потому что за ним скрывается человек, понять которого нам предстоит.

Кроме того, если вы говорите про экспертов, то хотелось бы видеть экспертов именно в agile.

Да, braintree он такой =(

К кнопкам никаких претензий нет, а вот Express Checkout все таки немного муторная штука. В случае реальных товаров нужно же собирать, например, адрес доставки, и тут начинается…

Первый же вопрос — зачем придумывать велосипед, если все описаное есть в Exploratory testing?

Нет, на хабре анонса мы не делали, только на сайте agile russia и в одноименной группе на facebook. Плюс в том, что мы эту встречу проводим регулярно, следующая возможно будет в январе-феврале

о, а по какому принципу у вас строится exploratory тестирование? SBTM или что-то свое? Как я понимаю, на вход помимо всего тестировщики получают и скетчи?

Спасибо за статью, но она все же спорная, потому что очень категоричная, даже для меня =)
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.

Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?

Часть вещей я не написал потому что это секрет фирмы =) В первую очередь это касается того, как мы проводим анализ и определяем текущий уровень компании. Модель строится на существующих в индустрии практиках. Например, когда мы говорим о разработке это касается следующих параметров:

• наличие VCS и как с ним идет работа
• практики тестирования (unit, integration,...)
• работа с Continuous Integration
• гибкость архитекутры
• качество кода
• и так далее

Если говорит об анализе, то нас интересует как именно команда работает на требованиями, как они строят видение продукта и прочее.
По большому счету правильнее назвать наш процесс assessment`ом, но так уж вышло что прицепилось слово аудит.

Как я писал — у нас есть внутренняя модель зрелости компаний с 7 показателями. Ключевым критерием является то, как быстро команда может реализовывать идеи бизнесы и доносить их до клиента. Отсюда собственно и вытекают метрики и критерии.

Обычно, мы обговариваем набор метрик, по котором и видно, как происходит работы. Обратную связь мы собираем постоянно, потому что цель не отсидеть часы и сделать только то, что в них описано, а решить насущные проблемы.

А можно раскрыть, что такое «занимаюсь DevOps»?

Люди уникальны, а вот паттерны поведения одинаковы. Проверено десятком компаний.

как раз на подходе статья про Nokia Entertainment

проблема в том, что хоть этим утверждениям уже и больше 30 лет, всем как то резко пофигу на них. зато потом большие глаза и фразы «как же так вышло»

Тогда нужно слушать вот этот доклад, это именно про DevOps для java в российском проекте для ростелекома.
Или тот же HeadHunter тоже исповедует принципы devops

Если я не ошибаюсь, то оно было написано на фортране. А вот про железо не был в курсе, так как был еще падаваном и изучал яву.

Это был один из самых первых проектов для меня. Писали систему для шедулинга (создание расписания для логистики в данном случае), а эта система отвечала в компании заказчика за внутреннюю бюрократию — счета, платежи и так далее. Так и работали — мы делаем расписание и считаем стоимость перевозок и если ок, то пользователь нажимал большую кнопку и генерировались нужные документы. Надо сказать, что система работала на редкость стабильно.