构建之法阅读笔记二

 最近终于有时间来读读书了。买了《构建之法》已经一年多了，这次静下心来读完了，收获很大。现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本，当时由于对于整个行业没有太大的感触，而这本书又全部由专业术语和定义组成，所以当时的课是相当痛苦。而老师通过的这门课程的方式又由各种理论知识考试为准，所以当时学习感觉相当“鸡肋”。

好的地方：

    1，情景式、对话式对白，有趣易读。这点非常喜欢，很多实际中碰到的问题在这里可以重现。比如：每日构建，在实际开发中，就会由于各种原因导致不愿意或者没时间去构建。比如：MSF章节中，对于推动信息共享与沟通中，讲“宁可过分沟通”，这点在实际开发过程中十分受用，有时甚至只有过分沟通才能暴露出问题。

    2，介绍作为软件从业人员的一些准则。这是本书的又一亮点，比如：两人合作章节，讲如何正确地给予反馈，这点对于很多开发人员来讲很重要，因为在开发过程中会有很多意见不同，如何正确的反馈自己的意见，减少不必要的争执，这点对于提高工作效率十分有用。

    3，注重实践。软件工程本来就是一门理论和实践并重的课程，可是很多时候，大学的软件工程理论和实践是分离的，甚至只注重理论，讲一堆概念，定义，这对于初学者理解非常不利，我记得当时我上大学的时候，老师讲解白盒测试、黑盒测试、集成测试、单元测试等等，很多测试的概念，这对于不使用这些测试的大学生完全是陌生的，只有实际做了项目，实际中应运了这个测试，才能知道各个测试是干什么的。而这本书不光讲了这些概念，还通过对话式独白讲解了这些概念在实际中的应运，并且通过学生做项目进一步加深了理解。

    4，由浅到深。比如：第一章，举例中讲解了软件工程可能涉及到的的方方面面，非常易于理解。（程序、工程、应用软件、软件服务、源程序、数据、构建、源代码管理、配置管理、质量保障、软件测试、需求分析、程序理解、软件维护、服务运营、软件的生命周期、软件项目的管理、用户体验、商业模式等等）。

    5，第十三章，软件测试章节的组织和安排非常喜欢。先讲了不同角度的测试分类，然后着重讲了各个测试，又讲了实战中的测试，并讲了测试中的文档，最后介绍了测试工具。非常喜欢。

    6，覆盖面广。这也是这本书的特点，比如：职业道德、绩效、IT行业创新、项目经理等章节。

可以改进的地方：

结构建议：

    1，我读的这个版本（人民邮电出版社，ISBN 978-7-115-36916-1）中，配图不够清晰，如图2-1、2-3、2-5、2-6、3-1等

    2，4.5.2这个题目一定忘记加粗了。

    3，图8-15对四个象限的不同建议，四个象限的标注应该是有问题的，每一象限中都写着第二象限。

    4，如果作为大学教程，MSF流程章节，其实没有必要单独成为一章。

内容建议：

    1，第2章讲个人技术和流程，从接受程度方面感觉有些突兀。

    2，第12章用户体验，讲的不够清楚。主要是：作为一个软件项目，用户体验应该考虑的更早，而整个软件开发的过程中都要考虑用户体验。改进建议：

    1)用户体验之初体验：一些设计方面好的例子、一些设计不好的例子

    2)用户体验的设计步骤和目标。这里最好能够讲解的更为详细一些。比如用户体验是要求从更底层、更早就要考虑的，应该扩展开来讲解。

    3)用户体验的一些标准

    4)练习。让大家举一些生活中的例子。马桶？

    3，书本重广度和易于理解，深度不够，所以对于选择阅读这本的人，可以看看是否适合自己。

对现在工作的提升：

1.代码复审

     代码复审这块的感触非常大，因为之前接触的公司项目，开发流程不够完整，在公司做开发的过程中，缺少了代码复审的环节。导致在上线过程中总会存在一些问题。今年初管理项目过程中加了代码复审，至少有以下几个方面的提升：

    1)代码质量较之前提升很多，上线成功率提高很大。

    2)新员工培养。很多时候新的开发人员，即使复审的人员不说话，只让他自己讲解一遍自己的代码都会发现很多问题。

2.敏捷流程

     在管理项目的这两年中，其实刚接手项目的新人是没有明确的项目管理流程，刚开始不知道自己是瀑布模型还是敏捷流程，把这段不知道自己是什么开发流程的模式称为：前任模型。因为项目是从带你的老员工手里接过来，为了保证项目顺利开发、人员稳定过度，所以一般的情况下刚接手是不会变的。只有在全部掌握了之后，才会去修改之前流程中的不合理部分。

     在管理项目的过程中，最接近敏捷流程的一次应该是去年下半年独立管理一个换版项目过程中。使用的是TDD（Test Driven Development）测试驱动开发。

3.需求分析

• 准确寻找需求

     现在公司定位的岗位是：项目管理岗位，但是公司对于项目管理的职责范围至少包含了：需求分析师、产品经理、项目经理这三个角色。所以分析需求是工作中的很大一部分。获取和引导需求、分析和定义需求是很考验一个需求分析师能力的时候。

失败案例：

    微信公众号系统，项目经理A负责

    活动系统，项目经理B负责

    业务要求，绑定公众号之后，才能参加活动。

    按照业务要求进行的系统功能划分，绑定的判断只能在微信公众号系统判别，而参加活动的业务实现是在活动系统，所以客户绑定之后可以从微信公众号系统跳转到活动系统参加活动，整个活动是在活动系统完成的，符合业务要求（绑定公众号之后，才能参加活动）。但是完成之后，在业务验收阶段：发生如下对话：

    业务：为什么我没绑定看不到活动？

    项目经理：你要求是绑定只能才能参加活动啊？

    业务：是啊，我是绑定之后才能参加活动，但是没绑定的客户要看到活动啊，要给微信公众号系统吸引流量，你绑定判断应该在活动主页的“参加活动”上面加啊，你不能让我们进不来，看不到活动啊。

    项目经理：。。。。。。

    （因为绑定的判断只能在微信公众号系统，而整个活动功能，活动系统已经实现了，活动系统是不能判断绑定的，所以需要对于功能重新划分实现）。

• 需求划分

    职责中有需求分析师的工作内容，接触了各个条线的业务人员之后，会发现很多业务方面的需求多是“对产品功能性的需求”，业务条线人员多是不知道“对产品开发过程的需求”、“非功能性需求”的。所以在这方面的开发过程中，作为项目经理务必要对于业务提出的需求进行审核和分析，提高“非功能性需求”质量。

• 计划和估计

    在做需求的过程中，业务和领导问的最多的大概就是这个功能的大概需求多长时间完成，所以项目经理对于项目的计划和估计显得十分重要。书中说的：回溯方法，在很多时候其实就是这样执行的，最终交付日期往前推。

4.事后诸葛亮会议

    一个项目或者一个需求完成之后的总结和反思是必不可少的。