第一本敏捷书

2013开始接触敏捷开发，一直在重复重复的学习，一本书不知道读了多少遍，对于一个问题，不断的思考了多少次，不同的阶段思考的想法又完全不同。

Arie van Bennekum提出“你需要真正的敏捷，为转变为此你需要克服范式”，

Van Bennekum指出为取得成功，需“达成敏捷”而非“去做敏捷”。克服范式是十分必要的；为了达成敏捷，人们需要正确的心态。敏捷是一种基于敏捷软件开发宣言的、在价值和原则上的互动理念。Van Bennekum声称：“技术促进了敏捷起作用，但是工具并不能使你达成敏捷。”，敏捷并非是仅去实现一件事情，而是一种增进企业适应性的变革。

敏捷宣言和原则，现在还有多少人在关心，当我们在实施“伪敏捷”的时候，我们可以在意的是形式，晨会，各种工具的使用。但是我们是不是忘了初心。勿忘初心。因为那些宣言和原则是我们一直的目标，晨会，工具往往不是。

敏捷软件开发宣言

个体和互动高于流程和工具

当我们实施大型项目的时候，我们往往有着各种的流程和工具，但是这些流程和工具往往没有提高我们的工作效率。每一个人都是独特和唯一的，他们都有着唯一性，每一个都有自己的特点和特长，要善于用这些特长和特点。

个体的技能的不同，当我们于他们之间的互动才是最关键的。

工作方式：

1.面对面沟通是极其重要的，它不能被其它形式完全替换。因为不管是文字还是图表还是任何形式的沟通，都无法达到面对面的沟通，科学研究发现文字的传输表达和图片的传输表达往往没有那么高。即使是图文并茂也是会有误差的。

2.产品管理和开发团队必须在一起工作,因为只有这样你才能时时知道项目情况和开发情况

3.架构师、需求设计师和测试人员必须每天在一起工作。因为架构师会根据需求设计出接口，测试人员根据需求编写许多的故事块。

4.当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法

工作的软件高于详尽的文档

意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。

1.要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计

2.设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的

3.好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。（来自InfoQ）

上面这二点可以总结为：

自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件

胜过

与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求

客户合作高于合同谈判

意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。

1.在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。

2.在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。

3.产品管理和开发应该密切合作，而不是通过契约或手续。（来自InfoQ）

项目开发一般都是跟随着合同开始的，由客户经理同客户交谈，在合同中确定一些法律条文以及交付产品包含的功能，然后客户经理拿着合同回到公司由开发团队完成开发后再交付给客户使用。在开发期间，如果需要变更合同，则需要经过一系列变更流程，遇到一些客户过程不参与，或只是简单的询问一下进度，有的甚至是到最后交付日了直接来问你要东西，这时产品不是他们想要的时候就麻烦大了，这可能就需要进行谈判商讨解决了。

仅仅通过合同谈判来开发产品，客户在开发过程中就不会进行实质性的反馈，导致最终的产品不满意也就很正常了。也许你说你们做的产品，暂时没有客户使用，其实也不是这样的，产品开发在早期市场不成熟的时候一般为公司领导（产品经理、LPDT）驱动，后期转变为用户驱动、销售驱动、服务驱动，在矩阵式管理模式下，产品事业部和开发管理部作为两个部门时，在做产品开发的时候就会类似在进行合同谈判，从一开始就会在两个部门之间产生争执而不是合作，这势必会影响产品的开发。（来自zhoujingen）

响应变化高于遵循计划

意味着欢迎需求变化，哪怕是开发后期。

软件复杂性

1.首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。

2.如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。

3.为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性

4.计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

计划赶不上变化，敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，它们的成功都是建立在现实反馈的基础上的。Scrum依照一组简单实践及规则，实施经验性过程控制方法的检查、适应和保证可视性等步骤，处理软件开发项目中的复杂问题。通过迭代开发，每次迭代都是基于上一迭代的完善基础之上进行的，通过不断的响应变化来消除开发中的不确定性。

