@SparkYu(喻志坚 招行 项目经理)：敏捷、精益有什么区别？

@何红旗[hktxcn.com]（何红旗-汇科天下-产品）：讲当敏捷和精益吧，看大家讲的多是敏捷，有提精益的，但我不是太理解两者之间的关系和区别

答：先说一个事实：敏捷早期受到了精益思想的一些影响，比如Scrum和XP的发明人都声称受到精益思想的启发，但这些影响不是根本性的。早年提敏捷时，较少说到精益。不过最近3，5年情况变了，好像只说敏捷，不带上精益就一点也不酷。

两者中，敏捷更容易理解。敏捷就是敏捷（able to move quickly and easily）。具体到产品开发就是：“更早的交付价值，更灵活的应对变化”，这是一个目标，也是一个能力要求。至于各种实践，其实都是为这一目标服务的。比如Scrum是管理迭代交付过程的一个框架，有人可能说不是，说Scrum还是一个持续改进的框架，但持续改进不也是为了价值交付吗？TDD，持续集成等实践都是服务于这个目标。

精益的目标也不复杂，消除价值交付过程中的浪费，交付更多有用的价值。它最核心的就是两个字“价值”，体现到产品开发中就是要“顺畅，高质量地交付有用的价值”，就目标本身而言，如果顺畅，你自然就是敏捷的，精益是涵盖了敏捷的，但不能因此就说精益更牛，毕竟说大目标谁不会啊。精益的核心还是为了实现这一目标背后的方法学支持。方法学我没办法展开来讲，好在，我有一篇完整的文章说了，也做过一次线上分享。大家可以参考。在我的公号（LeanAction）中回复“精益思想”可以找到这篇文章。

那为什么精益这两年提得特别多呢，我看到三个原因。

第一： 产品交付的要求越来越高了。如果只是开发阶段的迭代根本不能做到交付真正的价值。这时原先适应小团队和交付阶段的Scrum，XP方法搞不定了。我们需要打通组织的整个价值链，做到所谓前后的真正拉通，规模和关联复杂时还要融合左右，目标只有一个——快速的交付价值或验证设想。今天几乎所有的大规模敏捷框架（比如SAFe，LeSS）都会把精益思想和实践作为基础，背后就是这个道理。顺便说一句，我个人是不支持任何大规模敏捷框架的，包括。

第二：创新的要求越来越高了。敏捷宣言里说，我们要响应变化。Scrum和XP的实践也是这么做了。但今天互联网时代，要求变得更高了。响应变化这个词其实显得有点被动，它暗含了一个假设，就是有人会告诉你改变了，该怎么变。然而，今天这不是事实了。团队需要刻意的有计划的去探索、去寻求变化，甚至试错这个词都不能表达背后的意义，应该是目标驱动地、系统和高效试错。唯有这样才能交付出有用的东西。在这一背景先产生了精益创业的方法，精益创业事实上是精益思想，在产品创新（而不仅仅是创业）过程的应用。这个和精益思想有什么联系我就不展开了，Eric Ries在《精益创业》中有很好的阐述。

第三：敏捷的落地和变革非常困难。定义一个理想的模式是容易的，了解现状要难一些，但也还好。最困难的是，如何从现状到达理想的目标。精益方法为此提供了方法学和实践的支持。我在书的第19章，就专门阐述了这一点。我讲了怎么化解资源效率和流动效率的悖论，并以流动效率为核心来组织团队的改进过程。这背后其实就是精益的改进思路和实践。

总结一下：

第一：敏捷作为一个目标，就是更早交付和灵活的响应变化。它特别重要，但不代表产品交付的全部。

第二：精益强调是顺畅和高质量的交付，以及交付的是真正的价值。

第三：精益作为一个工具，应该主导精益和敏捷的实施。毕竟创新和价值交付是产品开发组织存在的理由。我们应该回到这个根本上来。

不过，很多时候精益和敏捷一般是混着用的，这没关系。重要的是，你应该合理应用敏捷的实践，并掌握精益这个强大的工具，实现真正的精益和敏捷的目标——顺畅（包含灵活）和高质量的交付真正的价值，有力支持业务的成功。

