团队沟通

团队应该如何安排QA 和测试工作？ 安排QA工作： （1）推动信息共享与沟通，在进行QA时我每天团队成员时刻保持沟通 （2）每一个人都为共同的目标而努力 （3）对于各自完成的部分充分授权和信任，再进行QA时，即便出现问题，也是对事不对 人，由项目经理理解项目的情况，协助成员甚至指导项目，比如识别风险，建议风险和问题的应对措施；能够根据规范和实践来修订PQA检查表 （4）每个人各司其职，对项目共同负责 （5）保持敏捷，对于可能出现的变化，团队成员一起实例，努力预期和适应变化 （6）积极查询项目参照样例和比较基准，辅导项目学习所有的经验，并在项目中识别改进机会，能够考虑到同类型项目，根据QA情况，PM努力总结经验，并开好团队QA总结例会，其他成员根据会议修改安排QA计划 （7）处理项目面临的优先改进机会，管理并提升用户/干系人的满意度， 积极与其他人合作 安排测试工作： 各司其职，各尽其责。 通过激发测试队员的积极性充分发挥各自潜能，并培养团队协作氛围增加团队精神，工作上步调一致，来最大程度的发挥团队效能。不同测试阶段采取不同测试策略，例如测试过程中出现定位效应、审丑疲劳和同化现象可采取交叉测试来规避;鼓励创新，不断变化测试方法来提升测试效率;尽量让每个人做不同的事情减少重叠和内耗，在专长上面要有互补性，充分发挥各自特长。 小组成员：徐永健，方敏，方星晨，杨波，葛兴杰 来源：

What About 随着春节即将来临，有种总结的想法不断在脑海浮现，要细细反省。再忙也要停下来思考！ 健康 健康是一切的支柱，需要重视起来。作息不规律，睡得太晚，需要调整。没有运动习惯，体重上涨严重，需要加强自律 家人陪伴 不放弃任何一个可以回家的机会，做不到不远游，但是可以经常发送远方的问候 子女教育 给娃找一个好的幼儿园，学习如何教娃 赚钱 主动收入： 努力工作，升职加薪，增加主动收入 工作目标：搞活团队氛围，尊重每一位同事，形成良好的职场关系。持续打破自己的舒适区，给自己增加挑战 被动收入： 学习理财知识，做合理投资配置。思考增加更多被动收入的方式，制定可行计划 专业技术输出 做一个开源项目，暂定Java插桩 输出一些技术文章到技术媒体 爱好培养 目前已经可以用复音口琴吹奏一些简单的曲子，明年继续学习乐理知识。布鲁斯的音色比较好听，明年要玩一玩。吉他、贝斯也想玩一玩。。。 个人提升 修心养性：读圣贤书，行君子事，三观自洽，无憾一生 专业技能：持续学习，对曾经做过的东西沉淀成自己的方法论，并学习如果应对没有做过的东西 社交能力：虽然不至于内向，但是讨厌与人交际，应该找一个最适合自己的度，与外保持沟通的同时，自己内心也要舒服 表达能力：能完整表达自己观点，具备说服别人的能力 来源： https://www.cnblogs.com/liushijie/p/12151118

最近三个月，我非常荣幸的做为TeamLeader带领几个小组成员做了一个国外项目，这里想为大家分享一些小经验,尽管我佣有六年多的项目经验，但我一直的方向是架构师。大家知道架构师一般情况是偏向技术方向，我也不例外，前三年，主要精力都花在技术架构上，挖空心思在通用平台上做出自己的东西，体现个人价值。但最近一年也想在项目管理上有所突破，有人可能认为方向走偏了，但我不这样认为，在中国的软件环境下，在很大程度上，公司更希望全才，或者说有些公司并不仅仅希望架构师只懂技术。而架构师如果一味的只走技术路线，在某些方面会存在缺陷： 1：与人沟通 这个很容易理解，技术人员一般情况下不会和太多的人沟通，大部分情况也就局限于自己所属的Team，但是做为一个PM，你有可能会和产品经理，客户经理等人合作，这是普通程序员不太方便接触的人群。而往往人与人之间的沟通非常重要，沟通的顺畅可以让大家做事都比较顺利，反之，累死但结果并不太好。 所以我认为，如果做为一个沟通能力非常强的架构师，那么会让他非常容易的被大家接受。 2：每个公司对架构师的理解不一样 有些公司比较注意架构师的技术水平，所以这类架构师会负责技术部的所有技术难题(比如一些B2C网站，他们也许注重的是架构师能够解决可扩展，性能，平台通用的问题)，但有一部分公司对技术要求并不太强烈，他们也许会要求架构师更多的懂业务，或者能够带领团队完成代表公司标志性的项目

