写在前面
最近看了一本书《团队软件过程》。
本来是想研究下这个过程的原理之类的内容，后来被其中的一些度量指标吸引了。
合上这本书，我觉得对于我来说，收获最大的就是了解到原来除了我们耳熟能详的缺陷率，Reopen率等等外，还有那么多的可以使用的度量指标。
在讲这些指标之前，我想先说一下《团队软件过程》到底介绍了一种什么过程。
TSPi
为研究生或高年级本科生的团队软件工程课程而设计的框架。
指导学生一步步的完成团队软件项目课程，并教会你如何在团队协作环境中应用成熟的软件工程和软件过程。
我不禁有些感慨，现在的学校都已经开始做这种实操的练习了。
其实这样挺好的，让学生亲身经历整个项目过程以及各种角色，会有更多的体会。
研究了下TSPi是TSP的简化版本，专门为了培训和软件工程而定制的。
麻雀虽小，五脏俱全。
TSPi在过程中通过周期性的迭代的方式开展工作，每个周期包含完整的计划、设计、开发、测试、总结。
但是因为选择的策略不同，可以是在瀑布的大过程中嵌套小周期迭代，也可以纯迭代。
我觉得这也是TSPi与敏捷过程的一个不同之处。
另外一个不同之处在于，TSPi很强调度量和评估。
不仅要在每个周期进行度量和评估，还要对包括角色、质量、规模等等方面进行评估。
所以在TSPi中给了很多的量表，很有CMMI的意思。
书中提到了很多度量的指标，我这里摘取其中几个我觉得比较有意思，也比较实用的分享给大家。
概要比率
这个指标包含了三个子指标，主要用于度量团队的贡献情况。
LOC/小时：度量了团队的总体生效率
每小时写多少行代码，这个指标非常常见。
复用百分比：当前产品中复用以前产品的LOC比例
在TSPi中很强调代码复用，甚至提到“在设计初期就对复用部分进行设计”。
复用率高，表示被复用的代码的质量等各方面的绩效不错，也间接的说明了在这个周期内的产出质量有一定的保证。
新增可复用百分比：新增的代码中可以作为未来周期及项目的复用代码的比例
我们不仅要在开发的时候尽量复用之前稳定的代码，还需要创造一些可以被复用的代码。
这些代码不仅在本项目中可以复用，还可以被复用到其他项目中去。
缺陷数/KLOC
千行代码缺陷数，这是一个重要的质量指标。
这个指标没什么好说的，主要是作者在这个指标后面的一句话，引起了我的思考
如果单元测试有很多缺陷，单元测试后遗留的缺陷也会很多。
也就是说，如果单元测试发现很多的缺陷，那就意味着有点先天不足的意思。
就算后期再怎么修补，也无法摆脱先天不足的劣势。
而在每个周期里面对这个指标进行评估，就大致可以知道在后面的阶段中的质量情况。
如果构建和集成测试的缺陷数/KLOC<0.5，系统测试的缺陷数/KLOC<0.2，那么一般不会有用户使用缺陷。
一个周期内的阶段时间
TSPi强调在一个周期内要把所有任务重复一遍，它也给出了各个阶段任务的大致时间比例，可以作为参考。
如果评审时间达标，其实会对质量有一点的改善作用。
即会避免在单元测试的时候发现过多的缺陷，进而避免先天不足的情况发生。
详细设计时间>编码时间
详细设计评审时间>详细设计时间50%
需求评审>需求分析时间25%
规模度量
对于项目规模的度量，我们一般会使用模块、LOC、敏捷中的点数进行度量。
而作者提出了一种度量方式，挺有意思的：需求规格说明书SRS，PRD。
通过文本页数，编号段落或者Shall语句进行规模度量。
我觉得这个指标对于BA和需求的小伙伴来说要求比较高。
因为毕竟现在80%以上的SRS等文档并没有进行规范化、格式化。
编写的粒度、范围、结构等等都没有进行规范化。
比如同样的一个功能，我写的粗了就只有2页，写的细了可能会有8页。
再比如，我们在写需求的时候并没有建立结构需求语句。
所谓结构需求语句，耳熟能详的就是敏捷里面的AS... I want to... so that...
而这边并不是写一句话的user story那么简单。
为了度量规模，需要写的是更详细的规格。
比如，Admin shall add new users by import excel.
统计整个SRS中出现了多少shall语句，就可以度量规模。
但是，前提是，你的语句写的足够规范。
如果我一时脑抽，写了个 want, need, should, will, can, is able to...那么度量的结果肯定不准了。
写在最后
前些天还和群里的小伙伴讨论软件团队的绩效评估问题。
其实我觉得《团队软件过程》中有一句话说的很在理：
团队度量不应该以是否实现了目标为标准，而应该以设定目标的意愿以及为此所做出的努力程度来评价团队。
小婧是一名行走在实践路上的资深业务分析师。
网友评论