标题：《构造之法》第4 8章心得体会
一、前言
先简要说明当前我在软件工程这两周的学习情况：由于在课堂上的学习进度比较快——两周的课程从软件需求分析一直上到了结构化分析、设计，显然我们软工小分队的进展肯定是没有那么快的，所以我在学课本知识的同时只得加快看《构造之法》这本书的速度，从第4章 两人合作、第5章 团队和流程、第6章 敏捷流程、第7章 MSF到第8章 需求分析，我越发觉得这本书中除了很多与企业性和商业性的竞争与开发有关（毕竟也不是完全针对学生的专业课本）外还是有我们能够借鉴的地方的，除第7章由于是专门讲关于微软解决方案框架我就不细说外，我将一一列出我认为的每一章的重点。（尤其是第8章的需求分析）
二、第4章——两人合作
两人合作的话，首先是说到了代码风格规范和设计规范，既然两个人要合作完成代码那就首先要制定代码的相关规范。前者主要原则就是 ** 简明，易读，无二义性。 ** ，包括缩进（ ** 建议用4个空格代替Tab键，原因是可读性正好，不会由于不同情况显示不同长度 ** ）、括号（‘{’、‘}’独占一行）、大小写（ ** 所有的类型/类/函数名都用Pascal形式——所有单词首字母大写，所有变量都用Camel形式——第一个单词均小写随后单词Pascal形式；类/类型/变量：名词或组合名词，函数：动词或动宾组合词 ** ）、注释（写清what、why及特别要注意的地方）。设计规范就牵涉到程序设计、模块之间的关系、设计模式等方方面面，不少与具体程序设计语言也息息相关。（通用原则也有很多细节，此处略去）
接着强调了代码复审，首先它的正确定义应该是 ** 看代码是否在“代码规范”的框架内正确地解决了问题。 ** ，而且代码复审一般是同伴复审，最好是早期发现并修复复审过程中的bug，他谈到可在复审时加特定标记如$todo:-----,$review,$bug......把$review标记的问题一一讨论，在复审过后该标记要清除，在一个里程碑或正式版本发布之前，另外两个也都要清除。（ ** 这里他在代码复审后做什么还用到了马原课中学过的一个哲学句子：人不能两次踏入同一条河流，放在这里就是程序员不能两次犯同样的错误。PS:感觉有点牵强 ** ）
最后他就谈到了课本上有的结对编程，从为把代码复审这些卓有成效的开发方法极致化——每时每刻都处在代码复审的状态这一思想体现的极限编程出发，说到了结对编程的why和how。重点有 ** 结对编程的两个角色驾驶员、领航员中，关键是如何最大限度地发挥“领航员”的作用！ 无领导与被领导的关系 它是一个相互学习、相互磨合的渐进的过程，需要经过许多个阶段，在其中也体现了评价人的三种层次（从最内层的本质和固有属性、中间层的习惯和动机到最外层的行为和后果）——关于如何正确给予反馈。 ** ，本章最后附上了案例和讨论的博客网址： ** http://www.cnblogs.com/xinz/p/3852241.html **
三、第5章——团队和流程及第6章——敏捷流程
首先介绍了软件团队的模式，有那种欢乐随意的一窝蜂模式、“一人干活其他打酱油”的主治医师模式、明星模式、社区（不意味着：随意）、业余剧团、交响乐、爵士乐（个性化表达）、功能团队、官僚（“老板驱动”）模式等。
接着讲解了软件开发的开发流程，与课本上的第3章有所对应。有写了再改模式、 ** 瀑布模型——强调文档的重要性、要求相邻步骤回溯，但同时最大的局限性在于最终产品最后才出现、各步骤分离，不适应变化的需求！ ** 、瀑布模型变形后的生鱼片和子瀑布模型、 ** RUP（Rational统一流程）——把不同类型工作叫做Discipline（科目）或Workflow（工作流），阶段从Inception（初始，达到生命周期目标Milestone）->Elaboration（细化，达到生命周期结构Milestone）->构造（达到初始功能Milestone，此时产品版本常被称为“beta”版）->交付（重点是产品发布里程碑） ** ，所谓Milestone(里程碑)就是一个大阶段的结束，每阶段内可有几个迭代（业务价值在不同时间段、跨迭代领域递增式地交付，在RUP驼峰图中反映了不同角色在每阶段的参与程度，包括的工作流有 ** 业务建模、需求、分析和设计、实现、测试和部署 ** ），因而RUP在大尺度上像瀑布模型，在每个阶段内像迭代模型。
在其他流程中，主要就包括了第6章讲解的敏捷流程了，对应课本第4章。先提出了和书上翻译类型的12条敏捷开发原则，其实敏捷是软件开发的众多方法论的集合，主要剖析的就是Scrum(PS:史克郎姆，另Aigle在本书中被笔者塑造的“移山公司”中的员工调侃成爱脚儿），用书上的解释敏捷是什么——一种思潮或价值观，涵盖方法论(有名的还有爱抚弟弟FDD-Feature Driven Design、XP(极限编程)），而方法论又建立在行之有效的最佳实践方法之上（如Bumdown、Sprint Backlog、Stand Ups、CI、BDD、TDD）。
在剖析SCRUM中，把流程概述成四个步骤： ** 找出完成产品需要做的事情——Product Backlog(积压的工作、待解决的问题或产品订单)->决定当前Sprint(整个产品的实现被划分为几个互相联系的冲刺)需要解决的事情——Sprint Backlog->冲刺（涉及到Scrum Meeting,每日例（立——站着报告昨天做的、今天要做的和碰到的问题）会。。）（提到了Burn Down Chart燃尽图和、Kanban的概念，且说明了该阶段是时间驱动的(Time-boxed)）->增量发布 ** 最后在 http://www.cnblogs.com/xinz/p/3852390.html 这篇博客里讨论了适合选择敏捷的时机，敏捷的参考资料：http://www.cnblogs.com/xinz/archive/2012/02/20/2358888.html 、现代软件工程学生小组Daily Scrum过程三个例子：http://www.cnblogs.com/ustc_msra_ase/archive/2011/02/17/1957382.html http://www.cnblogs.com/southseven/archive/2011/11/20/2255685.html http://www.cnblogs.com/Gun-N-Rose/archive/2012/09/29/2708889.html
时间原因，之后再继续补充这一次的体会——重点说说第8章的需求分析。
四、第8章——需求分析
首先介绍了软件团队准确而全面找到需求的几个步骤：1.获取和引导需求（Elicitation）2.分析和定义需求（Analysis&Specification）3.验证需求（Validation）4.在软件产品的生命周期中管理需求（Management）；对软件需求从不同角度划分为：对产品功能性的、对产品开发过程的、非功能性（服务质量需求）和综合需求。由于作者是更多的是站在公司或者实际一个大的软件项目的角度来介绍如何需求分析，所以其过程还包括产品利益相关者进行焦点小组、深入面谈、可用性调查和卡片分类等许多对我们借鉴性不是很大的地方。但在获取用户需求——用户调查的第4小点方法中他也谈到了用户调查问卷的方法（我们也结合我们实际完成了一次小规模的问卷调查，目前看来还是有其优势的）。
在User Survey里，他主要分析了调查者一些常见错误： ** a.问题定义不准确b.使用含糊不清的形容词、副词描述时间、频率、价格等c.让用户花额外努力回答问题d.问题带有引导性的倾向f.问题涉及隐私或商业机密细节等 ** 同时他又给出了建议的方式： ** a.全开放式问题（让用户畅所欲言）b.二项选择题（是/否）c.多项选择题d.顺位选择题（按优先级填写1.2.3.） **
接着他是针对竞争性需求分析，为了让团队提出新的创新，新得过别人，提出一个比较系统的框架——NABCD模型，具体分别是Need、Approach、Benefit、Competitors和Delivery。而在随后功能的定位中，定义了四象限法以及两对功能和需求（杀手功能core/外围功能Context和必要需求/辅助需求），四象限法就是针对两对需求、功能的不同搭配给出相应每个象限的建议，最终是让 ** 团队清楚看到自己感兴趣的功能处于什么地位，在一定资源情况下倾斜到可以产生差异化和独特用户价值的地方。 **
最后定义了目标、计划和决心，举出许多例子来说明。其中他提到 ** 在敏捷开发的项目中，团队目标是把软件写出来，让用户满意，不要为了“猜得准”而踌躇不前——要快速得到粗粒度的估计，然后进入实现阶段。一个团队经过依次里程碑之后，再回过头看看最初估计和实际花费时间的差距。 ** 从一次项目中掌握经验！两个书中分享的前面学生软件项目两个博客：http://www.cnblogs.com/bawangyishan/archive/2011/03/03/1969771.html http://www.cnblogs.com/se2011/archive/2011/03/04/1971185.html
这大概就是这本书的第4-8章一些重点内容了。