第五章

Posted 2020-11-20 lgx19

一。团队模式和团队的开发模式有什么关系？

软件团队的模式包括以下几种：

（1）主治医师模式：一人为主，其他人为此人服务。

（2）明星模式：主治医师模式到达极致，一人的光芒掩盖所有人。

（3）社区模式：每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。

（4）业余剧团模式：在不同项目中每个人扮演着不同的角色，可能随着项目的改变，自己的角色也会发生变化。

（5）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

（6）特工团队模式：有一些有特殊技能的专业人士组成的团队。

（7）交响乐团模式：人员工具齐全，准备充足的团队。

（8）爵士乐模式：相对自由，有风险，人少且不靠谱。

（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。

（10）官僚模式：层层领导的团队模式。

团队的开发模式包括以下几种：

（1）写了再改模式：和一窝蜂团队模式比较像。

（2）瀑布模型及其各种变形。

（3）RUP统一流程。

（4）老板驱动的流程。

（5）渐进交付的流程。

（6）TSP的原则。

至于团队模式和团队的开发模式的关系，我个人的理解是一群人在一起做软件开发，总是要一些方式方法。而这里团队模式就是这一群人的定性，团队的开发模式则是这群人使用的方法的定性。

二。如果你领头开展一个全新的项目，你要怎么选择“合适”的团队模式？

一个团队最重要的是氛围，一个向上、充满斗志的氛围是非常重要的，好的氛围远远比一个人艰难困苦挣扎坚持重要。大家可以设想，一个大家争先恐后去战斗的团队和在一个士气低牢骚满天下的团队，哪个团队里的个人更容易胜利？那么作为一个团队的带头人，要创造一个好的氛围。

1、每个人的性格很重要，并且对合作之间有着很大影响，所以要找一些性格合的过来的团队人员。

2、每个人都是不同的，每个人的专业技能也是不同，每个人在自己所涉及的领域中都可能是强者，所以大家在合作中可以交流感想，可分工，谁做哪一个模块，这样效率会很高。

三。不同的团队模式如何影响团队绩效的评估？

       一个好的团队模式自然会有一个好的团队绩效，团队模式很重要。不同的团队模式，在团队绩效评估时，会考虑很多不同的因素。比如，一个很严谨，从上到下都是一板一眼的团队，在对于其绩效的评估时候，就会更加按照公司给的要求和客户的反应等等来进行评估，而对于更加“人性化”的团队来说，在做评估时，可能更多的会考虑人的因素，比如，当评估结果不理想时，可能出来在按照公司要求和客户反应来反思的同时，还会可能想到“也许是大家最近太累了，或是负责那一不理想的模块的人最近家里有些事情等等”。

       不同的团队模式，在团队绩效评估时，会考虑很多不同的因素。

　　比如，一个很严谨，从上到下都是一板一眼的团队，在对于其绩效的评估时候，就会更加按照公司给的要求和客户的反应等等来进行评估。

 

　　而对于更加“人性化”（指要求上并不是绝对只按规章制度去做事的，有其灵活想的一面。）的团队来说，在做评估时，可能更多的会考虑人的因素，比如，当评估结果不理想时，可能出来在按照公司要求和客户反应来反思的同时，还会可能想到“也许是大家最近太累了，或是负责那一不理想的模块的人最近家里有些事情等等”。

四。团队精神和集体主义的区别？    

大家回想在小学和中学的学习过程，大家在一个班集体，有多少工作是以“团队”（Teamwork）的形式来完成的，有多少工作是以“工作组”（Workgroup)形式完成的？或许大部分工作都是以“非团队”的形式完成的。“团队精神”和平常讲的“集体主义”有什么区别？

（1）。团队精神：简单来说就是大局意识、协作精神和服务精神的集中体现。团队精神的基础是尊重个人的兴趣和成就。核心是协同合作，最高境界是全体成员的向心力、凝聚力，反映的是个体利益和整体利益的统一，并进而保证组织的高效率运转。

（2）。集体主义：是一种价值观。我们坚持集体主义原则，就是坚持社会本位原则，即社会与个人相比，具有更高的价值。其次，它是一种人生观。它提倡人们积极地为社会作贡献，每个人都要在为社会作贡献的过程中，通过壮大社会利益来满足自己的个人利益。这和资产阶级提倡个人主义，希望通过增加个人利益以壮大集体利益恰恰相反。再次，它是一种道德规范。一方面，集体利益和个人利益是统一的:集体应该尽最大努力，提供最完善的服务，以实现人的全面发展;个人只有在集体中才能获得最大的自由，应该尽最大努力为集体的完善而奋斗。

