《构建之法》阅读笔记三
已经读完构建之法的前十二章，这篇的阅读笔记从第十三章至十七章。
13软件测试
13.1基本名词解释及分类
·Bug、Test case、Test Suite
·按测试设计的方法分类：Black box &White box
·按测试的目的分类：功能测试、非功能测试
·按测试的时机和作用分类：“烽火台”软件开发是否顺利，“测试名称”说明不同测试方法
13.2各种测试方法
·构建验证测试
·验收测试
·“探索式”测试：为某一目的进行测试
·回归测试
·场景/集成/系统测试
·伙伴测试：可用于快速修复bug
·效能测试：设计负载、令用户满意的服务质量、设计负载的细化、服务质量的细化
·压力测试：用户轴的延长和时间轴的延长
·内部/外部公开测试
·易用性测试
·“小强”大扫荡：正确利用，处理bug
最好的测试能够防止小强的出现。
13.3实战中的测试：以最低的成本换取部分质量的提高
·似是而非的测试观念，容易导致软件出现问题，纠正观念
·测试工作中的文档：测试设计说明书、测试用例、错误报告、测试修复，关闭缺陷报告、测试报告
13.4运用测试工具
·运用工具记录手工测试
·运用工具记录自动测试
·如何测试效能：效能测试、负载测试、压力测试
13.5练习与讨论
·远景和计划阶段：收集需求
·开发阶段：开发人员写单元测试，测试人员写BVT
·稳定阶段：对产品进行验收测试
·发布阶段：产品发布，为下一版本做准备
看完这一章，对于测试有了新的认识，自己在学习过程中也做过测试，不过只做过一种--黑箱测试。在测试过程中可以更快的修复bug。在阅读这一章的时候，测试的方法有很多种，虽说测试人员并不是专业写代码的，但是代码还是得写得“漂亮”才行，不然很容易通不过测试，我觉得测试中一个关键点是：将“黑箱”变为“白箱”。对于bug也要有新的认识，有些程序甚至是依托bug才能运行，能说这个bug是错的吗？Excel表格中的1900是闰年的bug依旧在延续，但是该bug修复就会出现一堆问题。对于测试，我认为应该将阻碍程序运行的bug挑出，然后修改，最终的目的是保障用户体验。
14质量保障
14.1软件的质量
·程序的质量
·软件工程的质量：软件开发过程的可见性、软件开发过程的风险控制、软件内部模块，项目中间阶段的交付质量，项目管理工具的因素、软件开发成本的控制、内部质量指标的完成情况
·软件工程的质量如何衡量：CMMI，实施CMMI有重大意义，可以提高企业管理水平，降低成本。CMMI的实施方法：连续式（企业的管理能力）、阶段式（企业的成熟度）
·质量的成本：预防、评审、内部故障、外部故障、流程分析改进、提高职业技能、技术投资
14.2软件的质量保障工作
·测试的角色要独立出来么：独立的测试角色对于软件质量的提高有很大的帮助，对于一个软件的质量检验，通过官方的认证或者人肉认证，但后者更为可靠。用户更希望有独立的测试。
·和测试角色相关的问题：
既然有专人负责，那我就不用负责了（容易造成责任推卸，项目最终失败）；
盲目信任“专业人士”扮演的角色（“专业人士”不一定靠谱）；
为了自己的角色而做绩效优化（局部最优，但达不到全局最优）；
画地为牢的分工（不能够做出真正的测试用例）；
无明确责任的分工（一个优秀的团队是有明确的分工和协调的配合）
·总结
公司对于各个角色的培养，应该要明确他们自己的职责，搞清楚自己项目的特点，协调合作。
14.3联系与讨论
·如何衡量软件工程的质量
满足客户的需求；在一定的时间内将软件做出；证明软件是可以继续发展并且是可维护的。
·测试人员的职业发展
阅读完这一章之后，我对测试的认识更加深入，一个软件的质量高低并不是口头决定的，而是根据实际测出来的。对于测试不应该以程序员的角度去测，而应该以用户的角度来测试，最终将呈现出来的bug修复。除此之外，软件的质量还与制作方的团队息息相关，一个协调的团队制作出来的软件往往是协调的，还要注意制作软件花费的成本和其所带来的收益。在考察软件的质量时，测试是其中最重要的环节，其他环节为辅，共同制造高质量软件。
15稳定和发布阶段
15.1从代码完成到发布
·软件团队分为不同类型，对自我的认识也不同，“高质量”往往会拖延软件的发布。
·会诊小组：针对不同bug，采取不同的是手段
·复杂项目的会诊：修复最重要的bug,放走一些无关紧要的bug，换取软件的及时发布
·招数：设计变更，对代码进行重写或重构，做好DCR
·招数：ZBB，Zero Bug Bounce，不断的修复bug
·招数：最后回归测试，项目结束阶段，所有人员回归测试bug，保证所有的“大”bug被修复。
·招数：砍掉功能，学会取舍，适当取消掉完不成的功能。
·招数：修复bug的门槛逐渐提高，
·招数：逐渐冻结，将已经完成的代码进行封存，不在随意修改
15.2不同频率和不同覆盖范围渐进发布
·对于不同的用户组发布不同的版本
15.3发布之后--时候诸葛亮会议
·项目发布之后，对这个项目的反思，如项目设计、项目计划、所能使用的资源、管理模式、软件的测试和设计、团队的合作，团队之间如何合作。
15.4联系与讨论
·项目拐点
·银弹：绝对话语权
·软件后期出现问题，该团队的知名度迅速提升，问题在什么时候解决？
看完这一章之后，对于软件的稳定和发布有了新的认识，在平常无论使用哪款软件，都会出现各种各样的bug，然后等待官方修复，这样也是一种智慧，因为这些bug并不会影响软件的主要功能，只会影响用户的体验。软件发布之后，除了对bug进行修复之外，我觉得很重要的一点是对这个项目的反思，我一般写完程序之后，便不会在对其进行思考，因为这只是临时写的，除了上课测试一下之外，便没有其他用途了，我这一点值得反思，从自己之前的旧项目中可以看出很多问题，同样可以学习许多东西。
16 IT行业的创新
16.1创新的迷思
·一：灵光一闪，伟大的创新就紧随其后，创新并不是一闪而现的，往往需要长时间的思考，最终才能得出定律，真正的创新需要一步步的“拼图”。
·二：大家都喜欢创新，创新往往是颠覆性的，会对之前的产业造成或大或小的冲击
·三：好的想法会赢，一个好的创新想法，将其中的利益讲清楚，往往会收到好的效果
·四：创新者都是一马当先，创新者都是走在前方的人，但不一定是领导者
·五：要成为领域的专家，才能创新。一个领域的专家，在其他领域进行了创新
·六：技术的创新是关键
·七：成功的团队更能创新。企业创新的难点：①成功的企业要满足股东们巨大的期望值；②成功的公司有价值观--追逐利润；③成功的公司有流程；④成功的公司重视客户；⑤成功的团队有老大的心理
·八：创新这就是冒险家，创新者不是冒险家，而是有自己的原则、坚持和价值观
16.2创新的时机
·抓住创新的时机才能实现创新
16.3创新的招数
·一个创新的决定是由多个决定形成的，同时，创新的过程中还需要正确的战略指导
·SWOT分析框架，各种因素的分析
·动量和加速度，如何平衡不同处境下的软件，“即将停止的火车”和“正在起飞的飞机”
·技术产品的发展周期
·效能过剩和产品的各个阶段,维持性==效能过剩
·影响产品竞争的各种因素，产品和行业、公司和市场、团队执行、产品的价值
·四个象限划分产品，杀手、外围、必要、辅助
·打出组合拳和套路，
①了解团队能力、产品方向和大环境趋势
②选择合适的细分市场
③投放刚需产品、吸引客户、在用户中招募粉丝、把产品推向引爆点
16.4魔方的创新
从魔方的创新可以看出，明白自己的用户是谁，同样也要明白用户需要的是什么
16.5创新和作坊
·自己手工劳动，做出产品
·人不多，师傅带徒弟，或家传手艺
·只做某种行业，不太改行，商业技巧比较缺乏
·不太做广告，主要靠口口相传，容易被技术进步淘汰
16.6练习与讨论
·VCD的创新
·BBS的创新
·联系招数的创新
·软件工程的技术和实践如何帮助创新
·科研和创新
·创业-坚持目前的方向VS尝试更多新的想法
·Xerox Parc的成功技术创新和推向市场的失败
看完这一章之后，刷新了我对创新的认知。创新并不是简单的热血，也不是一个新的想法，而是知识积淀足够深的证明，只有在一个领域有专业的知识，才能有所创新。其次，创新的实现还要根据利益相关方来展开，没有利益的驱动，一般创新坚持不下来，尤其是技术方面颠覆性的革新，动摇的是之前所有产业的相关利益。最后，创新也需要一定的时机，在正确的时机面前创新才有可能成功，创新之前最重要的事情是积淀足够的知识，补充自己。
17 人、绩效和职业道德
17.1领导力
·领导更多的是“领导”，而不是“管理”，领导力的几个要素：①设定目标；②知人善任；③带领团队成长；④绩效管理
17.2领导力-知人善任
·领导看重的知识、专业技能、投入程度
·四大象限：第四象限（积极的初学者）、第三象限（迷惑的学习者）、第二象限（不爽的贡献者）、第一象限（自立、取得成就的人）。四个象限中的人具有不同的能力和动力，领导需要根据他们的实际情况，发挥出最大的价值。
17.3领导力-带领团队成长
·萌芽阶段：领导者带领团队相互熟悉，将团队的基础打好。
·磨合阶段：团队必然会经过磨合阶段，团队磨合的关键：①信任；②冲突，不同的态度导致的结果对团队会有很大影响；同样，对冲突采取不同的处理方法，会导致最终的不稳定性；③承诺；④责任；⑤结果，不只是项目的结果，还有团队的结果。
·规范阶段：这个阶段团队的一些规范已经制定好，对于做出的决定，90%可以团队内部自己解决。
·创造阶段：团队具有高效的执行力，可以自己完成各种项目，但是这样的团队容易骄傲自满，导致团队最终的解体。
·效能曲线和假团队：团队之间、团队与公司之间的面和心不和
17.4猪、鸡和鹦鹉的故事
·“猪”第一线、“鸡”办公室，主管流程、“鹦鹉”能说会道，台面展示
·重大决定由“猪”决定
·将角色列出，不同的角色在一个项目中所占比重不同
17.5其实还是人的问题
·人们总会想一些花招来蒙混过关，真正做实事的人很少
17.6绩效管理
·怎样计算一个员工的绩效
比资历？ 大锅饭？ 比效率？ 背靠背评比？ 比不犯错误？ 如何区别对待？使用动物比喻的体系、划分等级和公开刺激的做法、闷声发财的做法
17.7萝卜与白菜
·对于两种工作模式如何判断和取舍：慢工出细活和快而不洗型
17.8软件工程师的职业道德
·原则一：公众，软件工程师的行为英语公众利益一致
·原则二：客户与雇主，软件工程师应以其客户和雇主利益最大化的方式做事，与公众利益保持一致
·原则三：产品，软件工程师当确保自己的产品以及相关的修改满足最高的专业标准。
·原则四：判断，软件工程师应当具备完整且独立的专业判断
·原则五：管理，软件项目的经理和*应该提倡并亲自采用符合道德规范的方法来管理软件的开发和维护
·原则六：职业，在于公众利益一致的原则下，软件工程师应当保证其职业的诚信和声誉
·原则七：同事，软件工程师应当公平对待同侪，并予以支持和帮助
·原则八：自身，软件工程师应当终生学习以提高自身的专业水平，并在工作实践中推动落实道德准则
17.9练习与讨论
·绩效评估
·在团队中会不会出现“劣币驱逐良币”或“不敢犯错误”的现象
·驱动和责任
·现实世界中的绩效考核，不同类型的公司对于绩效的标准
·“自我”、“当下”与“别人”、“团队”、“将来”
·刷课软件和刷票软件
·A/B测试和道德
·软件团队的发展阶段
·测定工程师的效率
·合作伙伴评比
·职业道德，罪与罚
·团队的职业道德，用户的道德
·成长、责任和公司的关系
这一张的内容比较多，自己看完之后还需要梳理一下。在这一章中主要讲的是个人对于一个团队的影响、公司对于个人和团队的影响、一个团队在不同阶段如何应对？在一个团队中如何“分赃”是最大的问题，这就需要领导者找到一个好的方法来判断一个人绩效。在一个团队中，重要的决定往往需要经过一线人员的同意，他们才是团队的顶梁柱。无论是领导、还是员工，除了提高自身的专业技能和知识，还需要处理人际关系，如何和人交流，也是一门技术。在做软件开发的过程中，虽然要做到利益最大化，但是不能抛弃做为一名IT人员的道德修养。