原文作者：Jim Highsmith

译者：大卫张33

译者按

本文译自：http://www.agilemanifesto.org/history.html

要想了解敏捷软件开发，这篇文章是必读，对学习敏捷中的不少疑惑都给出了解释。感谢@AgileCoach和@徐毅-Kaveri的审校。

 

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

由全体参会者签署的《敏捷软件开发宣言》（Manifesto for Agile Software Development）成为了重要标志，因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。

Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站（http://www.agilemanifesto.org/）首页的《敏捷软件开发宣言》，他们称自己为“敏捷联盟”。
但多数人（如果不是所有的话）成为联盟成员的动力不仅仅是因为宣言上列出的那些理由，他们还有着更深层次的考虑。在长达两天的会议临近结束的时候，Bob Martin半开玩笑地说他打算谈点“虚的”，讲讲“空话”。Bob这话虽然有玩笑成分，却得到了几乎所有人的响应。因为我们都会非常乐于与一群拥有相似价值观的人一起共事，这些人会相互信任与尊重，会促成以人和协作为本的组织模式，能构建大家都愿意为之贡献的组织社区。本质上讲，我相信敏捷方法学家们确实要玩这些“虚的”东西。为了交付好产品给客户，他们会切实去做，不止是口头上说“人是我们最重要的资产”，还要从实际中体现出人本身就是最重要的，去掉“资产”这个提法。因此在最后的讨论过程中，敏捷方法学家们对价值观和文化这些“虚的”东西表现出了极大的兴趣，有时甚至会进行激烈的争论。

例如，我认为，极限编程呈现出强劲的发展势头，其根源不在于结对编程或重构等实践本身，而是从整体上看，极限编程能让开发人员们摆脱“呆伯特”组织中那些腐朽观念的束缚。Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候，经理临时换了另一个人和他一起工作，最后他们花了12个星期才完成项目。他的感觉很糟，因为在后面6个星期中间，经理一直喋喋不休，嫌他太慢。Kent有点沮丧，觉得自己作为一个程序员实在是太失败。到最后，他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败，是管理者的失败（指临时换人这件事），实际上是那些持续祸害着我们这个行业的，所谓标准化、流程化的“僵化”头脑的失败。

同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户，当然，也包括开发人员，谁都不想难为自己，去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人，甚至提出荒谬的要求。这不仅仅是软件开发的问题，在“呆伯特”组织中它无处不在。

想要在新经济环境下成功，并引领电子商务和网络时代，那么公司一定要去除“呆伯特”式的行为表现，不要没事找事做，不要搞出那些没人能搞懂的规章制度。敏捷是一种解放，让人不再虚度时光。这吸引了敏捷方法论的支持者们，却把传统主义者吓得屁滚尿流（抱歉，在专业文章中说脏话了）。坦率来讲，敏捷方法吓到了组织中的官僚们，尤其是那些乐于为过程而过程，却不全力为客户着想，不想履行承诺按时交付可见成果的官僚们，因为这（敏捷）会让他们无处藏身。

敏捷运动并不是反方法论的，事实上，我们中的大多数人正在试图恢复方法论的名声。我们希望能重归平衡。我们乐于建模，但目的不是给无人问津的企业资源库增加几篇图表存档。我们要写文档，但那些从不维护、并很少用到的长篇大论不算在内。我们得做计划，但同时也要认识到在剧烈变化的环境中计划的局限。有些人给XP、Scrum或任何一种敏捷方法论的支持者们打上“黑客”的标签，这只表示了他们对方法论和黑客本意的无知。

2000年春，Kent Beck组织了一次会议，地点在俄勒冈州的罗格里夫酒店，参会者包括极限编程的支持者们和一些“圈外人”，正是这次会议导致了后来在雪鸟的聚会。在罗格里夫会议上，参会者们宣称了对一系列“轻量”方法论的支持，但没有发表什么正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程，其中很多都提到“轻量级方法论，如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现，没人真正喜欢“轻”这个名号，但这似乎是当时约定俗成的称呼。

