1.团队模式和团队的开发模式有什么关系？
答：
首先我来解释一下这两个名词：
我查资料了解了一下，团队模式，更偏向于多人合作的那种，而且我理解的“团队”会是一种多人合作的情况下，长期磨合后的一个组织，他们是相互了解的，是拥有巨大的默契存在的。
对于团队的开发模式我并没有查到具体的解释，但对于开发模式，是有查到几种开发模式，比如瀑布开发模式、快速应用开发模式等等，我们在其他的课上有学过这些模式，所以我在这里认为开发模式是更偏向于后边的“模式”两个字的，更注重方法，用什么方法。
通过以上说明，我个人认为他们之间的关系是：团队模式是一种组织的存在，而团队的开发模式更注重于方法，团队采用什么样的方法开开发项目。
2.如果你领头开展一个全新的项目，你要怎么选择“合适”的团队模式？
http://www.cnblogs.com/tjuscs2014/p/4023221.html
答：
首先，对于进入公司组建团队来说，我的看法是，一个人要学会融入，对于刚入职的员工来说要尽快熟悉公司的环境，尽快找到合适的团队加入，做开发我始终认为这是需要团队的，不管一个人技术怎么过硬，都是需要团队的帮助和鼓舞的，对于团队我认为长期合作相互了解的团队才是好的团队。
其次，对于“合适”一词，从开发上来说，各个方向的程序员都有，完成这个项目需要什么样的技术的人，这是“合适”一词体现的重点，这样才能使项目更舒畅的开发。
对于课本上讲的那几种团队模式，我会选择“交响乐团”这种模式，因为我希望我们团队的成员是多才多艺又是各司其职的，会的东西多，而且都有自己的专长。当然交响乐团演奏靠谱，同时看指挥的这一点，也体现了我们的一个观点，就是一个项目团队得有领头人（项目经理），这是重要的一点。
最后，如果我是领头人、项目经理的话，我会在最一开始就先组建一个大的团队，不是为了开发项目，而是为了磨合，举行适当的活动，增进大家的了解，然后再遇到具体的项目的时候从这些人中选出在技术领域更适合开发这个项目的人去组成小队。而绝对不是当拿到一个项目的时候临时找人去组队，这样不利于团队更快的合作。
3.不同的团队模式如何影响团队绩效的评估？
答：
不同的团队模式，在团队绩效评估时，会考虑很多不同的因素。
比如，一个很严谨，从上到下都是一板一眼的团队，在对于其绩效的评估时候，就会更加按照公司给的要求和客户的反应等等来进行评估。
而对于更加“人性化”（指要求上并不是绝对只按规章制度去做事的，有其灵活想的一面。）的团队来说，在做评估时，可能更多的会考虑人的因素，比如，当评估结果不理想时，可能出来在按照公司要求和客户反应来反思的同时，还会可能想到“也许是大家最近太累了，或是负责那一不理想的模块的人最近家里有些事情等等”。
4.团队精神和集体主义的区别？
大家回想在小学和中学的学习过程，大家在一个班集体，有多少工作是以“团队”（Teamwork）的形式来完成的，有多少工作是以“工作组”（Workgroup)形式完成的？或许大部分工作都是以“非团队”的形式完成的。“团队精神”和平常讲的“集体主义”有什么区别？
答：
首先“精神”一词，我对其的了解是指人的意识、思维活动和一般心理状态，它是刻画在人的内在的东西。“主义”指最高理想和准则，比如说某某主义指以某某为最高理想和准则的思想体系。它有前提的要求，更加的体制化。
其次对于“团队精神”和“集体主义”来说，前者是内在的体现，后者是有外在的约束的存在。对于内在的体现，由内向外的展示是存在自愿的情感的，外在的约束是带有一种强制的感情的。
回想我的小学初中或是高中有的内容是“非团队”的形式存在的，比如说作业的完成。。。嘻嘻嘻嘻。有的是以“团队”的形式完成的。
5.阅读 《梦断代码》 (Dreaming in Code) 这本书，分析Chandler 团队的形式和流程，它们各有什么优缺点?
答：
首先，阅读《梦断代码》这本书我在写这篇博客之前的没有做到的，希望自己以后有机会可以了解一下这本书。
其次，我在网上查了一下这本书以下是《梦断代码》的简介：本书写的是作者罗森伯格对OSAF主持的Chandler项目进行田野调查，跟踪经年，试图借由Chandler的开发过程揭示软件开发中的一些根本性大问题。本书是讲一事，也是讲百千事;是写一软件，也是写百千软件;是写一群人，也是写百千万人。任何一个在软件领域稍有经验的技术人员看完本书，必掩卷长叹:做软件难。软件乃是人类自以为最有把握，实则最难掌控的技术。
好吧，我本想在网上查查这个问题然后Ctrl+v过来呢。结果并没有找到这个问题的确切答案，我还是如实的说吧，，，这道题我先欠着，等我真正的读了之后我定会回来补上它。 我现在就去找找资源，，，嘻嘻，（我比较穷买不起正版的书）好在资源被我找到了，现在也分享给大家，咱们一起学习学习。https://pan.baidu.com/s/14OIUiIDfTSDjJkA1DNEcVA 分享的网盘资源。
6.有人说 - 现代软件工程分为四个阶段：和PM 吵 和设计吵 和测试吵 和用户吵； 你觉得应该如何避免吵架?
答：
“吵”是一种不和谐的体现，为什么会吵呢，因为意见不合，为了避免吵架，就要相互多交谈意见，针对不同的意见要心平气和的交谈，毕竟吵架是不能解决问题的，没准还会让问题更加的严峻，更不利于项目的发展。
7.软件开发有流程，硬件开发和生产当然也有，请看硬件生产的流程（此流程不包括硬件设计）：http://dwz.cn/1W1qbn
这样的“生产”流程和软件“生产”的流程有什么区别呢？
答：对于硬件的生产流程，是从从一点点的芯片或是模块开始一点一点的去组装的，软件的生产流程是从一个一个的功能模块一个字母一个字母的敲打出来的，要说硬件生产和软件生产的区别我认为最大的不同之处就是，软件是一种根据人的思维，根据特定的算法创造出来的，硬件是现实中存在的东西，用这些东西去做的。
8.很多流程的目的是帮助大家减少风险，确保质量，但是流程未必全都是正面作用。请看下面的故事：
走六天流程改一行代码：htttp://blog.jobbole.com/19772/
这种情况需要改进么，如何改进？（在这里好像说不需要改进，嘻嘻嘻）
答：
大家可以先读一下上面超链接里面提到的故事，6天时间只修改了一行代码，这个故事确实向我们展示了在流程上面花费和占用了不少时间？但是可以看到其实里面很多时间都花费在了两个核心的地方。
其一是团队成员没有形成基础的团队词汇表或者说对流程规范本身就不熟悉，
其二是在流程推行前期需要做的诸多基础数据配置工作并没有完成，而是等到流程需要的才在处理。
再次，我们对领导或经理出差状况下相应的应急处理机制没有明确制定，也导致了时间上的拖延。
这种情况是绝对需要改进的，走六天改于行代码，说明管理上存在问题，效率绝对低下。当我们谈过程的时候更加强调了流程，人和方法工具技术三者之间的有机融合，这有这三者完美整合好，才可能形成一个高效率的体系。对于团队成员对流程规范等方面要做好工作，要提前做好工作，对于领导的出差时间要做好记录。这样的相铺相成才能提高效率。
原文地址：https://www.cnblogs.com/w527064207/p/9172079.html