Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.
![Реальность бывает жестокой. Реальность бывает жестокой.](https://habrastorage.org/getpro/habr/upload_files/d17/ad0/5fd/d17ad05fd18b7ccd5da0b47e91313969.jpg)
Пройдемся по совершенно обычным для каждого тимлида проблемам, и способам их решения. Начнем с самой распространённой.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь завершать все задачи по спринту в срок. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно.
1. Ниуспе…
Никогда не видел, чтобы на презентациях завершенные спринты выглядели вот так:
![Довольно частая картина в конце спринта Довольно частая картина в конце спринта](https://habrastorage.org/getpro/habr/upload_files/844/ac6/c00/844ac6c001dd3665cde3ec550c2c23a1.jpeg)
В идеале конечно надо всё успевать, но положа руку на сердце (а другую на библию конституцию), признайтесь, какой процент спринтов полностью выполняется? Хорошо, если ответ будет "около 50%"). В остальных же спринтах хоть что-то, да не успеваем. Что делать?
Стандартные решения – просто перенести на следующий спринт и доделать, закрыть и доделать в фоновом режиме, закрыть как есть и занести в техдолг. Все эти способы по тем или иным причинам не очень хорошие.
Решение:
Пересчитать историю, и зачесть команде столько сторипоинтов, насколько команда наработала, после сделать инъекцию в бэклог, куда внести остаток от спринта отдельной историей с остаточной оценкой и высшим приоритетом, и делать в следующем спринте уже её до победного. Недостаток этого решения очевиден – зачем точно оценивать истории, зачем спешить, если мы всегда можем взять время и доделать в следующем спринте. В этом случае неплохо применить к команде некие штрафы, например за каждый подобный случай лишать части премии назначать штрафные баллы, и устраивать соревнования команд.
2. Проблемы у конкретного разработчика
Разработчик – зверь хитрый и изворотливый. Это только кажется, что они все такие самостоятельные и проактивные, на самом деле они, как и все люди, очень разные.
Конечно, есть подход «не работай с мудаками», да вот только он совершенно не масштабируемый. Набрать 10 супергероев на суперинтересный и общественно значимый проект – можно. Набрать 100 супергероев на скучное банковское легаси – очень навряд ли. Так что работа с мудаками – это и есть самая настоящая будня тимлида особенно когда он сам мудак.
2.1 Прямой обман
Надо сказать, случай и правда довольно редкий, так как за него в итоге всё равно прилетит. Но потом. Поэтому можно перевести небольшую задачу в «сделано», зная, что лид сейчас занят и не проверит, и уйти в отпуск, а там как-нибудь отмажемся…
2.2 Разработчик перестал работать
Обычно случается после долгих праздников, отпусков, отмечания свадеб и прочих перерывов в работе. Ну и при выгорании, конечно же. Именно тут возникают очень интересные истории с такими «невероятной сложности плавающими» багами, которые «делались» полспринта, и в итоге решались за 2 минуты при ближайшем рассмотрении.
Решение:
Подобные случаи в начале моего тимлидского пути и научили меня никому не верить на слово, и просить показать, что сделано. Регулярно, раз в пару дней. Это приучает разработчиков к добросовестности и к тому, что лид всё равно не отстанет. Беда наступает, когда лид перестает всё контролировать сам – просто не успевает. Тогда лучше всего организовывать перекрестный код-ревью, а лиду показывать уже более-менее готовый функционал.
3. Конфликт
Как внутри команды, так и с заказчиком (его представителем, продукт-овнером и т.п.). Обычно выглядит как куча комментариев (и комментариев к комментариям) с постепенным повышением накала, вплоть до перехода к личным оскорблениям.
Бывает, что кто-то из команды очень хочет попробовать какую-то технологию, для проекта не нужную, и начинает её лоббировать. Случается, что включает её самостоятельно, огребает проблем и потом не знает, как их решать, что не сильно радует остальных.
Иногда не сходятся во мнениях представитель заказчика и техлид, что приводит к отсутствию согласования и срыву спринта, так как нельзя завершить историю без согласования представителем заказчика.
Решение:
Обычно конфликт заканчивается волевым решением ответственного, и именно для этого очень неплохо четко распределять зоны ответственности заранее. Если не получилось – можно прямо в ходе конфликта, только письменно с оповещением всей команды, и дальнейшими встречами один на один со сторонами, чтобы предотвратить намеренный саботаж решения или уничижение «проигравшей» стороны.
4. Мы тестировали-тестировали, да не вытестировали
Встречается регулярно при недостатке времени на тестирование и попытке закрыть историю до конца спринта. Думаю, всем понятно, что не до конца протестированное решение включать в релиз нельзя.
Решение:
Описано вот тут. А изловить такую ситуацию можно, затребовав с тестировщиков письменные результаты тестов. Они будут упираться (работа с документами всегда скучна), но даже мимолетного взгляда на план тестирования и результаты будет достаточно, чтобы задать ряд увесистых вопросов. Ну и заодно зафейлить сроки по истории.
5. Заказчик на дэмо: я не это имел ввиду
Этих слов боятся все, особенно менеджмент, потому что слова эти значат почти наверняка срыв сроков по проекту и уменьшение премиальной части. На этапе произнесения сделать уже ничего нельзя, история скорее всего уходит на помойку в стол, и начинается этап уточнения требований. Считать ли это проблемами спринта (ведь по сути история сделана, и сделана в срок) – ученые спорят.
Решение:
Работать с заказчиком не только на дэмо, но и в течении спринта, периодически уточняя, не изменились ли его требования. Помогает не всегда просто потому, что заказчик, с которым можно работать, и заказчик, принимающий работу – далеко не всегда одно и то же лицо. Но надо же хоть что-то делать.
6. Включи в текущий спринт очень срочную задачу сверх плана!
Случается не часто, но регулярно, обычно связана с багами на проде или прям срочными требованиями очень высокого руководства заказчика, про которые все, включая представителей этого самого заказчика, дружно забыли. Срывает все сроки, сносит крыши и башни, вызывает переработки, а потом лежит никому не нужное полтора месяца, потому что «ждем релизного окна».
Решение:
Запрет на включение в спринт любых задач, кроме запланированных. Всё, что прилетает сверху, снизу, сбоку, включается в бэклог будущих спринтов с высшим приоритетом. Помимо создания спокойной атмосферы в команде, это решение еще и здорово охлаждает горячие головы людей, старающихся понравиться заказчику, одобряя любые его требования и бросающихся немедленно их исполнить.
И вот теперь, ознакомившись с этим далеко не исчерпывающим перечнем проблем каждого спринта, вы перестанете задавать вопросы типа:
![Некоторые не в курсе. Некоторые не в курсе.](https://habrastorage.org/getpro/habr/upload_files/e0a/9f8/8b3/e0a9f88b395cded4476ee51c30d68a60.jpeg)