2000年9月，来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来，请告诉我。”Bob建立了一个Wiki网站，由此开始了热烈的讨论。

很快，Alistair Cockburn就用一封书信加入了讨论，他表达了对“轻”这种提法的不满：“我不介意用‘轻’来描述方法论的轻重程度，但我并不愿意因参加一个轻量级方法学家会议而被看作是轻量级的。这听起来有点像一群干瘦、低能、并无足轻重的人在试图回忆起某个特定的日子。”

关于会议地点的争论最为激烈。芝加哥让人不爽，既冷又无趣；犹他州的雪鸟，虽然也冷，但至少对那些想滑雪的人来说还挺有意思，像Martin Fowler在第一天滑雪就滑个头朝地；加勒比的安圭拉岛，暖和又好玩，但路途太远。最后还是可以滑雪的雪鸟胜出，不过有些人（例如Ron Jeffries）还是希望下次能去个暖和点的地方。

我们希望，一起组成的敏捷联盟能够帮助到其他同行，帮他们用新的更“敏捷”的方式去思考软件开发、方法论和组织。做到这一点，我们就得偿所愿了。

Jim Highsmith，来自敏捷联盟©2001 Jim Highsmith

 

参考：

极限编程：敏捷软件开发方法的一种，缩写XP，英文全称Extreme Programming。

Scrum：敏捷软件开发方法的一种。

DSDM：敏捷软件开发方法的一种，英文全称Dynamic Systems Development Method。

自适应软件开发：敏捷软件开发方法的一种，缩写ASD，英文全称Adaptive Software Development。

水晶系列：敏捷软件开发方法的一个方法系列，都用Crystal开头。

特征驱动开发：敏捷软件开发方法的一种，缩写FDD，英文全称Feature-Driven Development

实效编程：不是一个方法论，是一个流派，英文全称Pragmatic Programming，

呆伯特（又名迪尔伯特）：Dilbert，美国 Scott Adams 的有名职场卡通人物。呆伯特法则：http://zh.wikipedia.org/wiki/%E5%91%86%E4%BC%AF%E7%89%B9%E6%B3%95%E5%89%87

说“不”是件难事。我们大部分人都喜欢取悦别人，可是当我们向别人说“不”时，我们会让请求者失望。

但向干系人说“不”，却是产品负责人最重要的工作之一。产品负责人应以优化产品交付价值为己任，而不是每个客户需求都答应。

产品负责人每接受一个干系人的需求，就意味着可能要拒绝将来的一些客户需求。团队的时间总是有限的，接受今天的一个需求，就意味着可能要被迫丢掉明天的一个机会。

因此，学会向干系人说“不”是每个产品负责人都必须掌握的技巧。我想分享六条准则，以便大家能礼貌而坚定地做到这一点。

向干系人清楚说明：是“不”，还是暂时“不”？

当产品负责人需要告诉干系人，他们不会优先处理某个需求时，他们应该说明清楚“不”的含义。

如果你要表达的是你将永远不会让团队开发这个需求，不要给干系人留有任何幻想，这会鼓励他们在未来继续地提出类似的需求。这会浪费他们的时间，也会给心里清楚这个需求绝不会被实现的你，带来持续说“不”而引发的挫败感。

另一方面，对于你后续可能会实现的需求，你要清楚地告诉客户——只是暂时“不”。

例如，你可以说：

“非常抱歉，我们不能立刻实现这个需求。相信我，我非常希望现在就开发它，但我们已经承诺要在8月之前交付[任何可能的需求名称]。我必须让团队先集中精力开发那个需求，否则我们就可能会违反那个承诺。但是如果你在8月份提醒我，我保证会在那之后认真考虑。”

注意这个例子中的回复方式，我并建议你不要承诺稍后就做，而只是说你会考虑这一点。

还要注意的是，你要把责任转回到干系人或客户身上。让他们在合适时重新提需求或提醒你。我这样做的目的，是为了确保这个功能那个时候对他们来说仍然很重要。如果干系人不愿意为这个需求，再稍微费点事提醒你，我会质疑这个需求是否真的那么重要或紧急。

