敏捷宣言与12条原则

让我们一起来回顾一下敏捷宣言和12条原则，不了解这些，怎么进行实践呢。

敏捷宣言：

个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷12条原则

1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7、工作的软件是首要进度度量标准。
8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9、不断地关注优秀的技能和好的设计会增强敏捷能力。
10、简单----使未完成的工作最大化的艺术----是根本的。
11、最好的构架、需求和设计出自与自组织的团队。
12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

你真的在做敏捷实践吗？

【敏捷】一词诞生了很多年了，自从硅谷传出《人月神话》和《deadline》，敏捷一词便火便全球，什么结对编程、软件过程…好似一个个胎死腹中。

敏捷，咋一听，就是快速！软件开发不再是笨重和不断延期，而是可以快起来，如果不赶快乘上敏捷的高铁，就会慢人一等似的。老板一听到敏捷，就感觉本来5天的活3天就可以做完了。

敏捷，真的是这样吗？

敏捷其实只是一种理念，而不是一种工具，它是一种实践，而非标准化的流程。

敏捷不过分看重文档，不过分看重流程，也不过分看重形式。

大家一谈敏捷便与瀑布开发做对比，觉得瀑布开发流程繁琐，周期冗长，效率低下，于是每年都举办几次培训，号召大家要敏捷，不要瀑布，好像去年一年都没有用过“敏捷”似的。难道去年做的“敏捷”属于瀑布式开发？难道去年做的迭代效率太低？

我也不知道我的项目敏不敏捷，好像领导一直觉得不够快。

敏捷不是单纯的迭代，但敏捷里可以有迭代，通过小步快跑的方式，把确定性的需求逐步加入计划，通过有节奏的“心跳式”步伐，使得宠大的需求逐步变现，让大家都能及时地看到落地的进度和效果，而不是推土机式的开发：需求调研-可行性分析-需求评审-软件设计（概要-详细）-编码实现-测试-UAT-上线…，每个过程结束才能进行下个过程。

瀑布开发就是推土机式的开发吗？

其实不是的，瀑布是重视软件开发流程，并不是说任务不可以并行。在很久以前，大家比较注重文档，花了大量的精力写文档做设计，所以效率较低，敏捷宣称代码就是最好的文档，轻文档，并借此提高了效率，自从敏捷实施以来，效率的确提升不少，带来的副作用是越来越多的人不注重文档，甚至连基本的接口文档都懒得写了。

如果你对瀑布式开发没有了偏见，请继续往下看。

瀑布式开发真的效率低吗？

从惠州走路去成都，估计你要一天一天的走，晚上找酒店休息，如果从TCL工业大厦走到惠州西湖，请问你还要一段一段地走，中间休息一会吗？

到底要不要迭代开发，要看具体的工作量来定，如果你的项目通过3周就可以全部完成，那你还要硬生生地分成两个迭代来做吗？

如果你要跑50公里，那么，你最好是一段一段地跑，中间休息一下，做一下迭代回顾，汇报一下进度，让监视你的人知道你已经跑了百分之多少，如果你要跑1公里，那么最好的办法是一口气跑完。

如果你的需求全是比较确定的，那么敏捷迭代并不一定会提升效率，反而会耽搁更多时间。即便你的需求是渐进性确定的，敏捷也不会提升多少人效，并不是说采用了敏捷，5月人的活3个人就干完了，5天的活3天就搞好了。任务的安排其实是运筹学的算法，怎么安排更省时间，敏捷并不是最优解，它只是一种相对优的可能解。

敏捷实践是迭代开发吗？

迭代开发属不属于敏捷？敏捷是不是迭代开发？想必很多人区分不出来，迭代开发是一种战术，敏捷是一种战略，所以他们并不等价，只不过大多数情况下，敏捷都是迭代开发的。迭代是有确定（注意不是固定）的周期，它有开始和结束，在开始和结束时有相关的实践活动，比如需求评审、sprint计划、task拆解（类似瀑布里的WBS分解，只不过规模小一些）、迭代回顾、工作汇报等，像上面说的，即使不采用迭代，逐渐地把确定的需求滚动的加到任务里落地，也一样是敏捷实践。

