领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
创新哪去了？
作者 Shane Hastie 译者 金明 发布于 2009年10月28日
有一些评论人士最近质疑了敏捷世界的创新水平。
最近，Naresh Jain提出：
在我看来，敏捷社区在创新方面落后了。在大会、用户组、邮件列表等等上面，我们不断看到同样的老掉牙的一堆东西（也许我漏过了有些东西）。哪里有真正的创新？我应该关注哪些方面？
在“简单设计和测试”大会的wiki上，他提出可以关注的几个创新领域，从Web2.0到电子教学，到分布式开发。
同样地，Max Choong也质询敏捷迭代的“检验－适应”方式是否支持创新，因为创新是：
一种跳跃式变化，与我们已知的或已经在做的之间没有连续性。创新是关于打破常规的开放性思考，关于改变规则和关于革命。改良，从另一个角度讲，只是根据现有状况采取手段改善而已。
他接着陈述道：
依我的经验来看，项目压力通常意味着敏捷流程成为一种改良机器。客户即使十分清楚解决方案不对，他们也会继续进行下去。结果导致有根本性缺陷的解决方案也能被文过饰非，打上创可贴继续工作。需要勇敢的人站出来说：“这不行，让我们重新回到图板前吧！”
他主张这样一种方法，包括建立与迭代并行的“R&D stream”，探索和试验与增量式产品没有直接关联、但却可能导致更多的故事添加到backlog的新想法。
他也提议用R&D stream来指导以用户为中心的设计：
关于与迭代式开发周期并行进行的“R&D stream”，我提出这个建议其实是“别有用心”。它给以用户为中心的设计留下了空间。我们可以使用故事板、原型，以及深入性研究来试验新的想法。这些 活动都是要求有时间盒限制，而且产出物（如果合适）最终会作为合格的、经过深思熟虑的条目添加进backlog。
敏捷项目里有创新的空间吗？你的项目如何应对创新的挑战呢？不妨与大家一同探讨吧。
查看英文原文：Where has the innovation gone?
译者 金明 是ThoughtWorks咨询师，SCJP，系统分析师。关注敏捷方法学，特别是敏捷实施和项目管理的实践。
何必为了创新而创新呢？
发表人
Jun Ran
发表于
Re: 何必为了创新而创新呢？
发表人
徐 毅
发表于
Re: 何必为了创新而创新呢？
发表人
冯 希顺
发表于
Re: 何必为了创新而创新呢？
发表人
刘 显珂
发表于
创新可以用别的方法
发表人
jiang jianbo
发表于
创新不能泛泛而谈
发表人
Peng Sam
发表于
-
首先，创新是不是敏捷要解决的问题？为什么敏捷里面一定要有创新？
在一个项目里面需要创新，跟敏捷方法论本身需要创新是两码事，如果仅仅是在项目里面需要创新，我认为敏捷可以解决这个问题；
感觉太勉强了：哎呀，没有特别新的东西出来了，所以我们要创新？But what for? -
But what for?
说得太好了！ -
我觉得作者的意思是敏捷这种思维模式不利于创新。
-
敏捷方法很适合企业使用。我不赞成在敏捷里边放很多东西，结果成了一个大杂烩。企业需要创新，它完全可以同时应用其他更加适合创新的方法，和敏捷并行使用。从单个项目角度来看，压制创新比鼓励创新的风险要小很多，这个就是“研发”的“发”。我们为创新开始一个新的项目，就是“研发”的“研”！
-
同意。
敏捷软件开发是软件工程中关于方法和过程的理论和实践。
创新不属于敏捷的内涵，创新具有一般的意义。当然敏捷软件开发本身也是发展变化的，会产生一些新的观点、方法、实践。但是创新本身也是有条件，创新并非易事。
此外具体的软件项目、开发过程中，开发人员的创新肯定是需要的，比如设计是可以创新，此创新不是敏捷软件开发中的创新。
敏捷软件开发不会也不应该限制这些方面的创新，反而是要在实践中要鼓励这些创新。
总之创新是人的任务，不是方法和理论的任务。 -
我在项目中发现很多客户都有很创新的想法。但是实现出来后，确实泛泛而谈的东西。没有人觉得有用，那这样的创新只是尝试。。但偏偏很多人认为有了创新，牛奶和money也会有了。。
我个人认为，创新，应该是在某一点需求或者开发上产生和别人不同的表现形式，并且给最终用户带来真正的利益。空空而想的。。。不能叫创新。
6 条回复
关注此讨论 回复