Estimations considered harmful (?)
Alexey Krivitsky
http://blogs.agilefaqs.com/2008/12/25/estimation-considered-harmful/
У кого похожий опыт? Кто в корне несогласен?
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
Serhiy Yevtushenko
в. однородности размера задачи в предметной области
Artjom Serdyuk
бюджет, то, что нужно) мы должны хоть как-то предсказывать будущее.
Во-вторых, мы можем управлять только тем, что мы можем измерить.
Поэтому, с моей точки зрения, без оценок не обойтись. Вопрос: кто, что
и зачем должен оценивать.
С одной стороны я согласен с Нарешем, и с Сергеем: оценивать должен
менеджмент, и оценивать должен все задачи скопом. Потому что
менеджмент распоряжается бюджетами, и для них важно, за какое время и
какими затратами будет сделано ЭТО.
Для этих целей есть статистические модели, например та же COCOMO II
(http://en.wikipedia.org/wiki/COCOMO, http://www.cms4site.ru/utility.php?utility=cocomoii).
У Сергея Евтушенко в посте тоже приведён пример, когда можно оценить
беклог без детальной оценки задач.
С другой стороны, девелоперы дожны оценивать свои задачи. Если задачи
не оценены, и команда, и менеджмент лишаются обратной связи. Команда
лишается возможности измерить, а значит, и управлять процессом.
Мы работаем достаточно быстро? Наша производительность растёт или
падает? Это простая задача или сложная, в конце концов? Эти вопросы
остаются без ответа... или же, пытаясь ответить на них, мы все равно
делаем какую-то оценку задач.
Итого, я бы ответил на свой же вопрос "Кто, что и как должен
оценивать" следующим образом:
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_...
>
> Как на меня, вопрос - оценивать/не оценивать - это вопрос
> а. скорее контрактных отношений (на фиксед кост/фиксед тайм проекте
> прийдеться оценивать вначале по любому) и рисков
> б. уровня доверия между заказчиком и разработчиками,
> в. однородности размера задачи в предметной области
>
> Кроме Нареша, есть еще другие публикации касательно полезности/вредности
> оценок
>
> http://epistemologic.com/2007/05/12/estimation-considered-harmful/
>
> Сергей
> 8 января 2009 г. 15:14 пользователь Alexey Krivitsky <
> alexeykrivit...@gmail.com> написал:
>
> > Наш друг Нареш Джейн (выступал на Agile Gathering IV<http://www.agileukraine.org/2008/03/agile-gathering-iv.html>)
Alexander Rivkind
Пока что это наиболее комфортный проект из всех, в котором я когда-либо участвовал.
Не исключено, что это была специфика проекта и заказчика (заказчик умел разбить его на подзадачи длиной не больше 72 часов).
--
Best Regards, Alik.
Borys Lebeda
История совершенно банальная, но довольно интересно получилось из неё
выкрутиться:
Как обычно менеджер М попросил оценки как можно быстрее?
Я: Тут 46 задач. Насколько быстро их нужно оценить?
М: Как можно быстрее: можешь в ближайшие пару часов сделать?
Я: Ну вообще-то тут есть задачи, которые могут сами по себе затянутся
на несколько дней переговоров ... Вот эту задачу нужно будет разбить
на подзадачи, описать решение и оценить сколько времени уйдёт на
рефакторинг модуля G.
М: Не тратьте время на ерунду: для меня не надо разбивать или что-то
описывать, просто скажи сколько уйдёт времени.
Я: (тут мне вообще не ясно почему так много менеджеров думает, что
можно что-то оценить, не имея представления как это делается).
М: Я в конце концов не требую точных оценок. Сделай guestimate'ы ...
Я: (я в первые услышал это слово). Да конечно, guestimate'ы ...
Итак, мой способ получения guestimate'ов. Если этот пост читает кто-то
из моих бывших или настоящих менеджеров, пользуюсь случаем и передаю
привет.
Мой феноменальный способ получения оценок за пять минут на поздних
стадиях проекта:
0. Считаем средние трудозатраты на одну задачу за прошедшие периоды
1. Умножаем на коефициент риска (зависит от безнадёжности нашего
положения) обычно от 1.5 до 2 получаем некоторую величину L, которую
назовём коефициентом приведения.
2. Экспортируем из JIRA, BugZilla, devTrack, Trac или что там у вас
используется в Excel'овскую табличку в одну колонку описания задач на
итерацию
3. По формуле считаем количество символов в описании (функция LEN) и
делим на общее число символов описаний задач в итерации. Это будут
наши удельные веса задач
4. Удельные веса умножаем на коефициент приведения.
В атаче - расчётная таблица с примером.
Преимущества данного подхода:
- оценки получаются очень быстро
- метод в целом не нарушает статистику оценок разработки проекта (в
более сложной формуле можно учесть ещё и тренд :))
- оценки выглядят правдоподобно
Недостатки
- да, нужно иметь статистику по предыдущим итерациям (пункт 0 моего
подхода) (если вы её не ведёте отрежте себе палец и начните наконец
заливать "честные" оценки в трекинговую систему)
- в отдельных задачах оценки могут быть не реалистичными (но не факт,
что вы потратив два часа дадите лучшую оценку).
- в некоторых задачах возможен overestimate (его разумно использовать
для покрытия "задолженности" по задачам из предыдущего пункта).
- декомпозицию задач и продумывание решения всё равно нужно делать,
столько сколько потребуется (Если ваш менеджер это понимает, то вам
повезло и мой метод вам вообще не нужен).
В заключении: я абсолютно согласен с Нарешем и с Сергеем и уверен, что
оценки в целом по проекту должен делать в основном менеджер, исходя из
здравого смысла, опыта как в проекте так и за его пределами. Это легко
достигается если он и команда играют по-честному ...
Лаконичного заключения не получилось: это ещё одна тем для разговора!
2009/1/9 Alexander Rivkind <alik...@gmail.com>
--
Borys L.
Mykola Gurov
Понаперемешано всякого. Эстимейты с дедлайнами. Детальная оценка с
грубой. Оценка времени с оценкой размера/сложности.
Если грубые эстимейты превращаются в дедлайны, то это, конечно же,
плохо. Если самоцелью становится подтвердить эстимейты - плохо.
Детальное эстимирование на год вперед - тоже скорее всего зло. Но из
этого не следует вредность оценок самих по себе. Лишь необходимость
уметь применять их во благо.
Другой вопрос, что могут быть ситуации когда эти эстимейшены скорее
waste. Но это уже частные случаи.
On Jan 8, 3:14 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> Наш друг Нареш Джейн (выступал на Agile Gathering
> IV<http://www.agileukraine.org/2008/03/agile-gathering-iv.html>)
Borys Lebeda
Sergiy Movchan
--
...dali bude...
Alexander Rivkind
--
Best Regards, Alik.
Alimenkou Nikolay
On Jan 8, 3:14 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> Наш друг Нареш Джейн (выступал на Agile Gathering
> IV<http://www.agileukraine.org/2008/03/agile-gathering-iv.html>)
Artjom Serdyuk
> --
> Borys L.