时间跟踪并非完全是火箭科学，但是在3CS，我们发现正确地掌握一些小细节可以使事情顺利进行。
1.时间表是给客户的
我们记录时间的原因有很多，但最重要的是与客户沟通完成了哪些工作以及如何花钱。
在我们的时间跟踪系统（小时）中记录的所有内容最终都对客户可见，因为我们的时间表（经过审核过程）通常附在发票上。
虽然并非每个客户都阅读每张发票上的每个订单项，但我们的工作是基于他们可能会做的，我们也不希望由于发票时间缺乏透明度或沟通不畅而使出色的工作失望。
2.将时间条目保留在一项任务中，并且在2小时内
通常，我们尝试将时间条目（时间表上的各个订单项）限制为一项主要任务，并且持续时间不得超过两个小时 。
我们发现这有助于为客户提供有意义的细节和透明度，并希望防止在我们的时间记录实践中形成任何不公平和不准确的看法（例如，填充，猜测，懒惰等）
一切都取决于建立和维护与客户的信任-特别是相关性，因为我们的大部分工作都是在现场进行的。
这也意味着，在极少数情况下查询发票的情况下，我们会有可靠且可辩护的审计记录，我们可以在该记录中回顾我们的记录，并精确地指出完成的时间，完成的时间以及花费的时间。
在我们整天或大部分时间只完成一项任务的日子里，只需运用常识并将事情分解成更小的部分即可。 我们发现，定期记录时间会有所帮助（即，当您休息一下或吃午饭时），而不是等到一天结束时记忆会变得有些模糊。
不必担心时间条目与JIRA的工单或任务（或其他项目管理工具）具有一对一的关系。 多次输入一个票证项目是完美的选择。
有时候，两个任务是交织在一起的（例如，确定问题，进行初步修复，测试和迭代直到完成完整修复）。 可以将它们组合在一起，尤其是如果整个任务（研究，解决，测试）少于2小时。 如果时间超过2小时，我们将通过提供不同调查途径的高级描述来分解任务（例如，“探讨使用NHibernate代替Entity Framework进行数据层解决问题的可能性[x] ”，“考虑替换默认的Entity Framework服务层以解决问题[x]”）。
例子：
这不是一个很好的示例，其中整天只有一个订单项：
稍微好一点但仍然不是很好的示例，其中整天只有一个订单项：
这是一个更好的示例 ，其中将相同的大型任务在两个小时内分解为较小的任务：
3.使描述非技术性
我们不引用类名称，方法名称，解决方案文件名称或客户端不合理知道的其他任何名称。
可以提供技术细节，但是我们尝试以客户熟悉的水平来描述它-例如，页面或控件（如果与前端相关），或者相关功能区域（如果与后端相关）。
例子：
这不是一个很好的例子，描述太技术性了：
这是一个更好的示例，说明的技术性较低：
3.提供描述上下文
最后， 任务描述应具有适当的上下文，以便有可能 告诉他们与什么有关。
虽然我们不需要冗长的“战争与和平”任务描述，但我们需要足够的信息来确定什么是任务以及为什么执行任务。 请记住，我们或客户经常在事后几天，几周或几个月回头看这些任务。
例如，在举行会议时，我们应该注意会议的种类，为什么要举行会议以及潜在的参加者。
例子：
这不是一个很好的示例，其中的描述过于笼统：
这是一个更好的示例，其中的描述告诉我们会议的目的：
最后一句话…
这份清单绝不是详尽无遗的，我们会随着时间的推移不断增加。它也不是一成不变的，因此，如果您有新想法或不同想法，请告诉我们。
