理解敏捷价值观（学习敏捷笔记）

理解敏捷价值观

敏捷是指能够让团队思考更加有效、工作更为高效、并且做出更好决策的一组方法和相关理念。敏捷也是一种思维模式

敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人

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

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

• 客户协作高于合同谈判

• 响应变化高于遵循计划

也就是说，虽然右项有其价值，但是我们更重视左项的价值。

瀑布式项目管理

需求分析–> 设计 --> 实现 --> 验证 --> 维护

最成功的项目会充分运用优良实践、工具和思想，将时间节省下来，与用户和同事沟通，应该考虑如何解决问题而不是花时间同代码作对

瀑布式流程要求团队在项目开始阶段完整的写下软件的描述，然后完全按照写下的文档构建软件。

瀑布式流程很难应对变化，因为这种流程关注的是文档而不是协作

没什么银弹流程或实践可以让项目完美运作

有些团队可以成功使用瀑布式流程，是因为采纳了高效的软件开发实践和原则，尤其是加强了沟通。

初步实践敏捷

更好的沟通可以帮助团队更好的管理变化

**团队作为一个整体来制定计划（planning as a team）**好过事先过度详细地制定计划，然后盲目执行。

软件项目具有不可预知性，从20世纪60年代开始产出不好的结果。这种情况在当时被称作"软件危机"

很多团队”步入敏捷“的方法是采用伟大的敏捷实践改善他们已经做的很好的事情

因为团队没有从根本上改变沟通和工作的方法，因此他们采用更好的实践得到的只是聊胜于无的结果

用户故事是一种敏捷实践，在这种实践中，一名团队成员（通常是产品所有者）通过几句话描述用户操作系统的各种具体方式，使用的语言是用户可以理解的语言

目前，采用敏捷最常用的方法是一次采用一种时间，但这并不是最有效的方法

敏捷宣言帮助理解敏捷

敏捷宣言包含了高效团队必备的共同价值观和思想

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

团队应该首先关注团队中的人以及人之间沟通的方式，工具和实践是次要的。盲目的遵循流程会使人走入误区。

好的工具有时候可以帮助我们更快的犯错。

拥有”正确的"，"最佳的"流程并不够，更重要的是将这些流程推销给队友，让大家心里有数，每个人都明白为什么这么做，在做什么，明白每个人的工作会对其他人造成什么印象。

用户故事、每日站会等流程和工具本身并不重要，重要的是这些东西可以帮助团队一起沟通、讨论、碰撞、协作实现这些流程和工具的真正意义

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

交付满足用户需求的软件比交付描述这个软件的说明文档重要

对于敏捷实践者，可工作的软件是给公司带来实际价值的软件。虽然通常团队不直接谈钱，但价值的大部分情况下最终回落到钱上面。团队应该着重于构建和交付能带来价值的可工作的软件，文档只是实现目标的工具。

可工作的软件高于详尽的文档，并不代表敏捷开发团队就不需要文档。在一个团队中，很多种类的文档可以帮助团队成员之间、团队与客户之间理解、沟通问题，避免可工作的软件中引入错误的需求，偏离正轨。这种文档消耗的成本与节省的时间和精力相比是划算的。

团队可以采用一些将文档嵌入软件本身的方法，如使用swagger生成API文档、实践TDD记录自动化测试代码等

客户协作高于合同谈判

传统项目团队中，程序员、产品测试人员、产品所有者、项目经理在不同的团队工作，相互之间遵循协定进行合作，而不是真正朝着交付可工作的软件这样一个单一目标合作努力。合同谈判的好处在于出现矛盾、问题的时候，可以”甩锅“，坏处是大家会倾向于保护自己/团队，潜在台词就是会不太愿意尝试新的合作方法，也不愿意为可工作的软件采用创新的方法。

客户协作就是要把所有人看作同一个团队的成员。

敏捷团队中，通过把PO当作团队中的一员，来落实这个价值观，PO将产品当作自己的东西，不实际进行开发工作，但更开发团队一起参加会议、贡献想法进行协作。PO同其他成员之间协作的媒介通常是用户故事。

响应变化高于遵循计划

计划是会变的，交付软件产品比严格遵循计划更重要。