作出的计划常常会出错，面对这样的问题，开发小组往往会走上两个极端：要么根本不做任何规划，要么在计划中投入大量的精力直到自己确信计划是正确的。不做规划的小组对一些最基本的问题，例如“你们什么时候能完成？”以及“我们可以在6月份安排产品发布吗？”都无法回答。而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”。他们的计划也许更全面，但这并不一定意味着它更准确或更有用。这两种极端都是敏捷需要避免的，最开始漫画所说的“我们实施敏捷，不再需要计划和文档了”的论调是及其错误的。

敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。

虽然我们致力于响应变化，但并不是不需要计划了，只是变得更多规划了。

---------------------------------------------------------------------

以下原则来自InfoQ说明，本来想说说自己的理解，但是因为时间问题，只做摘要：

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。

尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。

2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。

3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。

4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。

只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策

5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。

6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。

7.可工作的软件是进度的首要度量标准。

跟踪有多少功能已经实现，集成，测试是一种更可靠的进度度量。

8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

目标是为了消除高负荷工作并保持可持续的速度工作(例如，不加班工作)。质量问题通常牺牲长期收益，人们越是疲劳创造力就越低。因此可持续开发吧！

9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

任何技术负债(代码缺陷、架构缺陷)都会使开发减慢。我们不应该让技术负债积压，所以要持续地做重构，更改发现的缺陷，持续关注实现架构的质量。

10.以简洁为本，它是极力减少不必要工作量的艺术。

这种简单原则既适用于产品的功能特性也适用于流程。多余的功能不要增加。所有流程步骤应该时刻面临挑战(例如，这步真的需要吗? 谁会读这个文档？…)。

11.最好的架构、需求和设计出自自组织团队。

架构、设计和需求会随着团队一起工作慢慢浮现，并且团队会从中学到很多。一些前置需求、架构和设计工作是需要的，但是不能把它们定义在纸面上传递。架构师和系统工程师是自管理研发团队的一部分，不要成为“孤岛”。

12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。

花时间反思和从经验中学习能够促进持续化开发。因此“检查与调整”是敏捷核心实践之一。

-------------------------------------------------------------------

以下是InfoQ对Arie van Bennekum的采访，很经典

InfoQ：你是敏捷软件开发宣言的签署者之一。在软件产业中你看到了哪些与敏捷相关的主要变化？

Arie van Bennekum：首先，行业内涌现了对承担职责的渴求。现在无论我走到那里，每个企业都至少在某些地方上具有达成敏捷的积极性。我们都了解重大的事件，但却常常不记得引发这些事件的火花。这些火花通常是由项目执行层面的人所引发。看到团队中更多的人逐渐地渴求去承担职责，这是很棒的事情。

其次，当前具有一个普遍共识，就是我们需要更短时间去走向市场。越来越多的企业转向更短的交付周期。虽然在我们撰写敏捷软件开发宣言之前，我们中的大多数人就试图去解决这个问题，但不幸的是时间和预算依然超支。不过认识到了该问题这也是向正确方向前进的一步。

InfoQ：为什么当人们工作于团队中或者是在管理团队时，感到难以去接受范式的偏移？

Van Bennekum：说实话，我并非一个治疗师，但你也能对模式进行观察。我们太长时间地处于独立的筒仓式工作的状态。有趣的是在足球赛中，我们都能看见每个人都多元化的，他们可互相配合，为共同的团队目标而努力。

当我们工作时，我们却躲进了筒仓。就我所见而言这种筒仓是由传统的管理方式所导致的。这种管理出现于一个世纪以前，基于经理在项目中知晓并决定一切的观点。筒仓是安全的（清晰地给出了你必须要做的工作），可为你给出工作的状态，对工作中是否进入或离开筒仓具有清晰的处理方式（纸面材料和签名）。

