月度归档： 2008年2月

对于利益和习惯的质疑是一种挑战！

 

要敢于幻想可能的事情，敢于赢得辉煌的胜利，即使最后失败了，也要比那些仅抱着消极信念而体验不到快乐和痛苦的人要强。因为那些人永远生活在没有成功也没有失败的灰色环境中。

——Theodare Eoosevelt

 

对我们这样一个网络自由软件组织来说，XP的理念很适合，而且不存在对传统的习惯的挑战，因为，一切才刚刚开始。

即使您现在的方向正确，但如果您坐在那儿一动不动，您照样不会成功。
——Will Rogers

 

XP的价值之一，集中精力做最简单而又保证能够成功的事情。开始使用XP时，选择一个合适（大小适中）的项目，尽可能使用最简单的工具，然后积极地去使用所有XP实践活动。

1、和朋友一起做——有了朋友，令人畏惧的风险看起来就更像一次冒险了。
2、发现目标——一次引入全部实践活动。
3、集成最有效的工具——老虎伍兹在300码以外将球打入球洞，可能他使用的球棒只是从一个小院子里买来的旧球棒。
4、冲浪——做一些能快速探索到领域中所有问题的有用尝试，以便在今后的尝试细节时降低成功的风险。
    4.1、孤独的狼——实践精简型XP
         计划游戏；
        
需求故事：按高中低的优先级分类存放；
         一次做一个测试用例；
        
识别出开发一项任务真正需要多长时间，并且记录下估算与实际的差距；
         做必需的版本控制；
     ——现在就有了将来集成时所用的基准。
        
重复这样的过程：估算、编写测试、编写代码、让测试通过、重构、记录结果、版本控制——节奏感；
        
总结学到的知识：与别人共同分享，思考如何将其应用在其他重要的任务上；
    4.2、单个对
        
既要编写测试用例，又要编写代码。
        
轮换做“司机”（编写代码）和“领航员”（提前思考）。
    4.3、小规模团队——全面感受XP的真正魅力
         团队每个人都享有权利
         估算小组中的几个主要对象
        
完成计划游戏后，讨论如何描述系统中的几个主要对象——系统隐喻的轮廓。
            
——不用担心难以完全正确的描述他们，只要同意某些事情就足够了
        
每天站着开个会，明确哪些任务应先处理、应该跟谁配对；编写测试用例和代码，经常交换配对；在一台机器上集成所有任务版本，确保每次集成能够允许所有测试；每次集成解决与现有集成基线的冲突——否则不要允许做集成的那对开发员去做其他事情。

    4.4、拥有领头开发员的小团队
        
加入一个有经验的领导者，会有很大帮助！
5、不害怕迷茫——先编写测试用例再编写代码。永远都是成对编写代码。开始编写代码前不用熟悉所有细节。改变以往的习惯。

极限编程（XP）是轻量开发方法中比较有影响的一种。

 

其中的“量”是指用于软件过程管理和控制的、除程序量之外的文档量的多少。
文档的优点：从不同角度提供软件开发的可见性，作为测量、预见、管理、决策和控制的客观依据。
文档的缺点：在很多情况下，按照传统观念建立的大量文档，一方面需要耗费大量的开发资源；同时，也失去了测量、预见、管理、决策和控制的依据的作用。

因此，必须重新审视开发环节，去除臃肿累赘，轻装上阵。

 

轻量的局限性：缺乏预见性，容易带来结构性的质量问题。
在享受轻量的好处的同时，也要避免其局限性。

 

XP让你想到：
1、代码审查有效——成对编程！
2、测试很有效——编写代码之前先编写测试用例！
3、文档很难与代码保持一致——撰写少量必要的文档，以便有助编写代码并有助于测试其他代码！

……

 

XP的4个价值：
1、沟通：项目所有问题的“关键点”！及时沟通、充分交流！
2、简明：“XP就是预测——通过今天做简单的事情，避免将来做更复杂但也许永远用不到的事情。”
3、反馈：从客户、最终用户获取反馈，少走弯路！确保方向正确！
4、勇气：如：放弃代码；软件变更……

 

XP的12个实践：
1、计划游戏：快速制订概要计划，随着项目细节的清晰，逐步完善——一套包含用户需求故事的索引卡（这些需求故事驱动项目的迭代）以及后续的一两个版本的概要计划。
客户——业务决策；开发团队——技术决策。
2、测试： 单元测试 + 验收测试；  单元测试用例是迄今为止最好的文档！  需求故事 对应
验收测试！
3、结对编程：比单独编程效率更高！
4、重构：保持代码简洁，不破坏测试。
5、简单设计：不要包含YAGNI(You Aren’t Going to Need It)
6、共同拥有代码：每个开发人员都拥有全部代码——每次集成之前和之后都要运行单元测试，确保自己造成的破坏自己修复
7、持续集成：在确保系统运行的所有单元测试通过后执行。使集成失败的原因很明显。Bug迟早要解决，一直解决问题会减少这种痛苦
8、现场客户：需求的明确及优先级确认等，面对面沟通误解小。  需求故事卡片只是承诺，而不是交付代码的唯一指示。
9、小版本：尽早为客户提供价值（今天的钱比明天的钱更值钱），同时也能获得具体的反馈。
10、每周工作40小时：长时间持续的工作会扼杀工作效率。“每天早晨都感到活力和激情，每天晚上都感到疲劳和满足”
11、编码标准：目标为团队中没人能分辨出代码是谁写的。有利于代码重构，以及交换编码配对。
不要把编码标准制订太细，会预支很多时间。
12、系统隐喻：系统中各个组件及组件间交互的结构蓝图。体系结构。

XP不是目标，而是到达终点的一种手段。