Советы и практики по управлению командой (по опыту работы над League of legends). Вещи хоть и очевидные, но многие про них всё равно забывают.
Курсивом будут помечены мои примечания по тексту или дополнения. По ходу разбора также будут пояснения по каким-то вещам, которые в самом докладе упоминаются.
Оценка сроков и планирование
Оценивать задачи сложно, но это необходимо при разработке сложного продукта. В первую очередь необходимо понять, что оценки задач не являются обязательствами, что прям к этому сроку задача будет выполнена.
Колоколообразная кривая очень хорошо иллюстрирует то, чего ожидать. Если по оценке задача была на 3 дня, то иногда её можно выполнить за день. Но если задача была выполнена за 5 дней, то это тоже нормально. И это математически ожидаемо (вариации). А вот на 10 день уже стоит переосмыслить задачу — вероятно она оказалась слишком сложной. Возможно стоит её вообще отменить или в беклог положить.
Вопросики стоит задавать уже на 3 день, а на 5 ещё настойчевей. В идеале, конечно, периодически проверять статус задачи (ещё до наступления срока выполнения), чтобы определить проблемы на ранних этапах.
Жёстко заданные тайминги выполнения задач не работают. При смещении хотя бы одной задачи всё быстро сдвигается, приходится постоянно модифицировать план + стресс у команды, т.к. ощущение, что постоянно не успевают.
Можно посмотреть на это иначе.
Каждый estimate или story могут съехать, но важнее мерить, сколько работы было сделано каждую итерацию. «Мы делаем каждый раз по 5-6 вещей», что-то перешло из прошлого спринта, что-то добавилось по ходу. Это позволяет построить вектор выполнения работы и не задавать жёстко рамки по каждой из задач.
Есть ещё интересная штука в рамках планирования — конус неопределённости.
Когда идея совсем новая, вы мало про неё знает. Не нужно давать жёстких оценок на этом этапе, т. к. это очень рискованно. Попросите экспертов прикинуть очень примерные сроки. Через некоторые время, когда станет больше понятно и станет меньше неизвестных, можно уже более реально обсуждать сроки. Суть в том, что не нужно тратить много времени на обсуждения задач, если они в беклоге или не хватает контекста.
Ещё одна из вещей, касающихся беклога — не нужно засорять его мелкими вещами, особенно если доберётесь до них лишь через несколько месяцев. Достаточно сгруппировать такие идеи/задачи и/или оформить в виде эпика. А возможно стоит и вовсе выкинуть, если вы не планируете возвращаться к этому в ближайшие полгода.
Оценка сроков
Люди используют различные системы t-shirt sizing (размеры футболок), Фибоначчи.
Размеры футболок
Все носят футболки, поэтому не составит труда понять разницу между размером XS и L. Использование этих размеров для оценки трудозатрат — хороший способ без сложных расчётов получить относительно достоверное представление о том, сколько времени и сил потребуется на выполнение задачи.
Фибоначчи
Маленькие числа (1, 2, 3, 5) довольно детальны и есть более-менее понятна разница сложности между ними. На 8, 13, 21 и далее точной понижается. У нас нет 21, 22, 23 и т. п, после 21 у нас 34 и далее. Если у вас в одной руке предмет весом 5кг, а в другой 10, то легко понять, какой предмет тяжелее. Но тяжелее, если один вести 5, а другой 6. Тут оценка по Фибоначчи и поможет.
Но важно не то, какую технику/метод вы выберите, главное не менять их по ходу разработки, нужно быть последовательным.
Ещё один важный момент: не правьте числа/эстимейты после выполнения задачи. Если задача должна была быть выполнена за 3 дня, а заняла полторы недели, то не нужно менять дату в задаче. После этого уже будет невозможно ничего спланировать и предсказать.
Discovered work
Когда вы решаете одну проблему, то у вас появляются новые.
Если команда делает 20 сторипоинтов каждую итерацию, а осталось 100, это не значит, что вы выполните их за 5 итераций, т.к. не учитываете задачи, которые появляются по ходу. Нужно знать, сколько задач появляются в течение каждой итерации. Если команда заканчивает 20, но появляется 10 новых поинтов, то в рамках каждой итерации будет больше работы.
На первых этапах разработки игры новых сторипоинтов может появляться столько же (а то и больше), чем выполненных задач. Но ближе к завершению проекта это числа должно уменьшаться, очевидно, т. к. иначе вы никогда не доберётесь до релиза.
Про команду
Команды не должны постоянно меняться. Часто в студиях по необходимости выдёргивают людей на те или иные задачи в другие проекты.
Перфомят не команды, состоящие чисто из профи, а из людей, которые дополняют сильные и слабые стороны друг друга.
Поиск людей в команду трудоёмкий процесс, который ударит по производительности. И не стоит забывает, что если вы добавляете людей в проект, то команда замедлится (порой на месяц-два, пока онбординг идёт). Рекомендую у Брукса «Мифический человеко-месяц».
Передача знаний
Всем известный bus factor. Не должно быть такого, что критические вещи зависят только от одного человека. В таком случае у вас просто будет группа индивидуалов, а не полноценная команда. К тому же, если такой человек уйдёт или с ним что-то случится, некому будет его заменить.
Автор доклада приводит в пример их систему подбора противников, над которой работал один разработчик. Он мог заниматься задачей месяцами, но при этом никому не передавал знания. Появилась необходимость подправить матчмейкер, чтобы игрокам, которые вернулись в игру через 6 месяцев, в первое время подкидывались простые матчи, т. к. их реальный рейтинг скорей всего уже не совпадает с ELO-рейтингом. И какое-то время это работало, но потом таким игрокам сразу начинали подсовываться матчи, где их разносили в пух и прах, хотя кривая сложности должна была возрастать плавно.
Несколько человек пыталось пофиксить проблему — безрезультатно, т. к. очень запутанная система. У них было 2 копии системы: одна по старой логике, вторая по новой. Из-за этого получилось так, что после боя со слабыми противниками их рейтинг всё равно поднимался Это приводило к тому, что он ещё больше стал не соответствовать реальному скиллу игрока.
Парное программирование
Одна из техник, при которой код создаётся парой людей, решающих вместе одну задачу. Один пишет код, другой в это время обдумывает задачу и строит картину в целом. Периодически они меняются местами.
QA — часть корабля
Не редки ситуации, когда QA подключают на последних этапах разработки и дают указ, чтобы они убедились, что с продуктом всё ок. Но они не были на проекте с самого начала, не принимали участия в обсуждениях, не в курсе контекста и многих нюансов.
QA должны быть включены в пайплайн, в дизайн ревью, в обсуждения.
Test-driven development
Хорошая практика, но весьма трудна в использовании. Если вкратце, то сначала пишется тест, покрывающий фичу/функционал (и он сразу же падает, т. к. кода то ещё нет), затем пишется код, проходящий тест, и под конец проводится рефакторинг нового кода под стандарты. Очень хороший доклад был у дядюшки Боба, где он, в том числе, эту тему затрагивает.
И стоит напомнить про закон Парето — мы думаем, что 80% фич сделаны и, по классике, потом понимаем, что осталось ещё 80% фич.
Continuous integration
Это не просто использование Дженкинса/Тимсити, они лишь технологии/средства. Людям нужна песочница, чтоб тестировать вещи, при этом чтоб не мешать остальным членам команды. Для этого придуманы features branches. Когда команда растёт, то их фичи могут ждать мёрджа в основную ветку неделями. Автор приводит пример того, как одна команда, работавшая над вичей 6 месяцев, ждала потом больше 2 лет, чтобы их код попал в мастер-ветку.
Некоторые используют trunk based development, когда все работают в одной ветке, не допускают создание других долгоживущих веток. При таком подходе нету геморра при мёрдже коммитов и редко ломаются билды.
В такой модели мыслишь категориями не чисто в рамках своей задачи, а учитываешь то, сломает ли эта фича билд другим членам команды. Если залить тестовые объекты/ассеты, то не сломается ли игра у других? Могу ли я добавить безопасно фичу или выключить её? У Мартина Фаулера очень подробная статья была про feature toggle.
Ценности команды
- «Мы будем отдавать предпочтение потребностям клиентов, а не теоретически идеальной системе». Не нужно запарываться над идеальным решением.
- Баланс между качество и скоростью. Хочется сразу приступить к задаче, но при этом не огрести потом в будущем из-за того, что что-то не учёл на ранних этапах.
- Нужно давать командам побольше свободы и меньше бюрократии.
Если хотите поддержать выход дайджеста и других материалов, сделать это можно одним из способов.