2017-2018-1 Java演绎法 第一周 做业

团队学习：《构建之法》

• 【团队成员】：

  学号	姓名	负责工做
  20162315	马军	平常统计，项目部分代码
  20162316	刘诚昊	项目部分代码，代码质量测试
  20162317	袁逸灏	组长，项目 主要 代码
  20162319	莫礼钟	市场推广，广告策划
  20162320	刘先润	项目部分代码，动画效果
  20162330	刘伟康	项目总结博客，平常管理，代码质量测试

  【注】个别成员在没有具体工做时会进行动态分配。

【本次团队贡献及完成度】

• 团队组长：袁逸灏
  本次编辑：刘伟康

• 【步骤】合做分工 → 大体内容框架 → 提出问题

  团队贡献及完成度

  Members	Personal Contribution	Completion and Time(h)
  袁逸灏	第一、二、3章及问题1~5	100%　　4.5
  刘伟康	第四、五、6章，建立团队博客，编辑博客及问题6~9	100%　　8.5
  刘先润	第七、八、9章及问题10~13	100%　　7.0
  马军	第十、十一、12章，问题14及交流会总结	100%　　3.0
  刘诚昊	第1三、1四、15章	70%　　 3.0
  莫礼钟	第1六、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、典型用户

• 1.典型用户
  定义： 描述了一组用户的典型技巧，能力，须要，工做习惯和工做环境。
  电影用户的角色：也有受欢迎的和不受欢迎之分。
  典型用户的完善：定义了一部分典型用户后继续与其中表明进行沟通，进一步完善需求理解。

• 2.从典型用户到场景
  场景：也能够是故事，用户为达到目标使用系统时经历的全部过程。
  场景的使用：设计者模拟用户，设计一个场景入口，描述用户在这个场景的内外部因素，给场景划分优先级并写场景。

• 3.从场景到任务
  分层：沿着子系统/模块的所属关系把场景划分开。（例如：P221.UI层，逻辑层，数据库）
  任务与场景：不一样的任务将会把一个场景编织起来，获得开发任务后，能够建立和分配测试任务。

2、用例(Use Case)

• 1.用例：与典型人物，典型场景的方法相似，一样是很经常使用的需求分析工具包含这样的一些基本元素：标题，角色，主要成功场景，步骤，拓展场景。
  用例的原则：
  • 1.经过简单的故事来传递信息。
  • 2.保持对全系统的理解。
  • 3.关注用户的价值。
  • 4.逐步构建整个系统，一次完成一个用力。
  • 5.增量开发，逐步构建整个系统。
  • 6.适应团队不断变化的需求。
• 用例的局限性：
  1.比较适合故事/人物/场景交互的系统。可是对于算法，速度，拓展性，安全性以及和系统技术相关等需求则不适用。
  2.故事的粒度没有统一标准与具体项目有关，初学者较难掌握。
  3.既要把UI的细节嵌入每一个故事，又要保证其简明性是一个难题。

3、功能说明书（Spec）

• 1.规格说明书
  软件功能说明书：说明软件的外部功能和用户的交互状况。（软件是一个黑盒子，看不到内部）
  软件技术说明书：又称设计文档，说明软件的内部的设计规范。（透明盒子）

• 2.功能说明书
  从用户的角度描述软件产品的功能，输入，输出，界面，功能的边界问题，功能的效率（to user），国际化，本地化，异常状况等，不涉及软件内部的实现细节。

• 3.制定一份Spec
  定义好相关的概念，规范好一些假设；避免一些误解，界定一些边界条件（定性且定量）；描述主流的用户/软件交互步骤；一些好的功能还会有反作用，服务质量的说明。

• 4.Spec的弊端
  枯燥乏味，没法跟上时间的变化。

• 5.技术说明书
  设计文档，用于描述开发者如何趋势线某一功能，或相互联系的一组功能。实现软件功能没有固定的模板，但总存在着一些规律。

4、功能驱动的设计

• 设计过程：
  构造整体模型 --> 构造功能列表 --> 制定开发计划 --> 功能设计阶段5实现具体功能

第 11 章 软件设计与实现

1、分析和设计方法