@Charles(charles+我爱卡+ 技术经理)敏捷和持续交付的关系讲讲

敏捷是一个目标，也是一个能力要求，而持续交付是这个能力的最核心部分，是集成和标志，具备持续交付能力，其它能力估计问题也不大。

Jez Humble 给持续交付的定义是：以可持续的方式将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速地落实到生产环境或用户手中的能力。

按这个定义，持续交付不就是敏捷响应的能力吗？不过，持续交付从字面意义上，偏向工程实践，特别是软件构建和部署的Pipeline，但它也应该包含组织和管理实践。

其实今天，敏捷、持续交付、DevOps、精益（产品开发）是近义词，每个社区也都在努力扩展自己的外延，都在拉近自己和业务以及创新的关系，最后也就殊途同归了。

另外，持续交付这个词，我蛮喜欢的，它指向明确，又有撬动作用。DevOps就不那么明确。但模糊性反而DevOps有更大的想象空间，搞得朋友多多的，谁都为它站台，特别是云计算厂商，都号称自己是DevOps 的enabler。这样也不错，众人拾柴火焰高吗。

@飞翔的心(杨亮+尚科+sm): 进行scrum开发，如果提升团队的需求拆解能力？

@梅（梅宝强+北森+架构师）：产品大特性如果需要跨sprint时，是否需要拆分成小故事？如何评估和衡量

答：大特性的分解是必要的，因为这样才能1）更早和更灵活地交付；2）更早的发现风险；3）方便计划安排

拆分有三个基本要求，1）要足够小，从迭代的角度，至少要能很容易的放入一个迭代，理想情况下一个迭代要能做多个需求；2）拆完的要端到端（有价值，能测试，能交付）；3）拆完后还要能看到整体。

为了拆而拆而拆，把拆分当成单独的工作是常见的误区。拆分应该是需求组织、分析和澄清的副产品，而不是单独的任务。

具体到实践，故事地图和实例化需求这两个实践很有用。其中故事地图是为了按业务场景来组织和规划需求。实例化需求的目的是有效地分析和澄清需求，过去OOA(面向对象分析)所解决的问题，实例化需求当中也会体现，只不过更适合迭代或持续的交付。实例化需求，我实施的时候觉得是个比较容易的实践，也能解决上面的问题。但是现实中做好的团队的确不多，等我有时间应该好好总结一下才对。

@小鱼（汇合发展-余晓蒨（软件开发部门经理））：如何让非IT人员理解敏捷，然后可以一起参与推动敏捷的实施和改善？

答：敏捷作为一个目标（快速、灵活的交付）本来就是业务的目标，而IT人员要做的是建立起实现这一目标的能力，我们称之为IT的敏捷交付能力。

这是前提，那怎么让非IT的人员理解敏捷呢。那就是要回到业务本省，谈灵活交付，谈端到端的价值交付，谈交付真实的价值。这些背后往往包含精益的思想，这部分解释了为什么最近两年，突然谈敏捷时，必有精益。

@天外来客（金毅，光环国际，敏捷咨询顾问）：WIP经验值与案例

答：我在书中用了三个章节和大量的案例谈WIP这件事，也给出了相应的经验和方法。

对这个问题，我在实施中很少会纠结。而那些纠结WIP应该是几的团队，往往还有更基础的问题需要解决。那就是要围绕价值组织团队的协作和交付，打通和可视化端到端的价值交付流程。有了这个基础，你会发现WIP的设置和贯彻难度会极大的降低。专注于已经开始的价值，快速完成它们，难道不是很自然的事吗？

如果团队看到的只是任务，这时要求设置WIP限制，就会很不容易接受，达到的实际业务效果也不直接，推广起来当然难。

@追梦(追梦 联想 研发)：我想了解的是：敏捷开发流程的前提是团队都需要具备敏捷思维，那么如何带动团队快速敏捷起来呢？

答：什么是敏捷思维？凭什么你的思维是敏捷的，而我的不是呢？这是我们应该思考的。

