Антикранч: советы и практики
Хоть названии доклада фигурируют кранчи, но разговор больше про управление командой. Вещи хоть и очевидные, но многие про них всё равно забывают. Основные моменты выписал.
- Эстимейты — это не комитмент.
- Жёстко заданные тайминги выполнения задач не работают. Всё быстро сдвигается, приходится постоянно модифицировать план + стресс у команды, т.к. ощущение, что постоянно не успевают.
- Bell Curve очень хорошо иллюстрирует то, чего ожидать. Если эстимейт был на 3 дня, то выполнить за 5 дней ок. А вот на 10 день уже стоит переосмыслить задачу — вероятно она оказалось слишком сложной. Возможно стоит её вообще отменить или в беклог положить.
- Cone of uncertainty.
- Не нужно засорять беклог мелкими вещами, особенно если доберётесь до них через много месяцев. Достаточно сгруппировать это и/или оформить в виде эпика. А возможно и вовсе выкинуть.
- Не правьте числа/эстимейты после выполнения задачи.
- Если команда делает 10 сторипоинтов за недельный спринт, а осталось 100, это не значит, что вы выполните их за 10 недель, т.к. не учитываете задачи, которые появляются по ходу дела.
По поводу методики разработки:
- Перфомят не команды, состоящие чисто из профи, а из людей, которые дополняют сильные и слабые стороны друг друга.
- Если вы добавляете людей в проект, то команда замедлится (порой на месяц-два, пока онбординг идёт и всё такое). Я рекомендую всем почитать у Брукса «Мифический человеко-месяц».
- Bus factor (да-да). Не должно быть такого, что критические вещи зависят только от одного человека. В таком случае у вас просто будет группа индивидуалов, а не команда.
- Парное программирование, код ревью и шаринг знаний внутри команды.
- QA должны быть включены в пайплайн, в дизайн ревью, в обсуждения.
- TDD хорошая практика.
- Continuous integration — это не просто использование Дженкинса или Тимсити, они лишь технологии/средства. На почитать: trunk based development, feature toggle.
И напоследок:
- Не нужно запарываться над идеальным решением.
- Качество vs скорость. Не нужно пытаться продумать всё заранее.
- Нужно давать командам побольше свободы и меньше бюрократии (кэп).
Небольшой эксперимент. Интересно ли вам про такие вещи читать? Если да, то готовы вложиться в статью по видео? Не знаю, работает ли такое, но решил попробовать собрать на статью денег через Бусти, чтобы посмотреть, насколько люди готовы закоммититься.
Не кранчите, пацаны, вы еще матерям нужны
Эстимейты — это не комитмент.Споткнулся уже на втором абзаце. Для меня пожалуй рекорд
Переизбыток ненужных англицизмов. А если вместо Bell Curve написать Нормальное распределение, то жопа отвалится?
Это небольшая заметка в блоге на скорую руку, написанная по ходу просмотра видео. Не нужно быть настолько критичным 😅
Увидел заголовок, думаю - збс, ведь все эти методы можно применять не только в ИТ, а вообще в жизни или у себя на работе, чтобы все было "быстро, четко, по полочкам".
Но прочитав понял, что без разговорника русско-айтишного вообще не стоит соваться. Обидно жи есть)
Если дойдут руки до статьи, то постараюсь русские аналоги подобрать. Эти английские термины постоянно использую, поэтому уже не замечаю и забываю, что не всем они понятны.
3000 за статью..
Совсем с ума сошёл.