理论上讲，遵循计划有利于项目顺利执行，但如果出现了变化，在产品完成度很高的情况下处理变化会更加困难。

制定计划的人通常很抗拒变化，这是正常的，因为将工作进行切分、评估每一份任务的工作量、重新调整工作安排都需要消耗不少精力。

任务板（task board）：是一种敏捷规划工具，大家把用户故事粘贴在任务板上，根据用户故事在当前项目或迭代中的状态，把这些用户故事分类在不同的列中。

任务板可以帮助团队做出响应变化的决策。建立任务、人、进度更快的反馈回路。必要的时候，可以站在任务板前面进行讨论、指定、移动相关卡片，拥抱变化。

原则高于实践

敏捷实践之上，还有一套敏捷的思维。践行实践的同时遵循原则，收获更大。

在为客户构建有价值的软件时，在互动、协作以及应对变化上采用敏捷实践，比仅仅在编程、文档、计划上采用敏捷实践收获更多。

jim highsmith 在《敏捷项目管理（第2版）》进行了总结

没有具体的实践，原则是贫瘠的；但是如果缺乏原则，实践则没有生命、没有个性、没有勇气。伟大的产品出自伟大的团队，而伟大的团队有原则、有个性、有勇气、有坚持、有胆量。

盲人摸象

以割裂的视角采用敏捷方法，每个人只会使用对自己的工作有影响的实践，对现状肯定会有所改善，就好像盲人只摸到大象的一部分，只看到敏捷实践中对自己有用的部分，这个团队会错过人与人之间重要的互动。视角割裂、相互独立，无法真正发挥团队的力量。

敏捷有很多优越的时间组成，整体比零散个体的总和更为强大。互动是内建在敏捷方法中的。

敏捷实践

只关注单个实践的团队看不到加强沟通和响应变化的大目标

敏捷方法涵盖了实践、思想、建议和团队

诸如scrum、极限编程、精益这样的敏捷方法，不仅包含了很多优越的实践，还要求团队关注这些目标背后的思想

敏捷教练通常使用隐喻帮助团队学习

敏捷团队不需要计划？？？，事实上敏捷团队做的计划比很多传统项目要更细致，敏捷团队只是不在一开始就做详尽的全局计划，而是工作计划的拆解到了敏捷实践的不同工具中了，以scrum为例，在每个sprint开始前，全员进行sprint计划会议，sprint进行中，每天组织每日站会。这些其实都是在为项目工作制定计划，而且由于是全员参与，所以花费在计划上的工作量折算起来，比传统项目团队要更多。也是由于全员参与，计划制定之后不需要再逐级宣贯、解释，可以直接开始实施，从外部看就是团队很少做项目计划，就直接进入项目实施阶段了。

现在可以做的事情

• 列出你和团队使用的所有实践，可以是：编写规格说明书、使用版本管理工具、甘特图、每日站会等
• 请团队中的其他人也写一个这样的列表，比较你们的列表。有哪些时间没有被所有人纳入列表？就此展开讨论。找出成员间视角的不同

学习资料

• 《敏捷软件开发（原书第 2 版）》，Alistair Cockburn 著：深入了解敏捷价值观和原则。
• 《敏捷项目管理（第 2 版）》，Jim Highsmith 著：深入了解原则和实践的关系。
• 《如何构建敏捷项目管理团队：ScrumMaster、敏捷教练与项目经理的实用指南 》，Lyssa Adkins 著：深入了解敏捷教练。

教练技巧

• 培训一个新团队的时候，单独与团队成员聊天，尝试理解不同角色之间视角的差异。
• 单独询问团队成员对敏捷宣言中价值观的理解：怎样看待这些价值观？哪些价值观最重 要？这些价值观是否可以用在日常工作中？
• 团队通常会有一种“聊胜于无”的感觉，但是不知道如何表达。直接提出这个概念，要 求团队成员想出一些感到“徒劳”的实践或一些事半功倍的实践。
• 发起关于敏捷宣言中某项价值观或原则的讨论。例如，如果团队谈到了他们与客户之间 协商定下的“合约”，那么可以以这份合约作为起点讨论合同谈判与客户协作之间的异同。 帮助他们理解在哪里作出选择。