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

Пройдемся по совершенно обычным для каждого тимлида проблемам, и способам их решения. Начнем с самой распространённой.

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

1. Ниуспе…

Никогда не видел, чтобы на презентациях завершенные спринты выглядели вот так:

В идеале конечно надо всё успевать, но положа руку на сердце (а другую на библию конституцию), признайтесь, какой процент спринтов полностью выполняется? Хорошо, если ответ будет "около 50%"). В остальных же спринтах хоть что-то, да не успеваем. Что делать?

Стандартные решения – просто перенести на следующий спринт и доделать, закрыть и доделать в фоновом режиме, закрыть как есть и занести в техдолг. Все эти способы по тем или иным причинам не очень хорошие.

Решение:

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

2. Проблемы у конкретного разработчика

Разработчик – зверь хитрый и изворотливый. Это только кажется, что они все такие самостоятельные и проактивные, на самом деле они, как и все люди, очень разные.

Конечно, есть подход «не работай с мудаками», да вот только он совершенно не масштабируемый. Набрать 10 супергероев на суперинтересный и общественно значимый проект – можно. Набрать 100 супергероев на скучное банковское легаси – очень навряд ли. Так что работа с мудаками – это и есть самая настоящая будня тимлида особенно когда он сам мудак.

2.1 Прямой обман

Надо сказать, случай и правда довольно редкий, так как за него в итоге всё равно прилетит. Но потом. Поэтому можно перевести небольшую задачу в «сделано», зная, что лид сейчас занят и не проверит, и уйти в отпуск, а там как-нибудь отмажемся…

2.2 Разработчик перестал работать

Обычно случается после долгих праздников, отпусков, отмечания свадеб и прочих перерывов в работе. Ну и при выгорании, конечно же. Именно тут возникают очень интересные истории с такими «невероятной сложности плавающими» багами, которые «делались» полспринта, и в итоге решались за 2 минуты при ближайшем рассмотрении.

Решение:

Подобные случаи в начале моего тимлидского пути и научили меня никому не верить на слово, и просить показать, что сделано. Регулярно, раз в пару дней. Это приучает разработчиков к добросовестности и к тому, что лид всё равно не отстанет. Беда наступает, когда лид перестает всё контролировать сам – просто не успевает. Тогда лучше всего организовывать перекрестный код-ревью, а лиду показывать уже более-менее готовый функционал.

3. Конфликт

Как внутри команды, так и с заказчиком (его представителем, продукт-овнером и т.п.). Обычно выглядит как куча комментариев (и комментариев к комментариям) с постепенным повышением накала, вплоть до перехода к личным оскорблениям.

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

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

Решение:

Обычно конфликт заканчивается волевым решением ответственного, и именно для этого очень неплохо четко распределять зоны ответственности заранее. Если не получилось – можно прямо в ходе конфликта, только письменно с оповещением всей команды, и дальнейшими встречами один на один со сторонами, чтобы предотвратить намеренный саботаж решения или уничижение «проигравшей» стороны.

4. Мы тестировали-тестировали, да не вытестировали

Встречается регулярно при недостатке времени на тестирование и попытке закрыть историю до конца спринта. Думаю, всем понятно, что не до конца протестированное решение включать в релиз нельзя.

Решение:

Описано вот тут. А изловить такую ситуацию можно, затребовав с тестировщиков письменные результаты тестов. Они будут упираться (работа с документами всегда скучна), но даже мимолетного взгляда на план тестирования и результаты будет достаточно, чтобы задать ряд увесистых вопросов. Ну и заодно зафейлить сроки по истории.

5. Заказчик на дэмо: я не это имел ввиду

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

Решение:

Работать с заказчиком не только на дэмо, но и в течении спринта, периодически уточняя, не изменились ли его требования. Помогает не всегда просто потому, что заказчик, с которым можно работать, и заказчик, принимающий работу – далеко не всегда одно и то же лицо. Но надо же хоть что-то делать.

6. Включи в текущий спринт очень срочную задачу сверх плана!

Случается не часто, но регулярно, обычно связана с багами на проде или прям срочными требованиями очень высокого руководства заказчика, про которые все, включая представителей этого самого заказчика, дружно забыли. Срывает все сроки, сносит крыши и башни, вызывает переработки, а потом лежит никому не нужное полтора месяца, потому что «ждем релизного окна».

Решение:

Запрет на включение в спринт любых задач, кроме запланированных. Всё, что прилетает сверху, снизу, сбоку, включается в бэклог будущих спринтов с высшим приоритетом. Помимо создания спокойной атмосферы в команде, это решение еще и здорово охлаждает горячие головы людей, старающихся понравиться заказчику, одобряя любые его требования и бросающихся немедленно их исполнить.

И вот теперь, ознакомившись с этим далеко не исчерпывающим перечнем проблем каждого спринта, вы перестанете задавать вопросы типа: