For software developers, one of the most-debated and maybe even most-hated questions is “…and how long will it take?”. I’ve experienced those discussions myself, which oftentimes lacked precise information on the requirements. What I’ve learned is: If only sparse information is available, a reliable estimate is almost impossible. To make matters worse, developers found themselves under pressure after having issued a wild guess and then requiring more time.

对于软件开发人员而言，最受争议甚至最讨厌的问题之一是“……需要多长时间？”。 我自己经历了这些讨论，而这些讨论通常缺少有关要求的准确信息。 我了解到的是：如果只有稀疏信息可用，那么几乎不可能进行可靠的估计。 更糟糕的是，开发人员在做出了疯狂的猜测之后发现自己处于压力之下，然后需要更多的时间。

体验另一面 (Experiencing the other side)

As I started working in direct contact with customers, I’ve (reluctantly) realized that the collaboration oftentimes benefits from providing a schedule. In my experience, time becomes an important factor when customers have plans and projects on their own which can’t continue without knowing when a missing piece arrives.

当我开始与客户直接联系时，我(很不情愿地)意识到，协作通常可以从提供计划中受益。 根据我的经验，当客户自己制定计划和项目时，时间变得很重要，而计划和项目无法不知道丢失的零件何时到达。

相互理解(业务理解) (Understanding each other (Business Understanding))

In the end, this comes down to a simple problem: “How can managers and developers work together on a project and get what they, respectively, need?”. For those who interact with a customer, this means that they need the information (estimates) to make the collaboration go smoothly. In turn, developers need accurate requirements and some flexibility has to be respected as well.

最后，这归结为一个简单的问题：“管理人员和开发人员如何才能共同完成一个项目，并分别获得他们需要的东西？”。 对于那些与客户互动的人来说，这意味着他们需要信息(估算)来使协作顺利进行。 反过来，开发人员需要准确的要求，并且还必须尊重一些灵活性。

学习！ (Learn!)

With that in mind, I’ve decided to use a data-science-driven approach to gain insights into the estimation problem. You can find the code that I used and more detailed technical explanations in my github repository. What I wanted to know, was:

考虑到这一点，我决定使用数据科学驱动的方法来深入了解估计问题。 您可以在github存储库中找到我使用的代码以及更详细的技术说明。 我想知道的是：

1. As a baseline reference, what are the average times that a “New Feature”, “Bug” (etc) spends in implementation (i.e. status “in progress”)?作为基准参考，“新功能”，“错误”(等)在实施(即状态“进行中”)上花费的平均时间是多少？
2. Is it possible to estimate the time spent “in progress” from analyzing the text in the summary and description of a ticket?是否可以通过分析票证摘要和说明中的文本来估计“进行中”所花费的时间？
3. Which words in the description make up for large / small durations?说明中的哪些词组成了较长/较短的持续时间？

数据理解 (Data Understanding)

As data, I gathered around 20.000 tickets from the RTFACT-repository of the JFrog open source project. For all tickets, the following is available: Issuetype (i.e. “Bug”, “New Feature”), summary, description, time spent “in progress”. Some initial data exploration showed, that out of all the tickets, only 10% (2258) have a nonzero “in progress”-time. All the others have not been worked at or they were never put in that status.

作为数据，我从JFrog开源项目的RTFACT存储库中收集了大约20.000张票证。 对于所有票证，以下内容可用：发行类型(即“错误”，“新功能”)，摘要，描述，“进行中”所花费的时间。 一些初步的数据研究表明，在所有故障单中，只有10％(2258)的“进行中”时间为非零。 所有其他人都没有工作过，或者从未处于这种状态。

To get a feeling for the data, I checked the counts of tickets by their issuetype. And as you can see in the next image, there is a large variation in the types with the highest count being Bugs.

为了了解数据，我按票证发行类型检查了票数。 正如您在下一张图片中看到的那样，类型之间的差异很大，其中错误最多。

准备数据 (Prepare Data)

