《软件工程之美》学后感

学习的初衷

记录时间：2019年9月17日

学习《软件工程之美》最初是为了了解整个软件开发过程，为实际软件开发过程中不符合标准的情况提供理论依据。
在没有系统的学习之前，会遇到很多问题，比如没有参与需求设计，甚至有些团队没有需求设计这个环节，或者人少活多领导还要求质量高，妄求多快好省，明知不合理却不能正确反驳等问题。

遇到问题没有理论依据指导方向，遇到不合理的安排却没有足够的理由支撑

学习这门课之后，不仅提供了解决已知问题的思路，更加拓宽的我的视野，用工程的眼光看问题，从软件工程的每个职位角色中去看待，站在全局的角度看问题。
Everything is project

学习的收获

每次学完一个课时，都有一种焕然大悟的感觉，整理完思路也很清晰，甚至能发现日常工作中出现某种现象的原因。
现在的我，只是个小小的测试人员，我相信这些知识储备，能为我后面的职业发展奠定基础，也会无形中指引我走得更远。

学后谈谈感受

全课程分为，理论基础，项目规划（项目经理），需求分析（产品经理），系统设计（架构师）开发编码（开发工程师），软件测试（测试工程师），系统维护（运维工程师），经典案例分析，这 几部分。

作为测试人员，按理说我应该更关注 【软件测试】部分，但是在学习的过程中，我却对【项目规划】部分特别有感触，直到 学习了软件测试中关于产品质量的那一课，我才明白其中原因。

项目规划，即项目经理的职责，包括 项目可行性分析，项目计划，会议管理，风险管理，文档管理等。

我当前实际工作中，遇到最多的是会议管理，风险管理和文档管理。

每个公司或多或少会有一些会议，但是大多数都流于形式，没有会后跟踪，
会议结束后和开之前没有太多区别，形同虚设，浪费时间。而这门课中讲到了开会的价值，开会的成本，以及如何提高开会的效率等会议管理方案。
学完后有一种想转发给领导的冲动（但是我不能）。。其实看一个会议有无价值以及认同程度，从参会人员的行为就可以看出来，如果开会期间，很多人拿着电脑在做与议题无关的事情，则一定程度上说明大家对这个会议不认可，但是又不得不来。

风险管理不管是工作还是生活都是一门需要学习，但是又希望永远用不上的课程，就像保险一样，买了希望永远用不上。
任何事情都要有plan B,对待不同的事情采用不同的应对风险的方式，可能性小损失大采用转移风险，可能性大损失大采用规避风险，可能性大损失小，则缓解风险，而对于可能性小损失小的则接受风险，毕竟没有百分百的安全。作为测试人员，比较心塞的就是把未修复的缺陷采用在版本日志中补充“已知问题”模块，来告知用户，避免踩坑这种风险转移方式了。

文档管理，什么？文档也要管理？**其实写文档也是一种学习的方式，很多人回避写文档，其背后真正的原因可能是他所掌握的知识不能结构化，系统化，输出文档的过程，也是串联知识的过程。**在软件项目中，比较关注的应该是需求文档了吧，但是，不知道有多少公司能很好的提供并维护需求文档，至少我没遇见过。

没有需求文档，又要求写测试用例，这对测试人员的知识储备以及理解能力依赖性很大，没有需求文档作为用例的参考，测试人员只能按照自己对产品的理解去设计了，知识储备多，理解能力强，可能设计的用例更全面。反之，漏测频频。

不管是维护项目文档还是输出技能文档，短期看起来是一件最不重要的事，优先级可以一低再低，但是长期，却是一件收获很多的事情。

以上是【项目规划】这部分我在工作中比较有感触的几个点，回到前面的问题，作为测试人员，为什么我对项目规划这部分特别有感触呢？

那再谈下 软件测试之产品质量这部分，产品质量主要是三方面，功能质量，结构质量，过程质量。

用户最后得到的是软件，体验的是软件，功能质量决定产品质量，这需要测试人员保证，这看起来没问题，
大多数领导可能也只能看到这一部分，所以出了问题测试背锅。

但是，除了功能质量还有结构质量，即包括架构质量，代码质量，这部分是开发人员保证，大部分测试人员接触不到结构，更别说保证质量

除此，还有过程质量，过程用户是无法感知的，但是过程质量直接影响代码质量和功能质量，甚至产品的成败。

软件质量从来不是单方面的，而是几个方面的综合因素互相影响，共同决定。需求，设计，开发，每一个环节都有可能导致质量问题，但是测试人员只参与了其中一环，测试只是最后一片雪花，但是雪崩的发生是每一片雪花造成的。

从权责对等角度来看，测试对功能质量负责，但是不能也无权对代码质量和过程质量负责，开发能对代码质量负责，也能写测试代码，保证质量，但是对过程质量的影响有限，项目负责人，有权控制过程，对过程质量负责，而且过程质量的高低，间接影响功能质量和代码质量。

综上，论事故责任：项目负责人>开发>测试

这简直说出了我的心声，再次想转发给领导（可是我不能）。。

这就是我对项目规划部分感触很深的原因，过程质量问题严重，导致项目成员都会觉得很累，吃力不讨好的感觉：

测试人员会抱怨，没有需求文档，周期也短，还要质量高，最后只能背锅。。
开发人员会抱怨，一直催着我们要，给出去了又说问题多，催生出来的质量能好么？
项目经理会抱怨，我求这个求那个，好不容易做好了，居然问题那么多！

比如之前拼多多撸羊毛那次，一张无门槛的百元券，能单方面怪测试么，不能，深层次说明软件开发过程质量差，没有流程制度加以控制。

项目管理是一项软技能，比起技术这种硬技能，可塑空间很大，流程问题也不是一个人所能改变，需要团队有意识，并且在有权利的人的推动下，逐步推行。

总结

《软件工程之美》适合互联网从业者学习，特别是项目经理，如果能做好过程质量，一定是一位受人待见的领导。

本课除了学习软件工程，还学会了工程思维，站在全局思考，大而化之，不被局部所限，以及道（本质），术（方法），器（工具）三种学习方式。附上思维导图，共勉，希望更多的从业人员看到。