首页 > 代码库 > 第五——十三章的作业
第五——十三章的作业
第五章
1.团队模式和团队的开发模式有什么关系？
团队模式指团队的分工模式，团队内部的结构，团队开发模式指团队开发的流程及步骤
2.如果你领头开展一个全新的项目，你要怎么选择“合适”的团队模式？
根据团队的能力和项目的结构，选择合适的团队模式。如果大家都比较自觉，且其中有一人能力较强，就会选择主治医师模式。如果项目比较复杂且每个人都有自己熟悉的开发领域，会选择功能团队模式。如果项目在不同方向和领域都有任务，就会选交响乐团模式。如果是开放式项目，可能会选择爵士乐模式。如果开发的人非常多，会选择官僚模式。
3.不同的团队模式如何影响团队绩效的评估？
主治医师主要看主刀医师的发挥以及其他人的配合；明星模式主要看明星的发挥；社区模式看大家的热情；业余剧团模式是锻炼人的学习能力，如果队员学习能力出色的话团队绩效会不错；秘密团队和特工团队主要看队员的能力；交响乐团模式看指挥员的指挥，一般绩效比较稳定；爵士乐模式看队员大家当时的状态；功能模式看功能的搭配；官僚模式看沟通
4.团队精神和集体主义的区别？ 大家回想在小学和中学的学习过程，大家在一个班集体，有多少工作是以“团队”（Teamwork）的形式来完成的，有多少工作是以“工作组”（Workgroup)形式完成的？或许大部分工作都是以“非团队”的形式完成的。“团队精神”和平常讲的“集体主义”有什么区别？
团队精神更强调个人的主动性，团队是由员工和管理层组成的一个共同体，该共同体合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。集体主义则强调大家共同性。两者具体区别如下：
1：在领导方面。群体应该有明确的领导人；团队可能就不一样，尤其团队发展到成熟阶段，成员共享决策权。
2：目标方面。群体的目标必须跟组织保持一致，但团队中除了这点之外，还可以产生自己的目标。
3：协作方面。群体的协作性可能是中等程度的，有时成员还有些消极，有些对立；但团队中是一种齐心协力的气氛。
4：责任方面。群体的领导者要负很大责任，而团队中除了领导者要负责之外，每一个团队的成员也要负责，甚至要一起相互作用，共同负责。
5：技能方面。群体成员的技能可能是不同的，也可能是相同的，而团队成员的技能是相互补充的，把不同知识、技能和经验的人综合在一起，形成角色互补，从而达到整个团队的有效组合。
6：结果方面。群体的绩效是每一个个体的绩效相加之和，团队的结果或绩效是由大家共同合作完成的产品。
5.阅读《梦断代码》 (Dreaming in Code) 这本书，分析Chandler 团队的形式和流程，它们各有什么优缺点?
Chandler 太过理想，推出太迟，很难赢得市场份额。但它蕴含的执着精神、始终不曾放弃梦想的实践，则具有更大价值。从实用角度，作为一款工具，大家可能都不太会去选择Chandler。但从价值观和信念角度，我觉得大家都应该去了解Chandler，了解他的内涵。
6.有人说 - 现代软件工程分为四个阶段：和PM 吵和设计吵和测试吵和用户吵；你觉得应该如何避免吵架?
多沟通。在设计之初定好需求，明确需求。在编码阶段注意交流，随时做出一些可以工作的软件交付给用户和测试，让他们给一些意见和建议，对于正确的意见和建议在接下来的编码中改进。
第六章
6.3.1 什么时候适合选择敏捷
选择合适的开发模型需要增加的问题：
1.团队人员的对软件的应用领域很熟悉吗？
2.项目的风险高吗？
3.项目的使用对象有些什么人？
4.项目的需求明确吗？
5.软件的更新周期长吗？
6.3.2讨论软件开发的思潮
在列举的一系列文章中其中一篇文章讲的是敏捷开发，强调了个人和互动高于流程和工具，工作软件高于理解文档，客户协作高于合同协商，变化响应高于计划遵循。在我们进行软件开发的时候，需要真正的落实敏捷开发的理念。用敏捷开发来做事，需要在开发的过程中找到适合的位置，慢慢的向目标靠近。知道目标就要立即行动去实现，做到真正的敏捷，不要只是说敏捷这个词，不能让敏捷这个词失去其意义。在软件开发过程中，要尽可能的做到自己的责任。有付出，才会有回报。有人负责才会有质量。一个软件的开发需要团队所有的人共同的来负责，这样才能做出好的软件好的效果。
第七章
7.7移山开发方法——比TFS敏捷更精简
我对二柱观点的看法是：软件工程里面确实有很多的概念和一些名词以及流程，这些东西不是像二柱说的没用，软件工程的这些东西是前人经验的总结可以给我们在开发的时候一个大的框架。程序员自身的修养和完成工作的素质确实是软件开发中不可缺少的部分，但是熟知了软件工程里面所讲的概念，并且能运用到开发中才能成为一个修养很高的程序员。
第八章
2．老板：有哪些功能，能如何帮助企业管理什么事情，能否达到自己的需求
管理员：是否易用
员工：会管理哪些方面的事情，需要注意什么
3．不可能
4. 不好，容易引起团队内的冲突，以及团队与领导间的不融洽。团队应该勇于适应变化，而不是照搬规律和计划。
第九章
1．有
2．都有点擅长是是会不是
3．长途汽车：速度一般灵活性一般不便宜
火车：速度较快灵活性一般比较便宜
自驾：速度一般灵活性强比较便宜
飞机：速度很快灵活性一般贵
自行车：速度慢灵活性强基本免费
第十章
1．只看到了用户的语言和行动，没有看到语言行动背后的动机
3．取钱的，查余额的，转账的，改密码的，存钱的，管理员
4．没有
第十一章
1、需要我们在做需求分析的时候尽量做的全面一些，不要漏掉一些重要的细节。在中途修改会带来很多的额外工作量，给开发带来极大的不便。
3、如何避免诧异的反应
当客户对我们的软件不了解的时候我们需要尽量的给用户解释，而且我们在设计软件的时候也尽量的要考虑用户的感受，从用户的角度去考虑问题。
4、团队成员只要尽自己的力量去做了事情，一般都能完成预先计划的任务。
5、编写代码是为了解决问题，一步步搭建起一个软件的框架。
第十二章 用户体验
1、 什么时候开始考虑用户体验？
用户体验应该在软件具有了初步的功能之后开始，根据不同的用户人群来设置不同的软件使用方法，以及不同的功能。比如在设计老人使用的软件的时候就尽量要精简，能达到主要的功能就好，在给年轻人用的时候就尽量展现软件的全部功能。
2、 个人电脑界面的演变
个人电脑从最初的有三个按键的鼠标，和最先的图形界面的使用。到现在的最新版本的电脑经历不很多的变化。软件的界面也是我们经常使用的软件的见面word2003到word2007的界面就是一个很大的变化，软件界面始终都是迎合用户体验来的，用户有什么要求，软件设计就会尽量的往那个方面发展。导致这些变化的原因主要是因为现在计算机技术的发展，硬件的技术上升使得电脑可以显示的内容越来越丰富，编程技术的上升也使得现在的电脑可以给用户带来更好的体验。
3、评论手头软件的用户体验
我们经常使用的软件比如输入法QQ拼音等，现在的输入法当你输入一个新的词语输入法都会记住，然后下次当我们再次输入时QQ拼音就会自动弹出。QQ拼音在记住用户选择这个方面做的很好，可以给我们一个好的用户体验。
4.1、产品设计的细节-确定/取消
确定在左边取消在右边比较好，符合人们日常的习惯，用退出、保存比用OK、Cancel要好，在中国毕竟大部分人对英语不是很了解。
4.2、产品设计细节
我觉得设计静音按键时应该把声音全部关闭，包括闹钟！我们可以在用户按静音时给用户提示，告诉他闹钟不会响了。
5、A/B测试和道德
我觉得能够影响用户的情绪，因为做测试的一般都是相信结果的人。不过为了一些科学实验做测试也没什么问题。
第十三章
13.5.9 可以使用Visual Studio IDE运行测试，还可以从命令运行手动测试之外的测试组或任何单项测试。支持的测试类型有
单元测试 ：由执行项目功能和方法的代码组成。
Web 测试：包括一系列可以从浏览器会话创建或记录的 HTTP URL。
通用测试：允许使用您的团队现有的自动测试和自动工具。
负载测试：模拟多个用户运行您的自动测试。
手动测试：逐步完成还未自动执行的任务。
13.5.10 设计的测试用例要覆盖代码所有的路径 分支和谓词层次与结构清晰 代码复用率高 每个接口都可以做黑盒测试 改进时做好单元测试
13.5.11 以前的代码如果参数里的文件是/dev/stdin时就会导致程序出现问题，而参数里的文件是普通的文件就不会出现问题。
第五——十三章的作业