2017-2018-1 Java演绎法 第一周 作业
- 【团队成员】：
| 学号 | 姓名 | 负责工作 |
|---|---|---|
| 20162315 | 马军 | 日常统计，项目部分代码 |
| 20162316 | 刘诚昊 | 项目部分代码，代码质量测试 |
| 20162317 | 袁逸灏 | 组长，项目 主要 代码 |
| 20162319 | 莫礼钟 | 市场推广，广告策划 |
| 20162320 | 刘先润 | 项目部分代码，动画效果 |
| 20162330 | 刘伟康 | 项目总结博客，日常管理，代码质量测试 |
【注】个别成员在没有具体工作时会进行动态分配。
【本次团队贡献及完成度】
团队贡献及完成度
| Members | Personal Contribution | Completion and Time(h) |
|---|---|---|
| 袁逸灏 | 第1、2、3章及问题1~5 | 100% 4.5 |
| 刘伟康 | 第4、5、6章，创建团队博客，编辑博客及问题6~9 | 100% 8.5 |
| 刘先润 | 第7、8、9章及问题10~13 | 100% 7.0 |
| 马军 | 第10、11、12章，问题14及交流会总结 | 100% 3.0 |
| 刘诚昊 | 第13、14、15章 | 70% 3.0 |
| 莫礼钟 | 第16、17章 | 20% 1.0 |
第 1 章 概论
-
1.1 软件 = 程序 + 软件工程
软件工程的核心部分（狭义，广义）、软件工程的地位、软件开发不同阶段的不同表现。 -
1.2 软件工程是什么
软件工程的定义、软件工程所包含的领域、软件开发的难点、工程的定义、软件工程并不等于计算机科学，两者有着不同的侧重点，软件工程的知识领域，软件工程的目标，初步学会软件工程需要达到的要求。
第 2 章 个人技术和流程
-
2.1 单元测试
保证覆盖率为100%，好的单元测试的标准，单元测试可以提高软件开发的效率，回归（回归到以前不正常的状态）测试。 -
2.2 效能分析工具：Visual Studio（抽样、代码注入）
不经分析就盲目优化，也许会事倍功半。 -
2.3 个人开发流程（PSP）
PSP任务清单（大学生VS工程师），PSP的特点。 -
2.4 实践
当前程序设计作业简单，无太多扩展、扩展的方面、做项目的时候需要对项目的处理；
开放 – 封闭原则：允许扩展，不允许修改。
第 3 章 软件工程师的成长
-
3.1 个人能力的衡量与发展
个人能力在团队中的作用与影响、个人应当承担的责任、个人的成长记方式。 -
3.2 软件工程师的思维误区
不要总想着在短时间内搞个大新闻，要结合自身实际，求稳，然后再扩展。 -
3.3 软件工程师的职业发展
-
3.4 技能的反面
注重自己的技术，要避免懂得“技术”但仍然经常犯一些低层次的问题。
第 4 章 两人合作
-
4.1 代码规范（风格、设计）
-
4.2 代码风格规范（简明、易读、无二义）
缩进（4个空格）、行宽、括号、断行与空白的{}行（每个{和}独占一行）、分行、命名、下划线、大小写、注释（What、Why）。 -
4.3 代码设计规范
函数、goto、错误处理（参数处理、断言）、处理类。 -
4.4 代码复审（自我、同伴、团队）
为什么（早发现早修复、互相了解）、步骤、核查表（概要、效能、可读性等）。 -
4.5 结对编程（极致）
为什么（高投入产出比）、不间断地复审、角色互换。 -
4.6 两人合作的不同阶段和技巧（萌芽、磨合、规范、创造、解体）
影响他人的方式、正确反馈（多层次）。
第 5 章 团队和流程
-
5.1 非团队和团队
非团队（独立、乌合之众）、团队（共同目标、合作）。 -
5.2 软件团队的模式（
窝蜂模式）
主治医师、明星、社区（众人拾柴火焰高）、业余剧团（不同角色）、秘密团队（无干扰）、特工团队（高手）、交响乐团（各司其职）、爵士乐（个性化表达）、功能团队（小组交流）、官僚（不提倡）。 -
5.3 开发流程（统一体系）
写了再改、瀑布模型（分析-->设计-->实现-->销售-->维护）、统一流程、渐进交付（MVP）、TSP原则
第 6 章 敏捷流程
-
6.1 敏捷的流程简介（找出待解决的问题 --> 决定当前目标 -->冲刺（每日例会）--> 改进）
-
6.2 敏捷流程的问题和解法（计划：体现依赖关系-->描述细化到技术层面 --> 跟踪三个时间 --> 总结教训）
-
6.3 敏捷的团队
自主管理（自己挑选任务）、自我组织（联合负责）、多功能（全面负责）。 -
6.4 敏捷总结
质量控制、短时间迭代、极致编程、经验教训。 -
6.5 敏捷的问答
敏捷是一种价值观、总结思想、最佳实践TDD、适用范围、宣言（左项）。
第 7 章 MSF
-
微软解决方案框架（Microsoft Solution Framework，MSF）,是微软公司通过吸取各部门积累的业务经验并随着时代更新的软件开发方法。其主要原则有9点：推动信息共享与沟通、为共同的远景而工作、 充分授权和信任、各司其职，对项目共同负责（不仅要完成本职工作，更要对项目负责）、重视商业价值、保持敏捷，预期变化、投资质量（投资的效率，时期并要求长期）、学习所有的经验（要坚持总结和分享）、与顾客合作（从用户角度出发）。
-
用户调研（User Study），A/B测试，通过态度、行为、定性、定量来规范调研的尺度。
第 8 章 需求分析
-
软件需求
将需求进行分类、清楚软件产品的利益相关者、获取用户需求（用户调研）、竞争性需求分析的框架、功能的定位和优先级、目标估计和决心、找出估计后面的假设、最后分而治之。 -
经验公式： Y = X ± X ÷ N
工程师的经验公式实际时间花费主要取决于两个因素—对 某件事的估计时间X，以及他做过类似开发工作的次数N。 -
提案，评估和WBS
NABC model（N--need需求、Approach--做法、Benefit--好处、Competitors--竞争、Delivery--推广方式）
评估：目标（根据实际的需求来定）、决心（它承诺在特定日期交付预定义的功能，作为特定的质量级别）、估计（单个任务花费的人力、时间）
WBS – Work Break Down
分而治之，顶层（产品）→中层（功能）-用户视角→较低级别（功能实现）-团队透视图（PM，test）→最低级别（模块）-开发透视图
第 9 章 项目经理
-
风险管理
第一步：确认风险、根据不同的来源对风险进行分类；
第二步：分析和优先级划分；
第三步：计划和管理风险
应对风险的方法：进一步研究、接受、 规避、转移、 降低、制定应急计划 -
项目经理（PM），PM负责除产品开发和测试之外的所有事情，包括正确地做产品和正确地做流程。
PM的作用：收集需求、设计用户界面，编写规范、协调市场、文档、测试、定位、带领团队达成决策
【注】项目经理是和大家平等工作，并且做具体工作，和其他团员一起形成决议，只管事不管人的，和领导型经理是不一样的。
第 10 章 典型用户和场景
一、典型用户
-
1.典型用户
定义： 描述了一组用户的典型技巧，能力，需要，工作习惯和工作环境。
电影用户的角色：也有受欢迎的和不受欢迎之分。
典型用户的完善：定义了一部分典型用户后继续与其中代表进行沟通，进一步完善需求理解。 -
2.从典型用户到场景
场景：也可以是故事，用户为达到目标使用系统时经历的所有过程。
场景的使用：设计者模拟用户，设计一个场景入口，描述用户在这个场景的内外部因素，给场景划分优先级并写场景。 -
3.从场景到任务
分层：沿着子系统/模块的所属关系把场景划分开。（例如：P221.UI层，逻辑层，数据库）
任务与场景：不同的任务将会把一个场景编织起来，得到开发任务后，可以创建和分配测试任务。
二、用例(Use Case)
-
1.用例：与典型人物，典型场景的方法类似，同样是很常用的需求分析工具包含这样的一些基本元素：标题，角色，主要成功场景，步骤，拓展场景。
用例的原则：- 1.通过简单的故事来传递信息。
- 2.保持对全系统的理解。
- 3.关注用户的价值。
- 4.逐步构建整个系统，一次完成一个用力。
- 5.增量开发，逐步构建整个系统。
- 6.适应团队不断变化的需求。
-
用例的局限性：
1.比较适合故事/人物/场景交互的系统。但是对于算法，速度，拓展性，安全性以及和系统技术相关等需求则不适用。
2.故事的粒度没有统一标准与具体项目有关，初学者较难掌握。
3.既要把UI的细节嵌入每个故事，又要保证其简明性是一个难题。
三、功能说明书（Spec）
-
1.规格说明书
软件功能说明书：说明软件的外部功能和用户的交互情况。（软件是一个黑盒子，看不到内部）
软件技术说明书：又称设计文档，说明软件的内部的设计规范。（透明盒子） -
2.功能说明书
从用户的角度描述软件产品的功能，输入，输出，界面，功能的边界问题，功能的效率（to user），国际化，本地化，异常情况等，不涉及软件内部的实现细节。 -
3.制定一份Spec
定义好相关的概念，规范好一些假设；避免一些误解，界定一些边界条件（定性且定量）；描述主流的用户/软件交互步骤；一些好的功能还会有副作用，服务质量的说明。 -
4.Spec的弊端
枯燥乏味，无法跟上时间的变化。 -
5.技术说明书
设计文档，用于描述开发者如何趋势线某一功能，或相互联系的一组功能。实现软件功能没有固定的模板，但总存在着一些规律。
四、功能驱动的设计
- 设计过程：
构造总体模型 --> 构造功能列表 --> 制定开发计划 --> 功能设计阶段5实现具体功能
第 11 章 软件设计与实现
一、分析和设计方法
-
1.四个过程：
- 1.需求分析：抽象出我们真正关心的属性，实体之间的关系。用户的需求，如何解决？
- 2.设计与实现阶段：软件如何解决这些需求，现实生活中的实体和属性在软件系统中怎么表现和交换信息？
- 3.4.测试,发布阶段：真的解决了这些需求吗，软件解决需求的效率如何，用户还有什么新的需求吗？
-
2.常用方法：
文档、图形为主构造的模型（思维导图，流程图等）、数学语言的描述、用类自然语言 + 代码构造的描述（Literate Programming）、源代码加注释描述。
二、图形建模和分析方法
- 表达实体和实体的关系
思维导图、实体关系图、ERD.UCD；表达数据的流动、表达控制流、统一的表达方式（UML）。
三、其他设计方法
- 1.形式化的方法：用无歧义的，形式化的语言描述我们要解决的问题，然后用严密的数学推理和交换一步步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。
2.文学化编程：与“写程序，时不时写一些注释”相反,“写文档，时不时写一些代码。”
四、从Spec到实现
-
1.预估开发时间
2.写一些快速成型代码，看看成效，查找问题。
3.看到初始效果与了解实现细节后，开始写设计文档，并与同事进行复审。
4.按照设计文档写代码，解决遇到的问题。
5.写好代码后先根据设计文档与代码指南进行自我复审，重构代码。
6.重建或更新单元测试。
7.得到一个可以测试的版本，交予相关测试人员测试或者公开测试。
8.修复测试中发现的问题。
9.根据代码复审的意见修改代码，完善单元测试和其他相关代码，把新的代码签入到数据库中。 -
2. 把修改集集成到代码库中
根据场景和开发任务来决定集成的次序、互相依赖的任务要一起集成。
在测试场景时，要保证端对端的测试。
场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”。 -
3.开发人员的标准工作流程（如下图所示）
五、开发阶段的日常管理
- 1.闭门造车（Leave me alone）：集中于某一件事情，将自己投入其中，拒绝其他人的干扰。
2.每日构建（Daily Bulid）：打好基础，精益求精。
3.“构建大师”：对于一个导致构建失败的成员，授予这个称号，并让他：
负责管理构建服务器 --> 调试构建，负责找错，并分析出错的原因 --> 将这个称号和责任交予下一位导致构建失败的成员 --> 构建大师为团队“构建之法基金”存入50元，以供大家团队构建之用。
4.宽严皆误：制定宽严标准，以及根据团队的情况（势）所反映的情况。成员行为影响个人的尽量宽松，而影响团队的则要严格处理。
5.小强地狱（Bug Hell）：类似于构建大师的选取：选出那些超过bug数标准的成员，让他们进入小强地狱专职于小强地狱处理bug，直到满足标准出狱，每周公布进出狱名单。
六、实战中的源代码管理
-
软件 = 程序 + 软件工程
软件的质量 = 程序的质量 + 软件工程的质量 -
代码需要版本管理
在源代码基础上进行修改后，留下新版本以及对应的负责人记录，记载bug的内容，处理人，处理时间，是否处理完成等内容以备查验。
七、代码完成
- 两个阶段：
1.task完成了，设想变成了可以运行的现实。
2.Bug仍等待着工程师去寻找，修正。
第 12 章 用户体验
一、用户体验的要素
- 1.用户的第一印象：5W1H来判断：
WhoWhenWhereWhyHow，用以判断用户对产品的设计需求。
2.从用户的角度考虑问题：从用户的立场上去使用自己的产品。而不是作为一个开发者，一个熟知产品构造的人去体验。
3.软件服务始终都要记住用户的选择。
4.短期刺激和长期影响：短期的刺激并不能成为客户长期使用的依据。
5.不让用户犯简单的错误：设计能让客户尽可能地避免出错。例如航班上的阅读灯与呼叫空乘客按纽。如果把紧急弹射座椅放在常用按钮面板按错的后果。除了文字完全没有区分度的Submit，Cancel按钮。
6.用户质量和体验：有时候质量要给用户的体验让步，才能让产品更具有吸引力。
7.情感设计
二、用户体验设计的步骤和目标
- 用户体验设计的一个重要目标就是降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差距。
如下表：
三、评价标准
- 1.尽快提供可感触的反馈。
2.系统界面符合用户的现实管理。
3.用户有控制权。
4.一致性和标准化。
5.适合各种类型的用户。
6.帮助用户识别，诊断并修复错误。
7.有必要的提示和帮助文档。
四、贯穿多种设备的用户体验
第 13 章 软件测试
-
测试方法名称非常多，但只不过是从各个方面描叙了软件测试，并不是说有这么多独立的测试方法，只要分类处理，也就不会很难理解。
-
13.1 基本名词解释与分类
三个基本名词：- Bug：软件的缺陷
- Test Case：测试用例
- Test Suite：测试用例集
-
Bug又可分解为：症状(Symptom)、程序错误(Fault)、根本原因(Foot Couse)。-
测试设计有两类方法：黑箱(Black Box)和白箱(White Box)。
【注】是测试的“设计”方法，而非测试方法。 -
黑箱从软件的行为，而非从内部设计出发来设计测试；白箱则可“看到”软件系统内部。
按测试的目的分类：功能测试、非功能测试。
按测试的时机和作用分类：测试“烽火台”，以及其他测试方法。 -
13.2 各种测试方法（该部分书中为举例了解）
① 单元测试(Unit Test) 和 代码覆盖率测试(Code Coverage Analysis)
② 构建验收测试：验收系统的基本功能。
③ 验收测试：拿到一个“可测”的构建以后，按测试计划测试各自负责的模块和功能。
④ “探索式”测试：为了某一特定目的而进行的测试，且仅此一次，以后一般不重复测试。
⑤ 回归测试
⑥ 场景/集成/系统测试：在开发一定阶段对软件进行一个全面系统的测试以保证软件的各个模块都能共同工作。
⑦ 伙伴测试
⑧ 效能测试：软件在设计负载能否提供令人满意的服务质量。
⑨ 压力测试：严格地说不属于效能测试，验证软件在超过设计负载的情况下能否返回正常结果。
⑩ 内部/外部公开测试：让特定用户使用正在处于开发阶段的版本，以便收集更多反馈。
⑪ 易用性测试
⑫ “Bug”大扫荡 -
13.3 实战中的测试观念：
1.从项目开始测试人员便要开始介入，从源头防止问题的发生。
2.测试并非一定要根据规格说明书来测，更要从用户的角度出发来测试软件。
3.测试人员的代码质量一定要特别高，因为测试人员是最后一道防线。
4.若为了让问题尽快显现，用Debug版本；若为了尽可能测试用户所看到的软件，用Release版本。
文档：在计划阶段就写出测试总纲与测试计划，它们主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责哪方面，各种资源在哪等。 -
13.4 运用测试工具
运用工具记录手工测试及自动测试。
测试效能：除功能方面的测试，还有“服务质量”
【例子】效能测试： 100个用户的情况下，产品搜索必须3S内返回结果。
负载测试： 2000个用户的情况下，产品搜索必须5S内返回结果。
压力测试： 压力高峰期（4000个用户）持续48小时的情况下，产品搜索必须保持稳定而不至于崩溃
第 14 章 质量保障
-
14.1 软件的质量
软件质量 = 程序质量 + 软件工程质量
程序质量体现在软件外在功能。例如一个字处理软件能否拷贝/粘贴等
软件工程质量：软件在功能、成本、时间三方面满足利益相关者的需求。
软件工程的质量以一套比较成熟的理论CMMI进行衡量。
质量成本组成部分包括预防、评审、内部故障、外在故障四个方面。 -
14.2 软件质量的保存工作
软件的质量保障（QA）和软件测试（Test）是有很大区别的，因此——测试的角色要独立出来，所有人都可以参与QA工作，但最后要有一个人对QA这件事负责，最后软件发布时，必须得到此角色的签字保证。尽管有专人负责测试工作，但保证质量仍是所有成员的职责。
不能盲目信任“专业人士”扮演的角色，即使有专业人士扮演的角色，还得有专人独立地检查验证质量。
分工不能“画地为牢”，为了避免出现局部最优而全局未必最优，同时也避免由于软件被切碎而导致整体不太行。
分工不能无明确责任。
第 15 章 稳定和发布阶段
-
15.1 从代码的完成到发布
软件生命周期的最后阶段往往是最考验团队的，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。
原计划的软件发布时间快到了，但是软件还存在各种问题，于是有了4种团队血型：
A型：他们知道优秀的软件公司会发布有已知缺陷的软件。
B型：他们不相信这一点。
O型：他们不知道这一点，因此嘴巴惊讶成O型。
AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型。
从代码完成到最终发布软件 -
会诊小组：软件团队的各个代表组成会诊小组，处理每个影响产品发布的问题，对于每一个Bug，会诊小组要决定采取何种行动：1.修复 2.设计本来如此 3.不修复 4.推迟
复杂项目的会诊招数：
设计变更、搞定所有已知Bug、最后回归测试、砍掉功能（不能因为以前花了成本，就要求以后一定要完成某个任务）、修复Bug的门槛逐渐提高、逐步冻结。 -
15.2 使用不同频率和不同覆盖范围的渐进发布
产品同时对不同的目标用户用不同的频率发布，以适应不同群体的需求。 -
15.3 发布之后——事后诸葛亮会议
这个软件生命的周期结束以后，如尸体解剖一样，把给软件的开发流程剖析一下。
问题集锦
1、(1.1)我看了这一段文字：
一个复杂的软件还要有各种文件和数据来描述各个程序文件之间的依赖关系、编译参数、链接参数等等。
有这个问题：再软件构建的过程中，链接参数是什么，能够起到一个什么样的功能？我查了资料，有很多种类型的链接参数，而且起到的作用也不大相同，根据我查资料后的总结，它们一定存在着一种共性，在软件开发的各个地方都可以有链接参数的影子，但我不能真切说出它们的共性。
2、(1.1)我看到了这一段文字：
软件团队的人员也会流动，新的成员要尽快读懂已有的程序，了解程序的设计，这叫程序理解。
有这个问题：在程序理解阶段，为了能够使不同的人快速接受非自己的代码，提高工作效率，打代码的时候应该要注意什么方面？我尝试上网去查找资料，但资料微乎其微，根据我的实践，在代码中添加注释是最好让别人理解的，但是这拖慢了自己的速度，总体效率仍然不够高。我的困惑是：有没有方法能够最大地提高团队合作的效率？
3、(1.1)我看到这一段文字：
商业模式决定了一个软件企业的成败。
我有这个问题：商业模式包含什么，光是商业模式是否能够真正地决定企业地成败？我上百度百科查商业模式的概念，发现商业模式有这几个要素：1、价值主张 2、消费者目标群体 3、分销渠道 4、客户关系 5、价值配置 6、核心能力 7、价值链 8、成本结构 9、收入模式 10、裂变模式；我的困惑是：人才的比重以及公司文化是否也会是影响因素？
4、（1.1）我在书上看到一个表，将软件工程师分为玩具阶段、业余爱好阶段、先行者阶段、成熟的产业阶段，
我有这样一个问题：在软件开发阶段中爱好者怎么才能晋升为先行者？根据我看书得到的结论：先行者比爱好者会接受更大更重要的计划，况且还需要资金的支持。但我还有困惑：彼此都是遭遇失败后仍然能够再次去尝试，那先行者的区别和爱好者的区别究竟在哪里？先行者遭遇失败后，没有资金的继续支持，先行者的级别会发生怎么样的变化？
5、（1.2）我在书中看到关于软件开发的几个难题：
复杂性，不可见性，易变性，服从性，非连续性。
我有这么一个问题软件工程开发有着较高的难度，但不代表不能进行开发，如何能使我们能够克服软件开发过程中的难题呢？根据我的实践，团队合作是应对这些困难的最好方法，团队分工合作，可以减少工作量，提升工作效率，但就回到之前的问题，程序员之间的代码传播该如何能够容易上手？
6、（5.2.1）书中提到软件团队的模式——“主治医师模式”：
就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。这样的软件团队中，有首席程序员，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。佛瑞德·布鲁克斯在主管 IBM System 360 项目时就采用了这种模式。
然而在1960 年代中期开始爆发了第一次软件危机,典型表现有软件质量低下、项目无法如期完成、项目严重超支等,因为软件而导致的重大事故时有发生。软件危机最典型的例子莫过于 IBM 的 System/360 的操作系统开发。在佛瑞德·布鲁克斯后来总结的《人月神话》一书中又提到：
软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。
得出的结论很简单：如果一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。
现在我们来验证一下这个解决方案。一方面，原有的开发队伍不是理想的小型强有力的团队，因为通常的共识是不超过10个人，而该团队规模如此之大，以至于至少需要两层的管理，或者说大约5名管理人员。另外，它需要额外的财务、人员、空间、文秘和机器操作方面的支持。
那么对于一个小型团队来说，如果原有的开发队伍也不是所谓的“理想的小型强有力的团队”，那么分配多人管理或者一直开除人员是不现实的。在这样一种小型团队的“主治医师模式”下，该如何避免一个学生干活，其余学生跟着打酱油的现象发生？
7、（5.2.2）书中提到软件团队的模式——“明星模式”：
主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后仍然能够保持？是这个模式要解决的问题。
对于明星来说，很容易被突如其来的成功或者被一个华丽的瞬间迷惑，从而失去自我，失去团队意识，篮球中的全明星赛就是一个很好的例子：
美国当地作家弗兰克·德福特表示：“全明星赛将成为NBA联盟最好的明星陈列馆，但是这仅仅是一个全明星而已。具有讽刺意味的是，那只是一个华丽的瞬间而已，但实际上这将被载入NBA史册，这只会让人们想起这个联盟是一个缺乏团队意识的联盟。”
当然，我们的团队并不是全明星，但是也会有因为明星个性突出而导致自身堕落甚至团队解体的可能。所以我和书中邹老师提出的问题相似：如何在明星光芒四射时使团队的利益最大化？其他团队成员要怎样配合，才能让明星时刻保持团队意识？
8、（6.4.1）书中提到敏捷总结中的“极致编程”：
Sprint/Scrum 对项目的众多需求采取分而治之的办法，能让相关人员集中精力，在一定期限内解决部分问题。它强调短时间内的迭代，在多次迭代中不断总结，改进团队的流程和产品功能。
推而广之，所谓极限编程，就是把一些认为重要和有效的做法发挥到极致，在这层意义上，“极限编程”应该叫“极致编程”。
在书中的表6-2中举例：如果了解客户的需求很重要，那么发挥到极致就变成每时每刻都有客户在身边，时时了解需求；如果计划没有变化快，那就别做详细的设计，做频繁的增量开发、重构和频繁地发布。对于一个持久合作的团队来说，他们有足够的时间来分而治之和在迭代中不断总结经验，那么在一个短期合作的团队中，要如何快速培养一个人或者一个团队把重要和有效的做法发挥到极致的能力？
9、（6）书中提到的敏捷团队：
在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。
软件开发流程有好多种，......
软件项目的团队各式各样，......
敏捷的团队大多是针对软件工程的团队而言的，但是对于我们专业也有一定的借鉴价值，在某些方面也存在一些区别。我在一篇关于软件工程和计算机专业的区别的资料中找到：
我不是专业人士,但我知道有很大区别。 软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言,它借鉴了传统工程的原则和要领,以求高效地研发高质量软件。
软件工程这一概念,主要是针对 20 世纪 60 年代"软件危机"而提出的。
我觉得我们的课程“程序设计与数据结构”与软件工程既有重合的地方，又有各自的特殊要求，那么类似于“敏捷的团队”这一观念，我们的课程“程序设计与数据结构”在其他的哪些方面还能够借鉴软件工程课程中的做法或者内容？构建之法上的哪些内容可以完全应用到我们的课程中？
10、在第7章，关于做用户调研，书中举了一个例子，
Bowman是谷歌的视觉设计主管，谷歌的一个团队不能在两个蓝色之间做出决定，所以他们在每一个蓝色之间测试41个阴影，看看哪一个表现更好。他最近就边界是否应该是3, 4，或5像素宽进行了辩论，并要求证明他的情况。我已经厌倦了辩论这种微小的设计决策
《论语》云：“如切如磋，如琢如磨。”做事要求精益求精，在进行用户调研的过程中，为什么不能调研细微到毫厘，即做调研做过头?或者说如何确定做用户调研的界限，究竟哪种调研才算是做过头呢？比如当我做用户调研时，我努力朝着最精确的方向去做，但我是否已经做过头了呢？
11、第9章中，
一个团队成熟的标记，就是对风险的管理。
在《构建之法》中如是说，几乎每个优秀的团队都会有自己独特的一套风险应对措施。关于如何应对风险，首先就应该确立态度，书上给了三种不同的态度，通过查阅百度百科，我了解到风险态度是一个专业名词，总共分为三种态度，引用该知识点如下：
风险厌恶是一个人接受一个有不确定的收益的交易时相对于接受另外一个更保险但是也可能具有更低期望收益的交易的不情愿程度。
风险中性是相对于风险偏好和风险厌恶的概念,风险中性的投资者对自己承担的风险并不要求风险补偿。我们把每个人都是风险中性的世界称之为风险中性世界(Risk-Neutral World)。
风险偏好是指人们在实现其目标的过程中愿意接受的风险的数量。
如上三种态度是一个从保守到开放的过程，这三种态度中任何一种都有其存在的理由，是不是风险中性一定是最好的选择呢，或者是求稳发育还是冒险一搏呢？
12、第9章关于项目经理PM，提到Project Manager 和Program Manager的一个区别是一个团队可以有很多Program Manager，并且是和团队其他成员进行决议。
我提出一个疑问如果一个团队中存在多个PM，他们针对一个项目形成了多个决议，这种窘况该如何解决呢?还有就是既然每个团队成员都可能当上PM，而这个职位又没有实际权力，这对团队的帮助作用真的大吗？我认为这设些带有少许管理权力的职位例如小组长效果会比较好，因为小组长是能力佼佼者，本身又能管事和管一定范围内的人，不就提高了小团队效率吗？
13、Project Manager 和 Program Manager，有一个区别在于前者管事也管人，后者只管事不管人，并且符合PM能力要求的程序员都有机会成为PM。倘若一个程序员能力很强，但是并不会管理和领导，像这样领导力较弱的PM和能力不是特别强但领导力出众的程序员相比，谁能更加胜任这一职位呢？所以PM需要有很强的领导力吗?
14、我读了第十章用例中的这一段文字：
如果软件的关键性在于用户体验的细节，那么如何把这些UI的细节嵌入每个故事中，并仍然保持故事的简明性。
经过继续的阅读和查阅资料，我知道了很多团队把目前的技术拓展为Use Case Storyboard，用一个简明的故事加上很多附加说明和图画，也就是形成功能说明书。根据我的生活经验，生活中有些药品的使用方法会使用相似的方法，例如喷雾的开启方法说明书：用图片加上文字说明的方式来介绍这个用例。我的困惑是这固然是一种解决方案，但这样将故事转变为图片经常使用例失去其故事性，变成索然无味的陈述说明。或者变成某些在图片故事穿插功能说明的有趣的引导，但这样的小故事又没有前者的包容性，通常只能涵盖很小的功能细节，但确实让使用者能够更加主动和轻松的了解其功能。那么，这两者哪一种更优或者说怎么将这两者结合起来呢？
讨论与交流
今天我们小组开展了第一次团队例会活动。我们小组将《构建之法》分为了六个部分并由六位成员先分别学习并向组长上传学习收获，这次的活动内容便是 交流前两周小组成员学习阅读《构建之法》的收获 。
在各位成员的交流中我们将自己所读的这部分内容的总结与其他人的进行交换，从而对自己还没有读到的内容有一个大致的了解。其中组员刘伟康提到的我们要形成 “交响乐队模式” 的团队是这次团队例会中大家共同赞成的观点，他提出要避免 “明星模式” 失控时一家独大的状态，让每个人都有明确的分工和职责，同时在某位成员工作暂时受到阻碍时，要有其他成员能够有能力及时补上他的工作。这样可以让团队中的每个人都最大化与格式化自己的力量，不会出现一个人干活一人偷懒的局面。同时我们也对尚未完成自己阅读项目的莫礼钟同学进行了鼓励，希望他能努力学习，在下一次交流中展现自己的学习成果。
【此次交流总结由 马军 记录】
【2017.10.11晚】
