摘要：38 定期安排会面时间立会（站着开的会议）是将团队召集在一起，并让每个人了解当下进展状况的好办法。顾名思义，参与者们不允许在立会就坐，这可以保证会议快速进行。要保证会议议题不会发散，每个人都应该只回答下述三个问题。1 昨天有什么收获。2 今天计划要做哪些工作作？3 面临着哪些障碍？只能给予每个参与者很少的发言（大约两分钟）。如果要讨论某些问题，可以在立会结束之后，再召集相关人员进行。平衡的艺术1 会议占用开发时间，所以要尽量保证投入的时间有较大的产出。立会时间最长不能超过30分钟。10到15分钟比较理想。2 如果要使用需提前预定的会议室，就把预定的时间设定为一个小时吧。这样就有机会在15分钟的 阅读全文

摘要：33 记录问题解决日志维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。解决方案日志应该作为思考的一个来源，可以在基中发现某些特定问题的细节。对某些类似但是有差异的问题，也能从中获得修复的指引。平衡的艺术1 记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单，不必达到对外发布式的质量。2 找到以前的解决方法非常关键。使用足够的关键字，可以帮助你在需要的时候发现需要的条目。3 如果通过搜索Web，发现没有曾经遇到同样的问题，也许搜索的方式有问题。4 要记录发生问题时应用程序，应用框架或平台的特定版本。同样的问题在不 阅读全文

摘要：25 代码要清晰地表达意图软件设计有两种方式，一种方式是设计得尽量简单，并且明显没有缺陷。另一种方式设计得尽量复杂，并且明显没有缺陷。开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过编写的次数，所以在编写的时候值得花点功能让它读起来更加简单。实际上，从衡量标准上来看，代码清晰程序的优先级应该排在执行效率之前。在改动代码以修复bug或者添加新功能时，应该有条不紊地进行。首先，应该理解代码做了什么，它是如何做的。接下来，搞清楚将要改变哪些部分，然后着手修改并进行测试。作为第1步的理解代码，往往是最难的。如果别人给你的代码是很容易理解，接下来的工作就省心多了。明天地告诉阅读 阅读全文

摘要：19 守护天使单元测试。用代码来测试变量的具体值。已经是非常的普遍的做法。你可以选择一个标准的测试框架，来帮忙你完成简单的编写和组织测试的工作，如Java的JUint, C# 或者.Net的NUit等。只要有了单元测试，就要让它们自动运行。也就是每次编译或者构建代码的时候，就运行一次。把单元测试的结果看作是和编译器一样，如果测试没有通过（或者没有测试），那就像编译没有通过一样糟糕。单元测试是最受欢迎者的一种敏捷实践，有很多图书和其他资料可以帮你起步。如果你是新手，建议阅读《单元测试之道》。如果想要自动化地连接单元测试，可以阅读《项目自动化之道》。如果仍然在寻找开始单元测试的理由，下面有很多：1 阅读全文

摘要：为了让软件符合用户的需求，要一直做下面的准备工作。为了降低集成新代码带来的破坏性变化，你要提早集成，频繁集成。当然，你不想破坏已有的代码，想让代码一直保持可以发布。10 让客户做决定开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。平衡的艺术第3章 记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、Wiki、邮件记录或者问题跟踪数据库。但是也要注意，你选择的记录方法不能太笨重或者太繁琐。第4章 不要用低级别和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没 阅读全文

摘要：5 跟踪变化平衡的技术只要你在某些方面成为专家，就能使用同样的方法，很容易地成为新领域的专家。避免在一时冲动的情况下，只是因为想学习而将应用切换到新的技术，框架或者开发语言。在做决策之前，你必须评估新技术的优势。开发一个小的原型系统，是对付技术狂热者的一剂良药。6 对团投资午餐会议□ 读书小组逐章一起阅读一本书，会非常有用，但是要选好书。《7天用设计模式和UML精通…》也许不会是一本好书。□ 不是所有的讲座都能引人入胜，有些甚至显得很不合时宜。不管怎么样，都要未雨绸缪；诺亚在建造方舟的时候，可并没有开始下雨，谁能料到后来洪水泛滥呢？□ 尽量让讲座走入团队中。如果午餐会议在礼堂中进行，有餐饮公司 阅读全文

摘要：1 做事出了问题，第一要点，应该是解决问题。清晰的表达你的目的是解决问题，而不是追究责任，这样会消除他的顾虑。指责是会修复bug.平衡的艺术1 ”这不是我的错”这句话不对，“这就是你的错”，这句话更不对2 如果你没有犯过任何错误，就说明你可能没有努力去工作。3 如果一个团队成员的行为一再伤害屯团队，则他的表现得很不职业，那么他不是在帮助团队，这种情况下必须要求他离开 这个团队，但不一定解雇他。2 欲事则不达优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须要加1，更重要的是，他会想明白产生什么样的影响。通过几年的积累，代码中会成千上万的+1或-1修正，在这样的代码中添加新的功能或者修复bug 阅读全文

摘要：敏捷开发的宣言：一种把以人为本，团队合作、快速响应和可工作的软件作为宗旨的开发方法。它要求团队中的每一个人具备职业精神，并积极的期望项目上能够获得成功的，这并要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。越早越发现问题，就越早容易修复。敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。敏捷团队往往是一个小型团队。在功能有不变的情况下，重新设计部分代码，改善代码的质量，这就是所谓的重构。这是软件开发中不可或缺的一部分，编码永远没有真正意义上的“结束”。要以迭代的方式进行，一般为一周左右的时间进行。 阅读全文