SPI解读敏捷十二原则

我们遵循以下原则：

（1） 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。（2） 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。（3） 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。（4） 项目过程中，业务人员与开发人员必须在一起工作。（5） 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。（6） 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。（7） 可用的软件是衡量进度的主要指标。（8） 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持持续稳定的进展速度。（9） 对技术的精益求精以及对设计的不断完善将提升敏捷性。（10） 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。（11） 最佳的架构、需求和设计出自于自组织的团队。（12） 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

（1） 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

          这里的关键词是尽早、持续地、有价值的，倡导它们背后的原因是：

          一般产品只有20%左右的功能是用户常用的，即对用户有价值的，为实现其他80%功能的投入被视为浪费；同时对客户无用的功能不仅不会产生价值，反而会让客户反感、甚至放弃使用整个产品；所以交付有价值的功能或产品是最基本的要求。

          尽早地交付产品 小则可以通过客户的反馈尽早发现产品的调整点，减少后期的不合理成本投入；大则可以及早调整产品策略或先于竞争对手抢占市场，进而让产品获得更大成功。

          持续地即可以让“尽早”交付“有价值的”产品的能力具备持续性，而不是建立在一种临时突击的策略上，好比打了兴奋剂能跑得更快，但是好名次不能总靠打兴奋剂得来；

          另外持续交付产品一方面可以满足用户持续增长或改变的需求，另一方面任何一个产品都不可能一次做完美、只有通过持续优化才能越来越好 越来越符合用户的使用。

          以上3点是一个产品满足用户最重要的方式，自然而然的就成为了敏捷的最高目标。

（2） 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

          这个观点往往是很难让开发测试等童鞋接受的，尤其是对“即使是在项目开发后期”这点。

          这可能是因为有时候我们了忽略“要善于利用需求变更，帮助客户获得竞争优势。”这句话，或者误解了“欢迎对需求提出变更——即使是在项目开发后期。”这句话；误以为敏捷倡导无条件的接受任何需求变更。

          其实敏捷认为 需求变更的基本价值要是让客户更爽，如果不具备这点的需求变更不是敏捷所倡导的；同时是否变更一定还会受影响于以下因素：

         A.改变的投入产出比；（RIO<1的要慎重考虑，>1的一般可以进行）

         B.这样的变更是否是PO和团队现阶段无法在前期预料到的；（如果是无法预料的，那么需要欣然接受；如果本可以预料但只是没有去关注、那么这样变更不能随意进行，因为久而久之会惯坏PO和团队。）

         其实这一点在教导我们要有一颗站在客户着想的心，而不是为自己着想的心。

（3） 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

          这条里的“不断”、“可用”“越短越好”与第一条的“持续”、“有价值”、“尽早”表达的应该是一个意思；只是说的更具体明了一点、同时特别强的了周期越短越好。

          对于“越短越好”，我认为还是需要有个“度”的，这个“度”是要用户能接受的；不同业务特点、用户特点、反馈方式让 这个“度”会不同，需要我们灵活的去判断。

（4） 项目过程中，业务人员与开发人员必须在一起工作。

          不管是业务人员还是开发人员，常把他们间的关系视为上下游的合作关系，业务人员把与客户谈判的东西整理为需求和合同交给开发人员，开发人员做出产品后交给业务人员反馈给客户，开发人员不关心业务人员在前方和客户怎么沟通的，业务人员不关注开发人员在后方怎么实现产品的。这样合作的问题是，彼此间划出明显的分界和串行的交付关系，当出现问题时，业务和开发维护各自利益，互相指责和扯皮。为了达到短迭代、快速交付有价值的产品，在项目过程中，业务人员和开发人员必须频繁进行有意义的交互，才能共同承担达成项目成功的责任，消除前面所提到的壁垒。这里的“在一起”，有两方面含义：业务人员和开发人员是一个团队的不同角色，要像一个团队那样工作；他们最好物理空间上在一起，可以迅速达成有效的沟通合作。

（5） 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

          敏捷的核心理念是“适应和以人为本”。以人为本可以从两方面解读：一方面是人被认为是项目取得成功的最重要的因素，其他的因素例如过程、环境、管理等等都被认为是次要的，其他因素对于人有负面的影响时，需要进行改善，反之，良好的过程、环境、管理等，能对人起到正向激励和辅助作用；另一方面是，人天然有把事情做完做好的意愿，要相信项目成员主观意愿上都是愿意投入和付出的，为了完成任务，他们有主动寻找更好的方式的驱动力（有自我改进的内驱力，需要给他们反思和反馈的机会）。

