Size: a a a

2020 November 03

VD

Valentin Denisenkov in ctodailychat
ну чтобы конкретнее — например, задачи такого уровня

есть существующий компонент, нужно добавить в него новую логику и немного расширить существующую фукнциональность
источник

VD

Valentin Denisenkov in ctodailychat
Onlinehead
Ощутимое или долгосрочное? У меня вот сейчас идет интерсный процесс в команде за понижение влияния эстимейтов и вообще некоторому уходу от этого процесса строго декомпозиции и сабмита сроков. Как показала практика, в процессе развития проекта фичи в установленное время пилить конечно можно, но скрытый техдолг накапливается такими темпами, что за несколько лет можно придти к состоянию "надо все нахуй выкидывать", а переделка будет дороже на порядок. Поэтому мы стараемся все таки фокусироваться на качестве, а не на эстимейтах.
такой подход звучит тоже неплохо, а качество как оцениваете?
источник

VD

Valentin Denisenkov in ctodailychat
я стараюсь в свои оценки всегда закладывать еще работу над техдолгом в тех частях проекта, где будут работы по фиче
источник

O

Onlinehead in ctodailychat
Valentin Denisenkov
такой подход звучит тоже неплохо, а качество как оцениваете?
у нас есть некоторое понимание и вектор развития, в рамках которого все и оценивается. экспертный подход, ничего другого пока не придумали, чтобы "качество" мерить. Ну мы, по крайней мере.
источник

O

Onlinehead in ctodailychat
Можно попробовать объективные метрики притащить, но боюсь работать они будут не сильно лучше, по крайней мере на данном этапе.
источник

IV

Igor V in ctodailychat
Valentin Denisenkov
Привет всем!

Зарубился со своим СТО про подходы разработчиков к работе над фичами

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

Я топлю за то, что декомпозиция и оценка задач — это просто скилл и он прокачивается, дело не в складе ума, а в мотивации развивать скилл.

Интересно узнать мнение чата — реально ли есть такие два "склада ума" у разработчиков?
имхо первые это сеньеры, а вторые это миддлы
источник

O

Onlinehead in ctodailychat
Onlinehead
Ощутимое или долгосрочное? У меня вот сейчас идет интерсный процесс в команде за понижение влияния эстимейтов и вообще некоторому уходу от этого процесса строго декомпозиции и сабмита сроков. Как показала практика, в процессе развития проекта фичи в установленное время пилить конечно можно, но скрытый техдолг накапливается такими темпами, что за несколько лет можно придти к состоянию "надо все нахуй выкидывать", а переделка будет дороже на порядок. Поэтому мы стараемся все таки фокусироваться на качестве, а не на эстимейтах.
Да, тут есть важный момент - можно закладывать время как "запилить фичу качественно", но по некоторым внешним во многом причина этот эстимейт тоже бывает часто продолбан.
Короче, предсказуемость это хорошо, но сжигать людей в погоне за циферками - хреновая затея.
источник

O

Onlinehead in ctodailychat
Igor V
имхо первые это сеньеры, а вторые это миддлы
Игорь, а почему ты считаешь что мидлы не могут в декомпозицию или эстимейты? Я могу еще в джунов поверить просто по причине отсутствия у них накомпленного опыта, но мидл то более-менее вкурсе обычно что надо.
источник

VD

Valentin Denisenkov in ctodailychat
Onlinehead
Да, тут есть важный момент - можно закладывать время как "запилить фичу качественно", но по некоторым внешним во многом причина этот эстимейт тоже бывает часто продолбан.
Короче, предсказуемость это хорошо, но сжигать людей в погоне за циферками - хреновая затея.
до сжигания людей за циферки нам очень далеко, нам бы понять, что мы успеваем делать за спринт, а что нет
источник

VD

Valentin Denisenkov in ctodailychat
Igor V
имхо первые это сеньеры, а вторые это миддлы
+++
источник

O

Onlinehead in ctodailychat
Onlinehead
Игорь, а почему ты считаешь что мидлы не могут в декомпозицию или эстимейты? Я могу еще в джунов поверить просто по причине отсутствия у них накомпленного опыта, но мидл то более-менее вкурсе обычно что надо.
Я скорее поверю что у них производительность разная, мидлам может быть не комфортно давать оценку и т.д, но вот чтобы эти да, а эти - нет, как то не похоже.
источник

