第十四章

15.3.1 有些成功人士或公司认为不需要独立的测试角色（Test），你怎么看？

      在一些软件公司中，QA的工作中包含了Test的角色，负责验证程序是否符合预先设计的功能和特性。但是QA的工作量是很多的，一个好的QA不仅需要对程序架构有着很好的理解，对程序功能和性能都有着较深的理解，并且要对测试工程了如指掌，如测试用例、MTTF等很多方面。

如果QA人员能够很好地完成工作，是可以的，但是细化分工能够使得每个人专于一部分，更好地提升团队效率。

15.3.2 为什么一些成功的公司不用测试人员

一些成功的公司中，软件开发人员的个人能力很强，能够保证自身代码的有效性。但是这要求开发人员充分信任自己的代码，并且自己对代码进行了很详尽的测试。

但是如果开发人员不能有效测试代码，或者不愿意测试代码，那么需要测试人员来进行这项工作。

15.3.3 微软是怎么做的呢？

微软的开发测试只要有三种角色：

SDE：Software Design Engineer，简称dev。

SDE/T：Software Design Engineer in Test，也写代码，但是重点在测试。

STE：Software Test Engineer。

15.3.4 团队应该如何安排QA 和测试工作

QA是质量保证，是对软件制作过程中的制作质量进行管理，强调控制和评估。软件测试是对软件产品的质量本身进行测试，是从技术方面出发测试软件质量，属于Life cycle的一部分，更准确的说法应该是QC。。

在工作安排上，测试关注的更多是被测对象上线前的质量，而QA关注的是宏观意义上的质量，包括开发环节的质量控制（如何提高代码本身质量）、测试环节、上线环节以及运维环节（如线上出现问题后如何快速止损），甚至还包括用那种开发模式能更有效的提升项目开发质量和效率，因而是一个更宽泛的领域。

15.3.5  测试人员的职业发展

查阅一些资料，测试人员的职业发展可以分为以下几个阶段：

初级测试工程师

　　刚入门的拥有科学学位的个人或具有一些手工测试经验的个人。开发测试脚本并开始熟悉测试生存周期和测试技术。

测试工程师/程序分析员

　　具有1-2年经验的测试工程师或程序员。编写自动测试脚本程序并担任测试编程初期的领导工作。进一步拓展编程语言、操作系统、网络与数据库方面的技能。

高级测试工程师/程序分析员

　　具有3-4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级的评审，并为其它初级的测试工程师或程序员充当顾问。继续拓展编程语言、操作系统、网络与数据库方面的技能。

测试组负责人

　　具有4-6年经验的测试工程师或程序员。负责管理1至3名测试工程师或程序员。担负一些进度安排和工作规模/成本估算职责。更集中于技能方面。

测试/编程负责人

　　具有6-10年经验的测试工程师或。负责管理8至10名技术人员。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。开发一些特定领域的技术专长

测试/质量保证/开发(项目)、经理

　　具有10多年的工作经验。管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工

计划经理

　　具有15年以上开发与支持(测试/质量保证)活动方面的经验。管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

个人观点是，在入行前，即工作前的1年时间内，选择一个大的入门方向；入行后的3~12个月，应该学习基本知识，如黑盒、白盒、自动化测试、测试工具等技能，培养测试、质量和项目管理的经验；入行后3~5年，根据选定方向，提升自己技能，根据管理或技术方向尽量做到全面、熟练；在入行5~10内，提升自己宏观把握能力，考虑长远的发展计划。

15.4 如何衡量软件工程的质量

除却邹老师提出的这些观点，我认为还可以从以下这些方面衡量代码：

1. 设计/开发约束：在软件开发过程中，许多设计约束和准则对于代码的可维护性和可读性都至关重要；
2. 环路复杂度：对于代码实现和执行过程中，不同方法的环路复杂度不同；
3. Bug的严重程度与数量：不同的Bug的严重程度不同，我们能够允许小Bug或小异常的出现，但是对于严重的Bug则属于不可原谅的。

                                                                                                 第十五章

