• Stop the line или прокачай свой pipeline, йоу
    0
    Дима, привет! Рад тебя видеть/слышать :)

    Для ускорения релиза придется вложиться в автоматизацию тестирования, без этого никуда.
    Когда будут тесты, которым можно доверять — оптимизировать выкладку. Перечислите этапы, которые проходит продукт от мержа в ветку (development done) до попадания на прод. Замерьте время каждого этапа, можно просто экспертно оценить. Сфокусированно решайте самую большую проблему, то есть которая больше всего задерживает релиз. Может понадобиться сфокусированная работа одной или нескольких команд в течение пары спринтов, может быть больше. Но без фокуса проблема не решится.
    Бизнес разработка замедлится, это тоже надо понимать и готовить к этому PO и кастомеров.
  • Stop the line или прокачай свой pipeline, йоу
    +1
    Все верно.
    Нет смысла педалить фичи, если они все равно в ближайшее время не смогут выйти на прод из-за пробки в deployment pipeline. Лучше помочь чем можешь с самой пробкой, с причинами, вызвавшими пробку. Если не можешь помочь — лучше ничего не делать (!), как это на парадоксально. Учись. Покрывай тестами. Рефакторь. Но не пиши новый код.
  • Stop the line или прокачай свой pipeline, йоу
    +1
    Нет, команда нагрузки прекрасно себя чувствует и никаких планов ее распустить нет :)
  • Будь как Мунк, или пару слов о техническом долге
    0
    Все правильно, не было бы. Монолитное решение было правильным выбором на первом этапе. Его и разрабатывать, и выкатывать, и тестировать проще всего.
  • Будь как Мунк, или пару слов о техническом долге
    0
    Спасибо за поддержку :)
  • Будь как Мунк, или пару слов о техническом долге
    0
    А еще у нас была пицца-пирог с брусникой в форме сердца :-P
    Такого ни у кого нет :)
  • Будь как Мунк, или пару слов о техническом долге
    0
    Фонового режима не было. Мы полностью остановили бизнес разработку и занимались только архитектурным рефакторингом системы.
    Почему техдолг не исправлялся до фейла? — потому что мы недооценивали угрозу, потому что мы прогибались под желание бизнеса сделать больше фич, и не отстаивали свое право на чистый код.
  • Будь как Мунк, или пару слов о техническом долге
    +1
    4000 юнит тестов, около 400 API тестов, около 100 UI тестов.
    Пишем вместе с кодом, некоторые команды пишут код по TDD.
    Влияют прямым образом. Перед выкладкой нужно, чтобы все тесты прошли. UI тесты раньше были не совсем качественные, хрупкие, ненадежные, мигающие. Приходилось их запускать несколько раз, это удлинняет выкладку. Во время Stop the Line мы сфокусированно улучшали билд, чинили и переписывали мигающие тесты. Вот тут я писал об этом. Теперь намного лучше, хотя еще можно кое-что поулучшать.
  • Будь как Мунк, или пару слов о техническом долге
    +1
    У нас веб приложение
  • Будь как Мунк, или пару слов о техническом долге
    0
    Ну как одноразовый…
    2 недели проката на 6 каналах на ТВ, до этого продакшн и съемка ролика, билборды.
    Роликов было несколько, каждый подбирали под контент и даже конкретную передачу.
  • Будь как Мунк, или пару слов о техническом долге
    0
    Конечно нет, именно поэтому с самого начала и взялись за инженерные практики. Но к сожалению, количество накопленного долго уже тогда было слишком велико. И поначалу мы недооценивали его последствия, были недостаточно настойчивы в своем праве писать хороший код. Это была ошибка.
  • Будь как Мунк, или пару слов о техническом долге
    0
    Придя в компанию, у меня было примерно 10 лет опыта работы в XP/Scrum команде + 3 года работы в SmartStepGroup — на тот момент единственной компанией в России, которая зарабатывала тренингами и коучингом инженерных практик XP. Собственно благодаря нашему опыту мы и стали частью Додо в начале 2017.

    К сожалению, к этому времени в Dodo IS уже был накоплен большой технический долг. Но это было не осознанное, не просчитанное решение. Мы жертвовали качеством ради скорости, но не осознавали цену, которую придется за это заплатить. А когда осознали — стало слишком поздно.
  • Sprint Review: Днище — Огнище
    +1
    Точно так же. Гипотеза уходит в прод, собираем данные, через пару спринтов команда рассказывает про результаты эксперимента на спринт ревью.
  • Машинное обучение в Додо. Как запустить новое направление, если ты разработчик
    +2
    Никогда, уже выпилили его из репозитория :)
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Могу я уточнить, в каком городе и в какой пиццерии вы пробовали пиццу и остались недовольны?

    Очень жаль, что вам не понравился наш продукт. Наши сотрудники тщательно выбирают ингредиенты для пиццы. Недавно мы поменяли поставщика пепперони, постоянно ищем новые более вкусные сорта сыра. Недавно я был свидетелем разговора между сотрудником R&D и поставщиком сыра — они помимо вкуса обсуждали еще десятки параметров — топкость, тянучесть, жирность, ведь важно чтобы сыр не расслаивался и не горел в печи, и чтобы он сохранял свои свойства как минимум в течении часа после выпекания. Оказывается есть 16 сортов моцареллы, каждый из которых лучше подходит для той или иной модели печи.

    Вы бы видели как они выбирали говяжьи кусочки — обсуждали не только вкус, но и форму, размер, цвет. «Этот недостаточно бугристый». Настоящие маньяки, которые любят свою работу и стремятся сделать продукт максимального качества.
    В первую очередь мы добиваемся превосходного вкуса горячей пиццы.

    Мы не экономим на ингредиентах, не ищем что подешевле. Поэтому наш продукт дороже, чем у многих других пиццерий, работающих на доставку.

    Мы проводит слепые тесты вкуса пиццы и по ним мы обходим конкурентов по флагманским продуктам (к которым относится и пепперони).

    Если вы в Москве, вы можете прийти к нам в офис, я вам с удовольствием проведу экскурсию по офису, познакомлю с людьми, которые выбирают и тестируют продукты.

    Также вы всегда можете прийти в любую нашу пиццерию на экскурсию и посмотреть как хранятся продукты, как готовится пицца, какая чистота в цехе.
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Мы не используем кукурузную муку. Тесто раскатывается на крупке — это пшеничная мука крупного помола, чтобы тесто не прилипало к столу и рукам. Мы используем крупку Mamma Mia.
    После раскатки основа встряхивается, чтобы стряхнуть крупку.

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

    Какая начинка вам кажется неприятной?
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Можете подробнее рассказать про то, что в сервисе вам не понравилось?
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Чем проще тем лучше.
    Мы использовали webwhiteboard.com
    С тем же успехом можно просто открыть google drawings и совместно создавать/двигать карточки. Мы так на распределенных ретроспективах делаем.
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Мы пользовались обыкновенным webwhiteboard.com, но с тем же успехом можно использовать realtimeboard.com (платный).
    Сохранение истории не так важно. Сторимап — живой инструмент, важно его текущее состояние. После того, как истории сделаны, он теряет свою актуальность. Его можно сфотографировать и сохранить на память, но толку от него уже нет. Для новой фичи или нового релиза делаем новый сторимап.

    Что касается индексирования — после того как сторимап помог нам определиться с приоритетами и разбить истории на мелкие, мы занесли их в обычный инструмент для работы в спринте (Jira или Trello), а там с поиском все в порядке :)
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    +1
    Мы так и сделали. Просто чтобы не откладывать выход на рынок, мы вышли с минимальным меню и услуг. В первой версии сайта для США у нас даже не было изображений пиццы :).
    Поняв, что своя пицца для американцев востребована, мы изучили решения конкурентов — Доминос, Папа Джонс и других, и на их основе сделали свое, только более легковесное и удобное.
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    0
    Мы пришли на новый рынок и изучаем его, открыв там маленькую тестовую пиццерию в маленьком городе с 20000 населением.
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    +1
    Сторимэп — это в первую очередь инструмент для общения, а общаться лучше всего лично, стоя у доски и тыкая в нее пальцами или маркерами. Удаленно тоже можно, но эффективность на порядок снижается. Удаленно как правило один говорит, остальные слушают (или делают вид).
  • Как сторимэп помогает не завязнуть в разработке нового продукта на годы
    +4
  • Тестирование в стиле TSA
    0
    Стоимость написания тестов сильно уменьшается при использовании DSL (Domain Specific Language).
    Правда написание самого DSL тоже не бесплатно :)
  • Перевод статьи Хенрика Книберга «ATDD from Trenches» (ATDD с передовой)
    +3
    Приемочные тесты, на мой взгляд, гораздо ценнее юнит тестов. Они несут больше информации о системе в целом, часто описывают сценарии с точки зрения пользователя а не разработчика и позволяют избегать сложной настройки моков. Это так.

    С другой стороны, юнит тесты очень сильно помогают выстроить дизайн приложения, когда он неизвестен (разработка через тестирование).
    Сложность, связанная с изменением архитектуры для запуска юнит тестов вызвана именно тем, что тесты пишутся после того, как дизайн системы уже построен. Если делать наоборот, то есть создавать систему одновременно с тестами, то дизайн сразу растет тестируемым и подстраивать его под тесты уже не приходится.

    Я думаю что нужны и те и другие тесты. Но их ценность меняется в процессе работы над проектом. Ценность юнит тестов высока сначала и постепенно снижается к концу проекта, потому что как правило мало что меняется.

    Тесты, которые запускаются на самом верхнем уровне, на мой взгляд, легко писать но очень сложно поддерживать. Поэтому Хенрик предлагает писать их так, чтобы они описывали сценарии пользователя, но при этом работали на фейкнутой системе, в которой подменяются самые нижние слои. Это сделает их быстрыми и поддерживаемыми.
  • Перевод статьи Хенрика Книберга «ATDD from Trenches» (ATDD с передовой)
    +1
    Возникает вопрос — а почему приемочные тесты длятся несколько часов? Обычно это происходит потому, тестируют приложение через UI, сверху донизу, через все слои. В тестирование вовлекаются медленные ресурсы (SQL DB, внешние сервисы, файловая система) — именно поэтому они и становятся долгими, и к тому же хрупкими и ненадежными. Требуется уйма дополнительных усилий на подготовку данных перед запуском теста и чистку данных после запуска. Чистить в том числе нужно и после неудачных запусков.

    Подход, который предлагает Хенрик, и который мы применяли в своих проектах — организовывать приемочные тесты таким образом, чтобы они по-прежнему охватывали максимальное количество слоев, но при этом не зависели от медленных ресурсов. Если вы подмените настойщую SQL DB на In-Memory DB, файловую систему и внешние сервисы на мок, то ваши приемочные тесты станут интеграционными, и бегать будут как из пулемета.