O

Onlinehead in ctodailychat
Valentin Denisenkov
до сжигания людей за циферки нам очень далеко, нам бы понять, что мы успеваем делать за спринт, а что нет
Нравятся мне все эти упражнения про "давайте попробуем предсказать плохо предсказуемое и посмотрим что из этого выйдет":)
Кстати, тоже вопрос чатику - у вас вообще получалось давать нормальные эстимейты в уникальной работе и без перегибов и подгонок? Ну не то, чтобы там круды и формошлепство, а реально делать какие-то новые вещи более-менее предсказуемо в установленное время, не растягивая его овертаймами, хаками с метриками и вот этим всем, что рисует цифру, но скрывает суть.
источник

IV

Igor V in ctodailychat
Onlinehead
Игорь, а почему ты считаешь что мидлы не могут в декомпозицию или эстимейты? Я могу еще в джунов поверить просто по причине отсутствия у них накомпленного опыта, но мидл то более-менее вкурсе обычно что надо.
Важно договориться как мы делим на senior/middle/junior. Для меня это не технические знания, а умение работать автономно. Джуну нужно сказать что делать и постоянно проверять, миддлу сказать и периодически проверять, а сеньор сам скажет что ему нужно. В моем мире, миддлы которые начинают понимать декомпизицию и эстимейты очень быстро переходят в сеньоров. Такие ребята могут отделять зерна от плевел
источник

O

Onlinehead in ctodailychat
Igor V
Важно договориться как мы делим на senior/middle/junior. Для меня это не технические знания, а умение работать автономно. Джуну нужно сказать что делать и постоянно проверять, миддлу сказать и периодически проверять, а сеньор сам скажет что ему нужно. В моем мире, миддлы которые начинают понимать декомпизицию и эстимейты очень быстро переходят в сеньоров. Такие ребята могут отделять зерна от плевел
Спасибо, так понятнее.
источник

VD

Valentin Denisenkov in ctodailychat
Onlinehead
Нравятся мне все эти упражнения про "давайте попробуем предсказать плохо предсказуемое и посмотрим что из этого выйдет":)
Кстати, тоже вопрос чатику - у вас вообще получалось давать нормальные эстимейты в уникальной работе и без перегибов и подгонок? Ну не то, чтобы там круды и формошлепство, а реально делать какие-то новые вещи более-менее предсказуемо в установленное время, не растягивая его овертаймами, хаками с метриками и вот этим всем, что рисует цифру, но скрывает суть.
а нормальные эстимейты — это как определить? какое отклонение от плана в пределах "нормы"?
источник

IV

Igor V in ctodailychat
Onlinehead
Нравятся мне все эти упражнения про "давайте попробуем предсказать плохо предсказуемое и посмотрим что из этого выйдет":)
Кстати, тоже вопрос чатику - у вас вообще получалось давать нормальные эстимейты в уникальной работе и без перегибов и подгонок? Ну не то, чтобы там круды и формошлепство, а реально делать какие-то новые вещи более-менее предсказуемо в установленное время, не растягивая его овертаймами, хаками с метриками и вот этим всем, что рисует цифру, но скрывает суть.
Я как-то здесь рассказывал как у меня «машина» сама считает estimation. Идея в том, что разработчики не дают не estimation, а заполняют feature table, которая меняется от проекта к проекту. Например, для каждой задачи разработчики указывают complexity, нужно ли интеграция, есть ли в задаче ui, нужно ли менять платформенные компоненты, но так же они дают риски и assumptions. Берите за правило никогда не принимать оценки задач без assumptions
источник

VD

Valentin Denisenkov in ctodailychat
не очень понял, что имеется в виду под assumptions в данном контексте, можешь пояснить?
источник

IV

Igor V in ctodailychat
источник

O

Onlinehead in ctodailychat
О, я помню это обсуждение:) Да, это классная схема. Она как раз учитывает всякие "известные неизвестные".
источник

VD

Valentin Denisenkov in ctodailychat
спасибо! крутая система! в явном виде учитывать такие вещи как requirements completeness — это отличная идея
источник