迭代开发的好处是，当你的距离很远时，有节奏的步伐更能给人信心，它并没有降低你到达终点的时间，反而往往是花费了更多的时间，如果需求模糊多变，敏捷整体上可能是省时的。

细数敏捷实践中的问题与误区

误区一：敏捷可以减人减时，提高效率

敏捷是否可以减人减时，提高效率是要分情况的，不能一概而论。 对于合适的场景，敏捷可以减少等待，快速落地，也能从容面对需求变更，从而提高效率，但项目分段实施带来的一系列活动，比如：每个迭代的需求评审、设计评审、每日站会、story-task拆分、工时确认、迭代回顾、代码评审…加重了项目组的负担，当然也占用了不可忽视的时间。

敏捷并没有减少任务，也没有让代码少写一行，而且往往因为设计、架构不充分，需要更多的精力重构、优化、测试，使时间拉长，既没有减人，也没有减时，能否最终提升效率，有待评估。

所以，以后不要说”都敏捷开发了，为什么人不能少几个呢？“。

误区二：所有项目都应该敏捷开发，不敏捷迭代就是低效

并不是所有项目都应该敏捷开发，比如需求已确定的小项目，或者不适合拆分的事项，或者有确定紧急的项目需要以最快的速度上线的。一些三五人两三周就可以搞定的小项目，没必要非得两周一个迭代的搞，一口气搞完就可以了。

对于产品开发，前期整体设计和基础框架很重要，这是打地基的阶段，很难以固定的周期进行，很多任务不宜拆的很细，要知道对迭代内容的确定、时间的确定、以及story-task的拆分都是比较困难的，硬性的限制只会让产品一开始就成为一个阉割版本，在后面的迭代中，会造成软件设计和架构的频繁变更，如果后期没有那么多时间进行重构，大家就只能采用折中的办法累积功能，这就是为什么一个前期堆人快速开发，或前期过分强调时间的项目，到后期变成了代码屎山，扔又扔不掉，改又改不动，问题多且不稳定。除非是为了领导的业绩，否则不建议这么搞。

误区三：每日站会、彩色便签…这就是敏捷开发

每日站会是否一定有必要开？

这要分情况，如果项目组不超过5个人，那么每日站会就不一定必须开，一个项目经理对5个人的工作内容和进度都掌握不了，还必须通过每日站会来了解，说明这个人管理水平不行。在人少的团队，需求是项目经理和用户定的、任务是项目经理分配 、每天的任务状态、代码提交，项目经理都可以看到，具体问题可以一对一的沟通，整体问题可以快速短会，大家也清楚各自的情况，没必要流于形式来开会。

如果一个项目有超过20人的开发测试队伍，那么也不适合每日站会，人太多了，每个人说三句话，一个上午快过去了，很多时候一个人并不关心所有人的进度，他也未必听得懂别人在说啥，人多就要分组管，分组开。

每日站会是进度跟踪会，不是问题解决会，有的项目每日站会可以开几个小时，中间讨论/争论一些问题，寻求在会议上解决问题，就没有意义了。项目经理通过站会了解到每个人做的事情和进度就可以了，问题单独处理。站会还可以带来中一个好处，一个人可以了解与之有关的其他人的进展，以免任务延迟或死锁。

另外，站会也不一定非得每天，如果能把控进度，两天一次也是可以的。

彩色便签，帖满了白板或整个墙，是不是很酷很有气氛？

彩色便签是对task的管理工具，用与不用都可以，达到目的即可。它是快速了解当前task状态的工具，包括todo,doing,done，无论是用物理的纸签，还是软件里的都可以，前提是task要拆的合理，及时的更新状态，这样可以根据燃尽图把控迭代进度。

有的项目写满了小纸签，贴了整面墙，私下里一问，其实没啥效果，反而写纸签，贴纸签花费了大量的时间，如果不是为了表现给外行人看，真的没必要为了更像敏捷而使用便签，当然用的好的一般都能提效。

