团队合作

[ 现代软件工程 讲义 ] 团队合作要经历的阶段 1 萌芽阶段 萌芽（Forming）阶段，就像小苗破土而出，柔弱但充满希望。在这个时候，团队成员刚刚接触到团队的宗旨，同时很可能刚刚互相认识。在学校的环境中，一些同学只是匆忙地加入一个团队，加入团队的原因并不是因为他们对团队的目标很认同, 而是多种多样的 (这个团队有大牛，我可以少做一些； 别的团队人满了，就剩这个了； 平时在一起混的还可以，就加入吧； 这个团队有女生，我要加入！ ... ). 团队的目标只是听说过，但是并没有真正达成一致。团队缺少一个明确的领导，团队成员也非常依赖领导的指导。其它特征： （1）个人的角色和职责不清楚，做事的规程往往被忽略。 （2）这时大家都有礼貌，一般交流不少，每个人往往想得到其他队友的接纳，试图避免冲突和容易引起挑战的观点。团队的成员在有意无意地探知同伴和领导的做事方式和容忍度。 （3）成员也在琢磨任务到底有多大，怎么去完成它。 （4）每个人都忙着适应环境、团队结构、角色、日常流程等。正是由于这些原因，严重的问题不一定能够及时地提出来讨论。重要的事情并不能够真正得到解决。 （5）开始各种各样的讨论。成员们对于组织结构有不少看法，对完成任务的困难也有不少讨论，但是还没有把注意力集中到解决问题上。这时已经有人对太多的讨论感到不耐烦了。 原因：大家都是来自五湖四海，项目还处于萌芽状态，每个人的能力

(1)第一次scrum团队合作我们首先制作了一个长大tips的登录界面，但是我们还没有实现其具体功能，只是做出了其面板模样，如下图所示： 以及其用例图如下 （2）任务完成情况 由于本组实力略低，组员分工尚未十分明确，而且课业繁忙，所以目前只构建了大致框架。部分观点还未统一，还存在分歧，还需进行下一次团队交流，解决出现的部分问题，进一步完善框架，抓紧完成长大Tips。 （3）个人感想 因为这是第一次团队合作开发一个软件，各方面做得还不是很好，对于我们来说还是有点难度的。但是我们会认真学习，克服困难，从而完善长大Tips。 来源： https://www.cnblogs.com/mljs666/p/7758189.html

在学习《软件工程》这门课之前，总是会用很简单的思维去理解表面的意义，而学了这门课， 才真正知道了软件工是一门很有趣，很有深度的课。 通过这学期的学习，我学到了很多专业上的知识，老师上课的方式也是很独特的，通过博客的 方式让我接触了之前没有接触过的博客，在博客园里也看到了其他很多优秀的文章，使我受益匪浅。 在课堂上，从一开始的个人编程，到结对编程，再到团队合作，从中我也学到了很多，有的时 候一意孤行是行不通的，团队合作在很多地方是非常重要的，团队合作当中每个人各有分工，同时 也提高了一个项目的工作效率。 老师每节课讲的非常好，非常感谢老师在这学期对我们的教导，让我学习到很多《软件工程》 的专业知识。 来源： https://www.cnblogs.com/songziwei/p/11954334.html

一.项目名称：教室选座系统 二.项目进度表： 项目进度表 活动名称 所属阶段 计划开始时间 计划结束时间 实际结束时间 完成情况 项目方向 项目确立阶段 2019.11.14 2019.11.15 2019.11.15 已完成 项目需求分析的总结 初步设计阶段 2019.11.15 2019.11.16 2019.11.16 已完成 确定未来实现方向 2019.11.16 2019.11.17 2019.11.18 已完成 APP具体功能实现 2019.11.17 2019.11.18 2019.11.18 已完成 网站设计 实现设计阶段 2019.11.18 2019.11.19 2019.11.19 已完成 环境确定 2019.11.19 2019.11.20 2019.11.20 已完成 市场价值 运营模式确立阶段 2019.11.20 2019.11.21 2019.11.21 已完成 商业模式 2019.11.21 2019.11.22 2019.11.22 已完成 三.对合作过程的评价 我们需要把一群一直“独干、单干、自己说了算”的开发者组织起来形成一个团队，让这个团队的成员与成员之间能够良好的相互交流，互通有无。这是一件十分困难的事情。难在团队个人的主观意识太强，总认为自己的想法无可取代。造成在项目中各种观点充斥，紊乱而繁于整理，不能快速的理出开发的中心思想

一.项目名称：教室选座系统 二.项目进度表： 项目进度表 活动名称 所属阶段 计划开始时间 计划结束时间 实际结束时间 完成情况 项目方向 项目确立阶段 2019.11.14 2019.11.15 2019.11.15 已完成 项目需求分析的总结 初步设计阶段 2019.11.15 2019.11.16 2019.11.16 已完成 确定未来实现方向 2019.11.16 2019.11.17 2019.11.18 已完成 APP具体功能实现 2019.11.17 2019.11.18 2019.11.18 已完成 网站设计 实现设计阶段 2019.11.18 2019.11.19 2019.11.19 已完成 环境确定 2019.11.19 2019.11.20 2019.11.20 已完成 市场价值 运营模式确立阶段 2019.11.20 2019.11.21 2019.11.21 已完成 商业模式 2019.11.21 2019.11.22 2019.11.22 已完成 三.对合作过程的评价 我们需要把一群一直“独干、单干、自己说了算”的开发者组织起来形成一个团队，让这个团队的成员与成员之间能够良好的相互交流，互通有无。这是一件十分困难的事情。难在团队个人的主观意识太强，总认为自己的想法无可取代。造成在项目中各种观点充斥，紊乱而繁于整理，不能快速的理出开发的中心思想

