产品经理该有的Scrum敏捷开发价值观Scrum敏捷开发的价值观Scrum是目前最流行的敏捷框架。它是敏捷宣?的价值观及原则（图1）的一个重
要思想来源，而这些价值观和原则也是所有敏捷方法的基础。本文将针对敏捷宣?言的价值观在Scrum方法中的体现进行一个详细的阐述。1个
体与互动重于流程和工具自管理团队、跨职能的团队是Scrum的重要特性，Scrum非常强调在保持所有一切透明的基础上进行团队决策
，以及团队协作，团队确定该做什么，团队确定如何去实现，然后由团队来完成。团队发现前进道路上的障碍，并负责解决职责范围内的所有困难。
团队也会与组织内的其他部门合作去解决团队职责范围外的困难。这个非常重要，尝试应用Scrum却忽视团队共担职责，往往导致问题。2工作
的软件重于详尽的文档Scrum要求每个Sprint都交付可工作的、已经完成的产品增量，并把这个看作Sprint的主要产出物。尽
管还会有类似于分析、设计、测试的工作，可能需要用文档记录下来，但是只有可工作的软件能帮助组织获得项目成功。这个非常重要，Scrum
团队每个Sprint都必须交付可工作的产品增量。3客户合作重于合同谈判Scrum产品负责人是Scrum团队与产品最终用户之间，
以及组织内部需要该产品的其它相关部门之间最主要的接口人。产品负责人是团队的一员，他与其他团队成员一起合作来确定哪些需要完成。在合作
中，产品负责人选择价值最高的下一批功能，并尽可能时刻确保产品具有最高的价值。这个非常重要，产品负责人需要跟团队充分合作。4响应变化
重于遵循计划Scrum的一切就是为了保证每个人都掌握足够的信息来对项目做出有利的决定。真实的、可以运行的产品增量才是项目进度的
体现。让所有人都能够了解待办事项列表，无论是总体进度还是每个Sprint的进度都保持公开可见，公开讨论并快速处理问题和担忧。这个非
常重要，对于那些能够公开检查现状，并根据真实的情况进行调整的团队，Scrum会十分有效。否则将收效甚微。对Scrum敏捷开发的误解
误解一：敏捷对人的要求很高很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。
可是，敏捷对人的要求真的那么高么？软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各
种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的
因素。从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此
看不到显著的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显著。
敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。误解二：敏捷没有文档，也不做设计这个误解从
XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都
不写。例如，用户手册是不是“必要且意义重大”？这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写；再如，架构
设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，
怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免
由某一个人（比如leader）来决定。误解三：敏捷好，其他方法不好有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CM
MI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样
也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。从另一个方面来看，
方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高
的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目－这恰恰是现在很多项目的共性。因此选择一个方法或过程，并不
是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。误解四：
敏捷就是XP，就是ScrumXP和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起
来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要
学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。即使将XP或Scrum完全的应用的
你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要
由你自己在实际工作中探索和寻找。误解五：敏捷很好，因此我要制定标准，所有项目都要遵循个标准没有哪两个项目是一样的，客户是不一样的，
人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务
的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一
所有项目过程的方法都是不正确的。同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和
方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就
是变化的，在变化的世界使用不变的方法，是不现实的。银弹从来就没有过，在有限的将来也不会存在。导致你的敏捷开发项目失败的5个原因
太多的敏捷开发项目失败。这很难甚至精确地测量这么多的软件开发项目失败的次数，因为最终“完成”和发布，即便：他们花了足够长的时间来构
建构建的质量很差构建的产品不是客户所期望的的构建的成本大大超出预期1不是产品所有者所有的事情，都可能会导致一个敏捷软件项目的失败，
而不是一个正在开发的产品的最终的决策者的人，是确保其（产品）消亡最快的方式。如果你追随Scrum的，没关系，只管做你自己的Kan
banstyleproject项目或者别的事;如果你想你的项目能取得成功，你需要能一个能多所开发的产品设定方向和做决定的人。想
想要改造一个厨房。如果你聘请了一堆的承建商进来，做各种各样的工作，如：管道，木工，地板等，但你没有一个人来决定实际完成的厨房看起来
应该像什么样，最终你将会得到一个乱七八糟的厨房。少有的几个承建商可能会足够的聪明的，能找到正确的人以询问应该做什么，但设计一个厨房
需要的不仅仅是随意的决定橱柜放哪儿，而是需要更多。你需要的是有人能真正的提出符合实际的设计和愿景，并随着工程的不断推进能对愿景进行
纠正，以避免问题的发生。当然，日复一日，我在软件项目中的确看到很多这样的行为。我看见很多公司在敏捷开发上花费了大量的金钱，但并不会
委任任何人成为正在建设的项目的真正的主人，并为它设置愿景。2没有迭代迭代是敏捷开发给软件开发世界带来的关键价值之一。但什么是迭代呢
？你可能会认为，这意味着将你的项目分成两个短周期或者迭代周期，虽然这样做可以促进迭代开发，这并不意味着你是在使用迭代。感到困惑了吧
？下面就让我们揭秘吧：迭代的关键是在时间范围内，一点点的开发一个产品。这将准确的，作为一个产品的演进来描述迭代过程中的商品。无论你
是否相信宏观进化，微进化，或适应性是否是一个成熟的概念。进化背后的想法是事情随着时间的推移逐渐被改变。由量变到质变。试想一下，如果
你是一条在大洋中游动的鱼，并有一些自己的在出生时就有功能健全的腿的鱼宝宝。然后，那些有腿的鱼宝宝长大了，然后又有翅膀的鱼宝宝。也许
腿和翅膀并不会让鱼能活的更好，也没有被恰当的设计，因为腿和翅膀的出现，不是随着时间的推移因适应所做的改变，而是突然出现。产品功能不
应该以单一的短周期或迭代来建立。好比在单一的一代鱼的身上出现腿一样愚蠢。反之，功能应该随着时间的推移和进化。某种功能不应被放入到某
种单一的短周期或迭代，然后去实现。一种功能应该从小规模开始，并随着时间的推移进行进化和开发收到反馈，客户或者产品所有者试图将其开发
出来。太多的时候，我看到敏捷开发的项目进行了错误迭代和迭代开发产品不要试图发送一次完成的功能，而是让它随着时间的推移来完成。3没有
将事物分解的足够小对于将食物分解成小的、容易接受的块，我是坚定的支持者。为什么如此重要的一个主要原因，是这样做可以避免延期。延期经
常发生在当我们对大型的可能困难的任务感到畏惧的时候，或者我们不知道接下来该做什么的时候。如果你能将大项目分成很多小块，这将使项目看
起来很容易完成，并有一个明确进展步骤。我经常看到，没有给之前的软件项目考虑足够的工作，人为的创造了积压工作或工作项目。我创造了一个
长期的积压类型：fatlogs。Fatlogs积压没有分解成足够小，并且经常对于要完成什么非常模糊。如果你不能花足够的时间来清楚地
说明你想要什么，那么它就没那么重要。但这也不足以豁免开发团队。开发团队应该将他们得到的任何挤压工作分解成小块任务。4没有设置标准
当你订一块牛排的时候，服务生问你的第一件事是什么？显而易见，他们问你你想如何完成它。如果厨师不知道你想要完成的牛排的制作标准，厨师
就必须决定他或她的制作标准是什么。你可会得到一个完美的牛排，或者一个让你难以置信的牛排，或者介于两者之间，完全取决于为你烤制牛排的
人。这不是一个烤制牛排的好方式，同样也不是制作软件的好方式。在大多数软件项目中，我经常遭遇到大量的在烤制时没有定义的牛排。积压工作
当时间耗尽的时候，经常被“做”。对于一个敏捷开发团队，做任何积压工作有一个明确的标准是相当重要的。这意味着，产品所有者应该定义一些
可接受性测试。测试是手动测试还是全自动测试没有关系，与团队指定的标准是否能达到其测试目标有关。缺乏标准，好比父母对孩子所提的问题“
我应该吃多少豆子？”时所做的回答：“吃饱就行”一样。没有制定标准会导致负面情绪，并为什么在手指指向的方向没有做正确的事。我发现，如
果你详细的告诉某人你对他的期望是什么以及评判的标准是什么，你将会比仅仅分配给他们任务得到更好的结果，牵着他们的鼻子说，“好好干。”
5不要为了团队而建立团队团队是一个奇怪的组织，特别是敏捷团队。有很多的变数，会影响到团队的行为和交互。有太多的方式组建一个健康的团
队，亦有很多方式创建很烂的团队。一个健康积极的团队具有协同作用，一个不健康的消极团队比其团队成员各干各的好不了多少。关键是有一个健康的团队，能让每个团队成员都变得很自主。无论你的政见如何，你也许会同意以下观点，当一个国家入侵另一个国家，并建立了一个并非由公民选举的政府来管理人民，肯定有问题的。同样的问题发生在敏捷开发过程中。我并不是说团队不应该有责任制。但如果你想以敏捷的方式管理一个软件项目，你必须让团队在达成共识的基础上自我组织以及自我管理。当团队老大总是监督和干扰的话，团队互动变得非常困难。自然而然的，团队时常有他们自己的开发节奏，领导力和角色（称之为准则）。然而，当外部力量直接干扰团队工作时，他们没有权力决定他们自己的命运，团队成员就会开始意识到他们需要好自为之。 |
|
