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

У нас тут каких-то сильных провалов не возникало. Просто у канбановых команд в итоге появляются какие-то классы обслуживания, вы это делаете на основе due date, мы в разных этапах использовали cost of delay или вообще прям выделенные лейны.

класс обслуживания тут можно воспринимать как правила, по которым вы выделяете ресуры на работу.

По due date например вы выделяете ресуры на те задачи, у которых срок подходит ближе всего

по cost of delay - считается цена задержки, чем больше вы теряете от "неделания" задачи, тем больше у нее приоритет.

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

спасиб

У меня самый сложный вопрос именно договориться. Причем коллеги въедливые и дотошные, поэтому для реализации своей идеи надо очень хорошо подготовиться к представлению этой идеи, запастись аргументами, рассмотреть разные варианты и кейсы и т.п.

Расписать своё видение - это одно, это просто и решаемо, а вот собрать воедино мнение восьми человек, найти консенсус и сделать единый документ в формате именно договоренности, а не административного решения руководства - задачка куда более сложная и интересная.

имхо собрать мнения восьми человек и всем угодить- нерешаемая задача. Иногда демократия- не лучший выбор. Мне больше нравится вариант, когда я все-таки своё видение описываю в общем ключе, а потом мы договариваемся уже о частных случаях. Тут важно правильно преподнести ценность своего видения, почему именно я считаю, что вот так будет хорошо и какуие проблемы пытаюсь этим решить

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

👍

Согласен, это рабочая схема

+1
с первого раза ничего не выходит как надо, а вот итеративно - после дорабтки/обсуждений на ретрах - дает по немногу  выхлоп

Да я тоже +1)))

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

да! да? да! ))

нужна консультация по питону 152 для GL868 Telit

Всем привет!

Приглашаем вас на онлайн-митап, который состоится 9 июля. Будет два докладчика из Контура и один из Miro. Поговорим о том, как бороться с проблемами в процессах. На конкретных примерах разберем, как их избежать. Обсудим, как поменялся процесс разработки и тестирования в Miro, и как это повлияло на релизы. И, конечно, поговорим об автоматизации: как выйти на этот путь и не свернуть обратно.

Регистрируйтесь по ссылке)

Всем привет в этом чатике🙋🏻‍♀️ (я честно пошерстила беседу, и, кажется, сюда можно врываться с неплохими предложениями о работе, что я и сделаю)

Команда Wrike в поисках QA-инженеров в несколько наших продуктовых команд: сейчас мы ищем ребят на ручное тестирование и на позицию fullstack QA. Пока мы работаем удаленно, но в целом позиции подразумевают работу из питерского офиса, а значит - релокацию (с которой мы, конечно, помогаем от и до).

Кратко о нас:
Создаем web-приложение для управления проектами и совместной работы, входим в топ-3 своей сферы и сотрудничаем с 20 тыс. компаний по всему миру.

Что ждем от тебя:
- опыт тестирования веб-приложений (от 1 года)
- знание английского (от В1)
- как плюс: знание на базовом уровне любого языка программирования

Что у нас есть:
- международная команда (пригодится английский от intermediate и вот это вот всё)
- реально работающий scrum
- 20000+ самодокументирующихся автотестов и возможность не делать ручную регрессию
- кропотливо подобранная команда сильных специалистов (500+ человек)
- оформление-дмс-английский и гибкая вилка от 100к
- классный офис и одни из лучших корпоративных ивентов в городе

Подробнее о позиции и бонусах написано тут.

Вопросы и резюме можно присылать мне на почту darina.povtar@team.wrike.com или сразу писать в лс @darinapovtar🙃