Paulina Iva
Довольно неплохая статья о том, как это должно работать.
Из личного опыта могу внести комментарий по поводу релиза, а именно: «одна команда простаивает, пока работает другая (и далее)»
Для того, чтобы не было простоя, актуализация кейсов может быть осуществлена в начале следующего спринта (обычно, первые пару дней, нагрузка в тестировании значительно ниже). Особенно это актуально, если бизнесом были внесены изменения во 2й половине спринта, из-за чего разработка физически не успевает и допилить доп.фичи, и актуализировать кейсы, и прорегрессить (в случае, когда покрытие автотестами мало или же вовсе отсутствует), и релизнуться.
Это не норма, но на моей личной практике помогает сэкономить драгоценное время и избежать перекоса нагрузки между концом текущего и началом нового спринта.
Начала читать в надежде найти что-то полезное для работы.
Продолжила с мыслью: «может быть, что-то полезное скажет, раз расписывает такой быстрый взлёт, чуть ли не с джуна до сеньора-техлида за пару лет. Может быть какая-то фраза поможет мне в решении некоторых вопросов в управлении процессами и командой».
После прочтения — в голове фраза Гоблина про потраченное время 🌚
Спасибо за статью!)
Некоторые проблемы и решения были очевидны, но после прочтения стало ясно, что интуитивные предположения оказались верны😌
Подскажите, пожалуйста, если не сложно, такой момент:
Сталкивались ли Вы в работе с необходимостью взаимодействовать с некомпетентными сотрудниками/руководителями других подразделений и как справлялись с последствиями их не очень правильных решений?
Или Вам отвело от этой «весёлой части» рабочего процесса?
Заранее спасибо за ответ!