As a first cleaning step, I only kept entries with a non-zero “in progress”-time and removed outliers (outside of the 96%-quantile). Now, keep in mind that statistical models can only understand numbers, not text. To translate between strings of characters, I computed TFIDF text analysis features. These are a way of numerically representing the occurrence and importance of certain words in a text document.

作为第一步清理，我只保留“进行中”时间为非零的条目，并删除了异常值(在96％的位数之外)。 现在，请记住，统计模型只能理解数字，而不能理解文本。 为了在字符串之间进行翻译，我计算了TFIDF文本分析功能。 这是一种数字表示文本文档中某些单词的出现和重要性的方法。

资料建模 (Data Modeling)

A powerful and insightful model for analyzing data are decision trees / random forests. One branch of that type of model are gradient boosted trees. These are my model of choice due to their performance (won several Kaggle competitions) and their interpretability. This mainly means, that we can draw further insight from the decisions made in the trees.

决策树/随机森林是分析数据的强大而有见地的模型。 这种模型的一个分支是梯度增强树 。 由于它们的表现(赢得了几次Kaggle比赛)和可解释性，这些是我选择的模型。 这主要意味着，我们可以从树中做出的决策中获得更多的见解。

评估结果 (Evaluate the Results)

So, the first question asked regarded a baseline for the duration of a ticket. As you can see in the next image, the mean duration spans between ~10h and ~100h. Note, that the standard deviation is very large (~50 or higher), which calls for additional estimation information through e.g. the boosted trees.

因此，首先要问的问题是机票期限的基准。 如下图所示，平均持续时间介于〜10h和〜100h之间。 请注意，标准偏差非常大(〜50或更高)，这需要通过增强树等其他估算信息。

For the trees, the performance is good (and can be tuned to “great”) — on the training set. However, on the test set, the model generalized badly. This is, why I captioned this article by “early results”. As you can see in the next image, the ground truth (blue) deviates significantly from the estimated values (orange).

对于树木而言， 训练集上的表现很好(并且可以调整为“出色”)。 但是，在测试集上，该模型的推广效果很差。 这就是为什么我用“早期结果”为本文加上标题。 如您在下一张图片中所看到的，地面实况(蓝色)与估计值(橙色)明显不同。

I think it’s still interesting to take a look at the keywords contribute in a positive way (larger time “in progress”) or a negative way (smaller time “in progress”):

我认为，以积极的方式(较长的时间在“进行中”)或否定的方式(较短的时间在“进行中”)查看关键字贡献是很有趣的：

As you can see from the results, the issue types “Bug” and “New Feature” have the largest positive impact on the estimation. On the other end of the spectrum are the “error” and “com”, which have the largest negative impact on the estimation. For the top 15 words that cause the highest positive / negative impact, see the figure below.

从结果中可以看出，问题类型“错误”和“新功能”对估计的影响最大。 另一方面，“误差”和“ com”对估计的负面影响最大。 有关正面/负面影响最大的前15个字，请参见下图。

未来的工作 (Future Work)

What else needs to be done?

还有什么需要做的？

1. The dataset is not very large (the model had to be trained based on only ~2200 valid samples). The next step would be to find a ticket repository with a larger number of valid tickets.数据集不是很大(必须仅基于约2200个有效样本来训练模型)。 下一步将是查找具有大量有效票证的票证存储库。

2. instead of only estimating the implementation time (time “in progress”), the cycle time is possibly as well interesting to know

   不仅可以估计实施时间(“进行中”的时间 )，还可以了解周期时间

3. Is it possible to estimate (classify) the ‘resolution’ (Fixed, Duplicate, Won’t Fix, …) of a ticket?是否可以估计(分类)票证的“解决方案”(固定，重复，无法解决……)？

谢谢 (Thanks)

This was my first article on medium! Thanks a lot for taking the time. If you have any feedback or insights that you’d like to share: I’d be glad to get some feedback.

这是我关于媒体的第一篇文章！ 非常感谢您抽出宝贵的时间。 如果您想分享任何反馈或见解：很高兴获得一些反馈。