误区四：两周一个迭代才是真敏捷

迭代是否需要以固定的频率？

不一定，跑步的速度有快有慢，心跳的频率也有加快和减慢，没有人能一直以极快的速度奔跑，心跳一直过快是心脏病的前兆。但，迭代不一定非得以固定的周期进行。

一个story可大可小，往往是分级的（在TONE中是Epic-Feature-Story实际上也是分级)，有的story不好拆分，它可能比较大，放到两周内比较占时间，虽说“大于3天的story理论上都是可以拆的"，但真的拆成多个，完成了其中一部分并没多大意义。比如某个迭代需要接入阿里的支付功能，这个功能流程较长且复杂，开发人员要熟悉SDK，写各种逻辑、做很多验证，如果拆成多个story当然可以做到，但可能要放到多个”两周“里，从而失去了上线的意义。硬要拆，硬要中间上线也是可以的，但是用户并不关心你中间的迭代，它只关心这个需求完全做好的里程碑节点。

其实，定死两周一个迭代是一个误区，只不过大多数人觉得1周太短做不了什么事，一个月太长领导接受不了，所以就有人提义2周一迭代。

迭代一定要两周一个吗？

在我看来，迭代的长短不需要定死，2周，3周，1个月，甚至5周都可以，根据节奏来，在每个迭代结束前定好下下迭代的目标，评估好时间，不要太短，不要过长就可以了，硬性拆分或硬性压缩没有必要，反而会拉长周期，降低效率。

敏捷常常需要根据当前的需求，优化前期的设计或架构，或代码，它是滚动优化的，但这个时间常常被忽视了，如果项目经理不是兼任开发经理，他常常不会考虑这块的工作量，而会根据人效确定累加的需求，可能造成大家堆功能，”不要做重构“，”不懂的代码不要改“，”能跑起来就行，别动，动了就是你的锅“…

迭代是敏捷的实践，两周一个迭代只是迭代的一种实践，迭代可以有周期，周期不一定不可变，凡事实事求是，因事制宜的来，死守成规的人多是懒于思考的人，或者是外行管内行的人。

误区五：所有项目应该迭代的步调一致

对于PMO来说，常常会遇到这样一种问题：甲部门的项目A要调用乙部门的项目B的功能，双方需要对接，对接任务可能需要3天，项目A在本周五迭代上线，但是项目B需要到下周五才迭代上线，那么项目A不得不等到项目B上线才能使功能可用。

也就是项目间迭代步调不一致，而且有相互协作的需求时，常常出现因为依赖没有上线，自己也不能如期交付的情况。

于是忽，有人提出应该所有项目迭代步调一致，这样大家都在同一天发版，就不会出现此问题了。

理想很丰满，现实很骨感。

首先，要做到所有项目步调一致，要定死迭代周期，并且协调各项目在同一天开始迭代，这个难度可想而知，实施过的企业基本都失败或放弃了； 其次，项目管理中的到项目有个特点，就是它是临时性的，它和产品不一样，一般产品的周期很长，而项目一般始于立项终于结项，要想做到所有项目同时立项，同时结项是不可能的，而且每个项目均有自己独特的里程碑，比如某项目要在一个工厂流水线开动前一周上线试动行，或者某个项目要在领导视察的那天演示，这些事件驱动的里程碑是无法做到和其他项目一致的节点的。即使项目强行拉到同一起跑线上，也会因为各种问题被打乱节奏。

对于这种项目间依赖的情况，需要项目间，或PMO或双方领导，甚至更上一层的领导协调的，这是躲不过的责任，不是把所有项目调成一个”调调“就可以躺平了。

只有需求粒度较细，且比较均匀的情况下有可能实现，但是即使实现了也只是短暂的，早晚会被打破。

误区六：敏捷开发不需要制定计划

敏捷并没有否定瀑布开发的模式，敏捷并非不需要制定计划，尤其在项目前期，应制定整个项目或产品的长期计划，虽然有些内容因为不确定性，无法确认最终的周期，但原景、大的里程节点、以及每个迭代的主体目标还是很有必要的，敏捷只是更加关注需求或用户故事、客户价值的优先级，并不是说一句”我们要做***！“，然后就冲上去干了。

