敏捷精灵日记10

[敏捷精灵日记]

• 对Prodcut Backlog中的用户故事做估算时，如果某项太大太空难以确切估算，及时对它细化。
• 使用计划纸牌可以极高的提高估算速度。一次估算中，如果任何两个人的估算值相差过大，一定要停下来澄清后，再重新估算。
• 给团队配置两倍的人，并不能得到两倍的生产力的。人越多，交流的成本越大，效率就越低。如果希望靠增加人员来提高软件团队的生产力，无疑是南辕北辙

阅读详细......

敏捷精灵日记9

[敏捷精灵日记]

• TDD 以可验证的方式迫使开发人员将质量内建在思维中, 长期的测试先行将历练开发人员思维的质量，而事后的单元测试只是惶恐的跟随者.
• 重构不是一种构建软件的工具，不是一种设计软件的模式，也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一种书写代码的方式或习惯，重构时时刻刻有可能发生。
• 软件构建学问中总有一些理论上很美好，但是一使用就可能面目全非，比如传统的瀑布模型。敏捷里很多被称之为思想的东西，恰恰没有太高深的理论，但都是一 些实践的艺术，强调动手做而不是用理论论证。TDD就是这样一种东西，单纯去研究它的理论，分析它的优点和缺点没有任何意义，因为它本身就是一个很单纯的东西，再对其抽象也得不出象“相对论”那样深厚的理论。更多的实践会给出正确的答案的。
• 结对编程不是一种形式化的组合，在实际的XP小组中，结对的双方应该是根据需要不断变换的，对的结成应该是自发的，应该保证双方都是对这部分工作感兴趣的人，而不是强行指定。
  
• 结对编程不是结队编程，是2个人，不是更多

• 就象Scrum一样，并不是所有的team都有能力实行XP，也不是所有的项目都适合实行XP，要看实际情况而定。
• xp中，多数实践方法是互相加强甚至是互相保证的，不能单单拿出某一个实践来单独实施，譬如结对编程，缺乏TDD/重构/简单递增设计的实践的有效补充，效果可能会大打折扣。

阅读详细......

敏捷精灵日记8

[敏捷精灵日记]

有效限制持续集成(Continue Integration) 反模式的建议：

• 经常提交代码，可以防止集成变得复杂。
• 在提交源代码之前运行私有构建，可以避免许多破碎的构建。
• 使用各种反馈机制避免开发人员忽视构建状态信息。
• 有针对性地向可以采取措施的人发送反馈，这是将构建问题通知团队成员的好方法。
• 购买更强大的构建机器，从而加快向团队成员提供反馈的速度。
• 避免构建膨胀。

阅读详细......

敏捷精灵日记7-2

[敏捷精灵日记]

1．持续集成最大的优点是可以避免传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

• 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。
• 支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
• 测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运行一套完整的系统测试。
• 提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
• 提倡开发人员频繁的提交（check in）修改过的代码。

2．项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。

阅读详细......