Антикранч: советы и практики

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

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

По поводу методики разработки:

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

И напоследок:

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

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

Антикранч: советы и практики
8080
46 комментариев

Не кранчите, пацаны, вы еще матерям нужны

22
Ответить

Эстимейты — это не комитмент.Споткнулся уже на втором абзаце. Для меня пожалуй рекорд

18
Ответить

Переизбыток ненужных англицизмов. А если вместо Bell Curve написать Нормальное распределение, то жопа отвалится?

13
Ответить

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

Ответить

Увидел заголовок, думаю - збс, ведь все эти методы можно применять не только в ИТ, а вообще в жизни или у себя на работе, чтобы все было "быстро, четко, по полочкам".

Но прочитав понял, что без разговорника русско-айтишного вообще не стоит соваться. Обидно жи есть)

9
Ответить

Если дойдут руки до статьи, то постараюсь русские аналоги подобрать. Эти английские термины постоянно использую, поэтому уже не замечаю и забываю, что не всем они понятны.

2
Ответить

3000 за статью..
Совсем с ума сошёл.

7
Ответить