最重要的是，如果你真的从未打算接受这个需求，不要让干系人离开，认为他们应该在一个月内再次提出需求。

向客户表达感激和理解

每当被提出一个需求时，产品负责人们应当总是向干系人表达谢意，并指出他们理解为何对干系人来说这个需求是如此得重要。

某人花时间向你们团队要求了某事。那就意味着他们对你的产品感兴趣。要告诉客户你感激他们花时间提需求。

你需要说诸如此类的话：

“谢谢您！感谢您考虑我们产品该如何改进！”

除了感激，产品负责人还应该表现出对干系人状况的理解。你即将说“不”的这个需求，可能对他们来说是非常重要的。至少在干系人的头脑中，这个需求可能是需要完成老板指派的目标，甚至可能会对他们造成的财务影响。

在表达你的理解之前，你要确保已经了解这个需求为什么对这个客户很重要。如果这时候仍不了解，那么在对这个需求说“不”前，你必须做到这一点。

在表达对客户状况的理解时，你可以采用类似这样的说法：

我能理解这个需求对于您完成[任何可能的事情]有多么重要！

要确信你对此是真诚的。谁都会被错误的理解感到失望。

只提供一个说“不”的理由

当说“不”时，产品负责人最好能提供一个令人信服的理由，而不是提供一堆理由。当提供一堆理由时，人们会倾向于挑选出最薄弱的理由并进行反驳。

设想一下，我是你的客户，我要求你们团队把手头的工作先放在一边，优先满足我想要的需求。你告诉我：
对不起，我不能那样做，我们已经规划好了这次冲刺。否则，我需要团队再开一次计划会议他们不喜欢这样。我相信我们现在正在做更高优先级的工作。

你认为我会攻击你论点的哪一部分？需要再开一次计划会议，还是当前的工作优先级更高？

我会去争论，尽管团队不喜欢，但我们仍需要再开一次计划会议。我可以提出，可通过在午餐时召集会议来减少大家对开会的不满，并且我会买披萨。

尽管你仍然不喜欢我的方案，但我现在已经改变了对话内容：我们正在争论是否需要再举行一次会议，而不是哪个需求的优先级更高。而这更难说服对方。

并且，这是一个错误的做决策的基础。

说“不”，要坚定地提出最令人信服的理由。如果干系人在这一点上成功地说服你改变自己的观点，那么就有必要考虑你的第二点拒绝理由是否足够充分。如果不够充分，你可能需要接受这个需求。

表示你们有着共同的目标

如果产品负责人和干系人共享一个相同的整体目标，当产品负责人带来不受欢迎的消息时，应该借助于这个共同的目标。

产品负责人和干系人们通常有各自不同的目标。然而，有时候它们之间是矛盾的。但是通常会共享一个更高的、产品级目标，你可以参考这一点。

如果你们身处同一家公司，这会变得特别简单。在这种情况下，可以这样说：

我和你一样，很想让团队为你开发这个，但我们需要专注于[更大的，共同的目标]。
我相信你们还记得，我们都被赋予了[更大的，共同的目标]的目标。

提醒客户，你们共享着一个共同目标，这会帮助他们理解为什么你需要说“不”，即使他们仍然并不完全认同你的答案。

向干系人解释清楚接受需求会造成的后果

当拒绝一个干系人的需求时，产品负责人应当解释清楚接受需求会造成的后果。

这能有助于让干系人明白你为何不得不拒绝他。例如，你可能可以这样说：

如果我们接受了您的需求，我们就无法按时交付了。
团队工作压力已经很大了，如果需要加上这条需求，我们就必须拿掉已经承诺的其它需求。

解释后果有助于让干系人明白，或许能理解你拒绝的理由。

为客户提供替代方案

产品负责人或许可以提供一个替代方案，而不是毫不客气地直接向客户说“不”。