本博客强烈推荐： Java电子书高清PDF集合免费下载 https://www.cnblogs.com/yuxiang1/p/12099324.html 微服务是近些年非常火热的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》（是Design RESTful API的作者）在InfoQ上的一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway's Law）。 在康威的这篇文章中，最有名的一句话就是： Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967) 中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片

所谓康威定律 　　有一位叫康威的人，提出一个观点：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。其实，这里的系统并不局限于软件领域的系统。康威对其定律又做了具体解读： 组织沟通方式会通过系统设计表达出来。 时间再多一件事情也不可能做得完美，但总有时间做完一件事情。 线型系统和线型组织架构间有潜在的异质同态特性。 大的系统组织总是比小系统更倾向于分解。 　　组织沟通方式会通过系统设计表达出来，沟通成本随着团队成员的增加而以几何级数增加。线型系统和线型组织架构间有潜在的异质同态特性，这句话说白一点就是，你需要构建什么样的系统，就搭建什么样的组织结构。下面我们会融合案例来看看这些逃不过的原则。 　　所谓技术债务 　　技术债务是由Ward Cunningham在1992年的报告中创造的一个比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。它和金融债务非常相似。一个人贷款了就会产生债务。如果他定期还款，那么所创建的债务是可以接受的，不会产生进一步的问题。但是，如果他不还款，就会以利息作为惩罚，并随着不还款次数的增加而增加。如果这个人很长一段时间不能支付任何款项，那么应计利息使得他更难以偿还债务。在极端情况下，该人不得不宣布自己破产。 　　为了快速做业务，采取简单粗暴的方案是大家表示支持的。临时方案的毛病不在于这2个月临时了，而在于这个临时上线之后

最近一直在思考技术转管理过程中需要注意到的一些事情，现在就总结下分享给大家看看 核心职责 确定团队目标 不论项目大小，一定要有目标，有目标才能让所有人看到方向，明确每天工作的意义。单纯技术人员应该切换思维为全局性，而不局限于技术层面，现在个人的成功而不是成功，团队的成功才算最终的成功，应该多思考怎么样才能让团队高质量的绩效产出。 欠缺哪些资源 项目开始时候，需明确知道目前团队有哪些资源，比如人员，技术风险点及物理硬件采集。只有了解了需要哪些资源，我们才能更好的完成定下的团队目标 怎么实现这个目标 这个在整个项目过程中都有所体现，具体怎么实现，我们可以拆分为三大块 业务管理 团队管理 技术管理 业务管理 业务管理，主要就是管理我们需要处理的业务需求。其实我们可分为这几大块 内容 每天的任务分配与分解 制定大致的开发排期 每天了解开发进度 讨论与跟进各种具体的技术问题 协调一些产品需求变更 响应一些市场同事的需求 跟进功能上线 敏捷 关于敏捷开发，针对不一样的团队、不同的产品，具体实践方式是不同的。不过重要的是每过段时间，需要做总结，来反思过去的一段时间中，是否出现变坏的趋势，然后在针对性的改进。总结下「敏捷是态度而不是流程，是氛围而不是方法」。 具体实践有下面 4 个部分组成 计划会议 每日站会 评审会议 回顾会议 困难 困难的地方很多，或者说当坐上管理岗位后，承担的责任就变重很多

优秀的项目经理要有责任心、要善于沟通、能引导客户、能预测风险、善于总结、随需应变、善于激励团队、同时也要懂技术。 　　 责任心 　　作为项目经理首先要有责任心。有了责任心，你会把项目当成自己的孩子，倾注你的全部心血。责任，会驱使你关注项目的进度，千方百计去寻找各种资源，推着项目往前走。甚至吃饭、睡觉，走路、坐车，都想着整个项目团队，想着他们还在加班加点，你可能很自然地给他们带点夜宵、冲杯咖啡，犒劳员工。 　　有了项目经理做表率，整个团队会鼎力支持工作，士气非常高，技术问题也迎刃而解，得到领导称赞和客户肯定，项目将朝着预想的方向发展。 　　许多开发人员抱怨项目经理一天没干多少事情，而工资还挺高。其实，项目经理一刻都没闲着，他总在想着怎样更好的执行项目计划，调整项目进度等，脑子一直在不停地运转，所以说项目经理是心累。 　 　善于沟通 　　PMBOK(项目管理的知识体系)指出，项目经理75%～90%的时间用在沟通上。沟通无处不在，项目经理要具备良好的沟通能力。如:跟领导报告工作进度、跟客户介绍产品及说明工作成果、跟项目成员交待工作、跟公司内的其它人员争取支持、跟合作厂商协调配合事项等。对项目经理来说，每天大部分的时间是跟人沟通。项目经理上有老板、客户，下有项目组员，属于夹板层，沟通不好，容易出事。 　　沟通的关键在于：在什么时间，用什么方式，将什么信息，传达给什么人

