这篇文章写的比较杂乱，思路不是很清晰。这本书的内容大多数讲怎么计算程序员的表现，和体育比赛的运动员记录相比较。个人感觉这个书如果给项目经理读或者人事读会有更多的感想。我仅仅是大概领略下里面的方法，并且把自己认为比较有用的知识摘录出来。一简单的成功团队模式模式1有一个无怨无悔的做琐事的人模式2一到两个牛人提高了整个团队的水平，虽然牛人并没有相应的头衔模式3常在创业小团队出现，项目在80%的时候撞墙。能生存下来的团队里面总有个人能够鼓舞士气。二作者的一个团队，软件从版本1到本部1.1用了6个月。并且没有加入任何新的功能。从1.1到2.0只用了9个月，期间还有很多功能增强。团队的主要变化是原来团队离开了两个特别依赖别人的程序员，新加入的程序员可以自己工作，自己找出软件的bug所在。所以作者认为一个团队要有各种能力的人，才能成功。三评价数据统计的离群点和异常点，，都表现为不在正常的范围内，如工作量迅速下降。也可能是不可解释的点,如某人学历背景不好，但是工作效率奇高。异常点可能是偶然事件导致如身体不适。可以忽视。离群点则可能表面上市异类，是打破常规的人。忽视离群点会限制我们对成功模型的理解，如黑天鹅效应。四峰值和谷值代表着周期五在学则统计项目的时候要意识到1统计的项目有局限性，很多有用的项目没有被统计。2统计的值与预期不一样。比如作者发现这样一个现象。团队里的人经常被售后，技术支持的人打扰项目质量反而提高，这与普通认为的程序员不该被打扰相反。六统计项目选择的标准1数据容易获得2容易让非程序员理解。这样便于管理，人力等交流七如何评价程序员。这里我们可以看做是如何培养自己的能力1核心职责表现2代码测试质量3能覆盖多少领域4主动解决自己的问题。主动指出他人的问题5创新6处理压力7逆境8与他人互动9领导力，支持队友，指导他人的能力10对项目的理解和接受团队角色的能力八团队的评价标准1用户对新版本的反应。如新版本的采用率2与竞争对手软件比较如何3质量4新版本交付率九作者在讲团队的时候举了一个例子。两个团队，一个团队组建的时候成员背景都很好，并且互相认识。二另一个团队的背景不是十分优秀，人也是临时组建的。但是后一个团队取得了成功，前一个团队失败了。作者有几点收获1成功的团队复杂任务集中在少量人手里。其他程序员承担数量多但是不难的工作。失败的团队差不多每个人工作负载类似，平均复杂度高。2成功团队每个人工作在多个领域。失败团队每个人工作在很小的领域3成功团队的人创新，也主动。
生活会变成什么样子?正因为时光流逝一去不复返，
