学习《解析极限编程》总结笔记

作者：[美国] Kent Beck Cynthia Andres

——这本书传授了很多让工作更加有效的经验，适合于任何人，里面干货满满，受到过广泛的赞誉。

关于极限

名词：是一种即刻失效的实际行动，它是是无法测量的。
动词：是尽力而为然后处理其结果。
极限地编程：每个成员都为了使团队达到极限而施展自己的极限。

极限编程定义

• 极限编程是一种方法论、战略，适用于各领域。
• 它在各领域的过程和目标是一致的，就是通过不断学习进步达到卓越，进而创造更多价值。
• 由于不同团队的需求是不同的，所以团队极限是不同的，所以极限编程的具体方法是不同的。
• 极限编程的价值观是：沟通、简单、反馈、勇气、尊重。
• 极限编程是用来做的，不是用来表现的。

极限编程原则

变化：经常性地尝试更新你的习惯和模式以适应新的现状，即使它在之前非常适用。
极限：让每个人认识自己在不同的团队中的能力，并做好力所能及的事情。
合作：开展任何可以促进团队合作关系的人力活动。

极限编程团队

• 好的团队协作，使团队总效能大于每个人的效能。
• 通过技术来建立团队信任，例如精准评估工作、提交有质量的工作、快速反馈。
• 以各种方式抛弃忧虑提升效率，例如：
  • 不要隐瞒，反馈很重要。透明的团队有更好的进度。
    • 敌对、不透明都会造成团队能力的浪费
    • 透明也要注意隐私
  • 足够的时间、资金或团队技能可以让团队有最好的表现。
    • 极限编程认知中，需要相应的回报，不能得到的团队是不极限的。
• 平衡个人和团队的需求是团队管理中的一个挑战。
• 每月需要一次回顾，用以在大方向上防止团队偏离价值
• 一旦失去连贯计划，暂停了项目，那么团队也就被实际解散了。
  • 要在关键节点形成项目的运维、开发文档，以存档项目的状态。

极限编程团员

• 自视成员的一部分，了解自己在团队中的作用。
• 愿意能与其他成员进行更好的配合。
• 愿意学习、思考、成长、进步、分享、改变。
• 保持趋近于完美的状态，每次都做到更好。
• 员工需要：基础安全、成就感、归属感、成长、亲切感。

极限编程业务

• 计算机业务最终还是人的业务。
• 盈利很重要，所以让业务驱动项目。
• 今天的钱比明天的钱更有价值。
• 客户驱动系统的内容
  • 客户知道自己要解决的问题的概要，但往往不清楚软件如何解决问题。
  • 让使用人员融入开发团队，根据业务做出灵活的需求反应。

极限编程沟通

• 你不能控制别人的期望，只能告诉别人你所知道的事情，而让对方主动调整期望。
• 选择合适的沟通方式，其中以谈话为主。
• 文档沟通对小型本地团队而言是低效的。
• 提出能解决问题的意见，而不是生成问题。
• 成员共同解决问题，而不是争论方案。
• 平衡行动和讨论，不要害怕失败，失败是成功之母。
• 清晰的沟通可以避免缺陷。 缺陷造成不信任，从而破坏团队。
• 很多信息的缺失，造成人力物力的浪费。

极限编程计划

• 计划：听、说以及将目标和特定时间段联系再一起的训练，每个团员都应参与计划。
• 计划是必要的浪费，提升能力减少它的费时。
• 迅速提出一个短期计划(一周)，并不断演化它。
• 通过调整交付范围来控制项目计划，有时候需要把一个功能分为多个步骤。
  • 预估周期内可用结对时间，选择故事的优先级，不要改变估算。
  • 按风险和价值排序故事，以选出低风险高价值的故事。
  • 每个人每天能完成的工作是固定的。
• 季度详细计划也是需要的，它用来形成一个目标，使上层可以更好的监管进度，也可以用来与实际进行对比。
• 每周的起点可以是任意一天。在那一天完成一周的测试用例
• 我的建议：周二为起点，周一为终点。
  • 周一的部署问题可以快速安排解决
  • 而周三到周五都可以对上一周的任务进行交付
• 应该抵制同时的大量交付，应该防止程序的阶段性跳跃，使用流模式进行生产。

极限编程设计

• 软件是由人开发的，开发过程不能忽视人性化。
• 设计是服务于技术和商业人员之间的信任关系的。
• 不再设计需求，转变为设计故事。
  • 需求是“我要什么”
  • 故事是“将会发生什么”
• 增量设计如此有价值是因为软件开发是科研工作。
  • 使用增量式设计更符合趋近于完美的步调。
    • 保持持续设计，将设计归为日常工作，而不是前期工作。
  • 经验促进设计，不止长期经验，还有短期经验。
    • 利用已有的经验为设计的下一阶段提供信息。
  • 在临近使用时设计，并在使用后获得反馈，可以降低造成系统严重破损的可能。
• 控制自己，不要做时间跨度过大的设计。
• 消除重复，是一个很好的设计优化的切入点。
• 减少项目数量，通过配置来多份部署，多份代码是巨大的浪费。
• 先按问题拆分来设计解决方案，再自然地按解决方案拆分系统。

极限编程开发

