Из известного мультфильма:
— я хочу измерить свой рост!
— два слоненка
— пять мартышек
— 38 попугаев и одно попугайское крылышко
Иногда прям хочется угодить менеджерам, высказав более-менее точные эстимейты. Сделать это бывает приятно — типа, братух, все под контролем, мы сделаем — правда после этого приходится сжать покрепче и педалить, педалить, педалить.
Что ж, чтоб не горело, там где сидело, предлагаю разработать некую систему оценок
Дано:
1) многие менеджеры не любят диапазоны в оценках
2) [ходят слухи] на задачу тратится все отведенное время
3) слишком много вариантов для оценки (1 час, 2 часа, 3, 4, 5,… n)
4) роль тимлида не учтена
Один известный дизайнер* как-то ввел термин «единица смысла», уточнив при этом: "… а именно, выписать их на листочек… Листочек в редких случаях окажется заполненным до середины, даже если писать крупным почерком." Ecли предположить, что середина листочка — это приблизительно десять пунктов, путем нехитрых вычислений постановим (почему, собственно, и не постановить :): любая задача — это два дня. Точка.
На любую задачу менеджера смело называйте оценку в два дня — если задача большая, всегда можно показать, что уже сделано (за два дня), если небольшая — дописать тесты, написать документацию, почистить код. Тут идея в том, что за два дня нужно обязательно сделать что-то законченное, что-то самостоятельное (какой бы смысл вы ни вкладывали в это слово). За два дня можно делать таски, которые, как сказал один известный румын** на одной известной однобуквенной conf [перевод мой]: «хочется видеть пул-реквесты, которые огонь, которые прям хочется вмержить». Двухдневные таски хороший инструмент. Но что делать, если хочется запланировать 153.75 часов, а писать слишком длинный список лень? Все верно — та-дам, создать большую задачу.
Большая задача это задача, которая терпима к ошибке (к одной большОй ошибке или к нескольким маленьким ошибочкам :) То есть мы делаем таску, поняли, что ошиблись, откатились к нулевому дню, делаем таску заново. Итого, просуммировав: два дня + ошибка + два дня = равно четыре дня. Большая задача это четыре дня. (Другими словами, на большую таску можно смотреть как на таску с большим кол-вом неизвестных при старте). Все это прекрасно, скажете вы, но что делать, если хочется пофиксить багу сегодня, сейчас (ну, то есть, вчера)? Та-ДАм — маленькая задача.
Берем рабочий день разработчика, это где-то 8 (7,6,5...) часов и делим на кол-во задач, которые стандартный (он же средний) разработчик может сделать (тут важно не забыть время на все pr change requests). Путем медитации и калькулятора получаем 3 часа, менеджеру говорим 4 часа, так как это полдня работы. Итого, маленькая задача это 4 часа.
Мне кажется, роль тимлида как-то потеряна, как-то тупо не учитывается при эстимейтах (банально, вы скажете — ну в принципе да :) Менеджерам мы сообщаем оценки в терминах трех задач, но тимлиду говорим, что мальнькая задача это 0-4 часов, задача (она же таска) это 0.5-2 дня, большая задача 2-4 дня. И тут открывается дзен тимлида, капитана судна, главного-преглавного. Если разработчик постоянно выполняет таски по верхней границе эстимейта — командный дух похерен.
… Что же делать? Да *** его знает, наверно, смотреть «Что? Где? Когда?» и учиться-учиться-учиться.
* www.artlebedev.ru/kovodstvo/sections/148
** Andrei Alexandrescu, DConf
— я хочу измерить свой рост!
— два слоненка
— пять мартышек
— 38 попугаев и одно попугайское крылышко
Иногда прям хочется угодить менеджерам, высказав более-менее точные эстимейты. Сделать это бывает приятно — типа, братух, все под контролем, мы сделаем — правда после этого приходится сжать покрепче и педалить, педалить, педалить.
Что ж, чтоб не горело, там где сидело, предлагаю разработать некую систему оценок
Дано:
1) многие менеджеры не любят диапазоны в оценках
2) [ходят слухи] на задачу тратится все отведенное время
3) слишком много вариантов для оценки (1 час, 2 часа, 3, 4, 5,… n)
4) роль тимлида не учтена
Один известный дизайнер* как-то ввел термин «единица смысла», уточнив при этом: "… а именно, выписать их на листочек… Листочек в редких случаях окажется заполненным до середины, даже если писать крупным почерком." Ecли предположить, что середина листочка — это приблизительно десять пунктов, путем нехитрых вычислений постановим (почему, собственно, и не постановить :): любая задача — это два дня. Точка.
На любую задачу менеджера смело называйте оценку в два дня — если задача большая, всегда можно показать, что уже сделано (за два дня), если небольшая — дописать тесты, написать документацию, почистить код. Тут идея в том, что за два дня нужно обязательно сделать что-то законченное, что-то самостоятельное (какой бы смысл вы ни вкладывали в это слово). За два дня можно делать таски, которые, как сказал один известный румын** на одной известной однобуквенной conf [перевод мой]: «хочется видеть пул-реквесты, которые огонь, которые прям хочется вмержить». Двухдневные таски хороший инструмент. Но что делать, если хочется запланировать 153.75 часов, а писать слишком длинный список лень? Все верно — та-дам, создать большую задачу.
Большая задача это задача, которая терпима к ошибке (к одной большОй ошибке или к нескольким маленьким ошибочкам :) То есть мы делаем таску, поняли, что ошиблись, откатились к нулевому дню, делаем таску заново. Итого, просуммировав: два дня + ошибка + два дня = равно четыре дня. Большая задача это четыре дня. (Другими словами, на большую таску можно смотреть как на таску с большим кол-вом неизвестных при старте). Все это прекрасно, скажете вы, но что делать, если хочется пофиксить багу сегодня, сейчас (ну, то есть, вчера)? Та-ДАм — маленькая задача.
Берем рабочий день разработчика, это где-то 8 (7,6,5...) часов и делим на кол-во задач, которые стандартный (он же средний) разработчик может сделать (тут важно не забыть время на все pr change requests). Путем медитации и калькулятора получаем 3 часа, менеджеру говорим 4 часа, так как это полдня работы. Итого, маленькая задача это 4 часа.
Мне кажется, роль тимлида как-то потеряна, как-то тупо не учитывается при эстимейтах (банально, вы скажете — ну в принципе да :) Менеджерам мы сообщаем оценки в терминах трех задач, но тимлиду говорим, что мальнькая задача это 0-4 часов, задача (она же таска) это 0.5-2 дня, большая задача 2-4 дня. И тут открывается дзен тимлида, капитана судна, главного-преглавного. Если разработчик постоянно выполняет таски по верхней границе эстимейта — командный дух похерен.
… Что же делать? Да *** его знает, наверно, смотреть «Что? Где? Когда?» и учиться-учиться-учиться.
* www.artlebedev.ru/kovodstvo/sections/148
** Andrei Alexandrescu, DConf
YChebotaev
Проблема в том, что разработчики дают противоположные по смыслу обещания, которые они не способны выполнить одновременно:
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» > «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» > «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
xyli0o Автор
> но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
хм… интересно :)
А какие есть варианты? Типа, разработчик говорит, что ему хочется заюзать либу и затем пополнить резюме или задача скучная и ее он будет делать осенью
YChebotaev
Да, так и нужно сказать, если так планируете.