1.格式描述 姓名 学号 所属课程 https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign 作业要求 https://www.cnblogs.com/harry240/p/11524252.html 作业目标 总结回顾 整理资料文档 团队名称 七剑下天山 GitHub地址 https://github.com/BigTent0/HappyReading.git 2.团队成员 姓名 学号 博客地址 张鹏 201731062524（组长） https://www.cnblogs.com/BigTent/ 陈超 201731062510 http://home.cnblogs.com/u/kotofight/ 王慧 201731062504 https://www.cnblogs.com/lazy-bear/ 李邦国 201731062513 https://www.cnblogs.com/iron-man6/ 沈梓琳 201731062501 https://www.cnblogs.com/LIn000 何鑫懿 201731062122 https://www.cnblogs.com/hxywxy521 侯思其 201731062124 https://www.cnblogs.com/siqihou 3

1. 基本 项目技术培训 提前解决项目难点，复杂点，宣讲并在项目新建demo目录 技术调研 专利申请 2. 项目可配置 字体配置 采用rem 布局 全局颜色，使用变量定义 mock抽离为json，便于前后端接口联调 路由定义可配置，抽离前缀 预览全项目，提取可共用组件 3 工作总结及开发建议 开发进度要如实汇报，做了多少就是多少，没做好，不要说做好了 技术实现尽量基于现有技术实现，以工作质量和工作效率第一，不要自己去实现一些插件的功能，因为很可能有bug，并且大幅增加开发时间 和团队leader及时沟通，比如，如果任务量大，要说出来，不要自己闷 头做 一些比较难的问题，如果自己解决困难，首先，不要自己硬做，团队内解决， 团队解决不了，leader解决 需求方新增需求，不要马上开发，首选和需求确定好，然后跟leader沟通，怎么做确定之后，再开发，以免白增加工作量 细节问题，一般来说，完成第一，细节后续优化，不要因小失大 开发总结 Git使用过程中，完成一个功能或者修复一个bug就提交push，不要写了一大堆再说，容易丢代码 去写一些功能，看看以前的代码或项目有没有现成的，拿来直接用 如果去维护样式，可以在下边写，覆盖上边的，可以减少代码冲突 写样式之前，要看一下项目，要不要封装成组件，统一处理 代码要简洁易懂，注意代码层次，不要有大段的注释啥的 数据容错处理， 空处理 来源：

到目前为止，本书大部分的内容集中在向细粒度架构迈进时所面临的技术挑战。但除此之 外，我们也需要考虑组织方面的问题。在这一章，我们将了解到忽略公司的组织结构会带 来什么样的危险。 我们的行业还很年轻，它似乎在不断地重塑自己。不过，一些关键定律还是经受住了时间 的考验。例如摩尔定律，它表示集成电路上可容纳的晶体管数目每两年会增加一倍。该定 律已经被证明准确得惊人（尽管有人预测，这种趋势已经放缓）。还有一条定律，我发现 几乎普遍适用，在我的日常工作中也更有用，那就是康威定律。 梅尔•康威于1%8年4月在Datamation杂志上发表了一篇名为“How Do Committees Invent”的论文，文中指出： 任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上 都与该组织的沟通结构保持一致， 这句话被称为康威定律，经常以各种形式被引述。埃里克*S.雷蒙德在《新黑客字典》 中总结这一现象时指出：“如果你有四个小组开发一个编译器，那你会得到一个四步编译器。” 论被证实，但你不必相信我的话。自从康威的论文提交以来，人们在这一领域进行了大量 的研究，探讨组织结构和他们创建的系统之间的关系。 10.1.1松耦合组织和紧耦合组织 在 Exploring the Duality Between Product and Organizational Architectures