ACP敏捷1.单团队单迭代.产品管理视角

PMI-ACP_-- 敏捷项目管理国际资格认证(Agile Certified Practitioner), 聚焦项目管理思路，没有方法偏见(包含Scrum/看板/精益/XP等多种敏捷方法)充分践行集理念、方法与实践为一体的团队级敏捷实践认证。

PMI (美国项目管理协会)距今成立50年，项目管理进入中国20年;为了更高效的实施项目成功的交付，于2011年开始在全球推广ACP。为计算机IT、制造、教育、医疗保健等各行各业，项目成果交付提供一系列方法和工具。

Agile Alliance (敏捷联盟)、SAI (美国规模化敏捷学院)体系认可。

自2015年ACP引入中国以来，ACP在中国的持证人士截止2019年已经突破1.5W人，发展速度远远大于PMP进入中国的发展速度。“敏捷+传统”融合将成为企业管理发展的必然结果。

PMP更多的是项目管理框架；ACP是侧重敏捷开发管理，侧重方法论。它能帮助我们：

将一个大的完整项目拆成一系列小的项目，通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。在需求不明确时，脱颖而出，降低项目风险，减少项目成本。

满足客户求新、求变、求快的要求，以最小可行性产品交付，不断的得到客户的反馈，不停的迭代，改进，或者重构产品。

交付客户价值，而不是执行计划；还能调动人的积极性、主动性和创造性，并培养人在工作中的自豪感。

PMI-ACP认证验证了从业人士理解、应用敏捷原则在项目上实践的能力。PMI-ACP认证与别的认证不同在于：它要求敏捷培训、敏捷项目工作经验以及包含敏捷实践、工具、技巧考试的结合。PMI-ACP认证也是知识方法内容全面、实践性强、含金量高、认可度广的证书。它同样也结合了其他敏捷方法，包括Scrum（敏捷开发）、XP（极限编程）和LeanDevelopment（精益敏捷）等。通过获取PMI-ACP认证，从业人士能够：

向企业展示他们在敏捷原则、实践、工具和技巧上的专业水准；

增强他们在专业项目管理工具与技巧方面的多样化能力；

敏捷思想的诞生和应用正不断的遍布整个互联网市场，也是人力资源引进人才的一个通行证；

学习过程中对思维和能力的开发过程，为职业规划打开了另一扇大门；

提升管理能力的同时，通过ACP认证，获得更多的职场晋升机会和空间。

ACP vs SAFe 什么区别，应该先学哪个？

从发证机构讲，一个是美国规模化敏捷学员SAI推出的相关体系化认证，SFAe是目前全球范围内使用占比最多的一种规模化敏捷方法；ACP是美国项目管理协会PMI推出的敏捷实践专业人士的资格认证

从内容上讲，SAFe是规模化敏捷，整个的实施框架不超过150人搭团队协同、发布等，而ACP是站位在团队级敏捷多种敏捷方法的角度上，来实施敏捷的价值观文化和实践落地。建议肯定先学习ACP，再进行SAFe-SA规模化敏捷领导力的学习。

ACP vs CSM

ACP和CSM是两个不一样组织发起的认证，相对CSM进入中国的时间会更早一些。但它核心聚焦在scrum的应用上，而ACP更多是站在敏捷多种方法的原则理念和使用的角度，会涉及到更多的多种方法，而scrum是其中之一。

所以说从敏捷方法的起源原则、理念和多种方法的学习理解上，更建议大家去学习ACP。当然具体还要看企业的实际情况，目前CSM在中国有将近不到5000人，而ACP有1.5万人，从体量上和学习内容的覆盖度上，肯定还是首选ACP的。

Lean Thinking精益思想 vs 敏捷

精益的本义是精瘦而健壮，核心思想是交付小而有价值的产品。

2001年，在《敏捷宣言》提出之后三个月，精益思想实践者玛丽.帕彭迪克(Mary Poppendieck)发表了
-篇关于精益编程的文章，指出“精益不是-种方法，而是思考如何管理工作的-种方式”，提炼出七个精益
原则，应用于软件开发。

七个精益原则

消除浪费:识别浪费、价值流图
增强学习:反馈、迭代、同步、基于集合开发
延迟决策:可选项、最后责任时刻、制定决策
快速交付:拉动系统、排队理论、延迟成本
授权团队:自我决策、动机、领导力、专业技能
内建质量:感知、概念、重构、测试
整体优化:度量、合同

引入精益思想的工具：精益思想屋

精益的思想通过交付产品来实现价值流动

基础是领导力，及组织要从管理控制的方式转换为授权和赋能的方式，注重领导力而不是管控力；Kaizen：小而不断地改善。

坚持目标：交付价值，实现价值的流动。

1. Agile Alliance (敏捷联盟)敏捷实践编年史

敏捷实践编年史记录了上世纪六十年代至今敏捷相关实践的发展史，其英文原版材料来自于敏捷联盟网站(AgileAlliance.org)

二十世纪七十年代:

Barry Boehm提出了“Wideband Delphi”估算技术，这是“计划扑克”估算法的先驱。

1976年: D. Panzl的系列文章描述了具有似于JUnit特性的工具，证明自动化单元测试有着悠久的历史。

1976年: Glenford Myers的著作《软件可靠性（Software Reliability）》出版，其中阐述了一条“公理”——“不应该由开发者来测试自己的代码”。

1977年: 出现了用于UNIX系统的“make”工具——自动化软件构建的原则从来就不是一个新主意。

1980年:在IBM联邦系统部中进行了关于增量开发的实质性讨论。在Dyer的文章中明确指出“软件工程的原则是，每个迭代完成的功能要尽可能地与其他迭代解耦。”

1980年:源于丰田生产系统的“可视化控制（visual control）”概念，是对“信息辐射器（information radiators）”的预期。

1983年:在CHI（人机交互）大会记录中描述了，在“施乐之星”的设计期间，施乐帕克研究中心大范围使用“人类因素测试（human factors testing）”技术，这为可用性（usability）测试埋下了伏笔。

