AXForum  
Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.04.2014, 21:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
Leon's CRM Musings: Treating Bug Management Like a Flow Problem
Источник: http://leontribe.blogspot.com/2014/0...like-flow.html
==============

At the moment I am managing the bugs for a project. I am responsible for triaging the bugs, allocating them to the right resource and generally making sure they get attended to.

One interesting aspect of this process is trying to predict when the bugs will be completed. The issue reminds me of the flow problems I used to work on in my physics days.

A Simple Bug Model

In this project, all bugs are in one of three states:

  • Active: The bug is not fixed
  • Resolved: The bug has been fixed and is ready for testing
  • Closed: The bug has been tested and found to be fixed
The client creates active bugs, the consultant resolves bugs and the client closes bugs.

The Physics of Bugs

The problem reminds me of a flow problem with sinks and sources. In this case our source is the inflow of new bugs and our sink is the bucket of closed bugs. The resolved state is like a leaky bucket with bugs flowing in from the active state and flowing out through a hole to the closed state.



The Maths of Flow Systems

Flow systems have rules of conservation. For us the rules are:

  • New bugs can only enter into the Active bucket
  • Bugs cannot be destroyed
  • All bugs eventually end up in the Closed bucket
Source and Sink Rates

Here are some mocked up data to see how we can apply our model to the bugs.

Date Active Resolved Closed Total 2014/03/17 25 11 6 42 2014/03/18 23 15 7 45 2014/03/20 21 18 7 46 2014/04/02 24 20 14 58 2014/04/04 22 25 16 63 2014/04/07 20 27 16 63 2014/04/09 11 34 20 65 2014/04/10 10 38 21 69 The data, in itself, is hard to gain insight from but the rates are a little more telling.

For us, we will look at the average flows over time. Firstly, the source and the sink rates.

  • Average Bug Creation Rate = (69-42)/24 = 1.125 bugs/day (source rate)
  • Average Close Rate = (21-6)/24 = 0.625 bugs/day (sink rate)
Here I have taken the difference in days, but you can also use ‘working days’ if this suits better.

This immediately tells us that bugs are being created faster than they are being closed. Therefore, if things remain the same, the bugs will never be finished. Let us revisit this a bit later.

Resolution Rate

All Active bugs must go to either Resolved or Closed so, with this information we can calculate the rate at which bugs are leaving the Active bucket i.e. the rate of Resolution

Rate of Leaving the Active Bucket = (59-17)/24 = 1.75 bugs/day

So we now have the

  • Rate of Bug Creation (1.125 bugs/day)
  • Rate of Resolution (1.75 bugs/day)
  • Rate of Closure (0.625 bugs/day)
What the Rates Tell Us

In the bug-fixing stage of a project, there is always pressure to get bugs closed. Often project payments are contingent on critical bugs being closed. Go-live dates put pressure on client and consultant alike to get the bug-fixing job finished.

Firstly, as we noted before, the Rate of Bug Creation is greater than the Rate of Closure. Bugs are flowing into the system faster than they are ending up in the Closed bucket. This means, if things continue as they are, there will always be Active and Resolved bugs in the system and they will continue to grow.

However, the Rate of Resolution is larger than the Rate of Bug Creation so the consultants are actioning the Active bugs but they are staying in the Resolved bucket with only a trickle into the Closed bucket. The consultants are doing what they can but the client is dragging the chain on closure. This is excellent information for a project manager to know, who may be negotiating the situation with the client or having to report to their bosses on why the project is getting delayed.

Conclusions

The model employed here is quite a simple one. For example, if the client does not accept a Resolution, the bug will return to Active, but it provides a foundation for analysing bugs through rates of change and gaining insights which otherwise may not be apparent. Other extensions of this model may be rates of change of the flow. For example, it is reasonable to expect the rate of bug creation to taper to zero as testers run out of things to test, that is, the rate of bug creation will decelerate over time. This can be calculated and fed into the model for greater accuracy.

See how you go and, if like above, you find out that there is more to the picture than too many bugs and not enough action, your team will thank you for it. Good luck.



Источник: http://leontribe.blogspot.com/2014/0...like-flow.html
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 15 Blog bot Dynamics CRM: Blogs 1 10.02.2016 10:26
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 16 Blog bot Dynamics CRM: Blogs 0 23.01.2014 03:15
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 14 Blog bot Dynamics CRM: Blogs 0 12.07.2013 07:13
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 13 Blog bot Dynamics CRM: Blogs 0 27.03.2013 22:12
crminthefield: Podcast and Overview: Microsoft Dynamics CRM 2011 Update Rollup 10 Blog bot Dynamics CRM: Blogs 0 17.08.2012 03:27
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:32.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.