15.1  案例分析

根据书中的例子，推断出两个团队的血型：

STG游戏的跳票（为了完美，推迟了7天，但是7天之后也没有发布……）：O型或B型

英语学习软件（说了“明早发布”，但是明早一直没到）：O型

15.3.1  反动分子阿超

阿超的做法是可取的，因为在稳定阶段，不适合对整个项目进行大的修改或增加工作，可以先行发布一个Alpha版本，后续发布Beta版本、RC、RTM来不断完善。但是需要对后续版本的工作明确定义，不能只是简单的推脱工作。

15.3.2  银弹之战

我觉得是有一定作用的，因为首先简单的争论是会不容易上升到银弹程度的，而复杂的问题大家讨论很久可能还是谁也不能说服谁，所以银弹政策能够在讨论的基础上节省时间。

但是，做项目有一个原则是：如果不同意那么在拍板前一定坚决抗议，一旦决定就不要再提意见。

15.3.3 扁鹊三兄弟

分析丹佛机场行李系统：

项目需求：由于丹佛市原有机场能力有限，需要新建一个机场。新机场有3个中央大厅，2号中央大厅使用方“美国联合航空公司”委托“BAE公司”为其开发自动化行李处理系统。

对于这个项目，乙方估计时间为2年半内完成，一开始事情都很顺利。但是，丹佛市负责新机场建设的小组认为如果能够假设一个同时为3个中央大厅同时使用的集成自动化行李处理系统是一个很有意义的事情。因此，他们说服原航空公司自行建设的方案，转而由BAE公司建设整个机场的集成自动化行李处理系统。

BAE作为在领域内全球最为顶尖的公司，提出以下这些问题：

 * 缺少安装行李系统所需的足够空间 
　　 * 建筑结构无法承受行李系统所附加的重量 
　　 * 缺少行李处理系统所需的稳定的电力 
　　 * 缺少消除行李处理系统散发的热量的通风和空调设施 

为了解决这些问题，提出以下条件：

* 上述的风险都将被作为项目能否顺利完成的重要里程碑 
　　 * 超出预订日期之后的需求或设计变更不被接受，并且需求和设计需要有一段冻结期 
　　 * BAE公司在整个新机场的施工现场拥有最高的优先权，包括场地的占用、工作顺序的安排等 

虽然BAE公司从专业的角度意识到风险并且明确地提出来，但是由于项目任务过于庞大，影响因素太多，在先后经过PM辞职、需求变更频繁、首席工程师去世等事件，并不能按要求完成任务，从而引起了项目的失控。最终美联航承租的2号中央大厅，仍将由BAE公司建设自动化行李处理系统，大陆航空公司承租的1号中央大厅均使用传统的拖车系统。

通过分析整个事件，我们不难发现需求过多、系统过于庞大无疑是主要问题之一。众所周知，越庞大的项目需求就越复杂，不可控因素越多，也越容易失控。管理层的变动也是影响因素之一，因为一般情况下，失控项目最初是由项目团队发现的、甚至是管理层发现的。此外，过高的性能要求，如实时、大规模越来越称为影响项目的最终成功的问题；最终，大型的涉及到集成的应用，则越容易失控。

                                                                                                      第十六章

IT行业的创新 练习与讨论

16.6.1 VCD的创新

先行者如何把技术领先变为市场领先：

1.先行者善于发现机遇，把握机遇

2. 先行者在研发前进行了市场调研，了解消费者需求

3．先行者敢于投资

4. 先行者进行反复试验，反复研发

如果我是竞争者

1. 我会购买一台万燕VCD作为解剖样机

2. 在样机基础上进行进一步的研发与创新，发展更多功能

3. 多进行市场调研，把握消费者需求

16.6.2 BBS的创新

Stack Overflow之前是以程序开发为主题的论坛，如今Stack Overflow作为Stack Exchange network的子站，已经发展成为拥有43个主题讨论区的社区。