课程总结 　　 随着课程到了到了最后一周，本学期也逐渐进入尾声。很感谢老师能给我们提供了这样的一种体验——团队协作，体会到了在团队里的那种氛围，尤其是在任务分配、分工合作，和归纳总结。 回想起初，课程刚开始时，期待着能跟着老师学到知识，以及实际的开发能力。老师也很努力的为我们合理的安排课后作业，从个人的开发项目到团队的分工合作都和课程有着紧密联系。我们从分发的书籍中《构建之法-现代软件工程》也可以很详细的了解到实际的开发情况，以及需要考虑到的各种问题。虽然在实际的个人开发的过程中会很痛苦，要么是为如何开发下一步想法摸不着头脑，要么就是被一些小细节小问题拖住进程的小尾巴，但回头一想这么坚持下去不但能让自己的动手能力逐步的提升，而且能对自己动手解除问题的（烧脑脱发）速度有所加快，在这些成就感的推动下一想便痛并快乐着。 作为小白的我，经过了在老师带领的课程后，尤其是在课程的后半部分，我们开始的人员进行组队、讨论开发项目、发表项目、分工任务、实际开发，最后的项目演示及答辩，对与软件工程有了些个人的理解，课程书籍里的老师也给了很多关于团队合作成功的人物。随深刻明白，所有事情的成功是离不开团队之间的共同合作。 再次感谢老师在这么庞大的班级里，努力指导每个同学，也很感谢助教同学们为老师分担了许多工作量，谢谢为我们付出这么多，我们也从课程中收获了很多专业上的知识。 来源： https://www

软件工程算是我这学期比较喜欢的一门课程了，老师讲课幽默风趣十分吸引大家的兴趣，本来我属于转专业来的，基础差底子相对薄弱，在别的科目中感觉需要花更多时间精力，但是在软件工程课上，学到很多团队协作的小技巧，这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容。在课程中让我们组成团队来做团队项目，这不仅可以加强自己团队合作能力，还能从中得到意想不到的好处，因为以后工作，我们都要融入团队，在团队中开发项目而且在团队合作中，组内有很多大神，积极正确的引导与帮助，让我觉得相对轻松，使用的教材《构建之法》第三版这本书，书里都是用有趣的例子来给我们讲解有关软件工程的一些知识，让我们在简单易懂的基础上更加喜欢这门课程。在初步了解了这本书的内容之后，我觉得整本书通过个人项目、两人合作、 团队合作等逐层递进的讲述方法带我们了解和学习软件工程这门课。通过这一学期的学习我喜欢并且热爱自己的专业。教材十分生动也是吸引我热爱这门课程的主要原因之一。 还有就是通过团队合作认识了很多新朋友也使我感觉收获颇丰，组内的很多编程大神还有一个口才非常好的大神让我们组在最后一节课展示时艳压全场。虽然我底子浅一直在进步但是贡献不多，但是浓浓的参与感还是让我为这个团队骄傲，参与的每一次讨论，都让我受益匪浅。在其中，学会了代码设计规范的重要性及结对编程每一个人的作用与角色

一个人生活在现代社会中，若说不懂如何与人合作，是绝对无法长久立足的。而合作共同完成一项工作，必不可少的就是要评价各个人对团队的贡献和成效，衡量作为一个团队中的一员的表现。 这个问题，有时难有时易，当然要根据事实情况的不同来“具体问题具体分析”了。完成工作的多少自然是一定要考虑的，然而只重视量而忽略了质依然不合理。举个例子，一组工人搬砖头，如果说将砖头随便一丢至目的地而导致了满地残渣，其他队员该接受这个表现最好的说法吗？自然不会。再说一个剧组排演话剧，一般来说，我们貌似都是把主角们视作关注的焦点，认为他们自然是对剧组贡献最大的。但其实又如何能够否认整个剧幕下那些不太吸引眼球的角色的功用，比如说一棵树、一个龙套，没有了这些那些的“微不足道”，什么的都不可能完整。只要做到各司其职，并且司到最好，是出色的团队绩效不可或缺的因素。 再拿我们做软件工程的项目为例，什么 PM ， Test 的，码 code 的，要做出一个好的项目还真是不容易啊，牵扯到各式各样的角色分配和相互之间的胡作。每个队员最起码要做到的就是完成自己应该做的部分，也就是按时按量按质。任何一个分支的拖欠 delay 都会给整个项目的进展带来很大的困难，就好像旋转的链条某一小节出了 bug ，整条链子上的其他部分都得停下自己的脚步等待。这样一来，损失是不是蛮严重的呢？所以，我认为吧，要评判某个成员的绩效