敏捷团队能力的挑战和提高(chester).ppt

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