Stack Overflow成功的秘诀在于始终如一地推崇高质量的内容，并对服务进行意义明确的垂直划分。然后获得了许多贡献优质内容的用户，Stack Overflow也得以优化问答服务流程，这样，可以实现对少部分用户进行收费。和其他问答服务网站不同的是，Stack Overflow对用户提问进行严格筛选，淘汰那些容易产生主观答案或难以产生高质回答的问题，网络社区管理员和成员都能投票删掉那些不合适的提问或者对提问进行修改和完善。

16.6.3 《梦断代码》大目标和远景

作为创新参考

16.6.4 讨论微软公司Xbox Kinect的创新，它是如何满足玩家需求的，给微软公司带来了多少营收，对所在行业的影响如何。

它是一种3D体感摄影机，同时导入了即时动态捕捉、影像辨识、麦克风输入、语音辨识、社群互动等功能。玩家可以通过这项技术在游戏中开车、与其他玩家互动、通过互联网与其他Xbox玩家分享图片和信息等。

Xbox Kinect采用最新的计算机图像处理技术，实现人的动态扑捉，将人和游戏结合，并进行实时反馈使玩家身临其境。满足玩家的互动感和代入感需求，不需要通过输入设备，人的自身就是游戏输入设备，可以获得更直接的体验。

微软CEO 鲍尔默18日在旧金山举办的Web 2.0高峰会上指出，今年假期旺季微软将针对Kinect、XBox推出一系列的重要创新。微软表示，Xbox 360销售量市占率达42%，已连续第7个月高于40%。Xbox 360已多次成为全美最畅销的游戏机。微软指出，过去16个月当中Xbox 360有15个月是美国游戏机单月销售量冠军。

微软认为这种无遥控器式的系统将为电玩体验掀起革命。它同时表示人脸辨识功能将让电玩人物能够和玩家透过表情来沟通，因此游戏终将加入更多社交经验于内。

16.6.5 练习创新的招数

1.市场调研并分析客户以及潜在客户的进一步需求。

2.积极研发，进行技术创新。

3.对其进行新的设计，内部科技与外观双方面。

4.聘用更好的广告团队，采取更积极的宣传方式。

16.6.6 软件工程的技术和实践如何帮助创新

比如以结对编程的合作方式来双赢互惠，通过合作来提高共同的工作效率，获得更完美的工作成果。

16.6.7 创业-坚持前进的方向VS尝试更多新的想法

我在创业，但是市面上和我的朋友圈又流传更cool 的想法和创新。

作为创业者，我要深刻思考这些新的想法的创新对我的创业有没有帮助和促进。如果是有帮助的，那么就把他们的cool想法吸收进来，为我的事业发展更添一块砖。这个新的想法创新是对我的创业没有什么实质性帮助的，那么我还要坚定自己的研发道路，同时注意自己的研发过程会不会出现与这些新想法同类型的错误，这样不断自我反省，前进发展。

第十七章

人，绩效和职业道德

1比较不同团队的绩效评估方法，提出自己团队的绩效评估计划

案例中五个小组的绩效评估方法各有利弊，我们团队的绩效评估计划介于第一种和第五种之间，既分配好每个人应做的任务和责任，又要形成以重要成员为中心的明星效应，以此来评估团队绩效。

2. 在团队中会不会出现“劣币驱逐良币”的现象？

在团队合作中确实有可能会出现这种不好的现象，这就需要我们所有团队成员一起坚定不移地贯彻校训的思想：实事求是。一切从实际出发，用事实说话。

3. 讨论团队如何能让所有人都明确驱动和责任

在一个责任驱动型团队内部，所有成员的职责都很确定，分工明确。团队在完成工作时，表现出的就是分工协作，各司其职，团队气氛轻松和谐，很少或几乎没有内耗，是较高级的团队组织管理形态。

为了保持这种管理形态必须要坚持几点原则：

原则1 每个责任都有人负责；每个责任都只有一个人负责。团队承担的所有责任，应当都能找到具体负责的人，团队所有人承担的责任之和，就是团队在组织内部承担的责任。

