Worktile带你学敏捷：问题解答篇

概述：细心的朋友会注意到，我们在每篇《Worktile带你学敏捷》的文章末尾都会征集读者对于敏捷的问题，今天，我们选取了一些呼声最高的问题做统一回答，为您答疑解惑。

答疑解惑

1.由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。这个问题怎么解决呢？

最开始导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的，所以只能是逐步导入。很多敏捷项目确实存在过于频繁的交付，主要是由于人们迫于各种压力，“好大喜功”的天性使人忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量。如果团队不能自主调整工作量，这其实已经偏离了敏捷。公司和团队对敏捷开发的正确理解是解决这个问题的根本。

2.需求还在设计中，或整理完毕，但还未决定让开发团队去实现，这些需求是否需要存放在Product Backlog来管理？

只有当需求决定要开发的时候，才需要有分配；有了分配后，才需要放到Backlog中。否则当一个需求还在设计阶段，或者还没有决定是否需要开始实施的时候，甚至都可以对开发部门和测试部门进行隐藏。有了这样的改进，能更好的控制、管理Product Backlog列表。

需求一旦分配到开发团队后，也就从Backlog中移除了。新的、设计完毕的，可供分派到开发团队的待处理需求，又从需求空间进入到 Product Backlog中。这样的改进，更能让Product Backlog实现了Scrum最早的思想；帮助项目经理从茫茫海洋中快速定位急待开发的任务。

3.在敏捷开发中，每日例会有时候会因为枯燥慢慢沦为一种形式，后来就放弃了，请问下在例会除了说三点必要的事还可以做什么吗？

Daily Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的效。能帮助团队快速发现问题,并促进团队的自组织和自立。所有Scrum会议都是限定时长的。每日Scrum通常不超过10分钟。而为了保证高效会议， 一般的三个问题，如下：我昨天做了什么，我计划今天做什么，我遇到的问题。但是并不限于这3个问题，可以根据实际去调整这三个问题。而且每个人都应该关注自己所做的事情距离迭代目标的距离，应该是从项目的角度去描述问题而不是个人的角度去描述。

4．技术专家能担任的Scrum Master的角色吗？

可以，但是要摒弃掉一些技术专家的习惯。

①不要过多的参与团队的技术讨论。这个是技术专家在做SM时候经常遇到的问题，就是在Sprint Plan Meeting和Daily Scrum上经常技痒，会参与到具体的讨论。要知道SM是不需要关注技术问题的，他只是保证流程和团队的运营，如果你过多的参与技术讨论，大家会觉得SM过多的参与到团队的日常工作特别是技术开发中，这样会让团队成员以为SM为团队的中心，不利于SM辅导团队。

②不要越俎代庖。有些技术专家的SM在开planning会议估点的时候，经常会主动说，这个任务几个点就够了，当然，实际上可能也是相对准确的，但是这样的话会导致团队成员不主动估点，最后造成有SM来决定任务的时间点数，看起来好像效率高了，但是实际上对于团队的成长起到了负面作用。

5．敏捷的效用被过度夸大，大家的期望值都很高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题，真的是这样吗？

实际上，敏捷开发不是以最小的投入解决开发问题，也不是使开发效率大幅提高，而是快速地得到可以工作的产品（功能较少，但核心），快速的得到反馈以改进产品，始终以市场/客户的要求为每一次推出产品的原始驱动力，这样产品的ROI（Return of Invest）才是最高。客观的说，和传统开发方法比较，Invest不见得是最小的，但Return却是较高的。

总结

敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。《Worktile带你学敏捷》到此将告一段落，后期如果您有任何关于敏捷理论或实践的问题可以随时在后台留言，我们也将及时为您解答。