У меня есть опыт работы без оценок. Для разработчиков так работать комфортнее, при условии, что менеджмент может сам грубо прикидывать размер задач (случаються предметные области, где задачи достаточно хорошо предсказуемые/малого размера), и есть хорошая коммуникация между разработчиками и менеджментом. Проблемы возникают, когда после большого количества небольших однородных задач выскакивают несколько больших задач, и тут внезапно ожидания по времени выполнения подводят всех.
Второй вариант когда-то читал у Девида Андерсена - проект ускорился за счет того, что отказались от детальной оценки задач - и убрали кучу времени, которое тратилось на оценку задач. Опять, в этом случае задачи были в основном сравнимого размера. Второй фактор, который приводил к большим тратам времени на естимейшн - это то, что выполнение задачи и ее естимейшн были сильно разнесены по времени, и знания, полученный при естимейшн, не использовались/забывались испольнителями. http://www.agilemanagement.net/Articles/Papers/From_Worst_to_Best_in_...
Как на меня, вопрос - оценивать/не оценивать - это вопрос а. скорее контрактных отношений (на фиксед кост/фиксед тайм проекте прийдеться оценивать вначале по любому) и рисков б. уровня доверия между заказчиком и разработчиками, в. однородности размера задачи в предметной области
Кроме Нареша, есть еще другие публикации касательно полезности/вредности оценок
Во-первых, чтобы хоть как-то гарантировать успех проекта (в срок, в бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
Во-вторых, мы можем управлять только тем, что мы можем измерить.
Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что и зачем должен оценивать.
С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен менеджмент, и оценивать должен все задачи скопом. Потому что менеджмент распоряжается бюджетами, и для них важно, за какое время и какими затратами будет сделано ЭТО.
С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи не оценены, и команда, и менеджмент лишаются обратной связи. Команда лишается возможности измерить, а значит, и управлять процессом.
Мы работаем достаточно быстро? Наша производительность растёт или падает? Это простая задача или сложная, в конце концов? Эти вопросы остаются без ответа... или же, пытаясь ответить на них, мы все равно делаем какую-то оценку задач.
Итого, я бы ответил на свой же вопрос "Кто, что и как должен оценивать" следующим образом: 1) для бюджетирования менеджмент должен оценивать беклог по статистическим алгоритмам; 2) для мотивации и обратной связи девелоперы должны оценивать задачи. ---------------- З.Ы. У Голдратта в "Distribution process" есть очень похожие выводы:
Предположим, у нас есть 3 магазина. Как узнать, какой магазин сколько товара продаст, и какой нужно иметь запас каждого товара на складе?
1) предсказывать спрос в каждом отдельном магазине на каждый отдельный продут (читай - делать естимейт каждой задачи) бессмысленно - слишком много факторов влияет, мы не угадаем.
2) Чем дольше срок предсказания, тем больше ошибка.
3) Поэтому предсказываем на малый срок, и для многих торговых точек (читай - для многих разработчиков, для команд). Здесь начинает играть статистика, колебания взаимно погашаются и оценка получается более точной.
Вывод: нужно иметь Центральный склад (читай Продакт беклог). Запас задач на центральном складе мы можем вычислить из средней продуктивности команд + какой-то буфер. Такая оценка будет а) более точной, и б) полезной для менеджмента, т.к. позволяет предсказать момент, когда Центральный склад (беклог) опустеет.
Обратите внимание! Мы всё равно не можем предсказать, когда какой магазин продаст какой товар! Вместо этого как только магазин продает товар, он запрашивает Центральный склад и получает новый запас товара оцень быстро.
On Jan 8, 5:53 pm, "Serhiy Yevtushenko" <syevtushe...@gmail.com> wrote:
> У меня есть опыт работы без оценок. Для разработчиков так работать > комфортнее, при условии, что менеджмент может сам грубо прикидывать размер > задач (случаються предметные области, где задачи достаточно хорошо > предсказуемые/малого размера), и есть хорошая коммуникация между > разработчиками и менеджментом. > Проблемы возникают, когда после большого количества небольших однородных > задач выскакивают несколько больших задач, и тут внезапно ожидания по > времени выполнения подводят всех.
> Второй вариант когда-то читал у Девида Андерсена - проект ускорился за счет > того, что отказались от детальной оценки задач - и убрали кучу времени, > которое тратилось на оценку задач. Опять, в этом случае задачи были в > основном сравнимого размера. Второй фактор, который приводил к большим > тратам времени на естимейшн - это то, что выполнение задачи и ее естимейшн > были сильно разнесены по времени, и знания, полученный при естимейшн, не > использовались/забывались испольнителями.http://www.agilemanagement.net/Articles/Papers/From_Worst_to_Best_in_...
> Как на меня, вопрос - оценивать/не оценивать - это вопрос > а. скорее контрактных отношений (на фиксед кост/фиксед тайм проекте > прийдеться оценивать вначале по любому) и рисков > б. уровня доверия между заказчиком и разработчиками, > в. однородности размера задачи в предметной области
> Кроме Нареша, есть еще другие публикации касательно полезности/вредности > оценок
У меня есть обыт работы без оценок, при том что иногда (на некоторые задачи) клиентпросил грубые оценки, чтобы оценить, стоит ли вообще из стартовать. Проект был T&M. У клиента был доступ к time reporting модулю, где он мог трекать сколько времени потрачено. Репортовалось ежедневно, а он смотрел раз в 2 недели. Пока что это наиболее комфортный проект из всех, в котором я когда-либо участвовал. Не исключено, что это была специфика проекта и заказчика (заказчик умел разбить его на подзадачи длиной не больше 72 часов).
> Во-первых, чтобы хоть как-то гарантировать успех проекта (в срок, в > бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
> Во-вторых, мы можем управлять только тем, что мы можем измерить.
> Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что > и зачем должен оценивать.
> С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен > менеджмент, и оценивать должен все задачи скопом. Потому что > менеджмент распоряжается бюджетами, и для них важно, за какое время и > какими затратами будет сделано ЭТО.
> С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи > не оценены, и команда, и менеджмент лишаются обратной связи. Команда > лишается возможности измерить, а значит, и управлять процессом.
> Мы работаем достаточно быстро? Наша производительность растёт или > падает? Это простая задача или сложная, в конце концов? Эти вопросы > остаются без ответа... или же, пытаясь ответить на них, мы все равно > делаем какую-то оценку задач.
> Итого, я бы ответил на свой же вопрос "Кто, что и как должен > оценивать" следующим образом: > 1) для бюджетирования менеджмент должен оценивать беклог по > статистическим алгоритмам; > 2) для мотивации и обратной связи девелоперы должны оценивать задачи. > ---------------- > З.Ы. У Голдратта в "Distribution process" есть очень похожие выводы:
> Предположим, у нас есть 3 магазина. Как узнать, какой магазин сколько > товара продаст, и какой нужно иметь запас каждого товара на складе?
> 1) предсказывать спрос в каждом отдельном магазине на каждый отдельный > продут (читай - делать естимейт каждой задачи) бессмысленно - слишком > много факторов влияет, мы не угадаем.
> 2) Чем дольше срок предсказания, тем больше ошибка.
> 3) Поэтому предсказываем на малый срок, и для многих торговых точек > (читай - для многих разработчиков, для команд). Здесь начинает играть > статистика, колебания взаимно погашаются и оценка получается более > точной.
> Вывод: нужно иметь Центральный склад (читай Продакт беклог). Запас > задач на центральном складе мы можем вычислить из средней > продуктивности команд + какой-то буфер. Такая оценка будет а) более > точной, и б) полезной для менеджмента, т.к. позволяет предсказать > момент, когда Центральный склад (беклог) опустеет.
> Обратите внимание! Мы всё равно не можем предсказать, когда какой > магазин продаст какой товар! Вместо этого как только магазин продает > товар, он запрашивает Центральный склад и получает новый запас товара > оцень быстро.
> On Jan 8, 5:53 pm, "Serhiy Yevtushenko" <syevtushe...@gmail.com> > wrote: > > У меня есть опыт работы без оценок. Для разработчиков так работать > > комфортнее, при условии, что менеджмент может сам грубо прикидывать > размер > > задач (случаються предметные области, где задачи достаточно хорошо > > предсказуемые/малого размера), и есть хорошая коммуникация между > > разработчиками и менеджментом. > > Проблемы возникают, когда после большого количества небольших однородных > > задач выскакивают несколько больших задач, и тут внезапно ожидания по > > времени выполнения подводят всех.
> > Второй вариант когда-то читал у Девида Андерсена - проект ускорился за > счет > > того, что отказались от детальной оценки задач - и убрали кучу времени, > > которое тратилось на оценку задач. Опять, в этом случае задачи были в > > основном сравнимого размера. Второй фактор, который приводил к большим > > тратам времени на естимейшн - это то, что выполнение задачи и ее > естимейшн > > были сильно разнесены по времени, и знания, полученный при естимейшн, не > > использовались/забывались испольнителями. > http://www.agilemanagement.net/Articles/Papers/From_Worst_to_Best_in_...
> > Как на меня, вопрос - оценивать/не оценивать - это вопрос > > а. скорее контрактных отношений (на фиксед кост/фиксед тайм проекте > > прийдеться оценивать вначале по любому) и рисков > > б. уровня доверия между заказчиком и разработчиками, > > в. однородности размера задачи в предметной области
> > Кроме Нареша, есть еще другие публикации касательно полезности/вредности > > оценок
История совершенно банальная, но довольно интересно получилось из неё выкрутиться: Как обычно менеджер М попросил оценки как можно быстрее? Я: Тут 46 задач. Насколько быстро их нужно оценить? М: Как можно быстрее: можешь в ближайшие пару часов сделать? Я: Ну вообще-то тут есть задачи, которые могут сами по себе затянутся на несколько дней переговоров ... Вот эту задачу нужно будет разбить на подзадачи, описать решение и оценить сколько времени уйдёт на рефакторинг модуля G. М: Не тратьте время на ерунду: для меня не надо разбивать или что-то описывать, просто скажи сколько уйдёт времени. Я: (тут мне вообще не ясно почему так много менеджеров думает, что можно что-то оценить, не имея представления как это делается). М: Я в конце концов не требую точных оценок. Сделай guestimate'ы ... Я: (я в первые услышал это слово). Да конечно, guestimate'ы ...
Итак, мой способ получения guestimate'ов. Если этот пост читает кто-то из моих бывших или настоящих менеджеров, пользуюсь случаем и передаю привет.
Мой феноменальный способ получения оценок за пять минут на поздних стадиях проекта: 0. Считаем средние трудозатраты на одну задачу за прошедшие периоды 1. Умножаем на коефициент риска (зависит от безнадёжности нашего положения) обычно от 1.5 до 2 получаем некоторую величину L, которую назовём коефициентом приведения. 2. Экспортируем из JIRA, BugZilla, devTrack, Trac или что там у вас используется в Excel'овскую табличку в одну колонку описания задач на итерацию 3. По формуле считаем количество символов в описании (функция LEN) и делим на общее число символов описаний задач в итерации. Это будут наши удельные веса задач 4. Удельные веса умножаем на коефициент приведения.
В атаче - расчётная таблица с примером. Преимущества данного подхода: - оценки получаются очень быстро - метод в целом не нарушает статистику оценок разработки проекта (в более сложной формуле можно учесть ещё и тренд :)) - оценки выглядят правдоподобно
Недостатки - да, нужно иметь статистику по предыдущим итерациям (пункт 0 моего подхода) (если вы её не ведёте отрежте себе палец и начните наконец заливать "честные" оценки в трекинговую систему) - в отдельных задачах оценки могут быть не реалистичными (но не факт, что вы потратив два часа дадите лучшую оценку). - в некоторых задачах возможен overestimate (его разумно использовать для покрытия "задолженности" по задачам из предыдущего пункта). - декомпозицию задач и продумывание решения всё равно нужно делать, столько сколько потребуется (Если ваш менеджер это понимает, то вам повезло и мой метод вам вообще не нужен).
В заключении: я абсолютно согласен с Нарешем и с Сергеем и уверен, что оценки в целом по проекту должен делать в основном менеджер, исходя из здравого смысла, опыта как в проекте так и за его пределами. Это легко достигается если он и команда играют по-честному ...
Лаконичного заключения не получилось: это ещё одна тем для разговора!
> У меня есть обыт работы без оценок, при том что иногда (на некоторые задачи) клиентпросил грубые оценки, чтобы оценить, стоит ли вообще из стартовать. Проект был T&M. У клиента был доступ к time reporting модулю, где он мог трекать сколько времени потрачено. Репортовалось ежедневно, а он смотрел раз в 2 недели. > Пока что это наиболее комфортный проект из всех, в котором я когда-либо участвовал. > Не исключено, что это была специфика проекта и заказчика (заказчик умел разбить его на подзадачи длиной не больше 72 часов).
>> Во-первых, чтобы хоть как-то гарантировать успех проекта (в срок, в >> бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
>> Во-вторых, мы можем управлять только тем, что мы можем измерить.
>> Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что >> и зачем должен оценивать.
>> С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен >> менеджмент, и оценивать должен все задачи скопом. Потому что >> менеджмент распоряжается бюджетами, и для них важно, за какое время и >> какими затратами будет сделано ЭТО.
>> С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи >> не оценены, и команда, и менеджмент лишаются обратной связи. Команда >> лишается возможности измерить, а значит, и управлять процессом.
>> Мы работаем достаточно быстро? Наша производительность растёт или >> падает? Это простая задача или сложная, в конце концов? Эти вопросы >> остаются без ответа... или же, пытаясь ответить на них, мы все равно >> делаем какую-то оценку задач.
>> Итого, я бы ответил на свой же вопрос "Кто, что и как должен >> оценивать" следующим образом: >> 1) для бюджетирования менеджмент должен оценивать беклог по >> статистическим алгоритмам; >> 2) для мотивации и обратной связи девелоперы должны оценивать задачи. >> ---------------- >> З.Ы. У Голдратта в "Distribution process" есть очень похожие выводы:
>> Предположим, у нас есть 3 магазина. Как узнать, какой магазин сколько >> товара продаст, и какой нужно иметь запас каждого товара на складе?
>> 1) предсказывать спрос в каждом отдельном магазине на каждый отдельный >> продут (читай - делать естимейт каждой задачи) бессмысленно - слишком >> много факторов влияет, мы не угадаем.
>> 2) Чем дольше срок предсказания, тем больше ошибка.
>> 3) Поэтому предсказываем на малый срок, и для многих торговых точек >> (читай - для многих разработчиков, для команд).
В корне не согласен с заглавием и основным выводом поста Нареша. Понаперемешано всякого. Эстимейты с дедлайнами. Детальная оценка с грубой. Оценка времени с оценкой размера/сложности.
Если грубые эстимейты превращаются в дедлайны, то это, конечно же, плохо. Если самоцелью становится подтвердить эстимейты - плохо. Детальное эстимирование на год вперед - тоже скорее всего зло. Но из этого не следует вредность оценок самих по себе. Лишь необходимость уметь применять их во благо.
Другой вопрос, что могут быть ситуации когда эти эстимейшены скорее waste. Но это уже частные случаи.
On Jan 8, 3:14 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> wrote:
Идея заключается в том, что грубые эстимейшены всегда waste: никакие это не частные случаи. Это везде происходит. Ты, Коля, можешь дать грубый эстимейт задачи размером в 100 человеко-часов за 10 минут? В следующий раз поставь 100 баксов на то, что отклонение будет не больше чем на 20%.
Может Тебя удивляет, что грубые эстимейты превращаются в дедлайны? Ну так их для того и запрашивают что бы поскорее превратить в дедлайн!
> В корне не согласен с заглавием и основным выводом поста Нареша. > Понаперемешано всякого. Эстимейты с дедлайнами. Детальная оценка с > грубой. Оценка времени с оценкой размера/сложности.
> Если грубые эстимейты превращаются в дедлайны, то это, конечно же, > плохо. Если самоцелью становится подтвердить эстимейты - плохо. > Детальное эстимирование на год вперед - тоже скорее всего зло. Но из > этого не следует вредность оценок самих по себе. Лишь необходимость > уметь применять их во благо.
> Другой вопрос, что могут быть ситуации когда эти эстимейшены скорее > waste. Но это уже частные случаи.
красиво :) в целом практически сосомо 2... там в принципе тоже можно в качестве функциональной точки выбрать любую лабуду, которая не меняется от проекта к проекту (вот например стиль изложения требований). недостатком кроме перечисленных (которые как по мне вообще не недостатки, т.к. они присущи любым системам оценок трудозатрат) есть только то, что если требования приходят от другого аналитика (то есть с другим стилем), то погрешность нарастает на порядки... хотя может и повезти.
но вообще способ очень оригинально-креативный. спасибо :)
> История совершенно банальная, но довольно интересно получилось из неё > выкрутиться: > Как обычно менеджер М попросил оценки как можно быстрее? > Я: Тут 46 задач. Насколько быстро их нужно оценить? > М: Как можно быстрее: можешь в ближайшие пару часов сделать? > Я: Ну вообще-то тут есть задачи, которые могут сами по себе затянутся > на несколько дней переговоров ... Вот эту задачу нужно будет разбить > на подзадачи, описать решение и оценить сколько времени уйдёт на > рефакторинг модуля G. > М: Не тратьте время на ерунду: для меня не надо разбивать или что-то > описывать, просто скажи сколько уйдёт времени. > Я: (тут мне вообще не ясно почему так много менеджеров думает, что > можно что-то оценить, не имея представления как это делается). > М: Я в конце концов не требую точных оценок. Сделай guestimate'ы ... > Я: (я в первые услышал это слово). Да конечно, guestimate'ы ...
> Итак, мой способ получения guestimate'ов. Если этот пост читает кто-то > из моих бывших или настоящих менеджеров, пользуюсь случаем и передаю > привет.
> Мой феноменальный способ получения оценок за пять минут на поздних > стадиях проекта: > 0. Считаем средние трудозатраты на одну задачу за прошедшие периоды > 1. Умножаем на коефициент риска (зависит от безнадёжности нашего > положения) обычно от 1.5 до 2 получаем некоторую величину L, которую > назовём коефициентом приведения. > 2. Экспортируем из JIRA, BugZilla, devTrack, Trac или что там у вас > используется в Excel'овскую табличку в одну колонку описания задач на > итерацию > 3. По формуле считаем количество символов в описании (функция LEN) и > делим на общее число символов описаний задач в итерации. Это будут > наши удельные веса задач > 4. Удельные веса умножаем на коефициент приведения.
> В атаче - расчётная таблица с примером. > Преимущества данного подхода: > - оценки получаются очень быстро > - метод в целом не нарушает статистику оценок разработки проекта (в > более сложной формуле можно учесть ещё и тренд :)) > - оценки выглядят правдоподобно
> Недостатки > - да, нужно иметь статистику по предыдущим итерациям (пункт 0 моего > подхода) (если вы её не ведёте отрежте себе палец и начните наконец > заливать "честные" оценки в трекинговую систему) > - в отдельных задачах оценки могут быть не реалистичными (но не факт, > что вы потратив два часа дадите лучшую оценку). > - в некоторых задачах возможен overestimate (его разумно использовать > для покрытия "задолженности" по задачам из предыдущего пункта). > - декомпозицию задач и продумывание решения всё равно нужно делать, > столько сколько потребуется (Если ваш менеджер это понимает, то вам > повезло и мой метод вам вообще не нужен).
> В заключении: я абсолютно согласен с Нарешем и с Сергеем и уверен, что > оценки в целом по проекту должен делать в основном менеджер, исходя из > здравого смысла, опыта как в проекте так и за его пределами. Это легко > достигается если он и команда играют по-честному ...
> Лаконичного заключения не получилось: это ещё одна тем для разговора!
> > У меня есть обыт работы без оценок, при том что иногда (на некоторые > задачи) клиентпросил грубые оценки, чтобы оценить, стоит ли вообще из > стартовать. Проект был T&M. У клиента был доступ к time reporting модулю, > где он мог трекать сколько времени потрачено. Репортовалось ежедневно, а он > смотрел раз в 2 недели. > > Пока что это наиболее комфортный проект из всех, в котором я когда-либо > участвовал. > > Не исключено, что это была специфика проекта и заказчика (заказчик умел > разбить его на подзадачи длиной не больше 72 часов).
> >> Во-первых, чтобы хоть как-то гарантировать успех проекта (в срок, в > >> бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
> >> Во-вторых, мы можем управлять только тем, что мы можем измерить.
> >> Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что > >> и зачем должен оценивать.
> >> С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен > >> менеджмент, и оценивать должен все задачи скопом. Потому что > >> менеджмент распоряжается бюджетами, и для них важно, за какое время и > >> какими затратами будет сделано ЭТО.
> >> С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи > >> не оценены, и команда, и менеджмент лишаются обратной связи. Команда > >> лишается возможности измерить, а значит, и управлять процессом.
> >> Мы работаем достаточно быстро? Наша производительность растёт или > >> падает? Это простая задача или сложная, в конце концов? Эти вопросы > >> остаются без ответа... или же, пытаясь ответить на них, мы все равно > >> делаем какую-то оценку задач.
> >> Итого, я бы ответил на свой же вопрос "Кто, что и как должен > >> оценивать" следующим образом: > >> 1) для бюджетирования менеджмент должен
> История совершенно банальная, но довольно интересно получилось из неё > выкрутиться: > Как обычно менеджер М попросил оценки как можно быстрее? > Я: Тут 46 задач. Насколько быстро их нужно оценить? > М: Как можно быстрее: можешь в ближайшие пару часов сделать? > Я: Ну вообще-то тут есть задачи, которые могут сами по себе затянутся > на несколько дней переговоров ... Вот эту задачу нужно будет разбить > на подзадачи, описать решение и оценить сколько времени уйдёт на > рефакторинг модуля G. > М: Не тратьте время на ерунду: для меня не надо разбивать или что-то > описывать, просто скажи сколько уйдёт времени. > Я: (тут мне вообще не ясно почему так много менеджеров думает, что > можно что-то оценить, не имея представления как это делается). > М: Я в конце концов не требую точных оценок. Сделай guestimate'ы ... > Я: (я в первые услышал это слово). Да конечно, guestimate'ы ...
> Итак, мой способ получения guestimate'ов. Если этот пост читает кто-то > из моих бывших или настоящих менеджеров, пользуюсь случаем и передаю > привет.
> Мой феноменальный способ получения оценок за пять минут на поздних > стадиях проекта: > 0. Считаем средние трудозатраты на одну задачу за прошедшие периоды > 1. Умножаем на коефициент риска (зависит от безнадёжности нашего > положения) обычно от 1.5 до 2 получаем некоторую величину L, которую > назовём коефициентом приведения. > 2. Экспортируем из JIRA, BugZilla, devTrack, Trac или что там у вас > используется в Excel'овскую табличку в одну колонку описания задач на > итерацию > 3. По формуле считаем количество символов в описании (функция LEN) и > делим на общее число символов описаний задач в итерации. Это будут > наши удельные веса задач > 4. Удельные веса умножаем на коефициент приведения.
> В атаче - расчётная таблица с примером. > Преимущества данного подхода: > - оценки получаются очень быстро > - метод в целом не нарушает статистику оценок разработки проекта (в > более сложной формуле можно учесть ещё и тренд :)) > - оценки выглядят правдоподобно
> Недостатки > - да, нужно иметь статистику по предыдущим итерациям (пункт 0 моего > подхода) (если вы её не ведёте отрежте себе палец и начните наконец > заливать "честные" оценки в трекинговую систему) > - в отдельных задачах оценки могут быть не реалистичными (но не факт, > что вы потратив два часа дадите лучшую оценку). > - в некоторых задачах возможен overestimate (его разумно использовать > для покрытия "задолженности" по задачам из предыдущего пункта). > - декомпозицию задач и продумывание решения всё равно нужно делать, > столько сколько потребуется (Если ваш менеджер это понимает, то вам > повезло и мой метод вам вообще не нужен).
> В заключении: я абсолютно согласен с Нарешем и с Сергеем и уверен, что > оценки в целом по проекту должен делать в основном менеджер, исходя из > здравого смысла, опыта как в проекте так и за его пределами. Это легко > достигается если он и команда играют по-честному ...
> Лаконичного заключения не получилось: это ещё одна тем для разговора!
> > У меня есть обыт работы без оценок, при том что иногда (на некоторые > задачи) клиентпросил грубые оценки, чтобы оценить, стоит ли вообще из > стартовать. Проект был T&M. У клиента был доступ к time reporting модулю, > где он мог трекать сколько времени потрачено. Репортовалось ежедневно, а он > смотрел раз в 2 недели. > > Пока что это наиболее комфортный проект из всех, в котором я когда-либо > участвовал. > > Не исключено, что это была специфика проекта и заказчика (заказчик умел > разбить его на подзадачи длиной не больше 72 часов).
> >> Во-первых, чтобы хоть как-то гарантировать успех проекта (в срок, в > >> бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
> >> Во-вторых, мы можем управлять только тем, что мы можем измерить.
> >> Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что > >> и зачем должен оценивать.
> >> С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен > >> менеджмент, и оценивать должен все задачи скопом. Потому что > >> менеджмент распоряжается бюджетами, и для них важно, за какое время и > >> какими затратами будет сделано ЭТО.
> >> С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи > >> не оценены, и команда, и менеджмент лишаются обратной связи. Команда > >> лишается возможности измерить, а значит, и управлять процессом.
> >> Мы работаем достаточно быстро? Наша производительность растёт или > >> падает? Это простая задача или сложная, в конце концов? Эти вопросы > >> остаются без ответа... или же, пытаясь ответить на них, мы все равно > >> делаем какую-то оценку задач.
> >> Итого, я бы ответил на свой же вопрос "Кто, что и как должен > >> оценивать" следующим образом: > >> 1) для бюджетирования менеджмент должен оценивать беклог по > >> статистическим алгоритмам; > >> 2) для мотивации и обратной связи девелоперы должны оценивать задачи. > >> ---------------- > >> З.Ы. У Голдратта в "Distribution process" есть очень похожие выводы:
> >> Предположим, у нас есть 3 магазина. Как узнать, какой магазин сколько > >> товара продаст, и какой нужно иметь запас каждого товара на складе?
> >> 1) предсказывать спрос в каждом отдельном магазине на каждый отдельный > >> продут (читай - делать естимейт каждой задачи) бессмысленно - слишком > >> много факторов влияет, мы не
> Идея заключается в том, что грубые эстимейшены всегда waste: никакие это не > частные случаи. Это везде происходит. Ты, Коля, можешь дать грубый > эстимейт задачи размером в 100 человеко-часов за 10 минут? > В следующий раз поставь 100 баксов на то, что отклонение будет не больше чем > на 20%.
> Может Тебя удивляет, что грубые эстимейты превращаются в дедлайны? Ну так их > для того и запрашивают что бы поскорее превратить в дедлайн!
> > В корне не согласен с заглавием и основным выводом поста Нареша. > > Понаперемешано всякого. Эстимейты с дедлайнами. Детальная оценка с > > грубой. Оценка времени с оценкой размера/сложности.
> > Если грубые эстимейты превращаются в дедлайны, то это, конечно же, > > плохо. Если самоцелью становится подтвердить эстимейты - плохо. > > Детальное эстимирование на год вперед - тоже скорее всего зло. Но из > > этого не следует вредность оценок самих по себе. Лишь необходимость > > уметь применять их во благо.
> > Другой вопрос, что могут быть ситуации когда эти эстимейшены скорее > > waste. Но это уже частные случаи.