原则2 权责利、义务、能力和岗位名称要匹配。权责利要统一很多人都知道，但是在责任驱动型团队中，强调的是权责利、义务、能力和岗位。

原则3 别人的责任，不要擅自去承担，团队应当做到每个成员都了解彼此承担的责任。

原则4 帮助原则。当你看到别人需要帮助，或当你收到别人的帮助请求时，你在确保不耽误自己履职的情况下，给予了他人帮助。而不能出现你帮助了别人，结果自己的责任没承担好的情况。

原则5 分歧处理原则。如果你觉得你的同事做得不对，请当面告诉他你的建议，而不是背后去告诉他的上级。

原则6 卫兵原则。卫兵的职责是确保每个通行者都有通行证，他的权力是阻止没有通行证的人通行。所谓的卫兵原则是，卫兵的上级领导有撸掉卫兵的权力，但是他没有权力干涉卫兵履职，即要求卫兵放行一个没有通行证的人。

4. 采访并收集下面几类公司对员工绩效考核的做法：

采访

5. 走出“自我”和“当下”

我觉得这些活动是有价值的

人类是社会性的动物，尤其在这个高度发达的信息社会，不可能将自己封闭起来不问世事。在一个软件团队工作，只考虑到“自我”，不考虑“别人”是不行的。同样，有些同学得过且过，只看到“当下”，不放眼“未来”的心态也是不积极的。

在成功的大型企业中，人际交流能力和人际觉察是员工素质培训的一个重要部分，它包括如何与别人建立平等而融洽的合作关系，如何处理矛盾与冲突，如何影响同事，如何给别人的工作做评价，如何能了解别人表面行动下的言外之意、隐含的动机等等。这正是不少在校学生所缺陷的部分，而课堂上这些活动可以弥补这个缺陷，所以我觉得它们是非常必要的。

6. 刷课软件和刷票软件

现阶段的法律中，使用这些插件，并不能算是违反法律。同时它又缺失的损害了大部分人的一部分利益，在这个领域合理运用法律法规与行业道德规范来约束，也是一个问题。

7. A/B 测试和道德

8. 软件团队的发展阶段

个人我们的团队处于规范阶段，因为我们的团队的任务个工作职责都是公开的、分配到每一个人的。每一位成员都对自己要做的事情非常清楚。大家互相了解，互相尊重，有一个共同奋斗的目标与决心。

9. 团队如何做决定

（1) 独裁：领导说了算

优：最明显的优点就是团队不会因意见不合而踟蹰不前。

缺：缺点就是独裁带来的无法群策群力，员工不能参与决策，一旦领导出现决策失误殃及整个团队。

（2) 独裁+顾问：领导和一些外部的顾问商量之后做决定

优：优点是比起独裁，这种方式使得领导出现错误毁灭团队的可能性大大降低。

缺：同样也是无法群策群力，员工参与不到决策里来，积极性不高。

（3) 民主投票：这样就产生了赢家和输家

优：优点为民主。

缺：缺点为决策缓慢及易产生小集团派系斗争。

（4) 全体一致同意后再决定：皆大欢喜?

优：优点为绝对民主？

缺：缺点为决策缓慢以及可能并不会产生真正有利于集体发展进步的决策。

10. 测定工程师的效率

11. 合作伙伴评比

12. 职业道德评论

对照软件工程师职业道德的条款， 评价当事人的软件工程师职业道德如何。

下面几点对软件工程师而言，应该是最基本的要求：

有高度的责任心和强烈的使命感

有自觉的规范化和标准化意识

有强烈的相互协作的团队精神

有良好的和同事沟通的能力

正确对待客户需求，认真弄懂客户需求，不任意解释客户需求

有自觉的保密意识和产权意识

通过实践养成良好的文档习惯

通过学习和总结而引发出创新精神和创新能力

服从上级主管分配的任务和安排

具有软件工程的概念。

第十四——十七章作业