BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷项目应该面向创新吗?

| 作者 Han Xu 关注 0 他的粉丝 ,译者 徐涵 关注 3 他的粉丝 发布于 2015年1月8日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

敏捷项目应该面向创新吗?

敏捷与创新常被认为存在着紧密联系。然而,早前Scrum Alliance联合创始人Mike Cohn批评现在的Scrum因太过于关注项目进度,而牺牲了创新能力。他说:

在九十年代中期那会儿,Scrum讲究的是探索创新性方案(这是我作为Scrum开发者之一对Scrum的回顾)。把问题交给团队,并给他们一个月 (或四周)的时间去解决问题。团队有那么多时间,便有机会去尝试一两种或更多有突破性潜质的方案,而不是直接采用相对保险、经过检验的解决方案。

而现在的Scrum,团队变得过分急于宣称完成任务。这导致团队倾向于直接采用保险的解决方案。许多团队绝不会去尝试疯狂的、却可能产生创新方案的念头。

我觉得这一结果很大程度上跟缩短sprint周期有关——如今sprint通常只有两周。Sprint较短的话,一旦某个有希望但存在风险的方案失败,就没有足够时间来进行弥补了。

Cohn并不是唯一得出此结论的人。来自英国伦敦城市大学(City University of London)的软件工程学者Bianca Hollis和Neil Maiden教授也认同,短的sprint周期会不利于创新孵化和创新性思维所需要的反思。他们在发表于《IEEE Software》杂志上的文章《用创新技术来扩展敏捷流程(Extending Agile Processes with Creativity Techniques)》中 写到

敏捷流程的一个明显不足是:没有充分利用可工作的软件来进行新需求的创新性思考。“避免浪费、降低复杂性”这一简单性原则被过分强调了。例 如,Kent Back建议敏捷开发者考虑最简单的方案。尽管这样做常常十分有效,但除非竭尽全力去尝试最简单方案以外的潜在方案,否则,客户只有勉强接受现有方案,而 不会了解到其他可能。

所以,项目效率与团队创新是时间维度上的不同方向,只能在二者间寻求平衡,敏捷项目不可能同时做好这两点。

另一方面,在2014 PMI全球大会上有一个来自Pedro Serrador的实证研究报告(相关论文将在《国际项目管理杂志(the International Journal of Project Management)》上发表)。该报告显示,敏捷项目在满足效率指标(即成本、时间、范围)上做得较好,而在改善客户满意度方面的成功尤为突出。他还发现,许多敏捷项目在先期规划(即所谓的Sprint 0)上花去了跟瀑布项目一样多的时间。许多敏捷项目正是在这一阶段对更广泛的项目目标与长期需求做了处理。

鉴于客户满意是敏捷的首要原则,那么似乎客户对于敏捷项目应该更面向创新还是更面向进度有最终发言权。你怎么看?你在项目效率与团队创新之间寻求平衡上有何经验?你们的客户满意吗?

查看英文原文:http://www.infoq.com/news/2015/01/agile-innovation

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT