Estimations: Ideal Days vs Story Points
Yuriy Mann
Хочу поднять избитую тему про оценку продакт бэклог айтемов.
Вся классическая теория на эту тему давно была перечитана, прослушана
и обсуждена. Аргументы изучены. В результате - мы с большим
энтузиазмом внедрили у себя "правильные" стори поинты (мы их называем
complexity, или complexity points, так сложилось исторически).
Пользуемся этой системой больше двух лет, 35 спринтов. Естественно,
постоянно что-то донастраиваем и улучшаем, но базовый механизм оценки
и подсчета velocity не меняется.
Velocity, что характерно, получается довольно консистентной и по ней
даже получается строить грубый релиз план.
На этом радужном фоне, меня не покидает ощущение ущербности системы и
нераскрытых потенциалов. Долго пытался сформулировать, что же не
нравится.
Пока вижу две явные проблемы:
1. Оценки, которые ставят ребята, явно непропорциональны. Они, скорее,
отражают некую логарифмическую зависимость: задача в 3 поинта зачастую
оказывается раза в 3-5 сложнее, чем задача в 2 поинта.
2. Команде сложно сравнивать сложность задач, покрывающих разные
технологии. Особенно заметны проблемы с разницей в оценке веб-задач и
бэк-энда (веб часто оказывается намного сложнее, чем оценили). Думали,
такое умение придет со временем, но что-то не очень приходит.
Мы видим следующие пути улучшения процесса:
а. Построить четкий процесс подготовки и обновления эталонных бэклог
айтемов.
Пробовали. Забываем и ленимся обновлять эталоны, а по старым качество
оценки не ахти. Самое сложное - опять же в покрытии разных технологий.
В идеале спецефические эталоны нужны для любой области работ
(исследование, документация, разработка-веб, разработка-networking
etc.).
б. Оценивать в Идеальных Днях.
Собственно, это я и хотел обсудить. Кстати, именно такой способ
рекомендует глубокоуважаемый мной Хенрик Книберг. Несмотря на то, что
аннотацию к книге написал Майк Кон, главный идеолог оценок, не
привязанных ко времени.
Итак, вопрос: к какому подходу вы сами склоняетесь: ideal days или
story points? Есть ли у вас аргументы, основанные на собственных
успехах или неудачах?
Artjom Serdyuk
Леши и Наташа.
Мы пользуемся человеко-днями для оценки бюджета (денег) и стори
поинтами для планирования релиза. Для планирования спринта мы
пользуемся gut feel.
Общая идея за этим такая:
1) оценки - это мусор, они не добавляют конечному продукту ценности.
2) оценок требуют от нас бизнес стейкхолдеры, и они их получат с каким-
то оговоренным занарее уровнем погрешности.
3) так как оценки это мусор, мы стараемся тратить на них как можно
меньше времени.
Итого - если уровень точности наших оценок и прогнозов на их основе
всех устраивает (а он устраивает), то мы не заморачиваемся, как
оценивать истории ещё точноее (ибо зачем?).
З.Ы. В идеальных днях есть идеальные МЕГА-грабли, на которые я устал
наступать (поэтом мы и пользуемся стори поинтами). Когда вы оценили
проект\спринт в днях, менеджер тут же делит их на количество
сотрудниоков-FTE в вашей команде. И видит ОГРОМНЫЙ потенциал для
увеличения производительности команды! И сроки почти в двое можно
урезать! Объяснить менеджеру, что такое фокус-фактор, почему он
0.5-0.7, и что идеальные дни напрямую НЕ СВЯЗАНЫ с дедлайном проекта,
ой как тяжело. Поэтому мы пользуемся Стори Поинтами и велосити
команды.
Anton Naumov
> отражают некую логарифмическую зависимость: задача в 3 поинта зачастую
> оказывается раза в 3-5 сложнее, чем задача в 2 поинта.
> 2. Команде сложно сравнивать сложность задач, покрывающих разные
> технологии. Особенно заметны проблемы с разницей в оценке веб-задач и
> бэк-энда (веб часто оказывается намного сложнее, чем оценили). Думали,
> такое умение придет со временем, но что-то не очень приходит.
А Вы не пробовали ввести коэфициент рисков для каждой из технологий?
Иначе говоря, если веб-задачи оказываются недоэстимэйчиными в 3-5 раз,
то можно попробовать ввести сюда коэфициент данного риска 4 и заложить
эту поправку в конечную оценку. И точно такие же оценки ввести для
остальных технологий. Сделать это частью планирования времени. Пусть
для задач, которые оцениваются корректно, коэфициент рисковости будет
равен 1. Ну или что-то в этом роде.
Это конечно совсем не выбор между ideal days и story points, но мне в
свое время реально помогло уменьшить отрыв планов от реального
положения дел :)
Pavel Kaplin
лишней нагрузки по поддержанию/созданию оценов в стори поинтах.
Менеджер проекта прекрасно знает о фокус-факторе и т.п. Заказчика в
детели планирования не посвящаем, показываем наши оценки, говорим что
они - в поинтах, и мы способны делать столько-то поинтов за 3 недели
итерации. И все.
Serge Levin
С уважением,
Сергей
2009/7/9 Anton Naumov <grays...@gmail.com>:
Alimenkou Nikolay
идеальному дню". Почему так? Потому что не у всех мозг способен
абстрагировать задачу и поставить ей маркер S, M, L, XL и так далее.
Многие прикидывают свою работу реальную и вспоминают опыт предыдущих
задач.
Я согласен что оценки - это waste, но не совсем. На оценках учатся. А
именно: мы можем анализировать когда мы не вложились в оценки и играть
рисками, мы узнаем где мы слабее и подтягиваем эти области, мы
понимаем что именно пошло не так.
А еще оценки мы используем ТОЛЬКО для лимитирования спринт бэклога.
Больше ни для чего. Потому что оценки со временем склонны меняться,
потому что задачи людям становится делать проще. Постоянно следить за
стандартами и пытаться вывести формулы - пустая трата времени. Лучше
предсказывать погоду... :)
On Jul 9, 1:21 pm, Yuriy Mann <yurym...@gmail.com> wrote:
Yuriy Mann
> абстрагировать задачу и поставить ей маркер S, M, L, XL и так далее.
> Многие прикидывают свою работу реальную и вспоминают опыт предыдущих
> задач.
Именно к такому выводу мы и пришли, обсуждая этот вопрос в команде.
Приятно, что он подтверждается и опытом Николая :)
> А еще оценки мы используем ТОЛЬКО для лимитирования спринт бэклога.
Тут уж я готов поспорить. По нашему опыту, даже при всем
несовершенстве наших "идеальных стори поинтов", спрогнозировать объем
работ на 3-4 спринта вперед очень даже реально. Естественно, со всеми
необоходимыми буферами и поправками. Можно и больше, чем на 3-4, но
тут уже с учетом известного правила об ухудшении точности оценок по
мере их удаления во времени. Я все же надеюсь улучшить точность таких
прогнозов, используя идеальные дни.
Сегодня родилась такая идея: попробуем выбрать 10-15 разноплановых и
разновеликих задач, стереть старые оценки (запомнив их отдельно), и
переоценить в идеальных днях. Получаем сразу два результата:
1. Проверим теорию о недостатках наших текущих оценок
(непропорциональность и несоответствие между разными видами работ).
2. В случае, если решим переходить на человеко-дни - у меня будет
готовая база для автоматического пересчет оцененных ранее айтемов по
новой системе. Естественно, метод будет грубым, но переоценивать их
все "вручную" было бы неоправданной тратой ресурсов.
Artjom Serdyuk
Alimenkou Nikolay
Надо убить таракана в голове. Вам ЭТО не нужно. Или же вы еще не
поняли что вам ЭТО не нужно. :)
Yuriy Mann
Ну, если все работает хорошо, надо же ответственному за процессы
оправдывать чем-то свою зарплату ;)
А если серьезно, то тут я руководствуюсь, скорее, профессиональной
интуицией - а она меня редко до сих пор подводила.
И если еще серьезнее, то, напрягшись и проанализировав интуицию, могу
навскидку сформулировать такие объяснения:
1. Мне кажется, что текущая мутность оценок и самого подхода к оценке
подрывает веру девелоперов в процесс. В связи с проблемами изложенными
в начале темы. Скорее, они заменяют ее верой в меня как опытного
чувака, к тому же с властными полномочиями. Ок, это больше догадки,
т.к. сами они не признаются и оценки делают довольно шустро. С другой
стороны, когда я касаюсь поднятой здесь темы, они охотно участвуют и
выражают интерес в том, чтобы попробовать вариант с идеальными днями.
2. Я тешусь надеждой, что наши датские коллеги когда-нибудь возьмутся
за голову, и тоже заработают по скраму. В этом случае, по-моему,
синхронизация наших и "их" стори поинтов будет серьезной проблемой.
Идеальные дни будет гораздо проще "транслировать" между двумя разными
командами в разных офисах.
3. В конце концов, почему бы не попробовать альтернативный подход? Мы,
например, прекрасно работали по вотерфолу до скрама. Однако же,
никогда не жалели, что внедрили скрам. Рациональные преимущества и
общее возросшее удовольствие от процесса - налицо. Не понравится -
откатимся назад к абстрактным стори поинтам.
Здесь же я хотел узнать, по крайней мере, многие ли работают с
идеальными днями, и какие у вас с этим проблемы. Пока что мои догадки
подтверждаются :) В любом случае, всем спасибо огромное за участие!
vova.oros
On 9 июл, 23:37, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> +1
>
> Надо убить таракана в голове. Вам ЭТО не нужно. Или же вы еще не
> поняли что вам ЭТО не нужно. :)
>
Николай, это заявление достаточно дерзкое. Не надо думать так плохо о
других людях.
Расскажите лучше как-же вы планируете релизы в своей команде, если
оценки используются "ТОЛЬКО для лимитирования спринт бэклога".
У вас были релизы на 3-6 месяцев? А fixed price проекты? Пробовали с
заказчиком утвердить план и бюджет проекта или релиза? Поделитесь
опытом, как вы обходились без оценок.
Artjom Serdyuk
Уточняю.
Почему столько внимания оценкам? Ваша главная задача сейчас - сделать
так, чтобы девелоперы идеально оценивали свою работу? Правильно ли я
понял?
Оценки ли являются вашим узким местом, которое сдерживает рост
команды? Не лучше ли будет потратить время на то, чтобы научиться чему-
нибудь интересному в плане разработки?
Что, с Вашей точки зрения, существенно улучшится, когда вы сможете
делать более точные оценки задач? Увеличит ли это прибыль от проекта?
Улучшит ли отношения с заказчиком? Добавит ли удовольствия в процесс
разработки? Насколько увеличатся шансы на общий успех проекта?
Т.е. мне интересно - а где тут польза кроме удовольствия от
эксперимента ;))
vova.oros
Хороший естимейт нужен для того, чтобы:
а) получить проект. Для этого нужно, чтобы ваше предложение хорошо
смотрелось на фоне конкурентов. Чем меньше оценка по времени-деньгам,
тем лучше.
б) суметь выполнить свои общания. Для этого надо перестраховываться, и
чем больше запаса вы заложите в оценку, тем лучше.
Тоесть нужно найти баланс между противоречивыми требованиями бизнеса и
исполнителей. Если сильно демпинговать и оптимистично оценивать, то
есть риск сидеть по ночам и по выходным, доделывая обещанное. А если
сильно уж перестраховываться, то не только новых клиентов не будет, но
и старые могут уйти. Примеров хватает (и переработки, и ухода
клиентов). Поэтому постоянно искать пути улучшения точности естимейтов
- это то, чем менеджеру приходится жить (ну, не только этим, конечно).
Теперь по теме.
Последние лет восемь пользуюсь оценкой в днях (ну, или в часах, для
небольших проектов). Особых проблем с этим небыло ни на одном проекте.
Напротив, это гораздо естественней, чем вводить дополнительный уровень
абстракции - стори-поинт - только время тратится на обьяснения команде
и заказчику (обязательно находится кто-то, кому не понятно). Ну и
зачем тогда морочить голову? Только под словом день надо понимать
реальный рабочий день, а не идеальный. И не ожидать хардкорного
колбасива по восемь часов от каждого члена команды.
Есть нюанс с маленькими задачами (по пол-дня). Если их много в плане,
то обычно реально все они будут выполнены быстрее. В такие задачи
удобно прятать "подушку безопасности" - тоесть вместо того, чтобы
обьединить всякую мелочь, пишем всё раздельно, с оценками по пол-дня.
Alimenkou Nikolay
тратить ни минуты на митинги и прочие растраты. Ведь в таком случае их
день очень сильно сократится. И явно они не успеют то, что
намеревались сделать в "свободный" день. Но в очередной раз повторюсь:
ЕСЛИ У ВАС ЭТО РАБОТАЕТ - ЭТО КЛАССНО.
Alimenkou Nikolay
участвовать потому что я бы предпочел аджайл контракт, я вынужден. Для
того чтобы оценить релиз или проект целиком собирается команда (а
возможно просто набор экспертов) и дают свои оценки. При этом лучше
всего играть в планнинг покер чтобы убрать субъективизм. Но велосити
такая хрупкая вещь, что не стоит им спекулировать. К примеру: уровни
всех разработчиков отличаются в корне, а велосити считается для всей
команды. В итоге если сильный член команды уходит или же временно
недоступен, то велосити команды в целом падает и планы рушатся как
карточный домик.
Anton Naumov
здорово и пусть он работает дальше. Лучшее, как известно, враг
хорошего.
Но если Вам интересно, то ниже мои комментарии.
> Можно и я отвечу, поскольку тема достаточно интересная.
> Хороший естимейт нужен для того, чтобы:
> а) получить проект. Для этого нужно, чтобы ваше предложение хорошо
> смотрелось на фоне конкурентов. Чем меньше оценка по времени-деньгам,
> тем лучше.
По-моему это не совсем техническая задача, нет? Когда джуниор
девелопер, в ответ на вопрос "Почему ты оценил эту задачу в два дня,
когда тебе на нее нужно минимум полторы недели?" отвечает "Ну как же,
если я буду называть такие длинные сроки, у нас уйдет клиент", для
меня это означает только одно -- в конторе сейлз не работает,
управление проектами не работает, управление командой не работает.
Разработчика должно беспокоить качество кода и количество функционала.
Лидера команды -- максимально точное соотвествие оценок и результата.
Остальное дело сейлз и/или менеджера проекта. Это их головная боль,
как ОБЪЯСНИТЬ клиенту, что на выполнение этого количества работы
потрбеуется вот это количество времени.
> б) суметь выполнить свои общания. Для этого надо перестраховываться, и
> чем больше запаса вы заложите в оценку, тем лучше.
Нет, для этого нужно максимально учесть риски проекта.
Перестраховываться не нужно, это ведет к неоправданому раздуванию
бюджета.
> Тоесть нужно найти баланс между противоречивыми требованиями бизнеса и
> исполнителей. Если сильно демпинговать и оптимистично оценивать, то
> есть риск сидеть по ночам и по выходным, доделывая обещанное. А если
> сильно уж перестраховываться, то не только новых клиентов не будет, но
> и старые могут уйти. Примеров хватает (и переработки, и ухода
> клиентов). Поэтому постоянно искать пути улучшения точности естимейтов
> - это то, чем менеджеру приходится жить (ну, не только этим, конечно).
Как я уже сказал выше, проблема не только в эстимэйтах. Более того,
любой сырой эстимэйт полученный от команды можно и должно привести в
соотвествие с реальностью, используя различные коэфициенты рисков,
собранные за предыдущие периоды. И даже окончательную стоимость
проекта можно варировать, используя похожие коэфициенты. Это то, что
является работой менеджера -- сбор статистики и учет всех нужных
коэфициентов.
Эстимэйт команды != длительность проекта в человеко-часах.
Длительность проекта * N долларов != конечная стоимость проекта.
Зависимости не линейны, об этом очень часто забывают.
> Последние лет восемь пользуюсь оценкой в днях (ну, или в часах, для
> небольших проектов). Особых проблем с этим небыло ни на одном проекте.
> Напротив, это гораздо естественней, чем вводить дополнительный уровень
> абстракции - стори-поинт - только время тратится на обьяснения команде
> и заказчику (обязательно находится кто-то, кому не понятно).
Для команды это те самые попугаии, которые позволят сосредоточится на
технической сложности задания. Без совершенно не нужных разработчикам
факторов времени и стоимости. А уж как стори-пойнты будут
коррелировать с оценкой задачи в днях и долларах, это уже совершенно
не технический вопрос.
А заказчику совершенно не нужно знать, как у вас устроен процесс
изнутри. Важно, чтобы команда работала и давала стране металл. Все.
Это все, что его по сути касается. И этот момент мнеджер должен
отстаивать всеми возможными ему средствами.
Sergiy Movchan
Когда джуниор девелопер, в ответ на вопрос "Почему ты оценил эту задачу в два дня,когда тебе на нее нужно минимум полторы недели?" отвечает "Ну как же,если я буду называть такие длинные сроки, у нас уйдет клиент", для меня это означает только одно -- в конторе сейлз не работает,
Важно, чтобы команда работала и давала стране металл.
по странной случайности вчера общался с представителем менеджмента Криворожстали... так вот он рассказывает, что после покупки их Митталом, там был упразднён отдел маркетинга (т.к. индус сам умеет продавать). И производство счастливо просто гоня объём. Команда работает и даёт металл, и голова у неё не болит, как продать. А продаёт тот, кто умеет.
--
...dali bude...
Sergiy Movchan
--
...dali bude...
vova.oros
On 11 Лип, 01:19, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:
> Могу только посочуствовать вашим разработчикам. Наверняка они не хотят
> тратить ни минуты на митинги и прочие растраты. Ведь в таком случае их
> день очень сильно сократится. И явно они не успеют то, что
> намеревались сделать в "свободный" день. Но в очередной раз повторюсь:
> ЕСЛИ У ВАС ЭТО РАБОТАЕТ - ЭТО КЛАССНО.
Я же писал о нахождении баланса, а не о том, что нужно шманать команду
до потери пульса.
В качестве иллюстрации - когда я писал свой предыдущий пост, моя
команда вызвала на турнир по настольному футболу соседнюю команду,
и минут за 40, уделала их со счётом 3:2 по серии матчей. В рабочее
время.
Так что жалеть их, наверное, не стоит. По крайней мере в контексте
перегрузки на работе.
vova.oros
On 12 Лип, 11:21, Anton Naumov <grayswan...@gmail.com> wrote:
> По-моему это не совсем техническая задача, нет?
Да никто и не утверждает, что мы тут сугубо технические вопросы
обсуждаем...
А умножение естимейта команды на некоторый поправочный коеффициент -
это и есть то, что я называю перестраховкой - вполне обоснованное
действие, базирующееся на предыдущем опыте. От команды к команде это
число варьируется - было и 1.1 и 2.0. Но чем точнее оценка команды,
тем больше у вас свободы и уверенности на переговорах с клиентом.
Поэтому, если нужен естимейт нового релиза или нового продукта -
учавствуют только Seniors. Если планируется следующая итерация -
только тогда джуниоры принимают участие в коммитменте и дают свои
оценки.
Anton Naumov
> это и есть то, что я называю перестраховкой - вполне обоснованное
> действие, базирующееся на предыдущем опыте. От команды к команде это
> число варьируется - было и 1.1 и 2.0. Но чем точнее оценка команды,
> тем больше у вас свободы и уверенности на переговорах с клиентом.
Я называю эту учетом рисков. Перестраховка, в моем понимании, это
сознательное увеличение эстимэйта на случай падения меторита, в
отдельно взятом районе города. Иначе говоря, переоценка там, где она
не нужна с вероятностью 85-90%.
> Поэтому, если нужен естимейт нового релиза или нового продукта -
> учавствуют только Seniors. Если планируется следующая итерация -
> только тогда джуниоры принимают участие в коммитменте и дают свои
> оценки.
Оценку задачи дает тот человек, который по плану будет эту задачу
выполнять. Всегда. По поводу изменения оценки может быть организована
дискуссия, задача может быть отдана другому исполнительнитю. Оценка
задачи сверху спускается только в том случае, если с исполнителя
снимается всяческая отвественность за результат. Другими словами я сам
никогда не беру отвестности за чужие эстимэйты и другим не советую.
Anton Naumov
> учавствуют только Seniors. Если планируется следующая итерация -
> только тогда джуниоры принимают участие в коммитменте и дают свои
> оценки.
Кстати, в случае эстимэйта нового релиза Вы получаете не
средневзвешенный эстимэйт, а идеальный. Риски срыва графика возрастают
тем больше, чем больше сеньйоров НЕ будут участовать в разработке
релиза. На эти риски тоже можно заложиться, только я не вижу в этом
смысла, когда можно получить средневзвешенный эстимэйт уже на этапе
оценки. И коэфициентов будет меньше и вероятность ошибки уменьшиться.
Все-таки риск-менеджмент это прогнозирование будущего, где
максимальная вероятность 50-70%.
vova.oros
On 13 Лип, 12:35, Anton Naumov <grayswan...@gmail.com> wrote:
> Оценку задачи дает тот человек, который по плану будет эту задачу
> выполнять. Всегда.
Вот в этом наши подходы отличаются. При планировании релиза у меня
нету распределения задач по людям. Только человеко-дни, зависимости
меджу задачами, принадлежность задачи к группе задач (UI, backend,
infrastructure setup etc).
Тоесть я не могу сказать кто будет делать какую задачу через 11
недель. Если это задача по веб-части, то кто-то из UI-щиков, а кто
именно - они сами решат, когда время придёт. Зато есть план на
следующую итерацию - кто что делает и его оценка (которая может не
совпадать с планом релиза, и тогда я буду его / этот план/
корректировать). Причём давать излишне оптимистичные оценки склонны
именно джуниоры. Это от них можно услышать оценку 2 дня на основную
фичу релиза, даже без попытки разбиения на подзадачи. От синьора
гораздо чаще я слышу слова "если я буду делать эту подсистему, то 2
дня, если кто-то из молодых - то 5-6. Поэтому пиши 5". И ведь прав
оказывается, в конце-концов.
Anton Naumov
> > выполнять. Всегда.
>
> Вот в этом наши подходы отличаются. При планировании релиза у меня
> нету распределения задач по людям. Только человеко-дни, зависимости
> меджу задачами, принадлежность задачи к группе задач (UI, backend,
> infrastructure setup etc).
Упс. Тут я похоже поспешил с выводами :) Я больше о тактите, а у Вас
стратегия. В такого рода планировании слишком много людей == слишком
много мнений. Согласен.
> Тоесть я не могу сказать кто будет делать какую задачу через 11
> недель. Если это задача по веб-части, то кто-то из UI-щиков, а кто
> именно - они сами решат, когда время придёт. Зато есть план на
> следующую итерацию - кто что делает и его оценка (которая может не
> совпадать с планом релиза, и тогда я буду его / этот план/
> корректировать).
Разумно. Если этот риск учтен, то возразить нечего. Главное помнить о
рисках :)
> Причём давать излишне оптимистичные оценки склонны
> именно джуниоры. Это от них можно услышать оценку 2 дня на основную
> фичу релиза, даже без попытки разбиения на подзадачи.
Для этого Господь дал людям речь и опыт проведения собраний :)
> От синьора
> гораздо чаще я слышу слова "если я буду делать эту подсистему, то 2
> дня, если кто-то из молодых - то 5-6. Поэтому пиши 5". И ведь прав
> оказывается, в конце-концов.
Сеньйоры-сеньйорам рознь. У Вас хорошие сеньйоры, честные. Это
здорово.
P.S. Как я и говорил в самом начале, если система работает и решает
необходимые задачи, это прекрасно.
Yuriy Mann
On 10 Лип, 13:14, Artjom Serdyuk <artem.serd...@gmail.com> wrote:
> Почему столько внимания оценкам? Ваша главная задача сейчас - сделать
> так, чтобы девелоперы идеально оценивали свою работу? Правильно ли я
> понял?
Нет, неправильно :) У меня достаточно опыта и мозгов, чтобы понимать,
что идеально оценить невозможно. Речь идет о тех же числах Фибоначчи,
но названных не стори поинтами, а идеальными днями.
А "главную" задачу даже сложно выделить. Философски говоря, главная
задача для меня - сделать свою работу интересной. Другими словами,
получать "драйв" от работы :) А уж способов достижения целый
комплекс: удовольствие от результата (работающий и продающийся
продукт); от улучшения оценок (почему бы к этому не стремиться, хотя
бы из чисто моральных соображений не нарушать обещаний); от ощущения,
что ребятам тоже работа нравится (включая и процесс эстимейшенов); от
собственно кодирования, когда есть возможность; от экспериментов по
улучшению процесса разработки, наконец (а эксперименты тоже дают
результат, от которого тоже удовольствие). Короче, это повод для
отдельной темы, точнее флейма ;)
> Оценки ли являются вашим узким местом, которое сдерживает рост
> команды? Не лучше ли будет потратить время на то, чтобы научиться чему-
> нибудь интересному в плане разработки?
Почему бы не развиваться всесторонне? В конце концов, это банально:
любое современное понятие процесса разработки, от CMMI до Скрама,
предполагает постоянное улучшение по всем направлением. Дабы случайно
не скатиться назад ;)
> Что, с Вашей точки зрения, существенно улучшится, когда вы сможете
> делать более точные оценки задач? Увеличит ли это прибыль от проекта?
> Улучшит ли отношения с заказчиком? Добавит ли удовольствия в процесс
> разработки? Насколько увеличатся шансы на общий успех проекта?
>
> Т.е. мне интересно - а где тут польза кроме удовольствия от
> эксперимента ;))
Мне кажется, я подробно описал свои соображения в предыдущих постах.
Но одно удовольствие от эксперимента - это ж уже немало! Не зря же мы
не пошли работать бухгалтерами. Кроме того, я уверен, подобные
эксперименты, проведенные с умом и с уверенностью в успехе, повышают
боевой дух всей команды. Рутину никто не любит...
> ...
>
> читати далі »
Artjom Serdyuk
придерживаюсь несколько других взгядов.
Мне близка позиция Теории Ограничений, что улучшать можно все и
бесконечно. Однако ресурсы, к сожалению, конечны, поэтому приходится
делать выбор - на что потратить mana points.
Я целиком и полностью согласен, что в работе нужен драйв. Если вам
этот драйв приносит улучшение точности эстимейтов, если вы заводите
команду на работу игрой в пленинг покер - значит, у вас это работает,
и это то, что вам нужно.
Рискну только заметить, что оценка времени - активность скорее
управленческая, нежели девелоперская. Если вам менеджмент и
планирование работы доставляют удовольствие, то я искренне за вас
рад )).
Юрий, поделитесь успехами. Две недели прошло с начала темы - вы что-то
применили из того, что тут было наговорено?
> ...
>
> продолжение >>
Yuriy Mann
On 22 Лип, 21:13, Artjom Serdyuk <artem.serd...@gmail.com> wrote:
> Рискну только заметить, что оценка времени - активность скорее
> управленческая, нежели девелоперская. Если вам менеджмент и
> планирование работы доставляют удовольствие, то я искренне за вас
> рад )).
В формате скрама - доставляют :) Потому что результат почти
мгновенный и осязаемый. Пока занимался а-ля-РУПом и CMMI, удовольствия
было гораздо меньше, нередко было страшное раздражение и легкая
депрессия. Удовольствие находил в съезжании на проектирование и
кодирование :) Ну и как-то дорос наверное до интереса к менеджменту
(врожденного интереса не было, так что вас я, кажется, тоже
понимаю ;) ).
> Юрий, поделитесь успехами. Две недели прошло с начала темы - вы что-то
> применили из того, что тут было наговорено?
Поговорил сегодня с командой на ретроспективе (только сегодня
закончился спринт). Народ воспринял по-разному, но большинство
проголосовало за то, чтобы попробовать новый способ оценки. Некоторые
вообще полностью согласны с моими доводами. С одной стороны, система
кое-как работает и высчитываемая велосити более-менее консистентна (ее
можно использовать в планах). С другой - система явно ненадежна. Если
в очередной спринт взять 20 задач сложности 1 или 10 сложности 2, они
могут занять очень разное время (из-за того, что оценки
непропорциональны, хотя порядок сложности соблюдается - так сказать,
транзитивность). Кроме того, часть команды путается в понятиях
сложности и времени: не всем понятно, что эта сложность в попугаях
призвана в конечном счете отражать время, затраченное на задачу - т.е.
быть ему пропорциональна. Это те выводы, которые родились в ходе
обсуждения.
Завтра попробуем переоценить по новой системе часть уже оцененных
задач (я об этом писал выше), выявить закономерности (корреляцию между
complexity points, как они у нас называются, и идеальными днями),
дооценить неоцененные и сконвертить старые оценки в остальном бэклоге.
О результатах, соответственно, можно будет говорить через полтора-два
месяца. О выявленных закономерностях, if any, напишу.