提问回顾

之前提出的问题

对软工课刚开始时自己问题的回答

1. 《构建之法》3.1节提到，花多少时间可以作为衡量一个软件开发的工作量的因素，即一组人的工作量可以用“人数 x 时间”来表示，而《人月神话》一书则是反对这种衡量标准的，请问实际项目中这样的标准实用吗？
   这种标准对于个人或小团队开发来说是适用的。由于团队中人数越少，信息传递就越直接，不会造成在信息传递上产生额外的工作量，保证了大部分工作量集中在作业上。《人月神话》中反对“人月”标准的基本假设是大规模团队，故可见这个标准适用与否是视团队规模而定的。

2. 3.1节讲的是个人能力的衡量与发展，请问代码量与个人的编码能力有直接关系吗？
   从熟能生巧这种万金油观点来说，回答是肯定的。而以我本人的经验来分析，回答也是肯定的。代码量理论上与上机时间呈正相关，我个人认为程序员都是长脑子的生物，没有程序员会在长时间编码后不对对编码这项工作产生自己的理解。有了自己的理解意味着你就拥有了之前不曾拥有或者别人尚未拥有的东西。从这个意义上讲，编码能力是肯定提高了的。

3. 第4章花了很多篇幅讲结对编程，请问结对编程在实际项目中真的十分高效吗？是否有很广的适用性？
   其实我在提出这个问题后，也去某乎上搜了一下相似问题的回答（链接在此），结果大致是中国普遍不流行结对编程，而是否高效则需视情况而定。在尝试了标准的结对编程过后，我认为某乎上的那些说法还是挺有道理的。先说说结对编程的优势：结对编程的角色互换方式让两人不会陷入疲劳状态，又能很好的抓住一些以一个人视角所看不到的问题，还能进行复审，实现了某种意义上的多线程处理；而结对编程的局限性也很明显，如缺乏独立的复审，无法发现两人认知中共同的盲区，再如结对编程无法发挥个人的特点，若两人水平相差较大将造成时间的浪费，这一点也是我结对编程中的亲身体会（当然我是那个编码水平低的一方）。

4. 9.6节讨论了风险管理，阐述了风险发生的情况和一些解决办法，请问能否提供真实的成功的风险管理案例？
   本学期参与的项目规模较小，还未达到需要使用风险管理的条件。

5. 17.4节提到了有些人就是难以为团队做出贡献，反而还添乱，似乎是本性难移的。我认为素质的缺陷可以通过制度来弥补。面对这样的成员，是否能通过制定完善的规则去约束他，从而让他做得更好？如果能，能否提供一个成功的例子？
   这个问题其实是一个管理学问题，由于并没有遇到这样难以应对的队友，所以我也没积累到处理类似问题的实际经验，只能纯粹靠YY来提供一个可能的解决方案。
   首先，团队需要制定一个共同认可的规章制度，明确在开发过程中出现何种情况进行奖励，何种情况进行处罚，奖励与处罚的程度也要细化，让团队成员有所追求又有所敬畏。
   其次，团队需要有合理与公开的绩效评分方式，让所有成员能看到自己与其他成员的贡献度，有所对比，提升大家竞争意识的同时间接处罚偷懒者。
   最后，PM需要拿出个人的领导能力，对那些“本性难移”的成员进行心理战，必要时对他进行善意的恐吓，这样的恐吓不能针对人格，但一定要起到震慑作用。这种能力是领导者必不可少的一项技能，因为只有对偷懒者严厉，才是对其他成员的公平，团队才会有凝聚力。

学到的知识点

需求部分

需求分为两部分，一部分是用户提供的需求，另一部分是用户自己未发现，而又对他们很重要的需求。

设计部分

设计需要划分粒度，有整体设计与局部设计的区别。整体设计得要抽象，把握着整个项目的结构；局部设计则需具体，尽量保证能够涵盖功能的细节。另外模块化设计是很重要的一个思想，在设计阶段千万不可忘了它，否则后期为项目的结构调整所付出的代价将不可估量。

实现部分

实现过程严格按照规范走，乐于学习新技术。然后早睡早起，避免秃顶。

测试部分

与开发紧密关联，避免责任推卸。

发布部分

完善发布宣传与用户体验优化，初始用户是产品的贵人。

维护部分

积极保持与用户的联系，收集反馈，不断完善产品。（雾