敏捷团队能力的挑战和提高（chester）.pptVIP

敏捷团队能力的挑战和提高 Chester Xi 四大最常见的挑战 开发者害怕暴露能力缺陷 要求全能型开发者 对沟通的要求太高 开发者缺少业务知识。 开发者害怕暴露能力缺陷 每个团队成员的工作往往是每天汇报的，例如在开会的时候每个人汇报工作。这样团队的每个成员都会知道你每天花了多少时间做了什么事。假如有一个工作你花了比正常流程更多的时间，那么你会感觉到每个人都在质问你为什么。还有，在一块白板前一起讨论设计等问题往往会暴露一个人的能力不足，或者沟通不善。 新团队应首先建立 一个安全的环境 团队成员不得为任何弱点受惩罚/讥笑 信任的环境 团队成员有信心在任何时候得到其他成员的帮助,如果他需要的话。 一切可见会团队成员受益,例如更容易获得帮助，成员之间更精确的期望值， 等等。 要求全能型开发者 成为一个成功的敏捷开发者，你需要是一个同时具备码农，架构师，测试工程师和客户的能力。很多公司为此去培训员工，但这个代价是很高的，并且不是很有效。 为了更好地帮助团队成员负责个人能力的积累，团队现在使用的是用矩阵跟踪团队能力的状态，例如： 或者，我们可以用一个更实用的方式： 在每个Sprint中，每一个工程师都应该做一些对自己全新的东西，不拘大小。 对于每一个要做的新功能，至少提前一个Sprint检查??团队能力的差距。如果有，利用提前量来补齐短版。使用此方法,团队至今没有功能交付延迟因为能力的原因。 把空余的人力资源投入人员紧张的工作. 忽视了练基本功 ： 实施敏捷有一个前提：基础扎实，具有很好的开发、设计、需求分析和项目管理的能力。 软件工程师需有好的编程能力和习惯， 这是敏捷成功的保证 代码可以工作； 沟通、表达业务逻辑； 没有重复代码； 没有额外代码 对沟通的要求太高 由于敏捷开发是在不断的沟通中进行的，所以团队的成员需要非常好的沟通的技能。但往往一个优秀的程序员是不善于社交、沟通的。这就是一个问题。有些团队成员无法有效的传递他们的想法给团队的其他成员。 为了帮助外部沟通，我们新增了一个角色: OPO 在PO之下. OPO, 执行产品负责人 跟进的合作单位用户故事的进展 与其他OPO的决定如何划分，分配功能开发 把APO从以上的日常沟通中解救出来，专注大型产品 Scrum Master Scrum Master是团队对外的唯一接口。保护团队 敏捷鼓励团队成员做他/她自己的对外沟通，以提高工作效率 开发者缺少业务知识 敏捷开发要求开发者可以直接和客户沟通有关程序的功能。但是对于一个大型项目来说，不可能每个开发者都对项目的所有功能了解。可能每个人就做一小块功能。这样的话一旦某个人休假或者离职，那么顶替上的程序员就不具有对这块功能的业务知识，当他去和客户沟通的时候就会显的不专业。 一个成熟的团队，每一位工程师都需要参预研究和分析涉及到的功能。每个人都应该有所贡献，这可以得到最佳的解决方案。 团队还需要了解什么是功能的商业动机，才能有更好的解决方案 在Scrum中的理想工程师 - T形 工程师是多面手（在有价值的广泛领域具有很高的技能 ，顶部的一横）和专家（在自己的领域内是一个顶尖高手，T的垂直腿）。 我们应该感到高兴地看到，无论工程师加强宽度或广度都是好事， 因为两者都需要，只要他们不浪费自己的时间。 能力的建立需要一定的时间。没有捷径可走，只是要更多的实践。 * 0 0 0.1 0.1 0.4 组员5 0 0 0 1 0 组员4 0.2 0.4 0.2 0.5 0 组员3 0.3 0.1 0.7 0 0 组员2 0 0 0 0.8 0.2 组员1 领域5 领域4 领域3 领域2 领域 1 能力值是0?1之间，粗略的定义是： 0：不知道 1：在这方面的专家 0?1之间的值留给团队定义。此表是团队成员和团队定期评估，每个Sprint或每月。 以这种方式，团队有一个很好的意识对团队能力状态有一个很好的认识。 最大的失败 *