两人合作的不同阶段和技巧

1.      萌芽阶段

以跳舞为例,两人刚刚认识,拘谨而彬彬有礼。这一阶段的现象:两人刚刚相互认识,这时大家都有礼貌,一般交流不少,每个人都想得到对方的接纳,试图避免冲突和容易引起挑战的观点。对即将进行的舞蹈,有不同的期望值,但是双方彼此并不了解。

2.      磨合阶段

开始跳舞,开始踩脚。解除之后,才感到手足无措,眼睛不知道往哪里看,才能感受到对方原来舞步是这样的……这样的笨拙。

3.      规范阶段

跳舞逐渐和谐,合拍,团队成员就很多事情取得了一致。一些不成文或成文的规则逐步建立起来了。男方轻轻的一个手势,女方就知道如何旋转。

4.      创造阶段

跳舞二人合而为一,为艺术而舞蹈。并不是所有的合作都能达到这一阶段,磨合太多后,我们还可能进入“解体阶段”。

5.      解体阶段

散伙,各走各的独木桥,回宿舍抱着板凳跳舞,或者另找舞伴。

影响他人的几种方式:

断言:感情很强烈,适用于有充分信任的同伴。语言,语调,肢体语言都能帮助传递强烈的信息。

桥梁:给双方充分条件互相了解。

说服:有条理,建立在逻辑分析的基础上。即使不能全部说服,对方也可能接受不分意见。

吸引:可以有效地传递信息,但是要注意信息的准确性。夸张的渲染会降低个人的可信度。

没有绝对正确或错误的方法,只有合适或者不合适的方法。几种方法可以同时使用,同时要注意,软件行业的从业人员还是理性思考的比较多。

时间: 2024-10-13 05:36:02

两人合作的不同阶段和技巧的相关文章

构建之法学习(第四章 两人合作)

第四章 两人合作 1.代码规范  1)代码风格规范.主要是文字上的规定,看似表面文章,实际上非常重要. *原则:简明,易读,无二义性 *缩进:4个空格 *行宽:行宽必须限制,可以限定为100字符 *括号:在复杂的条件表达式中,用括号清除地表示逻辑优先级 *断行与空白的{}行:推荐格式如下 if ( condition ) {        DoSomething(); } else {       DoSomethingElse(); } *分行:不要把多条语句放在一行上.并且,不要把多个变量定

2018--20179215--《构建之法(第三版)》第四章 两人合作

构建之法 第四章 读书笔记 4.1代码规范 代码规范可以分为两部分: 代码风格规范-主要是文字上的规定 代码设计规范-牵涉到程序设计.模块之间的关系.设计模式等方方面面的通用原则 4.2代码风格规范 代码风格的原则是:简明,易读,无二义性. 缩进:4个空格的距离阅读性最好. 行宽:可限制为100个字符. 分行:不要把多条语句放在一行,每个"{"和"}"单独占一行,不要把多个变量放在同一行. 命名:不要提到类型或其他语法方面的描述:避免过多的描述:避免可要可不要的修饰

《构建之法》--两人合作

本周学习的是<构建之法>的第四章,这章的主题是两人合作,看到这个题目我的第一反应是现在两人合作的项目还很多吗?因为我一直认为一个项目一般是几个人或是十几个人这样的团队来合作完成的,这个思想也不知道是看到了什么有的.值得一提的是,书中的第五章就是讲团队合作的. 合作的最小单位是两个人,合作过程中必然存在着个人看法,比如一个人看另一个人的代码时就不一定同意其看法了,每个人心中对于好代码的定义也不尽相同,这时候就很有必要给出一个基准线--什么是好的代码规范和设计规范. 看到课本上代码清单4-1,的确

两人合作源代码管理的基本操作

在编写程序过程中,程序代码不仅仅是给机器看,同时也会给与之合作的完成软件的同伴看,但是如果程序代码不符合代码规范,就很难让除自己之外的人看懂. 两人合作时的不同阶段和技巧: 1.萌芽阶段 两人刚开始合作,交流不少,试图避免冲突和容易引起挑战的观点,两人有不同的期望值,但是双方彼此并不了解. 2.磨合阶段 合开合作,但是会有不同程度的摩擦. 3.规范阶段 双方代码逐渐相似,一些不成文的规则逐步建立起来了. 基本操作: 在分析好需求,确定了最终设计文档后,需要设计具体的代码. 在设计代码前,需要确定

读构建之法 第四章:两人合作

程序员写的代码最终是人在看,所以代码规范很重要,原则是:简明,易读,无二义性. 不光是程序书写的格式问题,还牵涉到程序设计.模块之间的关系.设计模式等方方面面. 代码复审的正确定义看代码是否在代码规范的框架内正确的解决了问题 代码复审的目的在于: 1.找出代码的错误,比如: 1)编码错误,比如一些碰巧骗过了编译器的错误 2) 不符合团队代码规范的地方 2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的 3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等 4. 发现潜在的错误

第4章两人合作

1.结对项目的案例和论文 因为教材上给的案例是全英文的,而我的英语水平是异常异常的烂,看见英语就头疼,就没有了看见下去的欲望,我在网上找到了邹欣老师的观点,以下是他的观点. 总结1:那是project到了比较关键的创造阶段,整整一天,我们俩椅子靠椅子的坐在电脑前,一边讨论一般coding,那次才真正的体会到结对真的能够带来效率.一整天的coding是容易走神的事,还好有pair在旁边指导,总是不断在我敲某某变量之前提前告诉我成员变量的名字,数据修改时帮忙检查是否有漏掉的,变量和函数定义的时候一起

三读《构建之法》——源代码的设计、实现、控制与两人合作

现在,<构建之法>的一大半已经读完了,在这一大半本书中,这一部分可以说是对我触动最大的,也应该是整本书对我触动最大的. 整个第二章围绕测试展开,用一个很生动的类比告诉了我们测试的重要性:如果有人说,"一个人写写程序玩玩,单元测试似乎不那么重要.",那么你可以回应他:"你可以大胆对你的女朋友说:'我们只是玩一玩.'看看效果如何". namespace DemoUser{ public class User{ public User(String userE

读完第四章《两人合作》的内容后的总结

两人合作是团队合作的基础:这里介绍的这个基础型"团队"中通用的一些方法以及最重要的--交流--的细节 1.代码规范 代码风格规范.主要是文字上的规定: 缩进:4个空格,而不是tab: 关于断行与空白的{}行 下划线:用来分割变量名字中的作用域标注和变量的语义 大小写:通用的做法是,所有的类/函数名都采用所有单词首字母大写(Pascal)的形式:所有的变量首字母小写,随后的单词首字母大写(Camel): 注释:解释程序做什么.为什么这样做以及要特别注意的地方.注释只用ASCII码字符,不

构建之法 第四章 两人合作

两人合作是团队合作的基础:这里介绍的这个基础型"团队"中通用的一些方法以及最重要的--交流--的细节 1.代码规范 代码风格规范.主要是文字上的规定: 缩进:4个空格,而不是tab: 关于断行与空白的{}行:[作者的建议深得我心--{ .}单独占一行:中间的代码缩进] 下划线:用来分割变量名字中的作用域标注和变量的语义 大小写:通用的做法是,所有的类/函数名都采用所有单词首字母大写(Pascal)的形式:所有的变量首字母小写,随后的单词首字母大写(Camel): 注释:解释程序做什么.