阅读了构建之法第十、十一、十二章的内容后，了解到了典型用户(Persona)和场景(Scenario)、软件设计与实现、用户体验等内容。
第十章主要告诉我们典型用户的分析及场景分析。在开始写程序之前我们要和典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户。典型用户会强迫我们在考虑问题时从用户的角度出发。只有把自己置身于用户的角度，才能发现程序的不足与需要改进的地方。典型用户和典型场景。大概就是非专业的程序员、专业的程序员、项目经理这三种人吧！典型用户很大的作用就是让程序员考虑问题时从用户的角度出发。定义完典型用户后，我们还要和典型用户的代表交流并理解他们。从典型用户到典型场景，要针对典型用户写典型场景，在从场景到任务，最后编写故事模板。
用例，是需求分析工具。通过讲简单故事来传递信息。但讲故事较难，一般很难得心应手。所以，想掌握好，多努力吧！
规格说明书。有软件功能说明书和软件技术说明书。功能说明书是从用户角度描述不涉及软件内部细节。而技术说明书是设计文档，描述了开发者怎样实现功能，这对于中途加入团队的成员很有用。
功能驱动的设计。就是把用户的需求变成团队的开发工作，然后不断实现这些需求。它涉及到构造总体模型、构造功能列表、制定开发计划、功能设计阶段、实现具体功能这几个步骤。
第十一章主讲内容是软件的设计与实现。往往我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。像表达实体和实体之间的关系的E-R模型，当我们要关注数据在不同的实体之间依赖一定的规则流动的时候,表达数据的流动DFD则很好地帮助我们分析实体间关系，当然还有好多类似我们之前所学的UML建模等，这些构造模型的方法对我们进行软件的设计起了很重要的作用。当然还有一些不同的设计方法：1、形式化的方法（Formal Method）很多软件需求（例如计算机语言的编译器）可以抽象为对符号的运算和变换，很多软件的某些核心功能需要严密地验证，保证没有问题。2、文学化编程（Literate Programming）程序员在写程序的时候，要理解在文档中的需求，同时还要在程序里写相关的注释。这里的注释和文档中的需求共同实现软件的设计。事实上中国的软件行业之所以和印度及西方有差距就是因为这种文学化编程。
在软件的实现过程中，拿我们自己的团队来说，刚开始大家还兴致勃勃，但没过几天，就因为各种原因无精打采。之所以出现这种现象的问题是大家缺乏沟通，没有好好实现每日的程序构建，没有一个阶段性的目标导致团队方向不够用明确。在程序勉强实现一部分后，我们就被迫迎来了小强地狱，因为没有及时的沟通，在将每个人的模块组合起来时出现了许多bug。因而在一个团队开发过程中，及时的交流和讨论显得尤为重要，这一点需要我们在以后的学习和工作中警惕。
书中的第十二章则主要讲了用户体验的要素。我们常说做产品要从用户的角度考虑问题，这需要有“同理心”。软件团队的设计师和软件工程师有“同理心”（Empathy）么？什么是同理心？就是理解别人的处境、心理、动机的能力。西方谚语Put yourself in other people‘sshoes. 正是此意。设计不同于传统的数学题，是没有唯一的标准答案的。有一颗为用户着想的“同理心”，是好的产品设计的出发点。当我们的程序第一次被用户使用时，各种因素会影响用户的体验，因此往往我们程序的优化是在实战中的测试。团队在这一阶段的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量。由于时间的紧迫我们并没有进行实战测试，因此当我们软件第一次被使用时，我们就被一个用户提出的问题难到了。其实只要完整的经历了测试阶段，往往会发现很多被忽略的问题，所以不要轻视测试。
在开发软件的过程中，一定不能离开用户，毕竟我们的软件是为用户服务的软件，所以不要忘了时刻将用户放在第一位，而不是程序的实现。