- 结对编程
以跟多的脑力来实现更优质的代码。
一个人写代码‘驾驶员’，另一个‘领航员’负责思考。
不要指派合作伙伴，结对是流动的，自然形成的，争取跟团队里的每一个人合作。通过交换搭档来获得全新的想法。
结对编程时，频繁的切换角色-至少每半个小时一次，也可以几分钟一次。如果领航员总是在告诉驾驶员应该怎么写代码，那就交换一下，让领航员来写代码。
所有的工作都可以结对。
结对的两个人相互协作，而不是挑毛病。
技能不相称的时候，创造一些让两个人都要相互学习的机会，以此达到结对的平衡。
- 精力充沛的工作
短时间的冲刺工作是一回事，长时间的冲刺工作却是另外一码事。加班不能解决进度问题。事实上，它会带来严重的负面后果。
精力充沛的工作不是偷懒的借口，合理的工作强度能产生信任。
- 信息化工作场所
白板永远不嫌多。
手工绘制的表格更方便、快捷、直观。
- 根源分析
我们通过根源分析来防止错误。
遇到问题时，不应该责备个人。我们的工作方式应该是‘做什么样的改变才能让问题不易出现。
根源分析的一种经典的方法是问五次”为什么“，古话就是“刨根问底”。
在任何发现问题的时候进行根源分析—当你发现一个bug，注意到错误，正在领航，或正在回顾会议上。
- 回顾
我们持续的改善工作习惯。
最常见的回顾“迭代回顾”发送在每次迭代结束时。（决不能通过回顾来责备和个人攻击）
步骤：
Norm Kerth的最高指示。
头脑风暴（30分钟）：每个人回顾享受的、失望的、疑惑的、相同的、更多的、更少的事情。并记录到卡片上。
静音贴图（10分钟）：把相关的卡片贴在一起，凑成一组，并用笔圈上每个组。投票选出那一组应该在下一次迭代总得到改善。
回顾目标（20分钟）：投票结束，有一个分类会胜出。团队利用根源分析，提出改善问题的方法。自由讨论讨论并投票选出一个方法，集中精力去解决。
- 信任
客户和程序员换位思考。
程序员、测试源换位思考。
项目成员共同进餐。
给利益攸关者留一个好映像：可以让项目显得紧迫一点（精力充沛的工作、信息化的工作场所、适当的汇报、以及迭代演示，这些都有助于让项目显得紧迫一点）；按承诺交付。管理问题（你需要把计划做好。问题越大，你越应该更早的把它说出来， 利益攸关者知道问题的时间越早，他们就拥有更多的时间来找到绕过他的办法。对加班的依赖暗示着系统性的问题。）。尊重客户目标。为团队做宣传。诚实。
- 坐在一起
迅速而精确的沟通。
- 真实客户参与
理解客户与终端用户的目标与无赖。
- 统一协作语言
相互了解对方的意思。
- 站立会议
我们知道我们的队友在做什么。
在每日例会上，参与者要回答3个特定的问题：我昨天做了什么？今天要做什么？有什么问题妨碍我取得进展。
要简洁，通常每人30秒。
按时开始并按时结束，即使在有人缺席的情况下。
- 编码规范
接受一种共同的审美观。
制定我们可以接受的最小标准集合。
关注一致性和共识，而不是完美。
比如：我们都同意明确命名的变量和最小方法的重要性。我们之间一致同意使用断言让代码快速失败，没有实际测量不进行优化，而且永远不在对象之间传递空引用。我们一致同意应该怎样或不应该怎样处理异常，怎样调试代码，何时做事件日志，以及日志写到什么地方。
- 迭代演示
我们保持真实。从第一周开始，XP团队每周都产出能工作的软件。
团队中任何人都可以做迭代演示，但建议产品经历来做。
整个团队、关键的投资人以及执行发起人都应尽可能经常的参加会议。
演示结束，问两个问题：到目前为止，我们的工作令你满意吗？我们可以继续吗？
在最初的一个多月时间，可以忽视半小时演示原则，并回答利益攸关者的每一个问题，以此来建立友好。
将利益攸关则的问题记录在像故事一样记录在卡片上，在会议后让产品经理定优先级别。不在演示会议上解决问题。
如果这次迭代完全失败了，应该让利益攸关者知道你在采取什么行动来阻止同样的事情再次发生。
- 汇报
我们在团队决策中培养信任。
进展汇报：比如一次迭代演示或一次发布计划。良好的进展汇报能使利益攸关者信任团队的决策。
需要提供的进展汇报：愿景陈述；每周演示；发布和迭代计划；burn-up图。
- 全部完成
测试完成、编码完成、设计完成、集成完成、成功构建、成功安装、成功移植、评审完成、修复完成、用户接受。
测试人员应该完成非功能性测试和探索性测试。
- 没有bug
编写更少的bug：测试驱动开发、精力充沛工作、结对编程、坐在一起、客户测试、探索性测试、迭代演示、编码规范、全部完成，都可以帮助我们编写更少的bug。
消除滋生bug的温床：技术债务滋生bug。
现在修复bug：在实践中，不可能立即修复每个bug。当你发现一个bug时，你如果正在进行别的工作，可以让领航员在这个问题写在我们的todo列表上。在一二十分钟后，在方便中断手头工作的时候，回头看这个问题。如果没有足够的时间，估算一下修复这个bug的代价，然后请产品经理决定是否在这次发布中修复它。如果这个修复很重要，就把它安排到下次迭代中。
测试你的过程（探索性测试）：不要完全依赖探索性测试来寻找软件中的bug，面对bug，主要的防线应该是测试驱动开发以及其它敏捷开发的优秀实践。
修正你的过程：在你编写测试并修正设计的同时，一定要多问几个问题。为什么之前没有测试防止这个问题？为什么需要设计修改？利用五个为什么的方式去考虑根本原因。
- 版本控制
我们将项目相关的所有内容都保存在单一可靠的地方。
对于数据库，可以让构建数据库的初始化脚本放入版本控制系统。
- 十分钟构建
消除了构建和配置麻烦。
- 持续集成
我们保证代码随时可以交付。
如何做到持续集成：每隔借个小时持续集成一次代码。保证构建、测试和其它发布的组建都及时更新。
永远不要打破构建：你需要一台闲置的开发机作为中心集成环境。
- 代码集体所有制
我们应共同提高代码的质量。
不管在哪里发现问题，修复它们。
在不熟悉的代码上工作：开始时通过结对编程克服问题。在你工作的同时，寻找重构代码的机会。
- 文档
记录必要信息。
过程文档：需求文档、设计文档。面对面的交流比书写文档更加快捷有效。为避免编写过程性文档。必须严格遵守所有的XP实践（坐在一起）。
产品文档：用户手册和API文档。创建故事，估算它，并排定优先级来完成。
- 愿景
我们明白自己的工作什么重要，也知道怎样才能获得成功。
愿景陈述记录三件事：项目应该完成什么？项目为什么有价值？项目的成功标准是什么？
- 发布计划
我们为成功而计划。
一次一项目：每次只着手一个项目。
尽早发布，经常发布。
为自己留一些余地。
最终的故事列表就是你的发布计划。
在最后责任时间制定计划：在实际中意味着，越遥远的事情，你的发布计划需要为之包含的细节就应该越少。（适应性计划）
- 计划博弈
任何人都可以创建一个故事或选择一个未纳入计划的故事。
程序员估算故事。
客户按照相对优先次序将故事纳入计划中。
重复这些步骤，知道所有的故事都被估算并纳入计划。
- 风险管理
我们做出并实现长期的承诺。
一般的风险管理计划：每个项目都会面临一组常见的风险（推翻以前的工作；出现新的需求；工作中断等），这些分享会对你的时间估算代买倍增的效应。
倍增系数表
| 几率百分比 | 严格的 | 冒险的 | 描述 |
| 10% | X1 | X1 | 几乎不可能（忽略） |
| 50% | X1.4 | X2 | 50多50的几率（弹性目标） |
| 90% | X1.8 | X4 | 近乎确定（承诺） |
如果你采用XP实践（每一轮迭代中严格坚持“全部完成”，你的速度是稳定的，而且你的每一轮迭代中修正所有的bug），那么你的风险就会降低。可以采取“严格的”这一列的风险系数。相反，你应该使用“冒险的”一列中的风险因子。
项目特定的风险：应创建风险普查
团队聚在一起讨论，并写在卡片上：项目中什么事情会使你晚上睡不着觉；设想在项目灾难性的失败一年之后，你被采访，当被问及当时项目中出了什么问题的时候，你会怎样回答？；关于这个项目，你最美的梦想是什么？然后写下相反的一面？；在什么情况下，项目会在没有任何人犯错误的情况下失败？；如果是利益攸关者的错，项目会怎样失败？如果是客户、测试员、程序员的错、或者是管理上的错，你自己的错误等，情况又会怎样？；在什么情况下，项目会成功，但某个利益攸关者却会不满意或者很生气？
自由谈论后，留下部分人继续讨论找出的风险，估算风险发生的可能性，风险的影响。
如果发现一些风险并不重要，不再考虑它们。
对于剩下的，确定你是否可以通过不采取风险动作而避免这种风险；预留更多的时间和资金来容纳它；或者采取减轻其影响的步骤来缓解它。
确定：
过度指标：告诉你什么时候风险会变成现实。如：服务器利用率达到80%时可能出现宕机的风险。
缓解行为：预先做什么可以减轻风险的影响。如：准备负载均衡器
应变行为：风险发生时做什么可以减轻风险的影响。如：安装负载均衡器
风险敞口：你应该预留多少的时间或资金来容纳风险。
如果风险100%会发生，那就不再是风险，修改你id发布计划来应付它。
应该指派一个人来监测风险。
怎样承诺发布任务：
风险校正的剩余点数 = （剩余迭代次数 - 风险敞口） x 速度 / 风险倍增因子
如：使用严格的方法，你离发布还有12次迭代，你的速度是每次迭代14个故事，而你的风险敞口是一次迭代
那么：剩余点数 = (12 -1) x 14 = 154点
10%的几率： 154 / 1 = 154点
50%的几率： 154 / 1.4 = 130点
90%的几率： 154 / 1.8 = 86点
你可以把它画成更直观的burn-up图。每周注意一下你们完成了多少个故事点，下一次迭代中总共还有多少点（完成的加上剩余的）。
我们一般答应交付完成几率在90%的特性。
成功比时间表更重要。
风险管理只能用于你对外的任务承诺。在团队内部，应该把精力集中在发布计划的实现上，按进度要求时间未调整的发布计划。
- 迭代计划
我们预先确定一个时间间隔并保持不变，然后每隔一段时间便停下来将实现与计划作比较。
-演示前一轮迭代（半小时）
-回顾前一轮迭代（一小时）
-制定迭代计划（半小时到一小时）
-承担故事的交互（5分钟）
-开发故事（剩下时间）
-准备发布（小于10分钟）
我们应该选择一个合适团队的迭代开始时间，并坚持它。
首先把故事分解为工程任务。大家集思广益，讨论一下完成本次故事需要哪些任务。一起讨论任务是一种设计行为，这是编码开始之前一次很好的讨论机会，不需要考虑太多的细节。每项任务的细节应该给结对们在拿到任务后自己去弄清楚。
结束讨论后，看看这些任务能不能足以完成所有的故事》是否重复或重叠？谁还有不清楚的地方？发现任何问题都要讨论一下。
大家讨论估算时间，取得一致意见。使用理想时间来估算任务，即你将全部精力集中到任务下，不停顿，需要多少时间。如果任务超过6小时，分成更小的任务。如果任务小于两个小时，组合任务。
查看总的本次迭代估算计划，考虑增加或删除本次迭代的故事。
大家一起承诺迭代的任务。不要强迫任何人承诺。有问题一起讨论。
一些程序员自愿的承担某项任务，然后在一个人跟他结对。
迭代结束后，取下卡片，填写迭代编号、日期等信息，并夹在一起归档。
勤务员：处理突发请求。
迭代长度可以是任意的，许多团队喜欢两周的迭代。对新团队，建议一周 的迭代。迭代开始时间，建议每周三。
- 松弛
我们安装迭代的承诺交付软件。
研究时间。
当承诺遭遇风险时：
-将重构用作减震器，当遇到问题或落后与计划进度是，优先完成迭代承诺。以后在清理技术债务
-主动付出一点加班时间
-取消研究时间
如果你一值在利用大多数松弛时间，说明你承诺的太多了。
研究时间也可以结对。
缺乏良好的客户支持和技术债务，需要你需要更大的松弛度来实现承诺。
利用松弛度来清理一下技术债务，就会自动降低你将来所需要的松弛度。
- 故事
通过小的、以客户为中心的片段来计划我们的工作。
故事是为计划准备的。
故事的合适尺度依赖于你的速度。每次迭代中你应该能够完成4-10个故事。
特殊的故事：文档故事；‘非功能性’故事；bug故事；实验故事；估算；会议；架构、设计、重构和技术基础设施（不要为技术细节创建故事）
故事不能替代需求。你需要另一种获得细节的方法，如：现场专家客户，或者需求文档。
- 估算
我们提供可靠的估算。
客户或利益攸关者感觉你的估算时间太长的时候。应该跟他们解释为什么任务需要怎么多时间，要礼貌而坚定的拒绝改变你的估算。
- 增量式需求
我们在进行其它工作的同时定义需求。
现场的客户就是活动的需求文档。
客户评审：在开发各个故事的过程中，在它们被全部完成之前，评审没一个故事，确保它按客户期望的方式工作。
- 客户测试
关注业务规则。
程序员可以使用它们喜欢的工具把客户示例转化成自动测试。如Fit。
不要用客户测试来替代驱动测试开发。客户测试是一种协助交流复杂业务规则的工具，而不是一宗全面的自动测试工具。
- 驱动测试开发
第一步：思考。
第二步：红色进度条。测试编写后，运行全部测试套件，看着测试失败。
第三步：绿色进度条。编写足够的产品代码让测试通过。再次运行你的测试，看着测试通过。
第四步：重构
第五步：重复
单元测试：跑起来很快，如果不快，就不是单元测试。
如果一个测试需要：访问数据库、进行网络通信、使用文件系统、需要对环境做特殊处理。这个测试就不是单元测试，而是集成测试。
聚焦集成测试：只测试与外界进行的一次交互。确保各个测试之间相互隔离，每一个测试都可以独立运行。
- 重构
每一天，我们的代码都比前一天好一点点。
- 简单设计
做尽量少的预期，并保持干净整洁。一个简单的设计是干净和优雅的。
原则：一次有且仅有一次（每个概念在代码中表达一次）
自解释代码：解释并不坏，但它却暗示着代码的复杂程度可能超出了需要。
隔离第三方组件：将第三方组件隔离在一个你所控制的借口之后。创建自己的基类来扩展框架中的类，而不是直接该源类的代码在扩展功能。
- 增量式设计和架构
方法的增量设计
类的增量设计
架构的增量设计：开始时只在设计的某个部分上尝试新模式。将它持续使用一段时间以确认这种改变能在实际中正常工作，再调整到其它部分。重构的同时仍要坚持不断交付故事。
- 实验方案
小的、孤立性的实验。
如果在估算一个故事的时候就预见到有的地方需要试验，那就在故事的估算总包含试验所需的时间。有时，试验太复杂，就创建一个试验故事并对它进行估算。
- 性能优化
必要的时候进行优化。
使用性能分析器（profiler）来指导你的优化行为。
优化有两大缺点：常常导致复杂的问题代码，占用了本来可以用来交付特性的时间。仅当优化可以服务与真实的、可度量的需求时再进行优化。
编写性能故事：应包含吞吐量、延时、响应性。如：每分钟至少100多次交易；每次交易可以延时6秒钟；点击后10秒内完成搜索。
- 探索性测试
通过测试驱动开发来创建全面的、自动化的回归测试套件。将探索性测试的重点放在新特性上，特别是那些行事方式不同与以前特性的新特性。
不要试图将探索性测试用于回归测试策略。回归测试应该是自动化的。
仅当你可能揭示新的信息并可能根据这种信息采取行动时，再使用探索性测试。
86
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