你或许可以说这样的话：
我们可能无法做到你所说的一切，但是如果我们做到部分怎么样呢？
我无法让团队现在就开始做这个，但是如果我们在三个星期后开始做怎么样？

注意：只有你真的想接受这个需求时，才提供替代方案。

说“不”未必是一件难事

产品负责人经常害怕说“不”，不敢让干系人或客户失望。但是说“不”并不那么困难。

我发现，只要我们能够清楚地提供一个而不是多个理由，做到感激和理解，阐述我们的共同目标，解释清楚接受需求会造成的后果，以及提供一个替代方案，说“不”就会简单很多。

如果做得够好，说“不”能提升而不是损害产品负责人与干系人之间的关系。

作者：Mike Cohn

译者：李洁（Jerry Li） ,CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练

原文链接：

https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder

之前已经为大家介绍了“如何使用Leangoo自动生成燃尽图”

今天介绍，“如何使用Leangoo看板统计中的任务分布”

Scrum 团队是一个自组织的团队，团队每天的目标和工作安排由团队讨论决定。Leangoo 通过任务分布统计帮助团队快速直观的了解团队成员每个人负责的工作负荷及工作进展状态，帮助团队进行更高效的协作。

我们首先来创建一个新的看板，我们可以选择空白看板或者模版创建，该看板命名为：办公室改造项目，这样我们就创建好了一个看板。

默认的看板周期为2周（从当前日期开始）

接下来我们为此看板添加列表，泳道和卡片，添加好后的看板如下图：

一个完整的看板创建好了之后，我们需要自定义任务分布的各项设置

任务分布的统计方式有两种：卡片数和工作量

1.系统默认设置为根据“卡片数”进行成员工作分配统计（注：必须先为每一张卡片指定负责人，将成员拖拽至卡片上即可）

也可以根据项目的实际情况修改为根据“工作量”进行统计（注：必须先为每一张卡片设置工作量，点开卡片，右边栏选择相应工作量即可）

2.系统默认所有列都参与统计，您可以根据项目的实际情况勾选统计列。

3.系统默认设置成员都参与统计，您也可以根据成员的情况进行勾选。

现在我们就可以查看任务分布图了：

通过以上几步就可以轻松了解成员任务分布情况了，是不是非常方便呢？

 

 

 

 

跨职能团队就是指在团队里面的每一个人都具备完成所有工作的所有技能，这或许是敏捷中最流行和持续存在的一个误区。

这显然是不正确的。跨职能团队的成员具有各种技能，但这并不意味着每个成员都具备所有技能。

敏捷团队拥有专家成员是可以接受的

敏捷团队拥有专家成员是完全可以接受的。（注：本文提到的专家成员是指在团队里面只擅长某个方面的单一技能的团队成员。）

而且我怀疑团队追求一些虚假的圣杯让每个团队成员都能够做到一切会失去很多生产力。

如果我的团队包括世界上最牛的数据库开发人员，我希望那个人为我们的数据库做出非常出色的成果。我不需要这个最牛的数据库开发人员来学习JavaScript。
Read more →

在Scrum的标准定义中，团队在开每日站会的时候需要回答三个问题：

• 我昨天完成了什么？

• 我今天计划做什么？

• 我遇到了什么障碍？

 
在对很多团队做辅导的时候，我发现团队的确在回答这几个问题，看起来好像没有什么错。 但是，他们只关注自己做的事情，对伙伴们在做什么，我们这个迭代的目标是什么，差距还有多大？团队昨天的目标完成的如何？今天的目标是什么？似乎不怎么关心。

命令与控制式的传统式管理和自组织的主要区别在于，传统管理方式是命令驱动的，而自组织是团队目标驱动的，团队共享责任的。

自组织团队不是团队随意的想干什么都可以，也不是各自为政，做自己喜欢做的事情，而是围绕团队的共同目标，基于团队的决策和工作约定共同决定谁做什么，以达成团队目标。

因此，工作良好的自组织团队在进行每日站会的时候，我建议回答如下问题：
Read more →