1984年:Barry Boehm在项目中使用原型，以便在项目早期实验学习，这本质上是一种迭代策略。这表面此时迭代方法已首次开始得到认真关注，极可能是由于诸如个人电脑和图形用户界面的兴起因素导致的。

1984年:在Brodie的著作《Thinking Forth》中提出了“构造（factoring）”的概念，书中将其表述为“把代码组织成有用的片段”且这件事情“发生于详细设计和实现期间”，这是对重构的预期。

1984年:对“瀑布”顺序式方法的批判早已开始，而对作为替代物的“增量方法”的构想也正变得越来越突出。一个很好的例子是，早期在《软件工程中基于知识的沟通过程》上一篇文章倡导使用增量开发，具体原因是“不存在完整和稳定的需求规格”。

1985年:或许首个有明确命名的、用于替代“瀑布”的增量开发方法是Tom Gilb的进化交付模型（Evolutionary Delivery Model），绰号是“进化（Evo）”。

1986年:Barry Boehm提出了“软件开发和优化的螺旋模型”，一种通过合适的方法（尽管展示的“典型”例子是基于原型，但不仅限于原型法）来识别和减少风险的迭代模型。

1986年:竹内和野中在哈佛商业评论发表了他们的文章《新新产品开发游戏（The New New Product Development Game）》。这篇文章描述了一种橄榄球方法，方法中“产品开发过程是在一个精心挑选的多学科团队的持续互动中产生的，团队成员从头到尾都在一起工作”，这篇文章经常被引用为Scrum框架的灵感来源。

1988年-1990年:

事件驱动的图形用户界面软件的兴起，及其功能测试面临的挑战，为Segue 和Mercury等公司开发的“捕获和回放”类自动化测试工具提供了机会。这类工具在之后十年一致在市场占据主导地位。

1988年:“时间盒（timebox）”被描述为Scott Schultz的“快速迭代开发成型”法的基石，这种方法应用于杜邦公司的副业——信息工程协会。

1988年:尽管通过把对象拟人化来推理设计问题的思想似乎是很自然的，但仍存在着一些强大的反对者，比如Dijsktra的这篇文章《在实际计算机科学教学中的残酷性（On the cruelty of really teaching computing science）》，看起来就好像面向对象正在打击主流思想一样:“在计算机科学中，拟人化的隐喻都应该被禁止”。

1989年:Ward Cunningham与Kent Beck合作的文章中描述了CRC技术。卡片上采用这种特定格式，源于Cunningham设计的应用（其用途是为了把设计文档存储为超文本卡片堆）。

1990年:在一篇ACM SIGPLAN的文章中，Bill Opdyke与Ralph Johnson创造了“重构（refactoring）”这个术语——“重构:一种在设计应用框架和进化面向对象系统中使用的辅助手段”。

1990年:黑盒（black box）测试技术仍然在测试学科中占据主导地位，尤其是以“捕获和回放”测试工具的形式进行的测试技术。

二十世纪九十年代:

由于快速应用开发（RAD）工具和集成开发环境（IDE）的崛起，“make”类的构建工具毁誉参半。

1991年:James Martin在其著作《快速应用开发》中描述的RAD（快速应用开发）方法，或许是第一种把时间盒和迭代（较宽松意义上的“整个软件开发过程的一次重复”）紧密结合在一起的方法。这本书在某个章节中描述了时间盒的细节。

1991年:Taligent公司独立开发了一个测试框架，这个测试框架与SUnit有着惊人的相似。

1992年:在一次拜访Whitesmiths公司时，Larry Constantine创造和报道了“活力二人组（Dynamic Duo）”这个术语:“每一台终端前有两位程序员！当然，实际上只能由一位程序员来操作键盘编辑代码，但他们两个是并肩作战的。”Whitesmiths公司是由P.J. Plauger创建的编译器供应商，C语言的实现者之一，存在于1978年到1988年。

1992年:在Opdyke的文章《重构面向对象架构（Refactoring object-oriented frameworks）》中，对“重构（refactoring）”这一术语进行了全面的描述。

1993年:Wilson等人的文章《合作对实习生程序员的好处（The benefits of collaboration for student programmers）》，是一个“表明结对工作对编程任务特别有好处”的早期实证研究。在结对编程通过极限编程得到普及之后，出于“验证”的目的，后续又进行了更加充分的研究。

1993年:Jim Coplien 编写了最初的站立会议模式。

1993年:“持续集成（continuous integration）”这个短语已经在使用了，并在敏捷过程这种称呼之前就出现了这种说法。例如这一年有一篇文章把它与“计划（scheduled）”集成进行了对比，并建议采用后者，理由是持续集成存在“缺乏全面测试”的问题。这也帮助解释了为什么自动化测试会如此受敏捷团队的青睐，因为它是持续集成的使能器。

1993年:Jeff Sutherland发明了Scrum，并作为过程在Easel公司使用。

1994年:Jim Coplien描述了其对“超级多产的”Borland公司Quattro Pro团队的观察结果，注意到他们几乎完全依赖于每日会议（daily meeting）“这个项目召开会议远远多过做其他任何事情”，这篇文章也同样被引用为对Scrum有巨大的影响。

1994年:Kent Beck编写了用于Smalltalk编程语言的SUnit测试框架。