• 1.四个过程：
  • 1.需求分析：抽象出咱们真正关心的属性，实体之间的关系。用户的需求，如何解决？
  • 2.设计与实现阶段：软件如何解决这些需求，现实生活中的实体和属性在软件系统中怎么表现和交换信息？
  • 3.4.测试,发布阶段：真的解决了这些需求吗，软件解决需求的效率如何，用户还有什么新的需求吗？
• 2.经常使用方法：
  文档、图形为主构造的模型（思惟导图，流程图等）、数学语言的描述、用类天然语言 + 代码构造的描述（Literate Programming）、源代码加注释描述。

2、图形建模和分析方法

• 表达实体和实体的关系
  思惟导图、实体关系图、ERD.UCD；表达数据的流动、表达控制流、统一的表达方式（UML）。

3、其余设计方法

• 1.形式化的方法：用无歧义的，形式化的语言描述咱们要解决的问题，而后用严密的数学推理和交换一步步把软件实现出来，或者证实咱们的实现的确完整和正确地解决了问题。
  2.文学化编程：与“写程序，时不时写一些注释”相反,“写文档，时不时写一些代码。”

4、从Spec到实现

• 1.预估开发时间
  2.写一些快速成型代码，看当作效，查找问题。
  3.看到初始效果与了解实现细节后，开始写设计文档，并与同事进行复审。
  4.按照设计文档写代码，解决遇到的问题。
  5.写好代码后先根据设计文档与代码指南进行自我复审，重构代码。
  6.重建或更新单元测试。
  7.获得一个能够测试的版本，交予相关测试人员测试或者公开测试。
  8.修复测试中发现的问题。
  9.根据代码复审的意见修改代码，完善单元测试和其余相关代码，把新的代码签入到数据库中。

• 2. 把修改集集成到代码库中
  根据场景和开发任务来决定集成的次序、互相依赖的任务要一块儿集成。
  在测试场景时，要保证端对端的测试。
  场景的全部者必须保证场景彻底经过测试，而后把场景的状态改成“解决”。

• 3.开发人员的标准工做流程（以下图所示）
  

5、开发阶段的平常管理

• 1.闭门造车（Leave me alone）：集中于某一件事情，将本身投入其中，拒绝其余人的干扰。
  2.每日构建（Daily Bulid）：打好基础，精益求精。
  3.“构建大师”：对于一个致使构建失败的成员，授予这个称号，并让他：
  负责管理构建服务器 --> 调试构建，负责找错，并分析出错的缘由 --> 将这个称号和责任交予下一位致使构建失败的成员 --> 构建大师为团队“构建之法基金”存入50元，以供你们团队构建之用。
  4.宽严皆误：制定宽严标准，以及根据团队的状况（势）所反映的状况。成员行为影响我的的尽可能宽松，而影响团队的则要严格处理。
  5.小强地狱（Bug Hell）：相似于构建大师的选取：选出那些超过bug数标准的成员，让他们进入小强地狱专职于小强地狱处理bug，直到知足标准出狱，每周公布进出狱名单。

6、实战中的源代码管理

• 软件 = 程序 + 软件工程
  软件的质量 = 程序的质量 + 软件工程的质量

• 代码须要版本管理
  在源代码基础上进行修改后，留下新版本以及对应的负责人记录，记载bug的内容，处理人，处理时间，是否处理完成等内容以备查验。

7、代码完成

• 两个阶段：
  1.task完成了，设想变成了能够运行的现实。
  2.Bug仍等待着工程师去寻找，修正。

第 12 章 用户体验

1、用户体验的要素

• 1.用户的第一印象：5W1H来判断：Who When Where Why How，用以判断用户对产品的设计需求。
  2.从用户的角度考虑问题：从用户的立场上去使用本身的产品。而不是做为一个开发者，一个熟知产品构造的人去体验。
  3.软件服务始终都要记住用户的选择。
  4.短时间刺激和长期影响：短时间的刺激并不能成为客户长期使用的依据。
  5.不让用户犯简单的错误：设计能让客户尽量地避免出错。例如航班上的阅读灯与呼叫空乘客按纽。若是把紧急弹射座椅放在经常使用按钮面板按错的后果。除了文字彻底没有区分度的Submit，Cancel按钮。
  6.用户质量和体验：有时候质量要给用户的体验让步，才能让产品更具备吸引力。
  7.情感设计

