?

Log in

No account? Create an account

Previous Entry | Next Entry

EBDC


Исправил ошибку в ексельке, считающей Enhanced Burn-Down Chart (EBDC). Ошибка была глупой и дурацкой: при расчете средней скорости команды я усреднял имеющиеся данные по скорости команды и еще одну клеточку, где всегда был ноль. В итоге для малого числа итераций оценка была более пессимистичной, а для большого числа итерация ошибка вообще нивелировалась.

Зато теперь все стало красиво и правильно. Наглядное тому иллюстрация - точка пересечения линий трендов теперь соответствует максимуму функции плотности распределения.

Новую версию можно скачать тут. Там же есть слайдкаст с намеками как использовать табличку и детальным пояснением, как читать эту диаграмму. Эту диаграмму (со статистическими приблудами в виде зеленых линий и фиолетовых полосок) я люблю за то, что с ее помощью понять состояние проекта можно всего лишь бросив взгляд на эту картинку на пару секунд.

Tags:

Comments

( 31 comments — Leave a comment )
bytebuster463
Jan. 6th, 2014 10:45 pm (UTC)
Интересный подход, спасибо.
cartmendum
Jan. 7th, 2014 01:16 pm (UTC)
Используете где?
bytebuster463
Jan. 7th, 2014 03:54 pm (UTC)
Ысчо нет, но идея здравая. Меня только смущает необходимость повторной оценки всего-всего-всего. Понятно, что без этого никаких цифр быть не может, но всё равно, это бывает трудно. Чаще случается, что во входящие попадает всё подряд без оценки, только с предварительным подтверджением, что это технически реализуемо.
cartmendum
Jan. 7th, 2014 05:21 pm (UTC)
Если входящих задачек много (хотя бы десятки) и за итерацию делается тоже не мало задачек (ну хотя бы под десяток), то с оценкой можно не заморачиваться особо, точности +/- 2 раза хватит за глаза. А если и по трудоемкости задачки "ну +/- похожи", то вообще можно их не оценивать, а оперировать их числом.
bytebuster463
Jan. 7th, 2014 05:42 pm (UTC)
А вот кстати да, если давать не одну оценку, а range — это может сработать. Вопрос — следует ли это делать, и, если да, то имеет ли смысл допилить это в эксельке?
cartmendum
Jan. 7th, 2014 05:46 pm (UTC)
Хм... А ведь это идея...
cartmendum
Jan. 7th, 2014 06:40 pm (UTC)
Кто первый подал мне эту идею, тут пусть и смотрит :)

http://mnogosdelal.ru/slidecasts/project-estimation/simpleebdctemplate_range/

Табличка показывает, что когда задачек много и оценки между ними не отличаются в разы, то оценка в виде диапазона сильно дела не меняет. Но если задачек не много, то может пригодиться
(no subject) - bytebuster463 - Jan. 7th, 2014 07:09 pm (UTC) - Expand
Sergey Martynenko
Jan. 8th, 2014 12:26 pm (UTC)
Область применимости
Коллеги, может попробуем определить границы применимости данной модели?

Для всех проектов, для которых я эту диаграмму строил, получалась полная ерунда. Хвост изгибался, уходил вниз и вниз. И ничего было нельзя предсказать ни в один момент времени.
Тип проектов. Стандартные проекты по разработке ПО, скорее, среднего размера (десятки человеколет). Планирование (добавление задач) проходило во все время проекта. Т.е. стандартная итеративная разработка, с планированием аналогичном планированию методом "набегающей волны".

-- Отступление -------------
Область применимости производственной системы Тойота в мире материального производства - менее 10%. Попытки внедрения этой системы в неподходящей среде приводили к миллиардным потерям (для примера - Хитачи).
Область применимости SCRUM, похоже, менее 5%. Попытки внедрения этой методологии в неподходящей производственной среде приводят к заведомо предсказуемым печальным результатам.
Jira - маленькая трекинговая система для маленьких команд. Попытки приспособить ее для мультипроектной среды с разными типами проектов - ну вы поняли.
-- END ----------------------
Я это к тому, что знание ограничений метода - одно из самых ценных. Я немедленно укажу на дверь "консультанту" от SCRUM, если он не перечислит ограничения предлагаемой методологии.


Edited at 2014-01-08 12:27 pm (UTC)
cartmendum
Jan. 8th, 2014 12:30 pm (UTC)
Re: Область применимости
Во, и это может быть темой отдельного вебинара :)

Что касается области применимости, то эта екселька - нашлепка сверху на скрам. То есть, область ее применимости еще уже, чем у самого скрама.
Sergey Martynenko
Jan. 8th, 2014 01:18 pm (UTC)
Не уверен. Эта модель в отличии от SCRUM вполне может быть применима в среде с количеством рабочих центров более одного.

Полагаю, что модель больше подходит для проектов сопровождения, построенных на коротких циклах переменной длины (уже не SCRUM). А вот для проектов разработки с нуля ее применимость под вопросом.
sbase
Jan. 9th, 2014 07:24 pm (UTC)
Правильно ли я понимаю что расчетная дата завершения проекта это скорость_реализации минус скорость_добавления объема умноженной на остаток объема ?

В этой всей штуке мне непонятен только один момент: это пессимистичная , реалистичная или оптимистичная дата?

Так как
1. В расчетной скорости добавления объема учитывается негативный прогноз на рост с той же скоростью. - тогда дата пессимистична
2. Буфер (ТОС) на другие риски здесь не учитывается. - вроде бы дата оптимистична.
3. В скорости реализации объему уже учтены все стандартные риски. - дата наиболее вероятная.

так что это тугрик получается?



cartmendum
Jan. 9th, 2014 07:31 pm (UTC)
Чую, надо делать отдельное бухтелово на этот счет.

Тут нет никакой даты, есть ее функция плотности распределения вероятности.
sbase
Jan. 9th, 2014 11:37 pm (UTC)
хм.. понятно.

буду думать.
cartmendum
Jan. 10th, 2014 02:54 pm (UTC)
сложно? Самое главное, это отойти от точки и начать мыслить распределениями. Любая дата может оказаться датой поставки - весь вопрос в вероятности.
sbase
Jan. 10th, 2014 06:23 pm (UTC)
не то чтобы сложно. просто я обычно мыслю диапазоном:
- оптимистичная оценка
- пессимистичная оценка
- наиболее вероятная дата поставки.

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

а две/три оценки однозначно расставляют границы.


(no subject) - cartmendum - Jan. 10th, 2014 07:09 pm (UTC) - Expand
(no subject) - sbase - Jan. 10th, 2014 09:19 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 10th, 2014 09:23 pm (UTC) - Expand
(no subject) - sbase - Jan. 10th, 2014 09:58 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 10th, 2014 10:09 pm (UTC) - Expand
(no subject) - sbase - Jan. 10th, 2014 10:56 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 11th, 2014 08:47 pm (UTC) - Expand
(no subject) - sbase - Jan. 12th, 2014 01:26 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 12th, 2014 10:11 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 10th, 2014 09:24 pm (UTC) - Expand
(no subject) - sbase - Jan. 10th, 2014 10:15 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 11th, 2014 08:18 pm (UTC) - Expand
(no subject) - sbase - Jan. 12th, 2014 01:47 pm (UTC) - Expand
(no subject) - cartmendum - Jan. 12th, 2014 10:12 pm (UTC) - Expand
(no subject) - sbase - Jan. 12th, 2014 11:50 pm (UTC) - Expand
( 31 comments — Leave a comment )