【week2】 构建之法 读后感及问题

   上一次读后感涵盖前五章的内容包括个人技术，结对合作，小组项目等。本周作业的燃尽图以及站立会议是关于《构建之法》第六章的内容，所以关于这一章的读后感涵盖在上两篇博客中。

第七章 MSF

      介绍MSF（微软解决方案框架），他有自己的九条思想框架，总结起来就是勤于客户交流，保证个人价值的同时要注意与团队共进退，相信合作的力量，在保持敏捷的同时将作品价值最大化。还有重要的一点就是总结前人经验，并且把自己的经验与他人分享，利用这些经验避免一些错误，这在团队合作中尤为重要。

第九章：项目经理

     项目经理分为两种Project Manager和Program Manager。前者负责开发和测试以外的所有事，管事也管人。后者与大家平等的完成软件的功能只管事。本章主要介绍的ProgramManager是微软首先提出的，要具备观察分析能力，并且要有一定的专业知识，要对整个团队起到推进的作用，要有预测及处理风险的能力。综上我觉得PM一定要有一定的敲代码的能力，还会巧妙地处理技术人员以及上层领导的关系，对风险比较机敏。这确实是一向很艰巨的任务。

第十章：典型用户和场景：

     这一章让我明白了不是所有的人都是我所研发的软件的用户，要十分明确的定义谁是我们的用户。关于用例我一直觉得是软件测试的关键，但是本书说是需求分析的工具，想想也是这样的。要针对用户的需求，进行用例分析，能分析出我们需要开发的功能，每次完成一个用例，逐步完善需求。

第八章，第十一章，第十二章，第十三章 第十五章：

      这几章记录的是软件开发的流程。需求分析阶段提出NABCD是进行创新开发的一个很好地办法，有想法开始实施之前先问自己这五个问题，是否符合用户的需求？怎么做？这么做对于团队或用户有什么好处？进入市场有什么竞争力可以pk掉对手？产品研发成功之后如何让用户大规模使用？

      软件设计就是对上一阶段分析出的用户的问题进行抽象，形成文档，做出一些形象的图，比如流程图、实体关系图等。

      关于用户体验我一直很注重这个，因为我作为很多产品的用户，真的希望研发人员能对自己的作品负责，真正从用户的角度出发。公户之庞大使让用户有良好的体验变成一个很困难的事情，值得深入研究，也不是书中教几个方法就能彻底解决的，还要在以后慢慢深入研究。还有我想说的是邹老师在举例子的时候确实很风趣。

     软件测试，方法分为两类：黑盒测试和白盒测试。我的理解就是，黑盒就是看不见代码如何构成，而白盒就是能看见具体的代码，根据代码完成测试。

     软件发布前还会存在一些问题，这个时候十分考验团队的耐压能力，但是要记住优秀的软件公司也会发布有缺陷的软件。软件发布前要对项目做总结与回顾。

第十四章：质量保证

    即使对待自己的作业也要负责任，何况是要上线的软件，但是做到"好"、"快"、"便宜"确实不容易。QA和Testing我觉得区别就在与，测试是在发布前，为实现软件预期应该实现的功能而做的完善工作。而质量保障既包括软件测试，也包括“售后活动”。上线后根据反馈也要对软件进行一些完善，“事后诸葛亮”会议也很重要。

第十六章 IT行业的创新

     说到创新，确实是我们中国应试教育下的一个悲哀，对于计算机行业，我觉得，首先还是明确用户的需求，才能从基本的需求出发，搞出创新。创新者从来都是面对诸多压力的，面对创新的技术，大众接受的曲线也是很久之后才到高峰。看过这章之后我才知道，原来创新也招数，也有时机，在工作中，创新也要注重这些。

第十七章 人 绩效职业道德

    正如站立会议的要点，只允许猪讲话，不允许鸡讲话，因为“猪”是将全身心投入到整个项目，注入的更多也更了解，涉及切身利益，能做到真心负责。对于绩效，代码量多少不能代表什么，真正解决客户的问题的才是有用的，高效的。

读过本书之后的五个问题：

1.关于敏捷，书中说了我理解的就是介绍了敏捷就是“没有既定的计划与文档，马上写代码，随时发牢骚”，但是开发也是需要有一定的流程的，是否敏捷就是分阶段的瀑布？

2.书中的每章末尾的引用出处，我看了一些很有意思，但是一点点敲网址实在是麻烦，或许单独列出来每章的链接是个好主意？

3.我大学同学，还从事计算机专业的女生大多去做了软件测试岗位，不知道老师是如何看待女程序员的？是不是还是女生比较适合做测试？

4.全书所说的所有过程都十分的完备，但是对于一些小型公司，或者说就是只有几个人的小项目组，要进行这么完备的开发过程是不是有点太过于复杂，怎么平衡？

5.关于萝卜和白菜的问题，我自己是比较倾向白菜的，不知道老师怎么看？