2、用户体验设计的步骤和目标

• 用户体验设计的一个重要目标就是下降用户的认知阻力，即用户对于软件界面的认知和实际结果的差距。
  以下表：
  

3、评价标准

• 1.尽快提供可感触的反馈。
  2.系统界面符合用户的现实管理。
  3.用户有控制权。
  4.一致性和标准化。
  5.适合各类类型的用户。
  6.帮助用户识别，诊断并修复错误。
  7.有必要的提示和帮助文档。

4、贯穿多种设备的用户体验

第 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.1)我看到了这一段文字：

软件团队的人员也会流动，新的成员要尽快读懂已有的程序，了解程序的设计，这叫程序理解。

有这个问题：在程序理解阶段，为了可以使不一样的人快速接受非本身的代码，提升工做效率，打代码的时候应该要注意什么方面？我尝试上网去查找资料，但资料微乎其微，根据个人实践，在代码中添加注释是最好让别人理解的，可是这拖慢了本身的速度，整体效率仍然不够高。个人困惑是：有没有方法可以最大地提升团队合做的效率？

三、(1.1)我看到这一段文字：

商业模式决定了一个软件企业的成败。

我有这个问题：商业模式包含什么，光是商业模式是否可以真正地决定企业地成败？我上百度百科查商业模式的概念，发现商业模式有这几个要素：一、价值主张 二、消费者目标群体 三、分销渠道 四、客户关系 五、价值配置 六、核心能力 七、价值链 八、成本结构 九、收入模式 十、裂变模式；个人困惑是：人才的比重以及公司文化是否也会是影响因素？

四、（1.1）我在书上看到一个表，将软件工程师分为玩具阶段、业余爱好阶段、先行者阶段、成熟的产业阶段，
我有这样一个问题：在软件开发阶段中爱好者怎么才能晋升为先行者？根据我看书获得的结论：先行者比爱好者会接受更大更重要的计划，何况还须要资金的支持。但我还有困惑：彼此都是遭遇失败后仍然可以再次去尝试，那先行者的区别和爱好者的区别究竟在哪里？先行者遭遇失败后，没有资金的继续支持，先行者的级别会发生怎么样的变化？

五、（1.2）我在书中看到关于软件开发的几个难题：

复杂性，不可见性，易变性，服从性，非连续性。

我有这么一个问题软件工程开发有着较高的难度，但不表明不能进行开发，如何能使咱们可以克服软件开发过程当中的难题呢？根据个人实践，团队合做是应对这些困难的最好方法，团队分工合做，能够减小工做量，提高工做效率，但就回到以前的问题，程序员之间的代码传播该如何可以容易上手？

六、（5.2.1）书中提到软件团队的模式——“主治医师模式”：

就像在手术台上那样，有一个主刀医师，其余人（麻醉，护士，器械）各司其职，为主刀医师服务。这样的软件团队中，有首席程序员，他/她负责处理主要模块的设计和编码，其余成员从各类角度支持他/她的工做（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。佛瑞德·布鲁克斯在主管 IBM System 360 项目时就采用了这种模式。

然而在1960 年代中期开始爆发了第一次软件危机,典型表现有软件质量低下、项目没法如期完成、项目严重超支等,由于软件而致使的重大事故时有发生。软件危机最典型的例子莫过于 IBM 的 System/360 的操做系统开发。在佛瑞德·布鲁克斯后来总结的《人月神话》一书中又提到：

软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差别，但实际测量出的差别仍是令咱们全部的人吃惊。

得出的结论很简单：若是一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。

如今咱们来验证一下这个解决方案。一方面，原有的开发队伍不是理想的小型强有力的团队，由于一般的共识是不超过10我的，而该团队规模如此之大，以致于至少须要两层的管理，或者说大约5名管理人员。另外，它须要额外的财务、人员、空间、文秘和机器操做方面的支持。

