Неидеальный спринт
Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы — всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.
Реальность бывает жестокой.
Пройдемся по совершенно обычным для каждого тимлида проблемам, и способам их решения. Начнем с самой распространённой.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь завершать все задачи по спринту в срок. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно.
1 Ниуспе…
Никогда не видел, чтобы на презентациях завершенные спринты выглядели вот так:
Довольно частая картина в конце спринта
В идеале конечно надо всё успевать, но положа руку на сердце (а другую на библию конституцию), признайтесь, какой процент спринтов полностью выполняется? Хорошо, если ответ будет «около 50%»). В остальных же спринтах хоть что-то, да не успеваем. Что делать?
Стандартные решения — просто перенести на следующий спринт и доделать, закрыть и доделать в фоновом режиме, закрыть как есть и занести в техдолг. Все эти способы по тем или иным причинам не очень хорошие.
Решение:
Пересчитать историю, и зачесть команде столько сторипоинтов, насколько команда наработала, после сделать инъекцию в бэклог, куда внести остаток от спринта отдельной историей с остаточной оценкой и высшим приоритетом, и делать в следующем спринте уже её до победного. Недостаток этого решения очевиден — зачем точно оценивать истории, зачем спешить, если мы всегда можем взять время и доделать в следующем спринте. В этом случае неплохо применить к команде некие штрафы, например за каждый подобный случай лишать части премии назначать штрафные баллы, и устраивать соревнования команд.
2 Проблемы у конкретного разработчика
Разработчик — зверь хитрый и изворотливый. Это только кажется, что они все такие самостоятельные и проактивные, на самом деле они, как и все люди, очень разные.
Конечно, есть подход «не работай с мудаками», да вот только он совершенно не масштабируемый. Набрать 10 супергероев на суперинтересный и общественно значимый проект — можно. Набрать 100 супергероев на скучное банковское легаси — очень навряд ли. Так что работа с мудаками — это и есть самая настоящая будня тимлида особенно когда он сам мудак.
2.1 Прямой обман
Надо сказать, случай и правда довольно редкий, так как за него в итоге всё равно прилетит. Но потом. Поэтому можно перевести небольшую задачу в «сделано», зная, что лид сейчас занят и не проверит, и уйти в отпуск, а там как-нибудь отмажемся…
2.2 Разработчик перестал работать
Обычно случается после долгих праздников, отпусков, отмечания свадеб и прочих перерывов в работе. Ну и при выгорании, конечно же. Именно тут возникают очень интересные истории с такими «невероятной сложности плавающими» багами, которые «делались» полспринта, и в итоге решались за 2 минуты при ближайшем рассмотрении.
Решение:
Подобные случаи в начале моего тимлидского пути и научили меня никому не верить на слово, и просить показать, что сделано. Регулярно, раз в пару дней. Это приучает разработчиков к добросовестности и к тому, что лид всё равно не отстанет. Беда наступает, когда лид перестает всё контролировать сам — просто не успевает. Тогда лучше всего организовывать перекрестный код-ревью, а лиду показывать уже более-менее готовый функционал.
3 Конфликт
Как внутри команды, так и с заказчиком (его представителем, продукт-овнером и т.п.). Обычно выглядит как куча комментариев (и комментариев к комментариям) с постепенным повышением накала, вплоть до перехода к личным оскорблениям.
Бывает, что кто-то из команды очень хочет попробовать какую-то технологию, для проекта не нужную, и начинает её лоббировать. Случается, что включает её самостоятельно, огребает проблем и потом не знает, как их решать, что не сильно радует остальных.
Иногда не сходятся во мнениях представитель заказчика и техлид, что приводит к отсутствию согласования и срыву спринта, так как нельзя завершить историю без согласования представителем заказчика.
Решение:
Обычно конфликт заканчивается волевым решением ответственного, и именно для этого очень неплохо четко распределять зоны ответственности заранее. Если не получилось — можно прямо в ходе конфликта, только письменно с оповещением всей команды, и дальнейшими встречами один на один со сторонами, чтобы предотвратить намеренный саботаж решения или уничижение «проигравшей» стороны.
4 Мы тестировали-тестировали, да не вытестировали
Встречается регулярно при недостатке времени на тестирование и попытке закрыть историю до конца спринта. Думаю, всем понятно, что не до конца протестированное решение включать в релиз нельзя.
Решение:
Описано вот тут. А изловить такую ситуацию можно, затребовав с тестировщиков письменные результаты тестов. Они будут упираться (работа с документами всегда скучна), но даже мимолетного взгляда на план тестирования и результаты будет достаточно, чтобы задать ряд увесистых вопросов. Ну и заодно зафейлить сроки по истории.
5 Заказчик на дэмо: я не это имел ввиду
Этих слов боятся все, особенно менеджмент, потому что слова эти значат почти наверняка срыв сроков по проекту и уменьшение премиальной части. На этапе произнесения сделать уже ничего нельзя, история скорее всего уходит на помойку в стол, и начинается этап уточнения требований. Считать ли это проблемами спринта (ведь по сути история сделана, и сделана в срок) — ученые спорят.
Решение:
Работать с заказчиком не только на дэмо, но и в течении спринта, периодически уточняя, не изменились ли его требования. Помогает не всегда просто потому, что заказчик, с которым можно работать, и заказчик, принимающий работу — далеко не всегда одно и то же лицо. Но надо же хоть что-то делать.
6 Включи в текущий спринт очень срочную задачу сверх плана!
Случается не часто, но регулярно, обычно связана с багами на проде или прям срочными требованиями очень высокого руководства заказчика, про которые все, включая представителей этого самого заказчика, дружно забыли. Срывает все сроки, сносит крыши и башни, вызывает переработки, а потом лежит никому не нужное полтора месяца, потому что «ждем релизного окна».
Решение:
Запрет на включение в спринт любых задач, кроме запланированных. Всё, что прилетает сверху, снизу, сбоку, включается в бэклог будущих спринтов с высшим приоритетом. Помимо создания спокойной атмосферы в команде, это решение еще и здорово охлаждает горячие головы людей, старающихся понравиться заказчику, одобряя любые его требования и бросающихся немедленно их исполнить.
И вот теперь, ознакомившись с этим далеко не исчерпывающим перечнем проблем каждого спринта, вы перестанете задавать вопросы типа:
Некоторые не в курсе.
