Получи случайную криптовалюту за регистрацию!

Хоть в названии доклада фигурируют кранчи, но разговор больше | Gamedev suffering

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

Основные моменты выписал.
- Эстимейты — это не комитмент.
- Жёстко заданные тайминги выполнения задач не работают. Всё быстро сдвигается, приходится постоянно модифицировать план + стресс у команды, т.к. ощущение, что постоянно не успевают.
- Bell Curve очень хорошо иллюстрирует то, чего ожидать. Если эстимейт был на 3 дня, то выполнить за 5 дней ок. А вот на 10 день уже стоит переосмыслить задачу — вероятно она оказалось слишком сложной. Возможно стоит её вообще отменить или в беклог положить.
- Cone of uncertainty.
- Не нужно засорять беклог мелкими вещами, особенно если доберётесь до них через много месяцев. Достаточно сгруппировать это и/или оформить в виде эпика. А возможно и вовсе выкинуть.
- Не правьте числа/эстимейты после выполнения задачи.
- Если команда делает 10 сторипоинтов за недельный спринт, а осталось 100, это не значит, что вы выполните их за 10 недель, т.к. не учитываете задачи, которые появляются по ходу дела.

- Перфомят не команды, состоящие чисто из профи, а из людей, которые дополняют сильные и слабые стороны друг друга.
- Если вы добавляете людей в проект, то команда замедлится (порой на месяц-два, пока онбординг идёт и всё такое). Я рекомендую всем почитать у Брукса «Мифический человеко-месяц».
- Bus factor (да-да). Не должно быть такого, что критические вещи зависят только от одного человека. В таком случае у вас просто будет группа индивидуалов, а не команда.
- Парное программирование, код ревью и шаринг знаний внутри команды.
- QA должны быть включены в пайплайн, в дизайн ревью, в обсуждения.
- TDD хорошая практика.
- Continuous integration — это не просто использование Дженкинса или Тимсити, они лишь технологии/средства. На почитать: trunk based development, feature toggle.

- Не нужно запарываться над идеальным решением и продумывать всё заранее.
- Качество vs скорость. Не нужно пытаться продумать всё заранее.
- Нужно давать командам побольше свободы и меньше бюрократии (кэп).

#GDC