那么对于一个小型团队来讲，若是原有的开发队伍也不是所谓的“理想的小型强有力的团队”，那么分配多人管理或者一直开除人员是不现实的。在这样一种小型团队的“主治医师模式”下，该如何避免一个学生干活，其他学生跟着打酱油的现象发生？

• 参考：程序设计思想发展，《人月神话》

七、（5.2.2）书中提到软件团队的模式——“明星模式”：

主治医师模式运用到极点，能够蜕化为明星模式，在这里，明星的光芒盖过了团队其余人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落以后仍然可以保持？是这个模式要解决的问题。

对于明星来讲，很容易被突如其来的成功或者被一个华丽的瞬间迷惑，从而失去自我，失去团队意识，篮球中的全明星赛就是一个很好的例子：

美国当地做家弗兰克·德福特表示：“全明星赛将成为NBA联盟最好的明星陈列馆，可是这仅仅是一个全明星而已。具备讽刺意味的是，那只是一个华丽的瞬间而已，但实际上这将被载入NBA史册，这只会让人们想起这个联盟是一个缺少团队意识的联盟。”

固然，咱们的团队并非全明星，可是也会有由于明星个性突出而致使自身堕落甚至团队解体的可能。因此我和书中邹老师提出的问题类似：如何在明星光芒四射时使团队的利益最大化？其余团队成员要怎样配合，才能让明星时刻保持团队意识？

• 参考：全明星比赛缺少团队意识 伟大联盟应完美结合

八、（6.4.1）书中提到敏捷总结中的“极致编程”：

Sprint/Scrum 对项目的众多需求采起分而治之的办法，能让相关人员集中精力，在必定期限内解决部分问题。它强调短期内的迭代，在屡次迭代中不断总结，改进团队的流程和产品功能。

推而广之，所谓极限编程，就是把一些认为重要和有效的作法发挥到极致，在这层意义上，“极限编程”应该叫“极致编程”。

在书中的表6-2中举例：若是了解客户的需求很重要，那么发挥到极致就变成每时每刻都有客户在身边，时时了解需求；若是计划没有变化快，那就别作详细的设计，作频繁的增量开发、重构和频繁地发布。对于一个持久合做的团队来讲，他们有足够的时间来分而治之和在迭代中不断总结经验，那么在一个短时间合做的团队中，要如何快速培养一我的或者一个团队把重要和有效的作法发挥到极致的能力？

九、（6）书中提到的敏捷团队：

在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。

软件开发流程有好多种，......

软件项目的团队各式各样，......

敏捷的团队大可能是针对软件工程的团队而言的，可是对于咱们专业也有必定的借鉴价值，在某些方面也存在一些区别。我在一篇关于软件工程和计算机专业的区别的资料中找到：

我不是专业人士,但我知道有很大区别。 软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言,它借鉴了传统工程的原则和要领,以求高效地研发高质量软件。

软件工程这一律念,主要是针对 20 世纪 60 年代"软件危机"而提出的。

我以为咱们的课程“程序设计与数据结构”与软件工程既有重合的地方，又有各自的特殊要求，那么相似于“敏捷的团队”这一观念，咱们的课程“程序设计与数据结构”在其余的哪些方面还可以借鉴软件工程课程中的作法或者内容？构建之法上的哪些内容能够彻底应用到咱们的课程中？

• 参考：软件工程专业与计算机专业的区别是什么

十、在第7章，关于作用户调研，书中举了一个例子，

Bowman是谷歌的视觉设计主管，谷歌的一个团队不能在两个蓝色之间作出决定，因此他们在每个蓝色之间测试41个阴影，看看哪个表现更好。他最近就边界是否应该是3, 4，或5像素宽进行了辩论，并要求证实他的状况。我已经厌倦了辩论这种微小的设计决策

《论语》云：“如切如磋，如琢如磨。”作事要求精益求精，在进行用户调研的过程当中，为何不能调研细微到毫厘，即作调研作过头?或者说如何肯定作用户调研的界限，究竟哪一种调研才算是作过头呢？好比当我作用户调研时，我努力朝着最精确的方向去作，但我是否已经作过头了呢？

十一、第9章中，

一个团队成熟的标记，就是对风险的管理。

