Monthly Archives: October 2012

TFS Burndown and Burn Rate report

Те, кто использует TFS в качестве issue tracker, наверняка знают, что он предоставляет богатые возможности для построения отчетов. С ним также поставляется несколько предустановленных отчетов. И наиболее популярный из них – это, пожалуй, отчет Burndown and burn rate, показывающий прогресс по «сжиганию работы».

Выглядит он примерно так:

Большой график сверху – это burndown chart. По горизонтали календарные дни, по вертикали обычно выводят объем работ в часах, хотя можно показать и количество рабочих элементов (задач) вместо часов. Синяя зона – оставшаяся (remaining) работа, зеленая – выполненная (completed) работа. Две прямых линии: черная – идеальный тренд, красная – актуальный тренд.

Идеальный тренд строится от уровня remaining work на момент начала периода, до нуля в конце периода.

Как строится актуальный тренд?.. Я честно пытался понять expression, который это вычисляет, но упёрся в итоге в вызов магической функции “Code.Burndown”. Однако мои наблюдения показывают, что это линейная регрессия значений remaining work за предыдущие дни.

Этот график конечно красивый, на большом экране смотрится круто, но информативность его страдает.

Во-первых, он не учитывает выходные. Поэтому при двухнедельных итерациях в пятницу первой недели вечером burndown показывает, что всё замечательно, а в понедельник утром – уже всё плохо. Чтобы понять, что собственно происходит, иногда приходится делать скриншот и в Paint’е вырезать выходные J

Во-вторых, любые резкие изменения scope работ в ходе итерации делают график неинформативным. Например, если в первый день итерации не успели запланировать всю работу, и допланировали во вторник, burndown может выглядеть так:

А если в первый день перепланировали, а на второй день часть работ выкинули из итерации, burndown может выглядеть так:

В результате линии трэнда уже ничего не говорят, да и линии remaining/completed work уже не столь хорошо показывают, насколько всё плохо.

Снизу слева виден скромный график Burn Rate, который показывает два значения: Actual hours/day, Required hours/day. И вот этот график, хоть и не так красив на большом экране, но гораздо информативней. Просто смотрим на эти два числа, и сравниваем. Actual больше чем required – хорошо, высока вероятность успеть сделать всё задуманное. Actual меньше – всё плохо, придётся перепланировать, выкидывать наименее нужное с итерации.

Считаются эти значения просто. Для Actual hours/day берется объем всей выполненной за период работы, и делится на количество прошедших рабочих дней. Для Required – объем всей оставшейся работы делится на количество оставшихся рабочих дней.

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

А т.к. в расчете не участвуют значения remaining work за прошедшие дни, то перепланирование объема работ во время итерации не ломает показатели.

Хотя и у этого графика есть один неприятный нюанс. Actual hours – это часы, реально потраченные на выполнение задач. А Required hours – часы, планируемые. И поэтому здесь отражаются ошибки планирования. Но если обычно у вас задачи реально выполняются дольше плана, то при совпадении на графике показателей Actual и Required на самом деле всё плохо. Значит, при анализе этого графика нужно держать в уме среднюю ошибку оценки.

А знаете ли вы еще какие-то метрики или отчеты, позволяющие понять статус итерации?

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Итерации и релизы

Agile методологии, как правило, предполагают итеративную разработку. Что это значит?

Это конечно не эджайлисты придумали. Термин существует еще с мохнатых 60-х годов (http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf).

Основная идея уже тогда была в том, что waterfall – это плохо, и нужно строить систему по чуть-чуть, итеративно, на каждой итерации проверяя, что строим правильного зверя. Валидировать. И учиться.

In 1975, Vic Basili and Joe Turner published a paper about iterative enhancement that clearly described classic IID:

“The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made along with adding new functional capabilities.”

Замечательно. Когда в обществе витает здоровое недоверие к секте agile – приятно осознавать, что бородатые инженеры NASA еще полвека назад думали примерно так же.

Идём дальше. Откуда итерации взялись в Agile? Видимо из вот этих принципов Agile Manifesto (http://agilemanifesto.org/principles.html):

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Важно отгружать продукт почаще, чтобы удовлетворить клиента. Другие пункты манифеста, на мой взгляд, прямо не влияют на решение делать разработку итеративной.

Из этого (и из здравого смысла) можно сделать вывод, что итерации полезно было бы совместить с релизами. Зачем нам итерация, в конце которой нет delivery? Такая итерация гораздо менее полезна для валидации функционала и для обучения, да и клиенту такая итерация совершенно неинтересна. Если релизить каждую итерацию – то итеративная разработка обретает смысл.

Дальше возникает вопрос, а как часто нужно релизить? И здесь, наверное, ответ нужно искать в разрезе денег.

С одной стороны, чем реже релизы, тем ниже затраты, как у разработчика, так и у клиента. С другой стороны, и разработчику, и клиенту могут быть выгодны частые релизы.

Сравним две ситуации (цифры приведены условные, сильно не смейтесь).

Ситуация A. Компания-разработчик делает 1 релиз за месяц, релиз сразу же внедряется у клиента.

Затраты на ручное тестирование релиза и на выпуск – 2000 долларов.

Затраты клиента на внедрение новой версии – 15000 долларов (сюда входит upgrade лицензии на продукт, работы по upgrade ПО, переобучение пользователей и админов и т.п.).

Ситуация B. Компания-разработчик делает 2 релиза за месяц, релизы сразу же внедряются у клиента.

Затраты на ручное тестирование релизов и на выпуск – 2 * 2000 = 4000 долларов.

Затраты клиента на внедрение – 2 * 15000 долларов (на самом деле меньше наверное, но для простоты модели пусть будет так).

По сравнению с ситуацией A, в этом случае клиент на две недели раньше получает очень нужный ему функционал, который позволяет ему снизить издержки одного из своих подразделений на 30000 долларов.

А разработчик имеет возможность на 2 недели раньше провалидировать этот функционал. Какова ценность этого факта, выраженная в долларах? Допустим, это позволит скорректировать планы на вторую половину месяца, выкинув половину работ, оказавшихся ненужными, а значит сэкономить на разработке 10000 долларов.

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

Нужно найти правильный баланс. И постепенно сдвигать его в правильную сторону, снижая затраты на выпуск. Ведь если выпуск будет бесплатным, то можно хоть трижды в день релизиться, и всем будет счастье :)

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/