敏捷的计划是一个持续的过程，不断的细化，不断的调整，不断的落地。

误区七：敏捷就是要快，速度第一

敏捷的本意并非要快，不用敏捷开发并非就是要慢，敏捷同样是要注重质量的，而且随着需求的增加，很有可能前面的内容需要及时的重构和重测，否则，必将会是功能的堆砌，后期就会负重蹒跚而行。

敏捷的快，是速度响应变化的快，以帮助客户迅速适应市场的变化，响应变化带来的收益赶得上开发周期快带来的收益，敏捷才会更有价值。

如果只注重快速的投放，而忽视了质量，只会引来用户的嘲笑，今年ChartGPT出来后，国内各大公司纷纷推出自己的产品，可是，又有什么用呢？

误区八：敏捷不需要文档

敏捷并非不需要文档，只不过敏捷不要面面俱到的文档。

按理说，文档肯定越细越好，但问题是越细的文档越需要花大量的时间来撰写，也需要阅读的人花费更多的时间，因此不能要求什么文档都要。有的公司一边要求实施敏捷，一边要求项目各种文档都要齐全细致，简直自相矛盾。

当然，敏捷也需要写文档，文档要写干货，复杂的功能要有设计吧？前后端对接要有接口说明吧？文档不是最终目的，它只是交流的手段，也是应对人员变动的工具，没有文档，总不能光靠比划或嘴皮子吧？

至于哪些东西需要显式的文档，不是公司流程约束的，而应当实施团队负责任的提供。也许有人担心，不要求写就没人写了，如果真是这样，项目组通过比划或嘴皮子都能做的很好，你又何必操心呢？如果不是这样，这样的团队又怎么值得信任呢？

该写文档的地方不写，看似能加快开发速度，实际上会造成可怕的后果，将来一旦有点问题，便无章可查，写文档的确可以梳理思路，代码虽然是最全的文档，但是代码有可能写的是错的，简练而重要的文档，往往可以帮助新人或其他干系人快速了解项目，帮助工程师更好的阅读代码。

敏捷的好处

说了那么多问题，是不是说敏捷不好？

当然不是的，敏捷是好的，它是一种思想和战略，关键是实践的人，好的实践可以解决很多问题，差的实践会带来很多问题，不好不坏的实践不值一提。我们再来回顾一下敏捷的好处。

把逐步确定的需求，逐步落地实现，中间有成果，有反馈，可上线； 对于需求不确定的项目或产品，如果整个周期过长，可以用敏捷实践迭代开发，每个迭代都与用户沟通确定新的需求，验收已实现的需求，即不浪费时间，也可让干系人放心。

减少大量的调研、文档，减少不停的掰扯，快速落地产品；

规划的再好，没有落地就等于0，避免把时间耗在不确定的事情上，先做一个“会走的骷髅”，而不是从开始就去做一个完美的产品，早播种早上市，萝卜虽小但能卖个好价钱，等萝卜长大了，说不定价格低的不划算了。夜长梦多，当有了原始的需求，有了初步的想法后，可以马上做一个“原型机”出来，在后面不断地增加确定的需求，对前面的内容做修改和重构，让它演变成一个好的产品，好的架构。

敏捷的另外一个好处是它可以轻松应对快速变化的需求，因为它每次都只做一小批活，不会一次走的太远，可以及时调整方向，如果需求有变更，可以有针对性的评估，加入迭代。

精益模式

什么是精益模式

精益起源于丰田，只不过它之前适用于后产制造，而非软件开发，精益生产的思维是以人员为基础，尊重人性，注重培育员工，透过全员持续学习去参与改善，以更多的智慧、更优秀的人员、用更精实的方式去优化企业的营运，从而为人员、顾客、社会创造出更多的价值。

和敏捷一样，精益，也是一种思想，它是战略，具体采用了哪些战术，不同的企业实践的也是千差万别。