我不认为敏捷思维的说法是错的，但现实中鼓吹敏捷思维，效果的确不好。这你也看到了。作为个人应该有敏捷思维（不管这种思维是尊重人也好，适应性或成长思维也罢），但回到执行层面却不能要求别人有自己所为的“敏捷思维”，更不能以此占据道德高点。

我们需要的价值思维和目标思维，而把敏捷看成实现目标的方法。所以，第一步应该达成共识的是，我们作为一个组织应该如何交付价值，我们对外的目标是什么，需要什么样的能力。而后才是需要是是什么样的敏捷方法，来帮助我们建设这一能力，和实现目标。

组织存在一定是对外交付价值，灵活的交付价值，这一点是没有异议的。从这个基础出发，我们就有机会构建好基本的共识和选择正确的方法。这也是为什么我在书中，强调最多的两个字是“价值”，而后再强调“价值的流动”。我强调的还不够的是“有用的价值”，这是我后面要做的。

@小楼听雨(段智锋-品腾贸易-产品总监)：我想问一下，PMP项目管理和敏捷管理有啥区别？敏捷方法迭代速度快，在有限的时间和资源下，如何快速实现功能开发交付？用PMP方法管理团队和利用敏捷管理项目团队，各有啥优缺点？

答：我个人做项目经理很多年，PMP有它的价值，从PMP知识体系中我获益不少。但PMP的知识体系是不敏捷的，即使今天有ACP也改变不了这个事实。因为 “项目”这两个字就决定了它的属性，项目创造了批量、创造的节点。批量本身就和敏捷交付是背道而驰的。敏捷交付需要更多的是产品思维，实现产品的持续交付、持续反馈、持续运营和持续调整。

在敏捷交付中，我们需要弱化项目思维，而增加产品和价值思维。弱化批量化的阶段实践，而建设持续交付和反馈的能力。

另外，在需要大量同步、协调和决策评审的实施类项目中，PMP知识体系及实践框架会继续存在且发挥作用。

@大宇(大宇，联想中国，PCSD高级架构师)：请问，非互联网团队如何转型敏捷开发，团队成员应该如何培养敏捷开发的能力，另外，如何让产品->开发->QA->运维能合理配合从而实现整体敏捷？另外产品如何拆分story，这是我们最头疼的问题，有没有什么最佳工程实践。

答：这个问题非常大。我觉得从理清价值流，可视化价值流开始吧。关于故事拆分，我前面讲过，还是要有好的需求实践吧，比如故事地图和实例化需求。

@大宇(吉巧云-日本IBM-IT specialist)：敏捷开始的结束时间是固定的、而开发对象可以允许变更和追加的、如何在遵守时间的前提下对待式样变更。有没有什么实践经验上的注意点可以分享。

答：固定时间盒不是敏捷的必然实践，它只是Scrum的实践，在Scrum框架中有它的道理。要注意的点是，

1. 拆分需求，但不要为了拆分而拆分，比如通过实例化需求把需求拆分成端到端的小需求。这样才有安排和变更的灵活性。

2. 不要把Sprint做成小瀑布了，一旦做成小瀑布，所有的需求同时开始了，变更起来就不太可能了。而且最后往往会守不住时间，或因为时间而牺牲质量。

@Howe(赵豪-爱客仕-项目)：如何让团队自，主并且及时在看板上更新状态

答：通常，这个首先是看板设计的问题，看板设计合理，运作没大毛病，更新状态不应该是问题。

@宏利(张宏利+竞技世界+项目经理)：我想问的是，如何能调动研发人员的敏捷积极性，每天晨会项目经理对于未完成的内容如何更好的处理

答：关于积极性，我在书中第22章有详细的讨论。

@ 陈娇智⁶⁶⁶⁶(陈娇智＋金蝶＋部门经理)：项目进度推进一拖再拖，每个阶段都有无数不同问题，如果确保项目质量和进度并存问题？

关于质量：以需求为粒度控制质量，实现单个需求的持续流动，而不是以迭代或项目为粒度控制时间点。我在第21章有详细的讨论。进度问题其实也是相关的，实现需求的持续流动，而弱化项目的阶段，在需求上内建质量，就不存在每个阶段无数问题这一说了。这一点招商银行的项目管理是典范，做得非常好。