团队工作，就是我们作为一个团队而工作，具有一套事情去做，服务于一个共享的目标，并在其中现场决定团队中谁应承担承担什么的工作，这对我们而言已不仅仅是一种工作方式。我们市场尝试去走出筒仓并如上去开展工作，但一旦有事情出错，作为标准的条件反射而言我们将会重新躲回我们的筒仓中、恢复到旧的模式、文档、工作交接等。这就是为什么我使用“新陈代谢”一词的原因……

InfoQ：在此你能给出在公司中成功实现了敏捷价值和原则的一个例子吗？为此他们采取了怎样的做法？

Van Bennekum：我能给出一些例子，但是我并不确认这些公司是否愿意公开它们，所以在这里我并不会给出具体的公司名称。我将给出在各类的公司中使用敏捷转换的三个实例来解释这个问题，这三个实例分别发生在一个大型的零售商、一个中等规模的能源提供商和一个大型的技术企业中。

克服范式是十分重要的。这包括管理范式、开发范式、职责中的范式等。为做到这一点，你需要使以下三件事情到位。

首先，垂直提交对于敏捷工作而言是十分重要的。诸如透明度、固有规程、可视化、优先次序等方面不仅需要管理层的支持；也必须由管理层将这些方面进行角色模型化。尤其是经历了旧有的层次型文化，人们倾向于去拷贝管理行为。这也是为什么当我们在敏捷转化中对团队和个人进行指导时，我们（当然是与其它活动组合在一起）必须在各个层级对管理付出特别的关注。

其次是环境的安全性；人们只有在感觉足够安全时，才敢于尝试错误。学习意味着去尝试、开发、犯错误等，并且做这些需要假以时日。对此人们的标准条件反射是掉回到旧的模式中去。当你没有时间去犯错误并且管理层也不支持时，人们将遵循上述的条件反射行为，这使得改变成为不可能。

第三，除非企业深陷危机，否则我们在事实上更乐于去依照企业原有方式而工作。我们让人员处于自身的安全环境中，并在开发的浪潮中启动改变。其中的经验教训，尤其是关于如何进行改变的，就是如果仅将改变推动到团队中，企业是不会真正使其持续下去的。

InfoQ：是什么使得采用服务型管理取得成功？

Van Bennekum：证据……管理者们需要证据（绝大部分时间下）。包括：案例研究，参考资料，参观访问相似的处理领域，尤其是针对有助于克服类似于“非我所创”和“好主意但是不适用于我们”之类的事情。顺便说一下，这不仅仅是针对管理者的。很多人都需要其各自的专业领域内的证据，即使如此你还将会听到不少由“虽然如此但是”所引出的说法。

InfoQ：打破企业各部门间的隔离墙是一项十分具有挑战性的工作。你对完成这个目标以增进企业范围内的合作有什么好的见解吗？

Van Bennekum：心跳是十分必要的。所有的利益相关者需要参与进来，他们是在传统开发过程序列（无论你开发什么产品）中具有话语权的人。结合我对上一个问题的回答，我可对这个问题的做如下的解答。

正如上面所说的，我们将保持公司的原样。我们改变了项目或其他开发类型中的交流方式。我们将除去序列，并与所有利益相关者一起在多元化团队工作。这些利益相关者依旧在相关部门中任职，但在团队中，他们已授权在必要时可在他们各自的领域中进行决策、接纳或改变。这样考虑到了开发人员以及架构师、法务部、企业营销传播，只要他们是开发过程中任何过程的利益相关者。

心跳就是将所有团队中所有授权为利益相关者的人聚集在一起的时刻（这样他们可从源头得到信息）。从我们建立产品待做事项及设计原则的早期时刻，一直到最终产品的交付，这些心跳(最好每个星期一次）就是我们取得成功的要素。

InfoQ：最后你对企业如何去培育敏捷心态还有什么建议吗？

Van Bennekum：我常常听到人们说诸如“这不适用于我们”之类的话。事实上敏捷工作使你具备响应力。你需要在动态发展的当前和未来世界中具有响应力，这是无法回避的。就敏捷而言，永远不要接受“这不适用于我们”之类的说法。时常合作共事以寻求解决问题的方法。