1995年:Alistair Cockburn发表了文章《应用开发中人类因素的增长(Growth of human factors in application development》，提出了为什么迭代方法会逐渐被接受的主要原因之一是:软件开发的瓶颈正在转向（个人和组织）学习，并且人类学习本质上是一个迭代和试错的过程。

1995年:基于与CRC卡同样的灵感，Ward Cunningham创造了wiki这个概念，成为后来的维基百科的原型，这无疑是万维网发展历史上最具影响力的理念之一。

1995年:在最早的Scrum著作中介绍了作为迭代（iteration）的“冲刺（sprint）”概念，然而其持续时间是可变的。

1995年:在首本描写模式的著作——《程序设计模式语言（Pattern Languages of Program Design）》的“一种有生产力的开发过程模式语言（A Generative Development-Process Pattern Language）”章节中，Jim Coplien以Alexandrian模式风格的形式，给出了“结对开发（Developing in Pairs）”模式的简短描述。

1995年:在OOPSLA大会上，Ken Schwaber和Jeff Sutherland联合发布了Scrum。

1996年:Steve McConnell描述了九十年代微软公司在Windows NT 3.0上使用的“每日构建和冒烟测试（Daily Build and Smoke Test）”技术。其重点不在于自动化而在于应用频率，即在时间上被认为是非常“极端”的日循环。

1996年:自动化测试是极限编程的一个实践，但并不强调对单元测试和验收测试的区分，也没有要特别推荐的概念或工具。

1997年:Ken Schwaber描述了“每日Scrum站会（daily scrum）”（这在其早期的著作中并未出现，例如1995年的文章《Scrum开发过程（SCRUM Development Process）》），这个活动后来被Mike Beedle重新整理成了模式形式。

1997年:在Alistair Cockburn的著作《幸存的面向对象项目（Surviving Object-Oriented Projects）》中，描述了非正式地使用敏捷实践的几个项目（最早可以追溯到1993年），但并未给出敏捷的标签，而只是概括为“增量工作，逐个聚焦”。

1997年:Kent Beck和Erich Gamma编写了Junit测试工具，其灵感来自于Beck早期在SUnit上的工作。在接下来的几年中，它越来越受欢迎，并标志着“捕获和回放”时代的结束。

1998年-2002年:“测试先行（Test First）”被阐述为“测试驱动（Test Driven）”，特别是在“Wiki”上。

1998年:持续集成和“每日站立会议（daily stand-up）”被列入极限编程的核心实践。

1998年:Linda Rising在著作《模式手册：技术、策略和应用（the patterns handbook: techniques, strategies, and applications）》中转载了Keonig对反模式（antipattern）的定义。

1998年:《反模式——危机中软件、架构和项目的重构（AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis）》这一著作普及了“反模式antipattern）”这个术语年。

1998年:

在最早描述极限编程的文章《走向极限编程的克莱斯勒公司（Chrysler goes to Extremes）》中描述了几个极限编程实践，例如：自选任务（self-chosen tasks）、测试先行（test first）、三周迭代（three week iterations）、集体代码所有权（collective code ownership）和结对编程（pair programming）。

1999年:在一篇写给《C++报道（C++ Report）》的文章中，Robert C. Martin对“迭代（iterative）”和“增量（incremental）”术语，给出了最早的、敏捷观念的描述。

1999年:在Alan Cooper的著作《交互设计之路（The Inmates are Running the Asylum）》的某个章节中，首次描述了“用户画像（Personas）”实践，基于之前的工作以“目标导向的设计（Goal-Directed design）”来构建。

1999年:Kent Beck在一篇IEEE计算机文章《使用极限编程来拥抱变化（Embracing Change with Extreme Programming）》中首次描述了“简单设计规则（rules of simple design）”，对之前在OTUG邮件列表列表上的讨论做了总结。

1999年:“重构（refactoring）”实践，在几年前就已经被纳入极限编程，并由于Martin Fowler的同名著作而被普及。

1999年:Kent Beck在其著作《解析极限编程（Extreme Programming Explained）》中创造了“大可视化图表（Big Visible Chart）”这个术语，尽管后来他把此归结于Martin Fowler。

1999年:Ron Jeffries首次提到使用“橡皮糖熊（Gummi Bears）”代替“故事点（story points）”作为用户故事的估算单位。（后来此事被归结于一个由Joseph Pelrine领导的XP项目）

2000年,Scrum的每日站立会议形式中的“三个问题（three questions）”为极限编程团队广泛采用。

2000年(或更早):“驾驶员（Driver）”和“领航员（Navigator）”的角色被引入以帮助解释结对编程，已知的最早来源是一个邮件列表记录。然而值得注意的是，这些角色的现实性一直都存有争议，比如Sallyann Bryant的文章《结对编程与神秘的领航员角色》。

2000年:Martin Fowler的一篇文章中提供了或许可以说是对当时可用的持续集成（continuous integration）实践的最完整描述。

2000年:Freeman、McKinnon和Craig在他们的文章《内部测试：用模拟对象进行单元测试（Endo-Testing: Unit Testing with Mock Objects）》中描述了“模拟对象（mock objects）”测试技术，暗指路易斯·卡罗尔的“假海龟”这一角色。

2000年:Ken Schwaber首次描述了“燃尽图（burndown chart）”。在富达投资集团工作时，发明它，并在其网站上做了正式描述。

2000年:术语“团队速率（velocity）”添加到极限编程相对较晚，用于替代先前的、被认为过于复杂的概念——“负载系数（load factor）”。

21世纪初:

尽管这种实践远不是新起的，也不仅仅局限于敏捷团队；但部分归功于敏捷实践的兴起，使得“make”类自动构建得以复兴。

2001年2月11-13日:

在美国犹他州瓦萨奇山的雪鸟滑雪度假村，17位从事软件开发或者帮助他人从事软件开发的人相聚一堂，以在他们各自不同的软件开发方法中寻找共识。此次会议的产物就是敏捷软件开发宣言（Manifesto for Agile Software Development）。后来几位会议成员继续合作，成立了敏捷联盟（Agile Alliance）。

2001年:Brian Marick，一位“上下文驱动（context-driven）”软件测试学派的公开成员，参与了导致敏捷宣言发布的雪鸟事件。他经常把自己描述为团队的“预兆测试者”，并把一些探索性测试中的实践意识引入到敏捷社区中。

2001年:定期回顾是敏捷宣言的“团队要定期反省如何能够做到更有效，并相应地调整团队的行为（At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly）”原则的实践之一，虽然还不是必然例行的实践。

2001年:Mary Poppendieck的文章《精益编程（Lean Programming）》，引发了对敏捷与精益思想（以精益或“丰田生产系统”而闻名）间结构相似性的关注。

2001年:Cruise Control，是第一款“持续集成服务器（continuous integration server）”，在开源许可协议下发布。它能自动监测源代码仓库，触发构建和测试过程，并把执行结果和测试报告档案发送给开发人员。从2001-2007年可以看到大量类似工具的出现，导致可能过度关注工具超过了关注实践本身。

2001年:在Norm Kerth的著作《项目回顾（Project Retrospectives）》中描述的可视化手段中，“活力震荡仪（Energy Seismograph）”或许可以视为是“妮可-妮可日历（niko-niko calendar）”的先驱。

2001年:Bill Wake的一篇文章指出了敏捷团队所使用的两种不同喜好的估算——相对估算和绝对估算（relative and absolute estimation）。

2001年:“重构（Refactoring）”终于“破茧化蝶”， Martin Fowler发表言论，描述了Java语言集成开发环境中自动化重构辅助工具的广泛可用性。

2001年:在Kaner、Bach和Pettichord的著作《软件测试经验与教训（Lessons Learned in Software Testing）》中介绍了一些探索测试技术的技巧，并首次提到“上下文驱动的软件测试学派（context driven school of software testing）”。

注：三位作者的全名分别是：Cem Kaner、James Bash和Bret Pettichord。

2001年:在《极限编程实施（Extreme Programming Installed）》中描述了“快速设计会话（quick design session）”实践。

2001年:在英国Connextra公司，发明了用户故事的“role-feature-reason”描述形式。

2001年:Jeff Sutherland在其文章《规模化敏捷：在五家公司发明和重新发明了Scrum（Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies）》中，首次给出了“Scrum of Scrums”的描述（总结IDX公司的经验）。

2001年:极限编程社区早期是赞同“回顾（retrospective）”实践的，比如“XP 2001”大会上的这篇文章《适应极限编程风格（Adaptation: XP Style）》。

2001年:为了区分“交互的（social）”用户故事与“文档的（documentary）”传统需求实践（诸如用例（use case）），Ron Jeffries提出了用户故事的3C（Card,Conversation,Confirmation）模型。

2001年:《免疫可预见的项目失败（Immunizing Against Predictable Project Failure）》一文被发表，本文后来很大程度上使得定义项目章程成为一项敏捷实践活动。

2001年:在Alistair Cockburn的著作《敏捷软件开发（Agile Software Development）》，出现了对敏捷项目环境中“反思研讨会（reflection workshop）”的首次描述。

2001年:术语“项目回顾（Project Retrospectives）”在 Norm Kerth的同名书籍中进行了介绍。

2002年:Laurie Williams和Robert Kessler撰写了《结对编程详解（Pair Programming Illuminated）》是专门研究结对编程实践的第一本书，讨论了迄今为止的理论，实践和各种研究

2002年:极限编程的发明者之一沃德·坎宁安（Ward Cunningham）发表了Fit，这是一种基于Excel表格式的验收测试工具

2002年:一个早期的实践者描述了在更广泛的环境下的运用用户画像（personas）：Jeff Patton的论文《击中目标：将交互设计添加到敏捷软件开发中（Hitting the Target: Adding Interaction Design to Agile Software Development）》也许是在敏捷环境下的第一个正式描述，虽然这个话题至少从2000年开始就在一些邮件组被非正式的讨论过。

2002年:在将精益理念应用于软件的早期（未发表）讨论中，将未发布的特性视为“库存（inventory）”，Kent Beck提到在LifeWare和几个其他的企业运用持续部署。然而，这个想法还是要花几年的时间去梳理和整理。

2002年:Scrum社区汲取了度量“团队速度（velocity）”的实践。

2002年:燃尽图在Scrum社区中获得了普及，以及诸如仅仅反转垂直方向的“燃起图”，或者更复杂的“累积流图（Cumulative Flow Diagram）”，这与燃起非常类似，但似乎是一个独立的发明。

2002年:计划扑克的当前形式在James Grenning的一篇文章中被列出。

2002年:Rebecca Wirfs-Brock和Alan McKean通过他们关于责任驱动设计（Responsibility-driven design）的书：《对象设计：角色，责任和合作者（Object Design: Roles, Responsibilities and Collaborators）》来推广CRC卡。

2003年:Industrial Logic的Joshua Kerievsky发表了《Industrial XP》，这是一套建议的极限编程的扩展，其中包括项目宪章活动，基本上和他们2001年文章中定义的一样。

2003年:BDD的祖先AgileDox是一个自动从JUnit测试生成技术文档的工具，它的作者是Chris Stevenson。

2003年:Bob Martin将Fit与Wiki（Cunningham的另一个发明）结合在一起，创建了FitNesse。

2003年:Kent Beck 在《测试驱动开发（Test Driven Development：By Example）》一书中简要提到ATDD，但认为这是不切实际的。尽管Kent Beck持反对意见，部分归因于Fit / FitNesse的普及，ATDD成为公认的做法。

Acceptance Test Driven Development ”，中文称“验收测试驱动开发”。ATDD是一种开发方法论，通常由客户代表、市场人员，开发、测试等一起进行对需求进行交流，沟通，分解，例举和确认，以便所有角色对需求的理解都是一致的。

1）首先是一个讨论过程，目的就是将用户需求理解清楚，理解一致，避免后期因理解不一致而做出不满足要求的产品。

2） Distill其实是一个提取的过程，也就是将需求分解成开发人员和测试人员都能理解，切认可的最小单元。这里为了需求的理解一直，引入了一套满足Gherkins语法的需求描述语言，通过这种满足Gherkins语法的GWT语句需求描述语言，可以让需求理解上更加一致。

3）开发和后面的Demo其实就不用说太多了。开发根据GWT需求描述语言进行开发设计，测试根据GWT需求描述语言来写验收测试用例。验证的时候直接执行GWT需求，即：需求可执行。从而验证需求是否被实现。

TDD(Test-Driven Development),是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD 只是开发人员的职责，通过单元测试用例来驱动功能代码的实现。在准备实施一个功能或特xìng之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。

2003年至2006年:Fit / FitNesse组合让其它工具黯然失色，成为敏捷验收测试的主流模式。

2003年:C2 Wiki上的一篇匿名文章描述了乒乓编程（Ping-Pong Programming），这是结合结对编程和测试驱动开发的一个适度流行的变体。

2003年:早期的Scrum 培训资料暗示了未来“完成的定义（Definition of Done）”的重要性，最初只是以幻灯片的形式：“关于完成的故事（The story of Done）”。

2003年:Mary和Tom Poppendieck的著作《精益软件开发（Lean Software Development）》将“敏捷任务板（Agile task board）”描述为“软件看板系统（software kanban system）”。

2003年:Kent Beck 出版《测试驱动开发（Test Driven Development：By Example）》。

2003年:得益于XP Day大会的定期聚会，更多的团队开始实行项目和迭代的回顾。

2003年:用于快速评估用户故事的INVEST检查单来自Bill Wake的一篇文章，该文章还为用户故事分解得到的技术任务改写了SMART缩写（Specific具体的，Measurable可衡量的，Achievable可实现的，Relevant相关的，Time-boxed时间盒的）。

2003年:Mike Cohn在其网站上描述了五列任务板格式；

2003年:Joshua Kerievsky创造了术语“NUTs（Nebulous Units of Time，模糊的时间单位）”，作为“故事点”的替代品。

2003年:Eric Evans提出了术语“领域驱动设计domain driven design”，并在同名著作中进行了描述，最终成为“系统隐喻（System Metaphor）”的可行替代品。

2004年至2006年:每日会议被作为敏捷核心实践推广，随着任务板广泛使用，“在任务板前面召开每日会议” 成为最终的关键指导原则。

2004年:Kent Beck提出“完整团队（Whole Team）”作为之前名为“现场客户”的实践的新名称。

2004年:Alberto Savoia 的文章提出了“极限反馈设备（Extreme Feedback Devices）”，例如熔岩灯或专用监视器，以显示最近一次集成的结果，这是持续集成的一个重大创新。

2004年:为了验证他关于弱化“测试”术语而代之以“行为”的假设，Dan North发布了JBehave。

2004年:INVEST首字母缩略语是Mike Cohn的著作《用户故事与敏捷方法（User Stories applied）》中推荐的技术之一，在第二章详细讨论了这个技巧。

2005年:计划扑克技术在Scrum社区中开始流行，这是Mike Cohn的著作《敏捷估计与规划（Agile Estimating and Planning）》中做计划的多个技术中的其中一个。

2005年:术语“Backlog梳理（backlog grooming）”最早记录的使用源自Mike Cohn在“Scrum开发邮件列表上”的观点；几年之后，这个实践才被更正式地描述。

2005年:Jeff Patton在文章《It’s All in How You Slice It》明确表达了故事地图（story mapping）的概念，但并没有给出这个名字。

2006年至2009年:几个新的工具发布，证实了社区在BDD上的投入

BDD(Behavior-Driven Development）,行为驱动开发的根基是一种“通用语言”。这种通用语言同时被客户和开发者用来定义系统的行为。使用通用语言，客户和开发者可以一起定义出系统的行为，从而做出符合客户需求的设计。但如果光有设计，而没有验证的手段，就无法检验我们的实现是不是符合设计。所以 BDD还是要和测试结合在一起，用系统行为的定义来验证实现代码。虽然行为驱动开发是测试驱动开发的进化，但关注的核心是设计。行为驱动开发中，定义系统的行为是主要工作，而对系统行为的描述则变成了测试标准。在行为驱动开发中，我们需要使用通用语言来定义系统行为.

2006年:Jean Tabaka在她的著作《协作精解（Collaboration Explained）》一书将项目章程作为有效协作的关键实践之一; 虽然她明确地引用了《IndustrialXP》，但她的陈述与2001年的文章有所不同，表现出受到了其它来源的综合影响。

2006年:North与Chris Matts合作提出了“Given-When-Then 画布”的概念，将BDD的范围扩展到业务分析，并将这个方法写入了《Introducing BDD》。

2006年:Akinori Sakata在其文章中首次描述了妮可-妮可日历（Niko-niko calendars）。

2006年:描述持续部署核心的首篇会议文章《部署生产线（Deployment Production Line）》，由Jez Humble、Chris Read和Dan North发表在Agile2006的会议记录中，是对几个Thoughtworks英国团队实践的整理成果。

2006年:Esther Derby和Diana Larsen的《敏捷回顾（Agile Retrospectives）》的出版完结了对敏捷回顾的编纂。

2007年:在那个时候，“完成的定义（Definition of Done）”已经是一个完全成熟的实践，它作为一个文本化的清单展示在团队办公室已经变得非常普遍。

2007年:“Kanbandev”邮件列表的成立，为受看板启发的（Kanban-inspired）敏捷规划实践的提供了一个讨论场所。

2007年:来自看板团队的最早几份实践报告被发布，这些团队使用了一套特别的称为“看板（kanban）”的修订方案（没有迭代，没有估算，持续地带着WIP限制的任务板），其中包括来自Corbis（David Anderson）和BueTech（Arlo Belshee）的报告。

2007年:简化的三列任务板格式（“Todo”，“Doing”，“Done”）在当时变得比原始的五列版本更流行和更标准。

2008年:Alan Cooper在敏捷2008上的主题演讲，标志着敏捷论述和交互设计之间的正式和解，很长一段时间这两者之间被认为是存在矛盾的。Cooper是被敏捷领袖作为“外部人士”邀请来的，他在第二年已经被认为是“很内部的人士”。

2008年:Cem Kaner给出了“探索性测试（Exploratory Testing）”的一个新定义，反映了这种测试方法的不断完善。

2008年:Kane Mar以“故事时间(Story Time）”作为名称，首先正式描述了“Backlog梳理（backlog grooming）”，并建议把它作为一个例行会议。

2008年:Agile 2008大会专门设置了一个论坛来讨论“用户体验（User Experience）”的相关实践，比如可用性测试（usability testing）、用户画像（personas），以及纸上原型（paper prototyping）。

2008年:

Jeff Patton的文章《新的用户故事Backlog是一张地图（The new user story backlog is a map）》图文并茂地详尽描述了“故事地图（story mapping）”实践。

2008年:虽然最初提到团队开始使用“就绪的定义（Definition of Ready）”的时间是在年初，但第一次正式的说明似乎是从十月开始的，并且很快就被纳入了“官方”的Scrum培训材料。

2009年:“持续部署（continuous deployment）”实践已经确立，尽管仍有些争议，因为Timothy Fitz的文章《IMVU的持续部署（Continuous Deployment at IMVU）》仍然饱受评论。这篇文章不仅在敏捷领域变得非常重要，而且也是近期备受关注的精益创业或DevOps的核心要素。

2009年:两个致力于探讨看板方法的实体机构成立，一个是旨在解决商业问题的“精益系统协会（Lean Systems Society）”，另一个则是没有那么正式而旨在提升社区的知名度的“有限WIP协会（The Limited WIP Society）”。

2010年:Freeman 和 Pryce的著作《测试驱动的面向对象软件开发（Growing Object-Oriented Software Guided by Tests）》提供了一个整合“模拟对象（Mock Objects）”、“测试驱动开发（TDD）”和面向对象设计的全面描述。

2011年:“Backlog梳理（backlog grooming）”实践升级为Scrum的官方元素，并纳入了《Scrum指南（the Scrum Guide）》。

2015年:James Coplien发表了文章《两人智慧胜过一人（Two Heads are Better Than One）》，它提供了结对编程的历史的概述，可以追溯到20世纪80年代中期（如果不是以前的话）。

2017年:Janet Gregory和Lisa Crispin建立了对“敏捷测试（Agile Testing）”的定义，标志着该主题的第一个简洁的定义。

2. SAI （Scaled agile,inc. 美国规模化敏捷学院)

Scaled Agile, Inc.是全球领先的业务敏捷性框架SAFe的提供商。通过学习和认证、全球合作伙伴网络以及一个由80多万名经过培训的专业人员组成的不断壮大的社区，Scaled Agile帮助企业将敏捷性构建到其文化当中，以便企业快速识别和实现客户价值、利用新出现的机会，并改进业务成果。Scaled Agile是企业慈善和社区服务运动“Pledge 1%”的捐款成员。了解更多信息，请访问scaledagile.com。

SAFe 5.0，提供增强企业敏捷性的核心能力, 突破版Scaled Agile框架超越IT，使整个企业在战略和执行上保持一致。新版SAFe在战略、执行和领导能力方面取得了巨大进步，而这些是机构较竞争对手更快提供创新商业解决方案所必需的。

Tasktop首席执行官、《Project to Product》一书的作者Mik Kersten博士表示：“大规模软件提供商将定义21世纪的经济格局。SAFe 5.0是一个非常有意义的版本，我相信它将是帮助无数企业机构成功从项目转向产品的关键。”

如欲查看SAFe 5.0网站，请访问：scaledagileframework.com；如欲查看SAFe 5.0常见问题，请访问：support.scaledagile.com。

SAFe是Scaled Agile Framework的简称，是用于在企业范围内定义和实施敏捷软件开发过程的最佳实践和经过验证的成功模式的集合。 SAFe的创建者是Dean Leffingwell，他也是Rational Unified Process（RUP）的幕后推手。

SAFe通过在四个不同层面组织知识和最佳实践来帮助管理企业级的敏捷软件产品开发过程：

投资组合水平
价值流水平
计划水平
团队水平

在Scaled Agile Framework的语言中，在指定组织的寻求实现敏捷框架的过程中，要考虑两种变因：

四级安全----包括以上四个级别中的所有级别，适用于具有数百名团队成员的大型解决方案。
三级安全----不包括价值流级别（因为它只假设一个价值流），它主要适用于规模较小的团队和100人以下的项目。

SAFe投资组合级别提供了围绕敏捷原则组织企业所使用的工具、角色和技术。这一级别包括治理、预算和价值流管理，以满足组织的战略目标。在投资组合级别，企业战略由包含业务Epic的投资组合Backlog工作表示。

SAFe价值流级别被设计用于具有多个复杂价值流的大型组织。这一级别允许独立处理组织中不同部分的战略目标，同时允许管理复杂的相互依赖和约束。在价值流级别，即将到来的优先工作由包含功能的价值流Backlog工作来表示。

SAFe计划层面是为支持更大的企业战略目标而提供价值。这是产品开发在各种敏捷发布列车（Agile Release Trains）概念之间协调的一个层次，即作为给定项目计划的一部分持续交付价值。在计划层面，即将开展的优先工作由包含优先级特征的项目Backlog工作表示。

SAFe的团队级别是进行敏捷开发的地方，团队使用ScrumxP、团队看板或其他敏捷方法，通过迭代（通常每2周）以固定的周期交付价值。与大多数敏捷实践一样，团队级别的优先工作是以包含优先级用户故事的团队Backlog工作的形式捕获的。

3. 敏捷开发五个基本活动/事件

---------》产品待办列表《-------

敏捷产品需求

敏捷开发的scrum的5个活动/事件：

产品待办列表Backlog梳理会议（ Product Backlog Refinement）+（sprint规划）

待开发项的梳理过程，在冲刺计划会议时要进行的工作。主要就是对纳入到这一次冲刺的用户故事进行细化，拆分任务，优先级排序以及测试要点的分析等。具体要进行以下事项：

PO 和团队一起讨论用户故事的背景、业务目标、用户角色、场景、业务流程、规则等，保证团队理解充分。

PO 和团队一起讨论界面和交互流程，输出线框图或者原型图。

PO 和团队讨论用户故事的测试要点、技术实现方案、可能存在的技术风险，必须输出测试要点，这个测试要点其实也就是我们常说的验收标准。PO 可以与一位资深测试人员讨论和整理出要点，也可以与整个团队交流用户故事中的测试要点，最后也可以由团队来讨论初步的实现方案、技术风险。不过要注意，应该先准备好测试要点，避免从0开始讨论，另外现在讨论的还只是初步的估算和技术风险的评估，详细的内容需要在冲刺开发时再讨论。

团队估算出用户故事的规模（故事点数），对于过大的用户故事要拆分成小的。初始的估算由 PO 和 SM 进行，再由 SM 与开发人员进行估算，并组织测试人员估算测试规模，最后集中整合。这个时候的估算不需要团队全体人员参与，应该是 SM 为主并由少数核心人员一起进行。

PO 对用户故事排列优先级。优先级只需要 PO 决定即可，其他人的意见应该在前期就提出，在这里 PO 是做最后的汇总决定。

Sprint是Scrum的核心，在这里创意(idea) 转化为价值。它们是固定时长的事件，为期一一个月或更短，以保持一致性。前一个Sprint结束后，下一 .个新的Sprint紧接着立即开始。实现Product Goal所需的所有工作，包括Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective，都发生在Sprint内。

Sprint计划会议（Sprint Planning Meeting）

每日站会（Daily Scrum Meeting）

Sprint评审会议（Sprint Review Meeting）

Sprint回顾会议（Sprint Retrospective Meeting）结束sprint

4. 产品愿景（Elivator Pitch)

产品的愿景，需要在整个团队里面进行拉通，让每一个人都了解到当下正在进行中的产品的发展方向和存在意义，让每个人都知道产品的价值点是什么。

建立产品愿景的技巧，有用户角色模型、狩野模型（卡诺模型）、产品路线图、设计思维（Design Thinking）等，我们今天了解敏捷规划的产品愿景模式。

检验标准：

1.目标用户的痛点没有得到解决(比如说:用户缺少便捷触及行业客户的渠道，你的产品却来解决商品送货不及时的问题)
2.独特价值在其他产品中同样具备(比如说:京东主打快速准时的送货，淘宝主打商品琳琅满目)
3.找不出目标用户的真正痛点，只是在转圈打游戏(比如说，用户缺少-个便捷的销售渠道，却被定义为用户没有特定的销售模式)
4.产品类型定位和产品的特点不够匹配(比如说,想做双边市场的平台,却定义为单边服务提供商)

5. 用户画像(Persona / Profile)

用户画像又称用户角色，作为一种勾画目标用户、联系用户诉求与设计方向的有效工具，用户画像在各领域得到了广泛的应用。作为实际用户的虚拟代表，用户画像所形成的用户角色并不是脱离产品和市场之外所构建出来的，形成的用户角色需要有代表性能代表产品的主要受众和目标群体。

「用户画像」，有两个英文词，第一个叫「PERSONA」，这是Allen Cooper提出来的一种通过调研和问卷获得的典型用户模型，用于产品需求挖掘与交互设计的方法。而另一个单词，叫「Profile」，是利用已经获得的数据，用来勾勒用户需求、用户偏好的数据分析方法。这两个词，都可以翻译为「用户画像」，但第一种，用于产品调研与交互设计，第二种，用于运营与数据分析。

一个产品或者一个系统大概需要4-8种类型的用户画像。

用户画像的要素：
●基本信息(姓名、年龄、等)
●喜欢和不喜欢
●痛点:	必须解决的问题，雪中送炭的功能点
●期待(目标)：	不是用户实际经历或者困扰的功能点，如果作出来了，用户会很满意甚至惊喜，未来用户可能会要求的。属于锦上添花的需求。

我们主要介绍「PERSONA」，用户画像模板考虑如下：

6. 用户故事（敏捷工作方式中需求的呈现单位）

“所谓用户故事：描述了对用户、系统或软件购买者有价值的功能。” - Mike Cohn

总之，用户故事在软件开发过程中被作为描述需求的一种表达形式，并着重描述角色（谁要用这个功能）、功能（需要完成什么样子的功能）和价值（为什么需要这个功能，这个功能带来什么样的价值）。

3C原则

因为用户故事的描述信息写在卡片上，Ron Jeffries在2001年用3个C来描述它：

Card（卡⽚）：用户故事被写在一个小的卡片上包含故事描述、规则和验收标准，如下所示：

卡片正面：
卡片背面：

Conversation（交谈）：通过与客户或产品负责人（Product Owner）的交流来确定用户故事的细节，确保各方对用户故事的理解正确。

Confirmation （确认）：用验收测试来确认用户故事开发的完整度和正确性。

用户故事是敏捷开发模式中需求敏捷化的重要手段：

用户故事容易理解，着重角色（Who）和描述商业价值（Why），而不仅仅是功能的描述（What）。
通过看板（Kanban）用户故事有了流动，将研发过程中的需求、开发、测试都串联起来。通过优先级排序和开卡（指用户故事kick off），用户故事将需求与开发连接，通过验收条件（Acceptance Criteria, 简称AC），将需求与测试连接。
强调沟通与对话，易于理解和传播隐性知识。通过故事和客户进行深入交流，避免文字的记录产生歧义性，并提供了迅速的反馈周期，促进了对需求的理解。
小的故事适合做计划，利于客户和业务部门理解并判断优先级，适合于迭代开发。
鼓励延迟细节，支持变更。可以快速写出独立的用户故事，对于优先级低的可以使用史诗（Epic）代替。

INVEST原则

为了编写优秀的用户故事，我们需要关注下面六个特征：

独立的（Independent）：一个用户故事尽可能独立于其他用户故事，并确保每个单独的用户故事都有其独立的业务价值，避免用户故事间的相互依赖导致排优先级变得困难。
可讨论的（Negotiable）：用户故事是可以讨论的，用户故事不是合同，在保证价值的情况下，细节在与客户讨论中产生。
有价值的（Valuable）：每个用户故事必须对客户或用户具有价值，避免那些只对开发团队有价值的用户故事。
可估计的（Estimable）：可以对用户故事进⾏估计，以确定其优先级、工作量，并安排迭代计划。导致用户故事不可估计的原因如：缺少领域知识、缺少技术知识，故事太大了等。
小的（Small）：大小刚刚好，确保在一个迭代（Sprint）中能够完成。
可测试的（Testable）：用户故事必须是可测试的，测试通过可以确认用户故事被开发人员正确地实现了。

一个好的用户故事包括：ID+标题

角色：谁要使用这个功能，了解客户或用户使用我们软件的目的。并尽量只为单一用户编写，这样用户故事的可读性通常是最强的。

活动/功能：需要完成什么样的功能。

价值：为什么需要这个功能，这个功能带来什么样的价值。一个好的用户故事意味着完成后，客户或用户可以达成一个明确的、有意义的目标。

验收标准AC：用来描述用户故事达到必须完成的若干个条件，包括正常及异常条件。通常使用“Given<在什么样条件下>，When<采取了什么行动>，Then<得到什么结果>”格式，这样的写法和测试用例类似，可以使开发更好地理解细节，同时也更方便产品负责人进行验收。

7. 用户故事地图（用户故事的结构化呈现，MVP版本规划）-产品视角

在软件研发过程中，几乎所有产品经理和研发的痛点都在于需求沟通不清楚或者效率低。最常见的场景就是产品经理在给研发讲需求的时候，怎么讲都讲不清楚，沟通很费劲。既然说不清楚，那就写需求文档来说清楚吧，但是最后发现，往往需求文档写的越细越长，开发人员越不愿意看，而且即使写出来了也会发现，开发出来的产品和产品经理的设计永远都存在差异，这也是软件开发过程中客观存在的一个问题。

归根结底，是沟通效果和效率的问题。但是什么样的沟通方式效率最高呢？那就是面对面采取白板的形式来进行沟通，而【用户故事地图】就是比较好的一种选择方式。

对于大型产品开发，用户故事会特别多，用户故事擅长聚焦于构建小的特性，专注于小的细节就没法掌握整体，会带来困惑，不知道什么时候才能完成开发和分布。用户故事地图是一种组织和处理用户故事的方法。用户故事地图有利于：

更清楚看清backlog全貌
为新功能筛选和划定优先级提供更好的工具
便于使用静默头脑风暴模式和其他协作方式来产生用户故事
帮助更好地进行迭代或增量式开发，同时确保早期的发布可以验证整体框架和解决方案
为传统的项目计划提供更好的替代工具
激发讨论和管理项目范围
允许从多个维度进行项目规划，并确保不同的想法都可以得到采纳
基于用户故事规划MVP版本发布计划(Sprint规划)

用户故事地图有两个原则：从左到右讲故事（主干），从上到下拆故事（细节）。

一般来说，用户地图会分三层结构，上面两层把产品骨架或者用户体验路径梳理出来，产品的一级模块和二级模块也通过这种方式逐渐的梳理出来。

产品经理在写需求文档的时候，这两层基本也是对应的文档大纲视图的第一级和第二级，同时它可以从左到右把用户的体验进行排序展示。对研发来说，看到这样一个故事，再结合上面两级，他就能清晰的知道这个用户故事到底需要实现什么样的目标。

引入用户故事地图，让开发人员在关注细小功能的同时宏观对产品的发布计划有一定把握。用户故事地图不是在一开始确定下来后就不再改变的，而必须是可讨论、可沟通的。

用户旅程一般是基于功能定义旅程；而用户故事的颗粒度则更小。

用户故事匹配到用户活动上去，user story mapping.

8. 用户旅程地图User Journey Map(产品经理用户体验分析地图)

将用户使用产品的过程堪称一段旅途，将其呈现出来。开发阶段比较少用，主要用于产品经理考虑用户体验分析。

User Journey 可以把一个用户在使用一款产品时的关键接触点识别和描述出来。
通过一个典型的有序的“生命周期”，把用户行动的全过程用旅程的方式进行呈现。
可以为每个(或一类)用户画像创建一个相关的旅程地图，反映出其典型的行为和态度。

准备活动
确定关键的用户角色Persona,在水平方向标记出生命周期的关键行为(在垂直方向标记出相关的
渠道，如线上、线下等)。

方法
团队一起讨论，识别出用户角色Persona的具体旅程的典型行为，用即时贴呈现出来。

9. 敏捷产品开发--产品待办列表ProductBacklog-研发视角--三个必要条件DEEP+优先级+工作量

●产品需求的列表 ●包含业务需求、技术需求、NFR等 ●理想情况下，每一个待完成的工作都将对客户产生价值 ●PO对该列表进行优先级排序 ●每个迭代开始前，优先级排序还需要再度修正， ●待办事项列表中的条目以用户故事的形式呈现
	1. 适当详细程度的梳理 2. 估算用户故事的颗粒度（小于8个故事点原则） 3. 涌现出来的新故事新需求 4. 排列优先级的

估算工作量：故事点相对估算法 1. 选择故事中的基本故事点作为故事点1 2. 用修改过的斐波那契数列来作为估算故事点的取值范围 3. 工作量+复杂程度+不确定性-->故事点数

用户故事+技术需求+非功能性需求--Deep原则细化--->产生产品待办列表初稿。

10. 敏捷项目管理敏捷工作之发布计划

:确定一组最小可上市的特性集，并确认团队能够行动起来将最迫切的产品推出的日期。在创建产品愿景和产品路线图时,产品负责人确定发布目标和发布日期

发布计划包括两项关键活：
●修订产品代办列表
1.产品代办列表是与项目相关的所有用户故事的列表，是项目需求的主要来源。
2.产品负责人通过不断的添加用户故事和为用户故事排定优先级来创建和维护产品代办列表。
3. scrum团队在发布计划阶段和整个项目中使用该代办列表。
4.产品代办列表至少包括:
[1] 包含对需求的描述； [2]按优先级对用户故事进行排序 [3]添加工作量估算
5.产品代办列表的故事分数之和就是当前的产品代办列表的估算。随着故事的更新而更新。

●发布计划:包含发布目标日期以及支持发布目标的产品代表列表的优先级排序。产品代办列表以及发布计划是产品负责人与团队之间最重要的沟通渠道。
1.创建发布目标:发布目标是发布的产品特性的总体业务目标。产品负责人和开发团队根据业务优先级，开发速度和开发团队能力而创建的发布目标
2.通过评审产品的代办列表和产品路线图，确定哪一个是支持发布目标的最高优先级的用户故事。80%用户故事完成发布；20%去提升稳定性和产生惊喜的因素。
3.制定发布日期:一般在三个冲刺之后，也可以每个冲刺都为用户发布功能。
4.如果还没有准备充分，优化发布目标的用户故事。.
5.让开发团队接受首次发布并对这次发布许下承诺。确保团队对发布日期和发布目标取得共识。