@琪琪(战文琪-广联达-研发经理)：大项目做敏捷、持续集成，过程中专项或集成的工作并行太多，导致团队同时在运转的事项比较多，状态切换或专项转换混轮，怎么处理解决这种状态的混乱，或者怎么提高大项目管理中多项事情并行的效率

答：操作上两个方面。第一：合理规划，理清输入。这是源头。第二：在第一点的基础上，限制在制品。我不了解你的上下文，但可能还有两个更基础的问题：第一：组织结构的合理性，是否与交付的需要适配；第二：技术实践的到位程度，比如有很多手工集成的工作，可能意味着需要划分的合理性，或持续集成实践的到位程度。

@Apricotone(林天金+翼支付+项目经理)：作为精益敏捷项目经理，在新立项目/项目中期两个不同阶段进入项目，如何去推动在项目中实施精益敏捷。

答：立项阶段，关键是理清需求，和需求规划，这是一个很好的切入点，虽然不是唯一的。参见书的第20章。

项目中期，就不好回答了，要看具体情况。还是一解决和理清问题和交付为主。

@张丽华：互联网医疗项目，包含软件和硬件，按照传统的项目管控，对需求和进度的管控太死板，使用敏捷又避免不了需求变化带来的返工或开发功能弃用。如何更好管控项目进度和需求？如何提高团队效率？

答：需要太多的上下文，无法给出肯定的回答。一个可能的建议，尝试家里故事地图，来理清需求的关联和规划，包括硬件的计划。再用看板来管理需求的流动。这只是可能尝试的方向，具体问题需要具体对待。

@黄成东(黄成东、PM、麦子金服)：敏捷管理除了形式之外，在项目整个生命周期中，要注意哪些细节，如何实施？

答：敏捷的最终目标是弱化项目生命周期，实现持续产品交付。

@满江红(江晓红-随行付-开发经理): 梳理用户故事地图，如果即想按角色分类，又想按迭代划分，如何呈现到地图上，有没有好的实例

答：看来你已经实践的比较深入了。这两个本来就有一些冲突。我个人的观点，按角色分是为了挖掘和过滤需求，到规划的时候，就不要强求按角色来规划迭代了。规划的时候应该按业务目标（优先）和场景来规划，如果正好能匹配角色，那是件好事，匹配不上不要强求。

@Robin Lu（陆萍十中兴通讯十过程改进专家）在敏捷产品开发中如何发挥系统架构师的作用?有哪些推荐书?

答：我不是架构专家。只能从敏捷实施的角度来谈一谈。架构有很多类型，比如应用架构，系统架构和软件架构。我讲的偏向系统和软件架构。

首先架构是什么，这个就有就有很多说法，比如比较常见的定义是：软件系统的高层结构，以及决定这一结构的相关原则。我个人比较喜欢采纳的定义是：架构是软件设计中重要的决策，“重要”是根据后悔成本来衡量的。

根据这一定义，之所以顶层结构属于架构，是因为它一旦定下来，后面再发现问题要变更成本就会比较难（成本较高）。按照这一定义，同样选取何种编程语言，对大部分系统就是架构的一部分了，属于架构决策。

在敏捷开发中，架构的一个重要目的是降低后面变更的成本，支持产品的演进。在敏捷开发对架构提出了更高的要求，架构要更灵活，更具演进能力，降低决策的后悔成本，支持演进式的设计和交付。DDD和微服务都在解决这样的问题，“演进式设计”作为一个主题，也是在讨论这个问题。这对架构师的能力或团队的整体架构能力要求肯定是提高了。

总体而言，架构中所谓顶层结构的部分在减少，架构持续演进的要求在增加。DDD应该成为系统架构师的基本能力，而在结合今天的云和运维的生态，微服务方面的知识（包括运维、部署）也变得必不可少。

书籍我就不做具体的推荐了，毕竟我不是专家。DDD和微服务架构的能力肯定是要建立的，也有很多经典的书籍。