Comments 10
Нет чувства прогресса, нет ощущения, что продукт становится ближе к релизу.
Предложу версию.
Возможно, ваш проект топчется на месте, потому что в его оценке вы опираетесь на чувства и ощущения.
Если в качестве критериев оценки успешности использовать не чувства нежных разработчиков, а что-то реальное, то проект может перестать топтаться на месте.
Ради чего мы работаем в этом спринте?
Да как и всегда ради зарплаты.
KPI капает. Тимлид отчитывается, что все разработчики заняты. Надо ещё нанять, и ему зарплату поднять управлять то надо большим количеством. Менеджеры рады и тоже накручивают оклады. Пока есть доход который всё это окупает всё очень рады. Смит был прав вирусы.....
Кажется, что здесь проблема с приоритезацией задач. Должен быть некий менеджер проекта, который будет говорить что очень важно, а что не важно. Другие могут только добавлять вводные, например, я как разработчик могу повлиять на включение техдолга, который заблокирует разработку или что-нибудь подобное.
Цель спринта как решение проблемы не очень понятно что даст, так как проблема описанная в статье может быть и в канбане. В целом, задача сама по себе должна давать понимание того, зачем она нужна, без цели спринта.
Приоритезация - это то, что решит проблему.
DoD - не всегда должен влиять на клиента, могут быть технические оптимизации. Не стоит смешивать критерии завершенности задачи и клиента
Ежи плакали, кололись, но продолжали играть в скрам.
Важно также знать какова цель проекта в долгосрочном плане и хотя бы в крупную клетку промежуточные цели. И исходя из этого расставлять приоритеты.
Когда Скрам соскамился со старта)
ИМХО тут возможны два варианта:
Общая инрархичная структура компании довлеет над командой разработки, которая пытается в agile и натыкается на внешние директивы, приоритезацию и KPI, которые идут в разрез в внутренним подходом.
Тимлид не тянет уровень. Agile предъявляет высокие требования к компетенции тимоида как руководителя и как технолога в том продукте, что производит команда. Если глубина понимания недостаточная или не хватает навыков управления, то будет смещаться в неправильную сторону система приоритетов, постановка целей/задач и критерии эффективности/выполнения.
Докину до кучи, ИМХО неспециалиста в Agile, мне кажется этот подход страдает теми же болезнями проектного управления: конфликты интересов команды и административной структуры, внутренний конфликт интересов члена команды и члена административной структуры, двойственность роли и должности, неоднозначность приоритезации общих регламентов компании и внутрикомандных.
Синдром бессмысленного спринта