英文名：ACP
外文名：Agile Certified Practitioner
中文名：敏捷管理专业人士资格认证
是由 美国项目管理协会 PMI Project Management Institute 发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证。
一年开展4次考试，答题时间：3小时
敏捷开发
计算机名词
中文名：敏捷开发
外文名：Agile Development
核心：用户的需求进化
方法：迭代、循序渐进
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切成多个子项目，各个子项目的成果都经过测试，具备可视、可集成、可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态
原则
敏捷建模(AM)定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP（极限编程）中借鉴而来，在Extreme Programming Explained极限编程解释中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。
复用的思想随处可见，基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待
【核心原则】
- 主张简单
当从事开发工作时，主张最简单的解决方案就是最好的解决方案。不要过分构建overbuild软件。用AM敏捷模型的说法就是：如果现在并不需要这项额外功能，那就不要在模型中增加。要有这样的勇气：不必要多这个系统进行过分的建模over-model（超魔性），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单
- 拥抱变化
需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project Stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此开发方法必须要能够反映这种现实
- 第二个目标是可持续性
即使团队已经把一个能够运转的系统交付给用户，项目也还可能是失败的 -- 实现项目投资者的需求，其中就包括系统应该要有足够的鲁棒性rubush，能够适应日后的扩展。就像Alistair Cockburn常说的：进行软件开发的竞赛时，第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是正在构建的系统的运转和支持。要做到这一点，不仅仅要构建高质量的软件，还要创建足够的文档阂支持材料，保证下一场比赛能有效的进行。要考虑很多的因素，包括现有的恶团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对组织的重要程度。简单的说，在开发的的时候，要能想象到未来。
- 递增的变化
和建模相关的一个重要概念是不用在一开始就准备好一切。实际上，就算想这么做也不太可能。而且，不用在模型中包容所有的细节，只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不再需要的时候丢弃这个模型，这就是递增的思想
- 令投资最大化
项目投资者为了开发出满足自己需要的软件，需要投入时间、金钱、设备 等各种资源。投资者应该可以选取最好的方式投资，也可以要求团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源
- 有目的的建模
对于自己产出，例如模型、源代码、文档、很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它。和建模有关，也许应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，需要和高级经理交流方法，也许需要创建描述系统的文档，使其他人能够操作、维护、改进系统。如果连为什么建模、为谁建模都不清楚，又何必继续烦恼下去呢？首先，要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，就可以结束工作，把精力转移到其他的工作上去，例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型：如果要做一些改变，也许是一个熟知的模式，应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）。关于该项原则的一个重要暗示是应该要了解受众，即便受众是自己也一样
- 多种模型
开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于产出的清单，可以参阅AM敏捷建模的建模工件）。有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。比如：和家里的修理工一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。又比如，你可能会比较喜欢某些工具，同样，你可能会偏爱某一种模型。有多少的建模工件可供使用呢？如果你想了解这方面的更多细节，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling
- 高质量的工作
没有人喜欢糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望
- 快速反馈
从开始采取行动，到获得行动的反馈，二者之间的时间至关重要。和其他人一起开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如 白板、CRC卡片、即时贴 之类的基本建模材料。和你的客户紧密工作，去了解他们的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会
- 软件是你的主要目标
软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。任何一项活动（activity），如果不符合这项原则，不能有助于目标实现的，都应该收到审核，甚至取消
- 轻装前进
你建立一个工件，然后决定要保留它，随着时间的流逝，这些工件需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，愿需求的的更新，团队接受了一种新方法，采纳了一项新技术···），你就需要考虑变化对这7个模型产生的影响 并 采取相应的措施。而如果你想要保留的仅是3个模型，很明显。你实现同样的改变要话费的功夫就少多了。你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和项目投资者之间的沟通）。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图、帽子、质地优良的鞋子、水壶。如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？同样的道理，一个开发团队决定要维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型。那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上
【宣言原则】
最重要的是通过 尽早和不断交付 有价值的软件满足客户需要
我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势
经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务
在开发小组中最有效率，也最有效果的信息传达方式 是 面对面的交谈
可以工作的软件是进度的主要度量标准
敏捷过程提倡可持续开发。出资人、开发人员、用户应该总是维持不变的节奏
对卓越技术与良好设计的不断追求将有助于提高敏捷性
简单 -- 尽可能减少工作量的艺术至关重要
最好的架构、需求、设计 都源自自我组织的团队
每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为
成功
【随机应变】
要达到敏捷的成功 -- 交付支撑业务的最佳软件 -- 软件专家也可以引用这些规则
【自主权】
专注于工作，交付正确的软件，而不是被他人的愤怒情绪所影响
【分享经验】
构建完美软件开发流程，并没有统一的模式。但是在这个领域，敏捷技术，加上持续的应用和改进，都能够达到敏捷的成功
工具
Visual Studio Team Foundation Server (TFS)
TFS，即团队基础服务器（Team Foundation Server），是微软应用程序进行生命周期管理的服务器，用于帮助团队在Visual Studio的协作开发。最近，它进行了升级，包括工作项目执行改进、富文本编辑器的改进，以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善，提升了可以录入和跟踪的项目数量。该服务器现在有一个“利益相关者”许可，来规范服务器的访问权限。
Atlassian Jira
Atlassian推出的Jira是一个很流行的工具，主要用于跟踪产品开发、帮助团队整理问题、安排事务，以及记录团队行为。它内置的Jira Agile插件使开发人员更容易部署关键敏捷策略，这包括用户故事开发、冲刺模块构建，以及可视化的团队活动。
Axosoft
Axosoft以前被称为Axosoft OnTime Scrum，这一软件套件有四个功能模块：Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的，帮助开发团队管理待办事项列表、发布和冲刺，带有燃尽图功能，有一个管理仪表板用于跟踪编码和修改BUG的时间。
LeanKit
使用 LeanKit的团队可以看到工作负载的分布并导出历史数据。最近 LeanKit 进行了一次升级，包含单点登录功能和附加报告功能，从而提供更细粒度的数据详细信息。
Planbox
Planbox 敏捷管理工具通过燃尽图跟踪进程，集成客户反馈，它的目标人群很广泛。最近它对应用的前端和后端都做了升级，添加了更强大的报告功能和新仪表盘，来提升项目速度。它所具有的时间跟踪特性和工具允许用户得到所有他们在Planbox产生的数据。
实践
1/103 敏捷宣言
我们一直在实践中探寻更好的软件开发方法。身体力行的同时，也帮助他人，由此我们建立了如下价值观（4条）：
- 个体和互动 高于 流程和工具
- 可工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右侧 尤其价值，我们更重视左侧的价值
2/103 敏捷12项原则
- 我们最重要的目标，是通过持续不断地尽早交付有价值的软件使客户满意
- 欢迎对需求提出变更，即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势
- 不断交付可用软件，周期从几周到几个月不等，且越短越好
- 项目过程中，业务人员与开发人员开展日常协作工作
- 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
- 无论是团队内，还是团队间，最有效的沟通方法是面对面的交谈
- 可用的软件是衡量进度的主要指标
- 敏捷过程提倡可持续的开发。项目方、开发人员、用户应该能够保持恒久稳定的进展速度
- 对技术的精益求精，以及对设计的不断完善，将提升敏捷性
- 要做到简洁，即尽最大可能减少不必要的工作
- 最佳的架构、需求、设计，出自于自组织的团队
- 团队要定期反省如何能够做到更有效，并相应地调整团队的行为
3/103 项目生命周期选择
stacey矩阵
是Ralph Stacey提出的，通过确定两个维度的管理决策来帮助领导者恰当地选择合适的管理行为
包括：确认程度、认同程度
- 接近确定性 close to Agreement
当因果关系确定时，问题或决策也接近确定性。当过去一个相似问题 或 决策发生时，通常是这样的
人们可以非常确定地从过去 推断和预测 行动的结果
- 远离确定性 far from Agreement
确定性连续的另一端 是 远离确定性的决策
对决策制定者而言，这些情况常常是独特和新颖的
因果关系不是很明朗，从过去的经验推断，在远离确定性的范围，预测不是一个良好的方法
- 认同 certainty
竖轴代表 团队或组织内 关于问题、决策的认同级别。和预想中的一样，依赖于问题的认同级别，管理或领导职能发生变化
| 1.预测型（线性） 生命周期 | 简单项目 simple | 需求明确 技术确定 | 技术理性决策 & 控制监控模版 |
| 2.增量型 生命周期 | 复杂--烧脑项目 complicated | 需求不明确 技术确定 | 政治决策 & 控制、妥协、谈判、主导联盟 |
| 3.迭代型 生命周期 | 复杂--棘手项目 conplex | 需求明确 技术不确定 | 判断性决策 & 思想控制 和 逻辑增量 |
| 5.敏捷项目 | 混浊项目 模糊项目 hazy | 需求还在挖掘 技术还需探索 | 垃圾桶决策模式 集思广益 & 辩证探究 直觉 得过且过 探索错误 是非程序化的决策结果，而不是解决方案 识别，开发 & 选择 确立议程 |
| 4.不要碰项目 | 混乱项目 chaotic | 需求不明确 技术方案还不确定 | 分裂 & 无序 或者 大规模避免 |
Stacey矩阵的应用
Stacey矩阵经常应用到需要管理“不确定性”和“复杂性”问题、项目的场景之中
如敏捷管理就引用Stacey矩阵，用来区分项目 或 产品开发工作应该选用哪一类的生命周期，以确保成功
4/103 Scrum全视角流程
产品研发过程中在以前大多采取的方法为封闭式开发，整个团队历时一年半载同心协力去完成一个完整的项目，然后开始做推广让产品面世，去测试产品远景假设是否可行。这种方法在最初的时候的确是可行的，但是随着互联网的不断进展到现在，移动互联网的繁荣封闭式开发早已成为过去式
为了快速的验证我们的核心假设是否成立。在当下使用的方法为“最小化”产品设计。即用最少的人力、物力、财力成本去快速的验证最核心的假设，小步快跑，快速验证快速迭代的过程
Scrum是一种敏捷的项目管理方法。该方法起源于 英式橄榄球争球 的队形，该方法借鉴了橄榄球队成功的原则发展而来。在开发的过程中
https://baike.baidu.com/item/Scrum/1698901?fr=ge_ala创始人：Jeff Sutherland、Ken Schwaber
定义：是一种迭代式增量软件开发过程
应用：敏捷软件开发
包括：实践 和 预定义角色 的过程骨架
成员组成：主管、产品负责人、开发团队
业务领域：管理软件开发项目 以及 运行软件维护团队
Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。
Scrum中的主要角色包括：同项目经理类似的Scrum主管（角色负责维护过程和任务），产品负责人代表利益所有者，开发团队包括了所有开发人员。
虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.
特性：
Scrum过程
Scrum 是一个包括了一系列的实践和预定义角色的过程骨架（是一种 流程、计划、模式，用于有效率地开发软件）
在每一次冲刺（一个15到30天周期，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog，我觉得翻译成‘’产品目标‘’更恰当）。
产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单（目标项目）会被加入一次冲刺，由冲刺计划会议决定。在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺订单（product backlog），这意味着在下一个冲刺中需求是被冻结的
管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。
Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入（物质、金钱投入··精神内耗投入）
敏捷方法之极限编程（XP）和Scrum区别：
- 【迭代长度的不同】XP的一个Sprint的迭代长度大致为1~2周，而Scrum的迭代长度一般为2~4周
- 【在迭代中，是否允许修改需求】XP在一个迭代中，如果一个UserStory（用户故事，也就是一个需求）还没有实现，则可以考虑用另外的需求将其替换、替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕，任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰
- 【在迭代中，User Story是否严格按照优先级别来实现】XP是务必要遵守优先级别的。但Scrum在这点做的很灵活，可以不按照优先级来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其他事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但如果#6的实现要依赖#10，则不得不优先做#10
- 【软件的实施过程中，是否采用严格的工程方法，保证进度或者质量】Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义给常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为
“猪”角色
猪，是全身投入项目和Scrum过程的人；they are the ones whit “their bacon on the line”
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。
产品负责人编写用户故事，排出优先级，并放入产品订单。
Scrum主管（或促进者）促进Scrum过程，他的主要工作是解决那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷进行。Scrum主管是规划的执行者。
开发团队是负责交付产品的团队。
由5~9名具有跨职能技能的人（设计者、开发者等）组成小团队来完成实际的开发工作。
“鸡”角色
鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。
使用户 和 利益相关者参与到过程中是敏捷方法的一个重要实践。
“鸡”角色参与每一个冲刺的评审和计划，并提供反馈，对于Scrum过程来说是非常重要的
用户软件是为用户而创建的，就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗？”、“假如软件没有被使用，那么它算是被开发出来了吗？”
利益所有者（客户、提供商）是影响项目成功与否的人，他们只直接参与到冲刺评审的过程中。
经理是为产品开发团队架起环境的那个人
会议
在冲刺中，每一天都会举行项目状况会议，被称为“Scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：
会议准时开始，对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有“猪”可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：
- 你完成了哪些工作？
- 以后你打算做什么？
- 完成你的目标是否存在什么障碍？（Scrum主管要记下这些障碍）
每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。
Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范disciplines，这些有助于创造自我组织的团队
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法--承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化
文档
【产品订单】
产品订单（Product backlog）是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级（例如：如果“增加拼写检查”特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）
【冲刺订单】
冲刺订单（Spring backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
【燃尽图】
燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图混淆。燃尽图可以使“冲刺spring”平稳的覆盖大部分的迭代周期，且使项目仍然在计划周期内
项目管理
以下是一些Scrum的通用实践：
客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣）
和所有其他形式的敏捷软件过程一样，Scrum有频繁的包括可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。
- 频繁的风险和缓解计划是由开发团队自己制定：在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。
- 计划和模块开发的透明：让每一个人知道谁负责什么，以及什么时候完成
- 频繁的进行所有相关人员会议，以跟踪项目进展：平衡（发布、客户、员工、过程）
- 仪表板更新
- 所有相关人员的变更
- 你必须拥有预警机制，例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在工作场所和工作时间必须全身心投入
- 完成更多的工作并不意味着需要工作更长时间
术语
下面是Scrum用到的术语：
【角色】
产品负责人（PO） Product Owner：负责维护产品订单的人，维护PBls（profuct backlog）；代表利益相关者的利益
Scrum主管 （SM）Scrum Master：为Scrum过程负责的人，确保Scrum的正确使用并使得Scrum的收益最大化。一般不翻译。排除团队遇到的困难 以及 外界的干扰
开发团队 Team：由负责 自我管理开发产品 的人组成的 跨职能团队4
【工件】
产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求
冲刺订单 Spring Backlog：要在冲刺中完成的任务清单
产品增量 Increment：最终交付给客户的内容。（增量：可以工作的软件）
【活动】
计划会 Spring Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议
每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟 且 站立进行而得名
评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议
反思会、回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议
【其他】
冲刺Spring：一个时间周期（通常在2~4周之间），开发团队会在此期间内完成所承诺的一组订单项的开发
其他领域
虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他行业。当前Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程
【用于产品开发】
将Scrum应用于产品开发是在《T新新产品开发游戏》（哈佛商业评论86116:137-146,1986年）第一次提出，之后 野中郁次郎 和 竹内弘高 合著的《创造知识的企业》（牛津大学出版社，1995年）进行了详细的阐述，当前Scrum被用于开发金融产品、互联网产品、医药产品
【项目管理方法】
由于市场营销通常以项目的方式运作，许多一般项目管理的原则应用在市场营销上。市场营销也可以像项目管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时 和 固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：
在早期发现可能的问题，可以更快地，最小损失地应对问题。根据Scrum的主要原则“没有问题呗扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。
降低财务风险。在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以夸大顾客数量（增大投资未必会带来大量顾客），减少投资直至未知风险被减轻（减少投资未必会影响风险大小），或用与支持其他活动。
使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效，市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。使得客户以不同的方式参与
Scrum作为一个极佳的敏捷项目开发管理方法，让过程项目管理变得更加有形，而可控软件的自我组织和自我管理工作方式，也能让所有成员积极配合并参与到全过程中。在未来的工作实践环节，这些项目开发人员也需要在项目运行观念上进行调整，立足于项目实践工作进行优化和完善。
【极限编程】
ExtremeProgramming，简称XP。
是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能最富有成效的几种方法学之一。
如同其他敏捷方法学，极限编程 和 传统方法学的本质不同在于：极限编程更强调可适应性能性 以及 面临的困难。1996年3月，Kent终于在Daimler Chrysler所做的一个项目中引入了新的软件开发观念--XP。适用于小团队开发。
简介：
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。
极限编程的基础和价值观是交流、朴素、反馈、勇气
即：任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是
XP是一种近螺旋式的开发方法，它将复杂的的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
极限编程的目标：
极限编程XP的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加
极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
极限编程的特征：
极限编程方法的基本特征是：
- 增量 和 反复式 的开发 -- 一次小的改进 跟着 一个小的改进
- 反复性，通常是自动重复的 单元测试、回归测试
- 结对程序设计
- 在程序设计团队中的用户交互（在场的客户）
- 软件重构
- 共享的代码所有权
- 简单
- 反馈
- 用隐喻来组织系统
- 可以忍受的的速度
相关概念：
【软件开发过程】
软件开发的过程是：需求分析、设计、编码、测试
需求分析：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如：你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据···为了清楚地知道这些需求，你经常要和客户、项目经理等交流
设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会一团糟
编码：如果在项目截止前，你的程序不能跑起来 或 达不到客户的要求，你就拿不到钱
测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你是否真的完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远
【权利和义务】
定义每个用户需求的商业优先级
制订总体计划，包括用多少投资、经过多长时间、达到什么目的
在项目开发过程中的每个工作周，都能让投资获得最大的收益
通过重复运行你所指定的功能测试，准确地掌握项目进展情况
能随时改变需求、功能、优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划
能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，正在进行 或 未完成的工作则应该是不难接手的
【开发人员】
知道要做什么，以及要优先做什么
工作有效率
有问题 或 困难时，能得到客户、同事、上级的回答 或 帮助
对工作做评估，并根据周围情况的变化及时重新评估
积极承担工作，而不是消极接受分配
一周40小时工作制，不加班
【其他问题】
灵巧的轻量级软件开发方法
一套软件开发方法是由一系列与开发相关的规则、规范和惯例。
重量级的开发方法严格定义了许多的规则、流程、相关的文档工作
灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起来相对容易
在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很繁琐，程序员之间也很难读懂对方写的代码。1968年，Edsger Dijkstra给CACm写了一封信题为GOTO Statement Considered Harmful的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转而使用更系统、更严格的的开发方法。为了使控制软件开发和控制其他产品生产一样严格，人们陆续制定了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。随着遇到的问题更多，规则和流程也越来越精细和复杂
到了今天（2023年），在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，活着寄希望于更复杂的、功能更强大的辅助开发工具（case tools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。
为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法
失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行删减、重整、优化，这样就产生了很多适应不同需要的轻量级流程。在这些流程中，合乎实际需要的规则就保留下来，不必要的复杂化开发的规则被抛弃。而且，和传统的开发方法相比，轻量级流程不再像流水生产线，而是更加灵活。
XP就是这样一种灵巧的轻量级软件开发方法
为什么称为‘’Extreme 极限‘’？
Extreme极限是指：对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其他XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的、快速的，能够做到一周40小时工作制而不拖延项目进度
核心价值
极限编程中有4个核心价值是我们在开发中必须注意的：
沟通communication、简单simpkicit、反馈feedback、勇气courage、此外还扩展了第5个价值观：尊重respect
XP用‘’沟通、简单、反馈、勇气、尊重‘’来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解阂更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程‘’必须重量‘’才能成功的传统观念
XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈、勇气、尊重”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它
【价值】
极限编程技术以 沟通、简单、反馈、勇气、尊重为价值标准
【沟通】
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。极限编程的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈
【简单】
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统开发方法的不同之处在于，它只关注对当前的需求来进行设计、编码、而不去理会明天、下周或下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很有可能变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解
【反馈】
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
- 来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态
- 来自客户的反馈：功能性测试是由客户 还有 测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度
- 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户
反馈是与“交流、简单‘这两条价值观紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：”编程中的乐观主义是危险的，而及时反馈则是解决它的方法“
【勇气】
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求：设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。
另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
开发
【工作环境】
为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做的最好。
每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等）并履行相应的权利和义务；
所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点供应；
每周40小时，不提倡加班；
每天早晨，所有人一起站着开个短会；
墙上有一些大白板，所有的story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；
下班后大家可以一起玩电脑游戏··
【需求】
客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着重要的作用。开发人员和客户一起，把各种需求变成一个个小的用户故事UserStory，例如“计算年级的总人数，就是把该年级所有班的人数累加”；这些模块又会根据实际情况被组合在一起或者分解成更小的模块；它们都被记录在一些故事卡StoryCard上，之后分别被程序员在各个小的迭代中（Iteration，通常不超过3星期）实现；客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索、开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试（功能测试）。
每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。
【设计】
从具体开发的角度来看，XP内层的过程是一个个基于测试驱动开发TestDrivenDevelopment周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试UnitTest。刚开始，因为什么都没实现，所以所有的单元测试都是失败的，随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都有很容易检验，是否履行了对客户的承诺。XP提倡对于简单的设计SimpleDesign，就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式BigDesignUpFront，因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计走查Review、代码走查 以及 重构Refectory，所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求
【编程】
既然编程很重要，XP就提倡结对编程PairProgramming，而且代码所有权是归于整个开发队伍CollectiveCodeOwnership。程序员在写程序和重构程序的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。
结对编程的好处是：一个人编写代码时，另一个人在思考。思考者的头脑中保持总体概念，不仅手头问题的这一段，而且还有XP指导方针。
例如：如果两个人都在工作，就不太可能会有其中一个说“我不想首先写测试”而离开。如果编码者遇到障碍，他们就交换位置。如果两个人都遇到障碍，他们的讨论可能被在这个区域工作的其他听到，可能给出帮助。这种结对方式，使事情顺畅、有章可循。也许更重要的是，他能使程序设计更具有社交性和娱乐性。
【测试】
既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起ContinuousIntegration，每次整合后都要运行单元测试；做任何的代码走查阂修改，都要运行单元测试；发现BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，还有 集成测试、功能测试、压力测试、系统测试 等。所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一
方法
基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践
- 团队协作 Whole Team
- 规划策略 The Planning Game
- 结对编程 Pair Programming
- 测试驱动开发 Test - Driven Development
- 重构 Refactoring
- 简单设计 Simple Design
- 代码集体所有权 Collective Code Ownership
- 持续集成 Continuous Integration
- 客户测试 Customer Tests
- 小型发布 Small Release
- 每周40小时工作制 40-hour week
- 编码规范 Code Standards
- 系统隐喻 System Metaphor
极限编程的4个商业实践：
- 测试驱动开发 --TDD 是你的商业安全网。因为测试是在编码之前完成，所以写完的测试一定会运行失败，接下来再写代码使测试可以通过。TDD保证你的产品功能、不管公司和技术团队实现的是大规模的变更 还是 小规模的变更
- 结对编程 -- 让2名开发人员写同一段代码，使用同一个键盘和同一台显示器。因为结对大大降低了浪费的时间和缺陷，所以能发来更高质量的代码，并带来高水平的协作
- 集体代码所有制 和 持续集成 -- 如果每段代码不只是一个人熟悉，那么就不会有交流瓶颈了。把代码持续集成到一个主干可以避免重复和不匹配的代码
- 重构 -- 在当时的情况下，写的代码是解决已知问题。通常，团队巧妙地解决了他们的问题，然后持续重构和修改代码，确保代码库能以最为高效的方式不断满足业务最新的需要
规则
【项目开发小组】
在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。
- 这个小组中必须至少有一个人对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕最终用户的需求而展开的。
- 程序员是项目开发小组中必不可少的成员
- 小组中可以有测试员，他们帮助客户制定验收测试
- 有分析员，帮助客户确定需求
- 通常还有个Coach（教练），负责跟踪开发进度、解决开发中遇到的一些问题、推动项目进行
- 还可以有一个项目经理，负责调配资源、协助项目内外的交流沟通等
项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的XP开发小组
【过程】
计划项目 PlanningGrame、验收测试、小规模发布Small Release
XP开发小组使用简单的方式进行项目计划和开发跟踪，并以此预测项目进展情况和决定未来的步骤。根据需求的商业价值，开发小组针对一组组的需求进行一系列的开发和整合，每次开发都会产生一个通过测试的，可以使用的系统
计划项目
XP的计划过程主要针对软件开发中的两个问题：
- 预测在交付日期前可以完成多少工作
- 现在和下一步该做些什么
不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。针对这两个问题，XP中又两个主要的相应过程：
- 软件发布计划 ReleasePlanning。客户阐述需求，开发人员估算开发成本和风险。客户根据开发成本、风险和每个需求的重要性，制订一个大致的项目计划。最初的项目计划没有必要（也没有可能）非常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程中被不断地调整以趋精确。
- 周期开发计划 IterationPlanning。开发过程中，应该有很多阶段计划（比如每三个星期一个计划）。开发人员可能在某个周期对系统进行内部的重整和优化（代码和设计），而在某个周期增加了新功能，或者 会在一个周期内同时做两方面的工作。但是，经过每个开发周期，用户都应该能得到一个已经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过一个开发周期，下一次的估算都会有更多的经验、参照、依据，从而更加准确。这些简单的步骤对客户提供了丰富的、足够的信息，使之能灵活有效地调控开发进程。每过两三个星期，客户总能够实实在在地看到开发人员已经完成的需求。在XP里，没有什么“快要完成了”、“完成了90%的模糊说法，要不是完成了，要不就是没完成”。这种做法看起来好像有利有弊：好处是客户可以马上知道完成了哪些、做出来的东西是否合用、下面还要做些什么或改进什么等等；坏处是客户看到做出来的东西，可能会很不满意甚至中止合同。实际上，Xp的这种做法是为了及早发现问题、解决问题，而不是等到过了几个月，用户终于看到开发完的系统了，然后才告诉你这个不行、那个变了、还要增加哪些内容等
验收测试
客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费宝贵的时间，最好能将这些测试过程自动化
频繁地小规模发布软件（Small Releases）
每个周期Iteration开发的需求都是用户最需要的东西。在XP中，对于每个周期完成时发布的系统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说，不再是看不见摸不着的东西，而是实实在在的。XP需求频繁地发布软件，如果有可能，应该每天都发布一个新版本；而且在完成任何一个改动、整合或者新需求后，就应该立即发布一个新版本。这些版本的一致性和可靠性，是靠验收测试和测试驱动的开发来保证的
简单设计
XP中让初学者感到最困惑的就是这点。XP要求用最简单的办法实现每个需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化
在XP中，没有那种系统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿整个项目开发：从制订项目的计划、到制订每个开发周期Iteration的计划，到针对每个需求模块的简捷设计，到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是个螺旋式的、不断前进和发展的过程。从这个角度看，XP是把设计做到了极致
PairProgramming结对编程
XP中，所有的代码都是由两个程序员在同一台机器上一起写的 -- 这是XP中让人争议最多、也是最难实施的一点。这保证了所有代码、设计、单元测试 至少被另一个人复核过，代码、设计、测试的质量因此得到提高。看起来这样像是在浪费人力资源，但是各种研究表明事实恰恰相反。这种工作方式极大地提高了工作强度和工作效率
很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。开始时总是不习惯的，而且两个人的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统计，在所有刚开始PairProgramming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高效。
项目开发中，每个人会不断地更换合作编程的伙伴。因此，PairProgramming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个项目、开发队伍和公司。从这点看，PairProgramming不仅仅适用于XP，也适用于所有其他的软件开发方法。
测试驱动
反馈是XP的四个基本的价值观之一 -- 在软件开发中，只有通过充分的测试才能获得充分的反馈
XP中提出的测试，在其他软件开发方法中都可以见到，比如功能测试、单元测试、系统测试、负荷测试 等
与众不同的是：XP将测试结合到他独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的。即：任何人往往代码库中放程序Checkin前，都应该运行一遍所有的测试；任何人如果发现了一个Bug，都应该立即为这个Bug增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动玩以后如果能通过所有测试，就证明他的工作没有破坏原系统。这样，测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充足的反馈
【重构】
XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个UserStory用户故事都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫做 设计的重构Refactoring。这个名字最早出现在MartinFowler写的《Refactoring Improving the Design of Existing Code》这本书中
Refactoring主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。Refactoring的概念并不是XP首创的，重构已经被提出了近30年了，而且一直被认为是高质量的代码的特点之一。但XP强调：把Refactoring做到极致，应该随时随地、尽可能地进行Refactoring，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序都应该运行测试程序，保证新系统仍然符合预定的要求
XP开发小组经常整合不同的模块。为了提高软件质量，除了测试驱动开发和PairProgramming意外，XP要求每个人的代码都要遵守编码规范，任何人都可以修改其他人写的代码，而且所有人都应该主动检查其他人写的代码
【频繁的整合】
在很多项目中，开发人员往往很迟才把各个模块聚合在一起。在这些项目中，开发人员经常在整合过程中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为使用时间短，客户们心里并没有多少把握
为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的UserStory（每次整合一个新的UserStory）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。整合后，就发布一个新的应用系统。这样，整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布好几个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效地、及时地交流，以确保项目顺利完成
【集体拥有代码】
在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他人的代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好
为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序（从这点，我们可以再次看到，XP的各个惯例和规则是怎样有机地结合在一起的）
编码规范
XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人的代码，这是实现CollectiveCodeOwnership的重要前提之一
每周40小时工作制（40-hour week），不加班
XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的，因为这说明关于项目进度的估计和安排有问题
Metaphor（系统比喻）
为了帮助每一个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多想象的比喻来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西待会巢穴”
其他相关
大量的加班意味着原来的计划是不准确的，或者是程序员不清楚自己到底什么时候能完成什么工作。而且，开发管理人员和客户也因此无法掌握开发速度；开发人员也因此非常疲劳。XP认为，如果出现大量的加班现象，开发管理人员（比如Coach）应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源
XP中一些基本概念的简介
【UserStory】用户故事
开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory
【StoryEstimates 和 开发速度】
开发小组对每个UserStory进行估算，并根据每个开大周期 Iteration中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多少个UserStory
【ReleasePlan 和 ReleaseScope】
整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory
【Iteration 开发周期、迭代】
和IterationPlan：在一个Release过程中，开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容
【TheSeed】
第一个迭代完成后，提交给客户的系统。虽然这不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块
【Continuouslntergration（整合）】
把开发完的UserStory的模块一个个拼接起来，一步步接近乃至最终完成最终产品
【验收测试（功能测试）】
对于每个UserStory，客户将定义一些测试案例，开发人员将使运行这些测试案例的过程自动化
【UnitTest（单元测试）】
在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序
【Refactoring（重构）】
去掉代码中的冗余部分，增加代码的可重用性和伸缩性
XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统时怎么样的，你可能面对的系统功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP就可以取得别的方法不可能取得的成功。XP方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统时一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP将可以减少风险，增加成功的可能。
XP方法是为小团体开发建立的，在2-10人之间。假如你的团队恰好合适，你就不需要用其他的软件工程方法了，就用XP，但是要注意你不能将XP方法应用于大团队的开发项目中。我们应该注意：在需求一贯呈动态变化 或者 具有高风险的项目中，你就会发现XP方法在小团体的开发中的作用要远远高于在大团体的开发
XP方法需要一个扩展的开发团队，XP团队不仅仅包括开发者，经理、客户也是其中一员，所有的工作一环扣一环，问问，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者
另一个需要可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法
在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP项目都一致的表现出比使用其他方法‘高的多’的生产力。但这从来不是XP方法学的真正目标。XP真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP了
实践
- 【完整团队】XP项目的所有参与者（开发人员、客户、测试 等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西
- 【计划游戏】计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性
- 【客户测试】作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作
- 【简单设计】团队保持设计恰好和当前的系统功能相匹配。它通过了所有测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码
- 【结对编程】所有的产品软件都是由两个程序员，并排坐在一起在同一台机器上重构
- 【测试驱动开发】编写单元测试 是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过
- 【改进设计】随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力
- 【持续集成】团队总是使系统完整地被集成。一个人拆入check in后，其他所有人责任代码集成
- 【集体代码所有权】任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发
- 【编码标准】系统中所有的代码看起来就像是被单独一个人编写的
- 【隐喻】将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块的错误的
- 【可持续的速度】团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑
小结
XP的一个成功因素时重视客户的反馈 -- 开发的目的就是为了满足客户的需要。
XP方法使开发人员始终都能自信地面对客户需求的变化
XP强调团队合作，经理、客户、开发人员都是团队中的一员
团队通过相互之间的交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件
XP的设计简单而高效
程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早地将软件交付给客户
XP程序员能够勇于面对需求和技术上的变化
XP很像一个由很多小块拼起来的智力拼图，单独看每一小块没有什么意义，但拼装好后，一副美丽的图画就会呈现在你面前
Scrum敏捷研发 和 项目管理全流程详解 百度安全验证
未完
5/103 Scrum 三大支柱
1【透明性】
- 软件开发过程中各个环节必须对结果负责、透明
- 运用信息发射源保持高度可见性，如产品待办事项列表、风险日志 等
2【检视】
- 团队根据项目目标定期检查绩效和进展
- 不断寻找问题和计划的偏差
3【调整】
- 拥抱和适应变化，以便我们不断改进
- 定期进行迭代回顾，及时发现问题，并进行调整和解决
6/103 Scrum框架 3355
【3个角色】
- Dev Team 团队（Scrum Team）：开发和测试团队。由负责自我管理开发产品的人，组成的跨职能团队
- Product Owner 产品负责人（PO）：负责确定项目需求，维护Product Backlog（PBls）；代表利益相关者的利益
- Scrum Master Scrum主管（SM）：负责主持会议；排除团队遇到的困难 以及 外界的干扰；确保Scrum的正确使用 并 使得Scrum的收益最大化
【3个工件】
- Product Backlog 产品待办事项
- Spring Backlog 冲刺待办事项列表
- 潜在可交付产品增量
【5个事件】
- spring 冲刺
- spring planning meeting 冲刺计划会
- Daily StandUp Meeting 每日站会
- Sprint Review Meeting 迭代评审会
- Retrospective Meeting 迭代回顾会
【5个价值观】
- 专注
- 承诺
- 尊重
- 公开
- 勇气
7/103 Scrum 3个角色
【Development Team 团队（DT）】跨职能、自管理、T型人才，没有子团队
- 为Spring 创建计划，即Spring Backlog 冲刺计划
- 通过遵循Definition of Done 来注入质量
- 每天根据Sprint Goal（冲刺目标）调整计划
- 作为专业人士对彼此负责
【Product Owner 产品负责人（PO）】一个人、唯一授权、确定产品需求和优先级，负责投资回报率（ROI return on investment）
- 创建产品愿景
- 定义产品特性
- 根据市场价值排优先级
- 根据市场反馈调整功能及优先级
- 确保冲刺的输入处于就绪状态
- 接受/拒绝 团队交付结果
- 负责投资回报率（ROI）
【Scrum Master（SM）：Scrum主管】四种角色教练、牧羊犬、改革先锋、引导
- 作为教练在自组织阂跨职能方面辅导Scrum Team成员
- 帮助Scrum Team专注于创建符合Definition of Done的高价值增量
- 促使移除Scrum Team工作进展中的障碍
- 确保所有Scrum事件都发生并且是积极的、富有成就的，并且在时间盒内完成
8/103 Scrum 3个工件
【Product Backlog 产品待办事项】动态清单、优先级越高越详细、专注于What、PO（Product Owner 产品负责人）拥有
- 一个动态的清单
- 一组产品需求列表
- 理想状态下，每个待完成的工作都能产生价值
- PO可以随时调整列表优先级排序
- 待办事项列表中的条目以用户故事UserStory的形式呈现
- 专注于What，而不是How（What代表对要做的事情非常清晰清楚，知道要做什么；How代表不知道怎样去实现利益所有者的需求）
- 开发给所有人，但最终决定者是PO。（开放：有信息发射源。比如 即时贴、CRC、白板 等）
【Sprint Backlog 冲刺待办事项订单】团队承诺并领取、既有What，也有How、DT（development team 开发团队）拥有
- 是当前Sprint 冲刺工作的分解
- 放在方便团队看到的地方
- 工作不是分配指派的，而是团队承诺的
- 每天更新任务的状态
- 每个团队成员都可以更改，是团队的资产
【潜在可交付产品增量】完成的PBI（product backlog item）总和，是稳定的、可工作的产品功能，PO（产品负责人）和DT（development team 开发团队）共同拥有
- 在一个Spring中可以创建多个增量，每个增量都是之前所有的增量累加起来的，并经过彻底地验证，以确保整合在一起的所有增量都能工作
- 可工作的产品功能满足两个标准，一是满足需求，二是质量达标
9/103 Scrum 5个事件
【冲刺 spring】
- 通常1～4周，越短越好，冲刺长度一旦确定就不能再改变
- 前一个Sprint结束后，新的下一个Sprint紧接着立即开始，每轮冲刺应有一个目标
- 冲刺由 冲刺计划会议、每日站会、开发工作、冲刺评审会议、冲刺回顾会议 构成
【冲刺计划会议 sprint planning】做什么 & 怎么做
- 第一部分：做什么（承诺）
- PO产品负责人 提供需求和优先级信息
- DT 和 PO 一起审查PB（product backlog）条目的优先级、需求细节 等，确保理解一致
- DT 提供 PBI 的估算，以及产能历史数据，决定可以承诺的工作项
- 不可以压迫 DT开发团队 承担超过实际产能的工作
- 第二部分：怎么做（计划）
- DT开发团队 讨论完成 承诺工作的方法和工具
- 必要的技术分析和设计
- 识别需要的技术支持性工作
- 识别依赖项、风险、问题
【每日站会 daily stand-up meeting】个体广播和承诺、通报交付障碍、每日承诺状态检查
- 三个作用
- 个体状态广播，并在团队前做个人承诺
- 向团队通报交付障碍
- 团队每天一次：管理承诺的检查点
- 三个问题
- 昨天完成了什么
- 今天要完成什么
- 有什么障碍或问题
- 三个原则
- 只通报问题，不解决问题
- 鸡外猪内（鸡角色：项目团队外部人员；猪角色：项目团队内部人员）
- 只有猪可以开口
【迭代评审会 Review Meeting】展示成品、业务旁听
- 【猪角色】团队向PO(product owner 产品负责人)展示冲刺内完成的成品
- 不演示PPT，展示货真价实的成品
- 【鸡角色】业务方可以旁听，可以反馈意见
【迭代回顾会 Retrospective Meeting】开场、收集数据、产生见解、决定做什么
- 开场
- 设置阶段，预设基调
- 创造舒适的空间，坦诚讨论
- 明确会议的议题和目标
- 收集数据
- 回忆发生的场景
- 收集和展示全面性的数据
- 产生见解
- 给团队时间，评估收集的数据
- 推导出有深层次意义 或 根本原因
- 决定做什么
- 考虑下个迭代如何改变
- 识别出最高优先级的行动项
- 设置可度量的目标（目标要有意义，切实可行）
- 关闭回顾
- 为团队成员提供交流 和感激的机会
- 总结团队哪些事情需要保留，哪些事情需要改变
10/103 Scrum 5个价值观
- 承诺：愿意对目标作出承诺
- 专注：把心思和能力都用到承诺的工作上去
- 开放：Scrum把项目中的一切开放给每个人看
- 尊重：每个人都有他独特的背景和经验
- 勇气：有勇气作出承诺，履行承诺，勇于承认失败
11/103 XP极限编程核心实践
- 编程方法
- 简单设计
- 简单设计易于接纳变更需求
- 只提供客户需要的功能
- 测试驱动开发（TDD）：测试案例在开发之前完成
- 结对编程
- 两个程序员一起编码
- 结对的双方在不同迭代可以不同
- 重构
- 优化原始代码
- 尽可能降低变化引起的风险
- 简单设计
- 小组实践
- 代码集体所有：集体为所有代码负责，也可以修改集体任何部分代码
- 编码规范：不同的团队可能有不同的规范，但同一个团队用一套统一的规范
- 持续集成
- 尽快的集成，一天可能数次
- 团队不断的处理最新的变更，冲突会很快的被发现
- 稳定高速的步调：团队在整个项目中维持可持续的快
- 隐喻（词义学术语。隐喻就是建立在两个意义所反映的现实现象之间的某种相似的基础上的引申方式）
- 使用真实世界范例
- 技术系统要避免封闭思考
- 交付和管理
- 客户在现场
- 顾客负责写用户故事和定义验收标准
- 问题出现时，确保顾客能欣然接受
- 计划博弈
- 客户编写故事，开发人员进行估算，同时对已知迭代给予承诺
- 目标是最大化产品价值
- 小型发布
- 专注于最小可售功能
- 快速交付
- 减少复杂度，每个版本有较高的商业价值
- 让顾客有更多的参与度
- 完整的团队：所有参与者（开发、客户、测试人员）一起工作在一个开放的场所中
- 客户在现场
12/103 看板核心机制
- 可视化工作流
- 限制 在制品(WIP) 数量：是看板方法的核心机制，标题数字标识了该阶段在制品的最大数目
- 度量和管理流动：快速、顺畅的价值流动是看法开发方法的目标
- 协同改进：暴露产品开发中的问题和瓶颈，并系统解决
- 流程和原则更加的可视化：避免情绪化和主观的想法
13/103 在制品（WIP）
在制品，指的是团队已经开始进行，但还没完成的需求
- WIP越少越好，缩短交付周期，尽快资金回笼
- WIP太多遮蔽了瓶颈，减缓整个工作流程造成效率问题
- WIP太多，同时做多件事情，会造成质量下降，增加缺陷数量，增加返工的风险
14/103 鼓 缓冲 绳法
TOC制约理论（企业管理方法）：
通过DBR（drum鼓，buffer缓冲，R rope绳子）
1980年代，由高德拉特创立，目标是帮助企业降低库存，提高效益，不适当的加大批量，会增加 在制品WIP 储备量，占用较多的流动资金，占用较多的车间和仓库面积
- 鼓drum：控制点，用来控制系统中的产品流动。瓶颈是最好的控制点
- 缓冲：为了保证瓶颈的高产出率。时间缓冲（快接近‘’鼓‘’的时候，缓冲一下，避免风险出现）
- 绳子：建立 鼓与其上游工序 的联系，其传递生产命令
TOC制约法，theory of constraints，以色列籍物理学家和企业管理大师高的拉特博士所发明的一套企业管理方法。其管理方法的关键词是constraints，即制约。其理论核心在于：整个系统的绩效通常总由少数因素决定，这些因素就是系统的制约因素。TOC指导工厂企业人员如何找出运作上的制约 及 如何尽量利用自己手上有限的资源（资金、设备、人员等），令企业在极短时间内，以及无需大量额外投资下，达到运作及盈利上的显著改善。
TOC思维流程图
通常的过程 冲突->现状->核心冲突->未来->分支->条件->转变
- 现状图：识别造成不良效应的核心问题 -- 用逻辑关系列出不良效应
- 冲突图：识别问题背后的冲突和假设，化解冲突，实现双赢
- 未来图：描述解决方案与追求目标之间的逻辑关系
- 分支图：描述解决方案实施后带来的不良后果
- 条件图：识别解决方案可能面临的障碍
- 转变图：描述克服障碍的详细计划
TOC制约法的应用
首先可以应用到生产管理
TOC有一种排程的方法 叫做 鼓-缓冲-绳子
TOC也应用到分销、供应链、项目管理等其他领域，且获得很好的成效。由于任何的改变必然会触及当事人的心理反应，因为大多数人普遍存在有拒绝改变的心态。TOC也因此发展出-套管理技术来“化解日常的冲突”、“授权”、“团队假设-达成挑战性目标”、“构建良好的方案-消除负面效应”等。不仅如此，目前TOC还推广至教育界，几乎美国著名的学府还引进称为MBA课程。
15/103 精益Lean 7项核心概念
- 消除浪费：对客户没有带来价值的事务就是浪费
- 加强学习：通过‘’短期迭代周期、重构、集成测试、频繁的客户反馈会议‘’增强学习
- 推迟决策：决策太早不能获得足够的信息，决策太晚会承担更高的成本风险，所以适当推迟决策找到最佳的平衡点
- 尽快交付：短期迭代 或者 小批量提供有价值的反馈机会，促进有效的决策制定
- 授权给团队：对人尊重，允许团队成员具有灵活性，吸引和留住高素质员工
- 构建质量：不会再结束的时候“测试”质量，而是在整个开发过程持续确保质量，例如 重构、持续集成、单元测试 等
- 窥其全貌：目光长远，脚踏实地，快速失败，快速学习
精益Lean
未完
16/103 各实践方法论价值观
| Scrum | XP | 精益 Lean | DSDM | 看板 | 水晶 |
| 承诺 | 沟通 | 消除浪费 | 关注商业需要 | 可视化工作流 | 频繁的交付 |
| 专注 | 朴素 | 尊重人 | 按时交付 | WIP限制 | 反复改进 |
| 开放 | 反馈 | 快速交付 | 合作 | 管理工作流 | 渗透式沟通 |
| 尊重 | 勇气 | 全局优化 | 从不向质量妥协 | 避免情绪化 和 主观的想法 | 个人安全 |
| 勇气 | 尊重 | 质量为先 | 构建增量 | 提升合作 | 焦点 |
| 推迟决定 | 迭代交付 | 与专家用户建立方便的联系 | |||
| 窥其全貌 | 持续和清晰的沟通 | 持续测试集成技术 |
361
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
