团队游戏大全无敌风火轮一、项目类型: 团队协作竞技型二、道具要求: 报纸、胶带三、场地要求: 一片空旷的大场地四、游戏时间: 10 分钟左右五、详细游戏玩法: 12-15 人一组利用报纸和胶带制作一个可以容纳全体团队成员的封闭式大圆环,将圆环立起来全队成员站到圆环上边走边滚动大圆环。六、活动目的: 本游戏主要为培养学员团结一致, 密切合作, 克服困难的团队精神; 培养计划、组织、协调能力; 培养服从指挥、一丝不苟的工作态度; 增强队员间的相互信任和理解。齐眉棍一、游戏简介: 全体分为两队, 相向站立, 共同用手指将一根棍子放到地上, 手离开棍子即失败,这是一个考察团队是否同心协力的体验。在所有学员手指上的同心杆将按照培训师的要求团队建设游戏室内拓展, 完成一个看似简单但却最容易出现失误的项目。此活动深刻揭示了企业内部的协调配合之问题。二、游戏人数: 10-15 人三、场地要求: 开阔的场地一块四、需要器材:3米长的轻棍五、游戏时间: 30 分钟左右六、活动目的:在团队中,如果遇到困难或出现了问题,很多人马上会找到别人的不足,却很少发现自己的问题。队员间的抱怨、指责、不理解对于团队的危害??这个项目将告诉大家:“照顾好自己就是对团队最大的贡献”。
提高队员在工作中相互配合、相互协作的能力。统一的指挥 所有队员共同努力对于团队成功起着至关重要的作用。驿站传书一、游戏类型:团队协作型二、游戏目的:使学员强烈意识到,充分沟通对团队目标实现的重要意义; 制度规则的建立与修正。三、游戏介绍:全队成员排成一列,你们每个人这时候就相当于一个驿站, 到时候培训师会把一个带有 7 位数以内的数字信息卡片交到最后一位伙伴的手中, 你们要利用你们的聪明才智把这个数字信息传到最前面这位伙伴的手中. 当这位伙伴收到信息以后呢要迅速的举手,并把当然了信息写在纸片上交给最前面的培训师!! 比赛总共会进行四轮. 在信息传递的过程当中我们会有一些规则来约束. : 项目开始后:( 所谓项目开始是指培训师喊开始, 信息从后面一位伙伴开始传递那刻起) 1, 不能讲话. 2. 不能回头 3. 后面的伙伴的任何部位不能超过前面人身体的肩缝横截面以及无限延伸面.( 前后标准要以最前面的某个物品做参照, 比如白板. 离白板近则为前, 离白板远则为后) 4. 当信息传到最前面伙伴手中时, 这位伙伴要要迅速举手示意, 并把信息交到白板附近的培训师手中,计时会以举手那一刻为截止时间. 5. 不能传递纸条和仍纸条. 6. 项目的最终解释权和裁判权归培训师( 要解释清楚团队建设游戏室内拓展, 某些很有争议的方法, 和我们培训的整个中心相吻合算正确, 背离则算错误) 7. 第一轮时间≤2 分钟. ( 给出 8 分钟的讨论时间, 然后回来 PK) 第二轮:以前规则继续生效, 新的规则增加: 8,第一轮所有方法不能再使用. 9. 不能传递和扔任何物品. 10. 第二轮时间≤1 分钟(给出7 分钟的讨论时间, 然后回来 PK) 第三轮:以上规则继续生效, 新的规则增加 11, 第一轮第二轮所有方法不能使用. 12. 第三轮时间≤40秒(给出6 分钟的讨论时间, 然后回来 PK) 第四轮: 以上规则继续生效, 新的规则增加 13. 前三轮所有方法不可用. 14. 屁股不可以离开地面 15. 第四轮时间≤ 20秒坐地起身一. 项目类型: 团队合
前言
在1997年，开源运动的领导者之一 Eric S·发表文章，阐述了开源项目两种不同开发模式，并将其比喻为「大教堂模式」与「集市模式」。随后在 1999 年出版成书，被称为开源圣经的《大教堂与集市》。
在Linux的开源世界里，采用的是“集市”模式，更多是自主、自发、自我的协作和创作，面对未知的领域，通过-Up自下而上，Linux是颠覆性的，并取得了巨大的成功。
受此启发，对于商业软件系统、对于企业、对于创业团队，应该采用哪种开发流程、哪个协作模式，才不会混乱、才不会内耗、反而更能让项目取得成功呢？
标准化研发流程搭建思路和方向
一家企业，从招聘软件开发工程师、产品经理、技术经理、测试人员到组建开发团队，在日常企业办公过程中，在国内，与国外的氛围不同，需要在内部制定一套标准化的研发流程，明确每个岗位、每个人员需要共事的流转流程。不能过于崇尚所谓的敏捷开发而任其个人自我发挥。
在过往十多年的研发管理过程中，我发现，不管是做游戏开发，还是做电商行业；不管是几个人的创业团队，还是几百人成熟企业亦或是上市公司，作为老板、CTO、技术管理者、或技术经理，都需要在内部明确一套标准化的开发流程，甚至还需要在企业大范围内明确好和其他部门进行跨部门沟通协作的大流程。
没有流程那不行；有了标准化的研发流程却不匹配你的现状也不行；流程匹配了但不执行也不行；执行了却没有及时动态调整升级你的流程也不行。总而言之，研发流程不是万能的，没有最好的说法，只有更合适。更适合你和你自己团队的，就是更好的。匹配，更重要。
我曾经在给一家做SaaS解决方案的企业做技术顾问时，就见证了他们研发从痛苦到规范化的成长过程。一开始，他们内部也有明确研发流程，但是不匹配。表现出来的症状是什么呢？最明显、最为痛苦、最尴尬的莫过于在每次要给*大客户进行系统演示时，总会出现这样那样的问题，验收时总掉链子。老板很尴尬、很纠结也很无力感，明明知道问题出现在那，却不知道怎么规避和从根本上解决。员工和团队也很累，天天都很忙，验收演示前一晚总得要加班到很晚，第2天一演示还是有问题。开发说是测试的问题，测试说是开发的问题，差点都要拍桌子干起来，怎么办？！
后来经过梳理发现，背后的流程明显不匹配产品开发和交付的现状。例如：缺少统一的预发布环境，都是在开发人员本地电脑上进行联调测试，在验收前直接合并发布到正式环境，东拼西凑，总会有这个那个的遗漏设计团队搭建，没有统一进行集成测试。又如：每次演示时经常会出现数据库报错。为什么？因为数据库新加的字段又没忘了同步到正式数据库！后来要求每一次DDL和DML都要记录到git代码仓库中，发布前统一申请线上数据库变更，有了记录和变更申请的环节，后来这类问题就给杜绝了。还有：以前每次发布都是人工进行操作，没有做到自动化、一键发布，甚至那边正在验收开大会投大屏演示，这边还在手动发布改正式环境，那有系统不崩的道理。很多问题，都是流程不规范、操作不规范、不透明、不科学导致的。
归根到底，要么是流程有问题、要么是沟通有问题、要么是太依赖于人员和手工操作，导致每一次交付的质量和效率，都不如人意。
为此，老板总是私下问我：软件开发，怎么就那么难？
管理者需要一个好工具
软件开发，真的好难吗？不见得。那，软件开发设计团队搭建，真的好容易吗？也不是。
但，办法总比困难多，花点时间、花点精力，问题总是能解决的。这也是作为技术管理者应该肩负的责任。
如果你的团队也正在经历开发慢、协作难、交付差的情况，我的建议是，重新再一起梳理你团队现有的开发流程，并且让每个成员（如开发人员、测试人员、产品经理、项目经理等）、每个对接的部门（如市场部门、客服部门、财务部门、运营部门等）、每个老板（如你的上级、总监、老板）都清楚、认同和支持统一的开发流程。最后，把开发流程图画出来，贴出来，共享出来。有必要，可以组织会议进行培训、讲解和明确。
接下来，再结合你团队现在正在使用的项目管理工具，进行流程上的约束、明确和记录。
例如，过往我们就用为不少企业解决了研发过程中遇到的各类问题，而且还根据企业的需要进行了开发流程的个性化设置、配置和调整。
后台管理：如何搭建和设计你团队的开发流程？
首先，定义你团队开发流程中所需要的需求节点状态。对于互联网SaaS产品，常用的需求状态是（从起点到结束）：需求中、设计中、排期中、研发中、待测试、测试中、待发布、已上线、已完成、挂起。
企业管理员也可以到后台自己进行配置，包括：需求状态、需求优先级、需求评审状态。
全局别名配置：
//-like/-alias
例如，对于需求优先级，在某家轻医美企业他们的定义是：P0：临时紧急且重要需求；P1:紧急且重要；P2:重要不紧急；P3: 紧急不重要；P4：不紧急且不重要。并且，需求收集每个月和各部门需求方开会收集一次，先放到腾讯在线excel文档，再同步录入到需求池集中管理。
随后，管理员还可以根据实际需求流转的过程，把每一个需求状态能流转的节点和顺序在后台进行约束和配置。例如：对于已完成的需求，不希望再进行任何流转，可以对于已完成的需求，取消全部的状态流转。
开发流程配置：
//-like/-
上面两步是针对需求开发流程的设计和配置，简单好用又直接。如果管理员还需要针对需求列表和单个开发的需求进行调整和偏好配置，例如，如果需要对需求列表默认显示的需求字段和需求搜索条件进行调整，可以自行设置默认需求筛选器：
需求筛选器配置：
//-like/
最后对于单个需求所需要的默认组件，管理员也可以根据业务需要进行个性化配置。
需求组件模块配置：
//-like/
前台使用：如何落地进行和形成闭环考核？
对于产品经理：
可以定期收集业务部门的需求，用excel批量导入或单个录入到需求池。如果需要区分不同的产品线需求，可以通过产品分类来实现；如果需要区分不同需求方的需求，可以使用需求方字段；如果还需要其他自定义的需求分类方式，可以使用自定义需求标签。
需求池，
///reqm
对于需求方：
可以查看每周需求排期，查看本周或自己提的需求什么时候可以发布上线，以及当前是处理什么流转阶段。
需求排期，
//week2/-reqm
对于开发人员：
在每个协作的需求，可以根据制定的需求流转顺序和过程，进行流转。后面还可以统计每个需求状态停留的时长和研发效率。
项目需求管理：
///-
对于项目经理：
可以统一管理和查看每个项目的需求数量、完成情况和项目进度，还可以进行分组管理。
项目列表：
///
对于测试人员：
测试人员可以创建测试用例、测试库和测试计划，并和项目关联，最后提交Bug缺陷时，还可以和需求进行关联。
测试计划：
//test-plan/index
最后，当需要进行每月考核时，可以使用提供的周报、月报、统计报表和其他分析数据，形成你团队的闭环考核。持续复盘总结和提升。