在《构建之法》中如是说，几乎每一个优秀的团队都会有本身独特的一套风险应对措施。关于如何应对风险，首先就应该确立态度，书上给了三种不一样的态度，经过查阅百度百科，我了解到风险态度是一个专业名词，总共分为三种态度，引用该知识点以下：

风险厌恶是一我的接受一个有不肯定的收益的交易时相对于接受另一个更保险可是也可能具备更低指望收益的交易的不情愿程度。

风险中性是相对于风险偏好和风险厌恶的概念,风险中性的投资者对本身承担的风险并不要求风险补偿。咱们把每一个人都是风险中性的世界称之为风险中性世界(Risk-Neutral World)。

风险偏好是指人们在实现其目标的过程当中愿意接受的风险的数量。

如上三种态度是一个从保守到开放的过程，这三种态度中任何一种都有其存在的理由，是否是风险中性必定是最好的选择呢，或者是求稳发育仍是冒险一搏呢？

十二、第9章关于项目经理PM，提到Project Manager 和Program Manager的一个区别是一个团队能够有不少Program Manager，而且是和团队其余成员进行决议。
我提出一个疑问若是一个团队中存在多个PM，他们针对一个项目造成了多个决议，这种窘况该如何解决呢?还有就是既然每一个团队成员均可能当上PM，而这个职位又没有实际权力，这对团队的帮助做用真的大吗？我认为这设些带有少量管理权力的职位例如小组长效果会比较好，由于小组长是能力佼佼者，自己又能管事和管必定范围内的人，不就提升了小团队效率吗？

1三、project manager和program manager有一个区别在于前者管事也管人，后者只管事无论人，而且符合PM能力要求的程序员都有机会成为PM。假若一个程序员能力很强，可是并不会管理和领导，像这样领导力较弱的PM和能力不是特别强但领导力出众的程序员相比，谁能更加胜任这一职位呢？因此PM须要有很强的领导力吗?

1四、我读了第十章用例中的这一段文字：

若是软件的关键性在于用户体验的细节，那么如何把这些UI的细节嵌入每一个故事中，并仍然保持故事的简明性。

通过继续的阅读和查阅资料，我知道了不少团队把目前的技术拓展为Use Case Storyboard，用一个简明的故事加上不少附加说明和图画，也就是造成功能说明书。根据个人生活经验，生活中有些药品的使用方法会使用类似的方法，例如喷雾的开启方法说明书：用图片加上文字说明的方式来介绍这个用例。个人困惑是这当然是一种解决方案，但这样将故事转变为图片常用例失去其故事性，变成索然无味的陈述说明。或者变成某些在图片故事穿插功能说明的有趣的引导，但这样的小故事又没有前者的包容性，一般只能涵盖很小的功能细节，但确实让使用者可以更加主动和轻松的了解其功能。那么，这二者哪种更优或者说怎么将这二者结合起来呢？

讨论与交流

　　今天咱们小组开展了第一次团队例会活动。咱们小组将《构建之法》分为了六个部分并由六位成员先分别学习并向组长上传学习收获，此次的活动内容即是 交流前两周小组成员学习阅读《构建之法》的收获 。
　　在各位成员的交流中咱们将本身所读的这部份内容的总结与其余人的进行交换，从而对本身尚未读到的内容有一个大体的了解。其中组员刘伟康提到的咱们要造成 “交响乐队模式” 的团队是此次团队例会中你们共同同意的观点，他提出要避免 “明星模式” 失控时一家独大的状态，让每一个人都有明确的分工和职责，同时在某位成员工做暂时受到阻碍时，要有其余成员可以有能力及时补上他的工做。这样可让团队中的每一个人都最大化与格式化本身的力量，不会出现一我的干活一人偷懒的局面。同时咱们也对还没有完成本身阅读项目的莫礼钟同窗进行了鼓励，但愿他能努力学习，在下一次交流中展示本身的学习成果。

【这次交流总结由 马军 记录】
【2017.10.11晚】

参考资料

• 构建之法（第三版）

• 程序设计思想发展

• 《人月神话》

• 全明星比赛缺少团队意识 伟大联盟应完美结合

• 软件工程专业与计算机专业的区别是什么