• 提供自动测试作为验收依据。
• 使用测试优先编程：测试、编码、重构…再次循环
  • 越早发现的缺陷修复成本越低，所以采用自动化测试与测试先行。
  • 我的建议：从集成测试开始开发。
    • 集成让组件变得更为强大。
  • 让测试构建耗时低于10分钟，每天进行多次集成测试
• 每一次部署都应该有它的当前价值或者未来价值，都要尽量的考虑所有人的意愿。
• 不管项目上的问题是什么，始终是人的问题，也必然由人去解决，而不是极限方法。
  • 要对问题的后续全面负责，从根源上解决问题，使团队不再造成此类缺陷，而不是只针对当前问题去解决。
  • 解决难题：大问题转小问题、优先使用简单方案。
• 加班更容易使团队成员失去基本的人性需求，但这因人而异。
  • 当你太疲惫时，你很难意识到你正在降低项目的价值。
• 一切工作以产出代码(和测试代码)为基础，其它实践都使拘泥于形式的浪费。
• 模式不是目的，是平衡开发人员与使用人员双方需求的手段。

极限编程交付

• 以可使用的系统功能为单位验收，而不是单个成员的工作完成度。
• 付出回报让客户(或客户的客户)参与计划，可以更早的拿到反馈。
• 不要对客户遮掩团队的缺陷，这会让你变得不可信任。
• 保持短周期的、持续的、具体的交付与反馈。
  • 例如：每周一次迭代设计，每日进行功能迭代。
• 以管理手段为保险，防止技术手段失败造成的重大损失。
• 更早的进行第一次软件部署，尽量做到每日部署，尽早得到反馈。
  • 在做到每日部署的路上，可以得到改进的灵感。
  • 尽管是无感知的更新，或者也可以增加一个主动感知，促进反馈生成。

极限编程结对

• 成员间更紧密的空间距离，有助于解决问题，但也要考虑到隐私需求。
• 结对编程很好，但也要注意搭档的感受。
• 所有长期的代码都应该由两个人在讨论中编写完成。
  • 第一步：可以挑选我担心的一段代码，结对完成。
  • 如果没有进行结对编程，那就共享代码使一份程序最少有两个人能对它提出建议。

极限编程学习

• 提升能力的两条路径：从实践出发总结出理论，从理论出发完成实践。
• 实践极限编程并分享它，分享也是实践的一部分。
• 有高级能力的人能从更高的视角审视问题，所以要虚心请教。
• 不是你未知的东西导致你陷入困境，而是你已知的东西并不正确。 – Will Rogers
• 要留出做总结的时间，并实际地进行总结并应用总结，最终习惯于随时总结。
• 把问题看做改变的机遇，从问题中获得技能提升、关系升华、软件改进。
• 改变从意识开始，意识来自度量，就是从过去的经验中得到反省，以使未来的决定更加明智。
• 找到程序开发中的短板，并想办法解决它，即使它不来自技术。
• 应用新实践的目的是更多价值回报。

极限编程分享

• 你唯一能改变的人是自己。
• 积极发表意见是团队健康的一个标志，沉默代表了风险堆积。
• 除了季度计划，还需要每周了解本周实际情况。
• 模范带头开发是一种有力的领导形式。首先改变自己，然后把成果分享出来。
• 组织或参与开放的社区，倾听他人的想法，非常有助于进步。
  • 每个人的每句话都是有意义的，即使他不符合你的价值观。

极限编程组织

• 价值观指导人的行动，不要促使团队成员害怕失败，从而形成错误的价值观。
• 以团队为单位，增进沟通，齐头并进，共同承担，而不是个人领先，后续跟进。
  • 开发者了解功能定义，并编写功能代码和测试。
  • 测试员帮助定义功能点，并指导开发实现自动化测试用例。
  • 架构师发现并实现大规模重构，沟通以使架构大而化小。
  • 项目经理促进团队和其它组织的沟通，并陈述系统能做的事和客户的需求。
  • 产品经理编写并排序故事，还要解答未完善的部分，并根据团队进度调整排序。
  • 主管人员监察团队方向，负责清晰地表达并维持更大范围的目标。
• 虽然角色的工作是固定的，但团队成员的角色不是绝对固定的。
• 尽早解决软件开发的财务算法问题，明确软件团队和投资者之间的共赢关系。
• 以团队为单位进行绩效考评，以团队影响力为标准考评个人。
• 保持风险审计。明确整个系统的风险点。
• 为了使社会关系进步而分工，不为了减少工作而分工。
• 两个团队大小断点：12和150。 —— Malcolm Gladwell所著的《引爆流行》

极限编程经验

• 要尊重个体自由，但不惜任何代价的个体自由。这些是不能帮助团队取得成功的。
• 不要害怕冗余，有时候适当的冗余是有价值的。
• 主动降低质量并不会加速交付，除非你不知道如何获得高质量。
• 按量付费可以得到更多反馈，更好的部署环境。
  • 需要更好的价格优势才能使客户也能支持按量付费。
• 将每个人的计划和实际完成，放在一个公开的地方。
• 减少缺陷的目标是，团队信任在适度增长。
• XP最难的一点是，XP需要一个教练，否则很容易进入误区。
• 要鼓励使用先进的技术，否则整个市场会变得萧条。

写在后面

闲人老师花了一个月读了两遍本书，然后花了两天总结了读书笔记。
稍后还准备搞个PPT版的分享文案，用来分享给需要的人。
有需要的可以加QQ群：1033245535。
也欢迎加群讨论学习编程、测试与管理的艺术。