（3）。它们在现实社会的发展过程中都发挥着积极作用，在处理个体和群体，个体和个体之间关系上相似的合理内核。

（4）。“团队精神”和“集体主义”来说，前者是内在的体现，后者是有外在的约束的存在。对于内在的体现，由内向外的展示是存在自愿的情感的，外在的约束是带有一种强制的感情的。

五。阅读 《梦断代码》  (Dreaming in Code) 这本书，分析Chandler 团队的形式和流程，它们各有什么优缺点?

（1）。我在网上查了一下这本书以下是《梦断代码》的简介：本书写的是作者罗森伯格对OSAF主持的Chandler项目进行田野调查，跟踪经年，试图借由Chandler的开发过程揭示软件开发中的一些根本性大问题。本书是讲一事，也是讲百千事;是写一软件，也是写百千软件;是写一群人，也是写百千万人。任何一个在软件领域稍有经验的技术人员看完本书，必掩卷长叹:做软件难。软件乃是人类自以为最有把握，实则最难掌控的技术。

（2）。Chandler团队的形式和流程过于理想化，很多东西都是想当然缺乏实践的演练。但是Chandler团队具有一个良好的团队所具有的品质，他们执着，从不放弃梦想。 我们可以以从中得到一些经验和教训，对我们今后的职业生涯中有很大的作用。

六。有人说 - 现代软件工程分为四个阶段：和PM 吵   和设计吵    和测试吵    和用户吵； 你觉得应该如何避免吵架?

 吵架有很多种方式和原因，有的吵架实为讨论，这样的吵架其实也是有利于产品的进步的，是提高效率的一种积极因素，可以适当鼓励；但有些却是因为个人因素(如性格原因，推卸责任等)，这种情况应该避免和遏制。避免吵架的方法我觉得有以下几种：

和PM、设计、测试的阶段：

（1）。每个人清楚自己的任务和责任，自己的问题在别人提示的时候应该及时改正并有良好的认错态度，对于别人的问题应该理性的提醒。

（2）。就事论事，理性。

和用户阶段：

（1）。把用户放第一位，产品是做出来让用户使用的，并期待得到他们的认证和肯定的，认真听取他们的建议。

（2）。学术有专攻，很多时候用户和产品开发人员关于产品需求等的讨论是并不完善的，要懂得站在别人的角度(知识专业水平、表达方式)去看待问题，去了解用户到底是想要什么样的东西。

（3）。把用户当做协作开发者是快速改进代码和高效调试的无可争辩的方式，大家都是为了做出更好的产品，不如将这一次次的争吵当成对自己技术耐心的磨练，团队都是在不断的磨合中变得紧密优秀的。

七。软件开发有流程，硬件开发和生产当然也有，请看硬件生产的流程（此流程不包括硬件设计）这样的“生产”流程和软件“生产”的流程有什么区别呢？

       对于硬件的生产流程，是从从一点点的芯片或是模块开始一点一点的去组装的，软件的生产流程是从一个一个的功能模块一个字母一个字母的敲打出来的，要说硬件生产和软件生产的区别我认为最大的不同之处就是，软件是一种根据人的思维，根据特定的算法创造出来的，硬件是现实中存在的东西，用这些东西去做的。

八。.很多流程的目的是帮助大家减少风险，确保质量，但是流程未必全都是正面作用。请看下面的故事：

走六天流程改一行代码：

 

这种情况需要改进么。如何改进？

大家可以先读一下上面超链接里面提到的故事，6天时间只修改了一行代码，这个故事确实向我们展示了在流程上面花费和占用了不少时间？但是可以看到其实里面很多时间都花费在了两个核心的地方。

　　（1）。是团队成员没有形成基础的团队词汇表或者说对流程规范本身就不熟悉，

　　（2）。是在流程推行前期需要做的诸多基础数据配置工作并没有完成，而是等到流程需要的才在处理。

　　（3）。我们对领导或经理出差状况下相应的应急处理机制没有明确制定，也导致了时间上的拖延。

   　这种情况是绝对需要改进的，走六天改于行代码，说明管理上存在问题，效率绝对低下。当我们谈过程的时候更加强调了流程，人和方法工具技术三者之间的有机融合，这有这三者完美整合好，才可能形成一个高效率的体系。对于团队成员对流程规范等方面要做好工作，要提前做好工作，对于领导的出差时间要做好记录。这样的相铺相成才能提高效率。