Еще не участник? Зарегистрируйся!
Забыли пароль? Восстановить

Антикранч: советы и практики по планированию и работе в команде

11 октября 2022

Кранчи — это плохо, тут никаких сомнений нет. Но организовать работу технической (и не только) команды так, чтобы кранчей не случалось — задача непростая. Полезные советы на эту тему в своём докладе на GDC дал Крис Кобб, технический директор компании Pragma — а мы пересказываем самые важные тезисы из его выступления и дополняем их.


Оценивать задачи сложно, но это необходимо при разработке продукта

Важно понимать, что оценка задачи — это не обязательство выполнить её безусловно в поставленный срок.

Колоколообразная кривая очень хорошо иллюстрирует, чего ожидать. Если по оценке задача была на три дня, то иногда её можно выполнить за день. Но если она была выполнена за пять дней — это тоже нормально. И это математически ожидаемо. А вот на десятый день задачу стоит переосмыслить — вероятно, она оказалась слишком сложной. Возможно стоит её даже отменить или положить в бэклог.

Но вопросы стоит задавать уже на третий день, а на пятый — делать это настойчивее. В идеале нужно периодически проверять статус задачи (ещё до наступления срока выполнения), чтобы определить проблемы на ранних этапах.


Жёстко заданные тайминги выполнения задач не работают. При смещении хотя бы одной задачи, быстро сдвигается и всё остальное. Приходится постоянно менять план, а у команды растёт стресс из-за ощущения, что ничего не успевается.


Можно посмотреть на это иначе.


Эстимейты или стори поинты могут съехать, но важнее мерить, сколько работы было сделано в каждой итерации. «Мы делаем каждый раз по пять-шесть вещей» — что-то перешло из прошлого спринта, что-то добавилось по ходу. Это позволяет построить вектор выполнения работы и не задавать жёсткие рамки по каждой из задач.

Другая интересная штука в рамках планирования — конус неопределённости.

Когда идея совсем новая, вы мало про неё знаете. Не стоит давать жёстких оценок на этом этапе — это рискованно. Попросите экспертов прикинуть очень примерные сроки. Через некоторые время, когда будет меньше неизвестных, можно уже обсуждать сроки более реальные. Суть в том, что нецелесообразно тратить много времени на обсуждение задач, если они в бэклоге или вам не хватает контекста.

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


Оценка сроков

Для оценки сроков можно использовать различные системы — например, t-shirt sizing (размеры футболок) и Фибоначчи.

Размеры футболок

Все носят футболки, поэтому не составит труда понять разницу между размером XS и L. Использование этих размеров для оценки трудозатрат — хороший способ без сложных расчётов получить относительно достоверное представление о том, сколько времени и сил потребуется на выполнение задачи.


Фибоначчи

Маленькие числа (1, 2, 3, 5) довольно детальны — разница сложности между ними понятна. А вот на 8, 13, 21 и далее точность понижается. Условно, если у вас в одной руке предмет весом пять килограмм, а в другой десять, легко понять, какой предмет тяжелее. Но всё усложняется, если один весит пять, а другой шесть. Тут оценка по Фибоначчи и поможет.

Но важно не то, какую технику или метод вы выберите. Главное — не менять их по ходу разработки, нужно быть последовательным. И ещё один важный момент: не правьте числа и эстимейты после выполнения задачи. Если задача должна была быть выполнена за три дня, а заняла полторы недели, то лучше не менять дату в задаче. После этого будет невозможно ничего спланировать и предсказать.


Discovered work

Когда вы решаете одну проблему, то у вас появляются новые. Если команда делает 20 стори поинтов каждую итерацию, а осталось 100 — это не значит, что вы выполните их за пять итераций. Потому что не учитываются задачи, которые появляются по ходу. Нужно знать, сколько задач появляется в течение каждой итерации. Если команда заканчивает 20, но появляется 10 новых поинтов, то в рамках каждой итерации будет больше работы.

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


Передача знаний

Всем известный bus factor. Критические вещи не должны зависеть от одного человека. Иначе получится группа индивидуалов, а не полноценная команда. А если такой человек уйдёт или с ним что-то случится, некому будет его заменить.

Команды не должны постоянно меняться

Часто в студиях по необходимости выдёргивают людей на другие проекты — это сказывается времени.  Эффективны не команды, состоящие чисто из профи, а из людей, которые дополняют сильные стороны друг друга и перекрывают слабые. Поиск новых людей в команду — трудоёмкий процесс, который бьёт по производительности. И не стоит забывает, что если вы добавляете людей в проект, то в целом команда замедлится.

Парное программирование

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


QA — часть корабля

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

Test-driven development

Хорошая практика, тяжёлая в использовании. Говоря кратко, сначала пишется тест, покрывающий функцию, затем пишется код, проходящий тест. А под конец проводится переработка нового кода под стандарты. У дядюшки Боба есть очень хороший доклад, где он как раз касается этой темы. И стоит напомнить про закон Парето: 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата.


Continuous integration

Людям нужна песочница, чтоб тестировать что-то, не мешая остальным членам команды. Для этого придуманы features branches. Ведь когда команда растёт, их фичи могут ждать добавления в основную ветку неделями.

Некоторые используют trunk based development, когда все работают в одной ветке, не допуская создания других долгоживущих веток. В такой модели мыслишь не только в рамках своей задачи, но также учитываешь, сломает ли твоя фича билд другим членам команды, можно ли её безопасно добавить или выключить. Подробнее о feature toggle можно почитать у Мартина Фаулера.

Автор: Андрей Апанасик

Оригинальная публикация в блоге автора


Больше полезных материалов






 Подпишись на нас