精益模式的精髓是只在必要的时候，按照需求的量，仅生产必要的产品，拒绝浪费，把这一点用在软件开发领域，就是精益软件开发。精益模式看重的是人、流程和技术三者的结合，招聘或培养团队，用好的技术和工具，三位一体，协调发展，才能真正的做到精益。

由此可见，敏捷强调的是事，而精益强调的是人。对于敏捷，你采用正编还是外包，采用高级还是中级，它并不十分关心，只要大家都采用敏捷的模式去做事就可以了，无非能力差一点，每个迭代做的少一点，而精益则不然:

精益思想强调如何将每个员工的能力发挥到极限，认为不应该只是简单的管理人，而应该去培训人。如果不能将管理的重点放在员工的培养上，就不能理解精益生产的真理。

同时，精益生产的另一个精髓是管理过程，精益思想不是着眼于结果，而是强调过程。“只对结果管理”的管理思路的结果是员工对找借口、为结果辩护很在行，对数据、报告很在行，但软件项目成果的质量只有在全过程都有效控制下才能得到根本的保证。

由此可见，精益和敏捷他们不是对立的，它们的理念都很好，能否实践的好，在于团队在于人，人的思想存在误区，那么采取的措施就有问题，可能南辕北辙，可能背离了降本提效的初衷。

精益开发的原则

杜绝浪费：将所有的时间花在能够增加客户价值的事情上。
推迟决策：根据实际情况保持可选方案的开放性，但时间不能过长。
加强学习：使用科学的学习方法。
快速交付：当客户索取价值时应立即交付价值。
打造精品：使用恰当的方法确保质量。
授权团队：让创造增值的员工充分发挥自己的潜力。
优化整体：防止以损害整体为代价而优化部分的倾向。

精益模式如何做

精益模式，实践的第一步，是要建立一套完整的开发流程，然后建立一套测量流程的手段，不断持之以恒地改善流程，不断优化，坚持不懈。无论是Scrum还是TONE，都是工具，依托工具制定的一系列要求和考核是在完善工具，并加强测量。

各企业的研发流程一定是不一样的，建立建全适合自己的流程，是精益模式的必备。流程的精细化、标准化、可操作化是精益的基础之一。流程需要规范和固化下来，持续的发挥价值。

将合适的人员安排在合适的岗位上,项目首席要面对挑战，不退缩，找出问题的根源，在不同的方案中找到平衡。因此，精益模式对人的要求比较高，没有合适的人，无论采用什么样的敏捷迭代都不能把项目做好。团队是精益的根本，有稳固的团队，调动每个员工的积极性，才能使项目高效实施。

建立应用开发技术平台和工具也是精益的核心，好的项目管理工具可以减少管理损耗，减少浪费，不断地追求新技术、新工具，才能使团队和产品立于不败之地。

精益开发会优先推出一个MVP原型机，把他们认为的产品应当具备的功能罗列出来，然后一一排除，排定优先级，决定哪个功能要在最初的版本中出现，而哪个可以靠后一些，这些抉择是很纠结的，，因为诱惑太多，把某些功能刻意强加进产品，是会削弱产品整体流畅性的。

总结

无论是敏捷，还是精益，都是软件开发中的实践，目的是提高生产率，敏捷并不一定是最好的，它只不过有好的理论观点，实践的好坏全看项目或个人，并且想靠它节省人力或时间，恐怕不一定是敏捷能解决的，请IT的管理人员要想清楚，不要误入歧途了。

敏捷这个词太有诱惑力了，一听上去就好像能变快似的，所以一些外行管理都就开始拍脑袋了。敏捷的每个迭代就像一个个小瀑布，走出敏捷的误区，才能真正有帮助。

从敏捷走向精益，并不是软件实施过程的最终解决方案，其实敏捷中的各种问题都是人们对敏捷做了错误的实践，如果你认清了问题的本质，什么瀑布模式、敏捷模式，还是精益模式，又有多大的区别呢，什么时候做迭代，周期多长，什么时候用瀑布快速交付，什么时候用精益以人为本，都可以，问题是你要首先找到主要问题，因事制宜地用。