第五章
1、 团队模式和团队的开发模式有什么关系？
团队模式是指一个团队的成员在一起合作的方式，而团队的开发模式特制软件开发团队在软件开发过程中所使用的合作方式。也就是说团队的开发模式是一种特殊的应用在软件开发领域的团队模式。
2.如果你领头开展一个全新的项目，你要怎么选择“合适”的团队模式？
如果我带头做一个全新的项目，我会选择特点不同的人，各自发挥自己的特长，类似功能团队模式，大家各司其事，平等协作。如我擅长代码编写，数据库设计，成员中还有负责需求分析的，负责文档整理和总结的，负责测试等。
3. 吵架有很多种方式和原因，有的吵架实为讨论，这样的吵架其实也是有利于产品的进步的，是提高效率的一种积极因素，可以适当鼓励；但有些却是因为个人因素(如性格原因，推卸责任等)，这种情况应该避免和遏制。避免吵架的方法我觉得有以下几种：
和PM、设计、测试的阶段：
1）、每个人清楚自己的任务和责任，自己的问题在别人提示的时候应该及时改正并有良好的认错态度，对于别人的问题应该理性的提醒
2）、就事论事，理性
和用户阶段：
1)、把用户放第一位，产品是做出来让用户使用的，并期待得到他们的认证和肯定的，认真听取他们的建议
2)、学术有专攻，很多时候用户和产品开发人员关于产品需求等的讨论是并不完善的，要懂得站在别人的角度(知识专业水平、表达方式)去看待问题，去了解用户到底是想要什么样的东西
3)、把用户当做协作开发者是快速改进代码和高效调试的无可争辩的方式
大家都是为了做出更好的产品，不如将这一次次的争吵当成对自己技术耐心的磨练，团队都是在不断的磨合中变得紧密优秀的。
4.团队精神和集体主义的区别？大家回想在小学和中学的学习过程，大家在一个班集体，有多少工作是以“团队”（Teamwork）的形式来完成的，有多少工作是以“工作组”（Workgroup)形式完成的？或许大部分工作都是以“非团队”的形式完成的。“团队精神”和平常讲的“集体主义”有什么区别？
团队精神更强调个人的主动性，团队不一定有明确领导人，成员可以有决策权，团队的每个成员还必须齐心协力，共同承担责任，每个人都有不同的技能，进行互补等。
而集体主义更多强调明确的领导人，每个人目标相同，大家的技能也有可能相同，集体中的成员也有消极懈怠的等。
3.蜂窝模式，一群人开始写代码，没有具体的分工，团队的生产的产量较低，团队之间没有直接的交流，从而影响团队绩效的评估。
主治医师模式：这个模式往往会演化成只有一个人在努力，其他的团队成员只是摆着，导致团队的整体生产能力的下降。
明星模式：明星的光芒往往会盖过其他团队成员的总和，不能达到绩效的最大化，往往明星成员的绩效影响到整个团队的绩效。
社区模式：这种模式下如果人人都贡献力量的话，那么团队的整体绩效肯定会到达提升，但是往往不是所有的人都愿意为团队做出贡献，所以团队的绩效会受到团队成员的自愿程度和贡献力量影响。
业余剧团模式：角色的交替改变，使得团队在不同的项目中绩效的大小也会随之改变，如果一个团队的成员能够充当正确的角色就会给整个团队的绩效带来最大的利益。
秘密团队：这种模式下不能对团队的绩效进行估计，所以需要团队成员自己的努力。团队成员和谐相处共同努力才能为团队带来良好的绩效。
秘密团队和特工团队则团队成员的自身能力是非常重要的，。
交响乐团模式顾名思义，指挥者指挥的好坏会直接影响到团队的绩效。
爵士乐模式，有团队成员之间的即兴发挥和状态影响绩效
功能模式影响团队绩效主要是成员之间的搭配，取得良好的绩效。
官僚模式，顾名思义，只有具有良好的沟通能力才，主要影响其绩效。
5.Chandler团队的形式和流程过于理想化，很多东西都是想当然缺乏实践的演练。但是Chandler团队具有一个良好的团队所具有的品质，他们执着，从不放弃梦想。 我们可以以从中得到一些经验和教训，对我们今后的职业生涯中有很大的作用。
第六章
我们看了这么多方法论之后，一些同学一定比较困惑，到底选择哪一种开发方法比较好呢? 这在实践中不是难题，有学者还列出了一些简单的问题来帮助人们做决定：
表6-3 问题引出方法
问题
Yes – 偏向传统的瀑布+文档的流程
No – 偏向敏捷流程
1. 项目需要有明确的spec 么？
2. 项目没有明确的用户，也无法联系用户进行沟通
3. 软件系统是大型的么？
4. 软件系统是复杂的么？例如实时系统
5. 软件的生命周期很长么？
6. 你使用比较差的软件工具么？
7. 软件项目成员是分布在不同的地区么？
8. 团队是否有“文档为先”的传统？
9. 团队的编程技术较差么？
10. 要交付的软件系统是否要通过某种行业规定或行政法规的批准？
11.用户是否在开发完成才看到结果？
12.项目是否一次性交付？
6.3.2 团队建造软件的方式
1.boss等人抓住市场动态，获取需求
2.开发人员根据需求提出设计方案
3.讨论方案可行性并加以改进
4.着手开始写(做不到敏捷开发，so code and fix)
5.编码同时伴随测试，并结合用户需求和开发找到平衡点
6.开发完成，投放市场，收取反馈并修改产品，进入下次迭代
第七章
第一题：Barry Boehm总结的软件工程原则与MSF和Agile：
1、这个原则注重分阶段的计划，而MSF和Agile更加注重灵活的开发。
2、 这个原则要求持续地检查认证，争取在早期发现问题，而MSF和Agile也要求早期地发现问题，但是是通过尽可能早地做出产品来实现。
3、 这个原则坚持规范的产品控制，而MSF和Agile更加在乎的是成员之间的交流。
4、 这个原则以及MSF和Agile都使用现代的编程方法和工具，但是使用的方法和工具略有不同。
5、 这个原则的开发过程确保团队成员能分阶段，分模块，而MSF和Agile中的每个团队成员都要为项目负责。
6、 这两种原则都用少而精的人员，减少交流成本。
7、 这个原则通过总结来实现软件过程和质量的提高，而MSF和Agile通过总结更多地会提高团队成员的能力。
第二题：MSF原则和Barry Boehm提出的原则的区别：
MSF是敏捷开发，而Barry Boehm提出的原则偏向传统软件开发类型，强调明确的需求。
MSF预期变化，而Barry Boehm提出的原则是早期发现错误和问题，
MSF强调商业价值，而Barry Boehm提出的原则坚持规范的流程，
程序员的自身修养和工作素质是有不同层次的，软件工程中的那些概念和工作原则只是一种评判的准则，旨在帮助程序员在不断评判自身和提高自身的，但也不能一味听从于这些准则，因人而异，因事而异吧。
第八章需求分析
2题第二问你要写一个企业管理软件, 你要找谁去做用户调研?请列出你认为重要的用户类型和你认为合适的用户调研的方式。
员工—大部分使用系统的用户
老板—需要从系统中了解公司的发展情况
系统管理员—负责管理这套系统的人
基层领导—在日常工作中与员工共同使用
员工和基层领导应该是最重要的用户类型，因为他们是主要使用这个系统的人。
3、应该怎么都不可能恢复到平均每天30小时的工作量，因为预定的时间已经用完。
4、我感觉这样的项目经理比较好，因为使用太长时间来开动员大会这种事情确实浪费了大多数人的时间。因为在项目开始后，每个人对项目的目标应该都是很清楚，现在主要的问题是集中精力解决项目中遇到的具体问题，这样子的开一天的动员大会完全是没有必要的。项目经理更加为项目和项目成员考虑。
转载于:https://www.cnblogs.com/flym/p/4022849.html