（6） 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

          在工作中有很多的先进的沟通工具可以选择，文档、信件、Email、电话、手机、IM、SNS、远程视频、协同管理软件等等，我们每天的工作中都会用到这些工具，以至于我们是如此的依赖它们，反而忽视了最原始却也是最直接有效的沟通方式——面对面交谈。在合作中，过度依赖编写详尽的文档、忽视人和人之间的沟通是不可取的，只有近距离的、面对面的交谈，我们才能最大限度的接收对方的信息从而做出准确的判断和反馈，进而提升沟通效率，例如旺旺给工作带来很多便利，但文字有二义性，如果不能看到对方的面孔手势语气，沟通的结果也许会南辕北辙。工作中不可避免要借用许多沟通工具提升效率，“刚刚好”的文档也是必须的，但面对面的沟通，才是最有效的、默认的第一选择。

（7）可工作的软件是衡量进度的首要标准

          无论是产出的文档量，还是计划显示的进展，燃尽图，等等各种手段，仍旧只是中间的证明产物，和说服证据，最终能够作为实际进度事实的，就是无限趋近于最终成果的软件拼图片段－可工作的软件部件。引申联想一下，精益思想中认为有时过程中的与最终目标没有必备关系的其他产物，哪怕是过程中间产物，也是多余的耗损和浪费。应该在达到最终目标的过程中最小程度减少不必要的分散产能的行为和产物。也许这也是这条原则形成的根源支持思想吧。  

（8）敏捷过程提倡可持续的开发

          项目方、开发人员和用户应该能够保持恒久稳定的进展速度。敏捷最终是希望提升平均交付周期，发布速率的提升，而不是短视的某一次产品发布的快，或甚至某一轮sprint冲刺的快。所以如果简单的说敏捷就是快，是不准确的。这里关注的是视宏观过程，是在人员养成敏捷习惯后，才能达成提升整体交付周期的效果。

（9）持续专注于技术的精进和设计的完善会促进敏捷性

          相当于工欲善其事，必先利其器。工程实践上的提升，将会从根本上支持敏捷性的提升。好比工业时代于生产力的变革带来的大幅生产力提升。所以敏捷是推崇和支持优秀的工程实践萌发的，于是后续出现了XP极限编程、持续集成等实践。这点原则也体现了敏捷不仅追求效率，也重视和有助益于质量。

（10） 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术

          未来的变化可以预期但不一定会按照预期的发生，所以不可能在一开始就构建完美的架构和功能满足未来的所有变化。做了不需要的即为浪费，敏捷倡导“刚刚好”，不为未来的需求写代码，不为写文档而写文档，而是专注于如何用最简单的方法解决现在的问题，尽可能的减少浪费的产生。但做到这点不完全有迹可循，是为艺术。
         减少不必要的工作不是说不要文档或者完全抵触，文档的展示方式有很多种，如果通过一个流程图、架构图或者的UED的交互图、flash等就可以让大家明确的知道需求和怎么去做，那就不用把需求用详尽的文字描述出来，倡导“刚刚好”，另外也有一个方面需要注意，如果是方便后续可持续的维护产品（比如团队有人离职来新人等），则可能也需要有部分文档沉淀下来，做为后续的指导，总之，对于敏捷而言，这里没有特定的规则，需要根据团队的实际情况来定义文档的简洁程度，来决定是否为必要的工作，这个度即为艺术。

（11） 最佳的架构、需求和设计出自于自组织的团队

          自组织团队没有管理者发号施令，由团队自身寻找最佳的工作方式来完成工作。软件开发是脑力产品，不同主观意愿驱动下产生的结果可能天壤之别。基于对人有把事情做好的良好愿望并愿意为之付出最大努力的信任，放手团队，可以充分发挥团队成员的主观能动性，产出基于团队能力的最好的产物。 
         老板和员工的游戏，员工要在规定的时间内从一堆障碍物之间穿过去，如果员工只能等老板发号施令才能去行动，则“老板”思考的时间、发出指令的时间和“员工”的反应时间，这些无疑都成了拖延时间的因素，在这个过程中，员工为了在规定时间完成目标，手忙脚乱，老板也很累，而另一种游戏方式，则是老板完全放手让员工去走，不用等老板发号施令，于是员工灵活变通很快就完成了目标，敏捷倡导的是自我管理，这是敏捷思想很重要的一个理念，充分的信任与授权，更能激发出人的潜能和主动性，因此最佳的产物出自于自组织的团队。

（12） 团队要定期反省如何能够做到更有效，并相应地调整团队的行为

          过程中的很多不确定因素对团队的影响都需要团队作出不同反应。敏捷基于经验性过程控制理论，其优化目标的实现手段是通过不断的检查-反省和调整-适应来使得范围、时间、成本保持平衡。团队通过定期的反省，找出可以改进的方向并据此调整团队的行为，以团队认可的方式不断修正达到目标的路径，保持团队的敏捷性。 
         定期的回顾会议与反省是让团队成长和进步的最好的机会，除了找出问题和改进点，在下一个迭代中哪几个是必须要做到并改进的，如何去执行也很重要，可以通过优先级、重要程度一步步来进行推进和调整团队的行为，以避免反省成为一种形式。