敏捷开发

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


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

带你学敏捷1000_400.png

答疑解惑

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带你学敏捷》到此将告一段落,后期如果您有任何关于敏捷理论或实践的问题可以随时在后台留言,我们也将及时为您解答。

智齿客服