Вот когда у тебя начинается кровавый энтерпрайз, датацентры, виртуализация, мейнфреймы...

Вот когда у тебя начинается кровавый энтерпрайз, датацентры, виртуализация, мейнфреймы...

Я как раз об этом =)

Сделайте ка для моей команды дата центр =) Мы историю будем разрабатывать

Ну датацентр для разработки - это перебор :)

такой маленький датацентрик, датацентричек, на два-три серверочка - норм :)

И да, прод обслуживает целая сервис-служба из 20 человек. Вот для нашей команды такую же наймите..

такой маленький датацентрик, датацентричек, на два-три серверочка - норм :)

Эм.. Нет. Систему то на 100% надо реплицировать. Все 100500 компонент поднять и обеспечить их бесперебойную работу

Или вот разрабатываем мы устройство мониторинга электростанции. Дайте нам и электростанцию =)

Скажу даже так. Я никогда не видел чтобы локальный env команды разработки на 100% повторял бы прод

В лучшем случае это был staging повторяющий прод, но тоже один на всех

воу, так я про него и говорю :)

misunderstanding, сорри. Я забыл, что еще остались те, кто для _команды_ отдельное коружение делают :)

(глумление)

Но он один, как и прод. А команд много. И каждому разработчику нужно свое состояние env

Зачем?

Чтобы разрабатывать

Повторюсь, зачем ему, чтобы разрабатывать, отдельное _состояние_ env

Какая цель?

Вот есть вышеупомянутые 7 команд и их беклог на три части разбит. Всё ок. Каждая группа свою часть продукта разрабатывает. Но на рынке это один продукт. Есть прод и есть staging.

Вот, все правильно

Из этого, кстати, ненавязчиво следует, что командам отдельное окружение вредит :)

Да, и первая группа вводит staging в состояние нужное ей. В этом состоянии энвом не могут пользоваться остальные группы.

А продукт по результатам как работать будет?:)

Не понял..

Группа 1 работает над изолированной частью 1, но для работы этой группе нужны все остальные части продукта. Причём все части в нужном состоянии

Если на энве будут работать сразу две группы, пусть и в разных углах, то используя shared ресурсы они вносят смуту друг другу

Чтобы их полностью развязать нужно каждой выдать по полной копии системы

Макс, а продукт потом как будет работать, тоже смуту внося?

Нет, когда продуктом будут пользоваться никто его изменять на ходу не будет

Если это система с outage SLA в 50% то и пофиг =)) а если 99.99%?

И вот мы плавно подошли к agile architecture :)

И "почему мкросервисы не только бесполезный модный тренд, но и жизненная необходимость" :)

(опять глумлюсь)

И как микросервисность снимает проблему? (к слову, я в своём примере также подразумеваю микросервисную архитектуру)

Если серьезно, то sharted staging тоже требует от команд умения с ним обращаться.

Т.е. если ты комитишь и твой код после CI не работает, потмоу что кто-то еще что-то поломал... Ну, печаль, договаривайтесь.

Потому что без "договаривайтесь" совместной работы толпы команд не будет никак.

Ха, мы выше говорили что более 15 человек договориться не могут и заставили их разойтись по отдельным беклогам. А тут убеждаем 500 человек работать на одном shared resource..

Ну да.

Вот и давайте вернёмся к вопросу беклога =)) почему энв обязан быть один и беклогов много?

Минута пошла.. =)))

Вот и давайте вернёмся к вопросу беклога =)) почему энв обязан быть один и беклогов много?

Потому что продукт - один :)

Элементы бэклога, если с ними все в порядке, починяются правилу INVEST. Т.е. разделение большого бэклога на много маленьких из за I консистентность продукта не рарушит.

Но если продукт, конечный. должен выполняться в едином окружении, то почему его разработка не должна вестись в едином коружении?

Ну так и если мы найдём волшебный способ научить 500 человек договариваться об использовании одним ресурсом. То почему продуктом они смогут пользоваться, а беклогом нет?

Гм, потому что "волшебный сопосб научить 500 человек пользоваться одним ресурсом" уже есть, а с бэклогом пока нету :)

Беклог нельзя рассматривать как продукт?

Бэклог НУЖНО рассматривать, как продукт.

там же даже программировать не надо =)

Но в хорошем бэклоге элементы - independent.

Т.е. нет технической необходимости устраивать дурдом с system team, которая будет поддерживать среду разработки

(это если говорить про масштабы в 100+ разработчиков)

Т.е. смотри, все команды МОГУТ работать из единого бэклога. Но для этого их придется обеспечить едиными инструментами, правилами, скиллами и метриками.

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

В общем, придется быть МЕНЕДЖЕРОМ :)

Теперь обратная ситуация: у тебя есть сборная солянка DEV энвайроментов.

Приближается РЕЛИЗ

(когда система состоит из большого количества кусочков, релизов не бывает, бывают РЕЛИЗЫ)

Вот зачем создавать себе ОГРОМНЫЙ оверхед в момент, когда у тебя ГАРАНТИРОВАННО появятся конфликтующие куски функционала, несовместимые окружения и т.п.?

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

Чтоб это было частью definition of done

Внутри спринта, например, ты жеж не поощряешь сидение 8 дней из 10 в feature branch и лехорадочное тестирование в самом конце?

Так зачем такое поощрять на уровне межкомандного взаимодействия?

Но в хорошем бэклоге элементы - independent.

👍

Внезапное, но не помню, обсуждали-ли тут.

ВОпрос с интервью: если бы вы могли оставить только один скрам-ивент, то какой б вы оставили? И почему.

Встречается на каждом буквально первом интервью :)

ВОпрос с интервью: если бы вы могли оставить только один скрам-ивент, то какой б вы оставили? И почему.

ретроспектива, я думаю, остальное можно на ней решить вернуть

Ревью тоже неплохо, имхо

Пленниг, впрочем, тоже покатит.

Я бы дейли оставил =) потому как это спринт в миниатюре

Хотя быть может это вопрос с подвохом и нужно встать и гордо ударить себя пяткой в грудь и сказать что в Скраме все события важны =)

Да фиг их знает.

На инетрвью не поймешь, из какого списка вопросов для интервью вопрос взят :)

=))))

https://www.youtube.com/watch?v=MUOv8ksL9zk

Мне в интервью скрам-мастера кажется самым честным и результативным вариант полного погружения - когда просят событие провести. Как у Дениса в статье.

Да, это хороший вариант. Главное чтоб сбытия выбирали... адекватно

А то "провести ретроспективу" оно какбэ... Не всегда так стоит делать, мягко говоря

Планнинг хорошо