分类： 2. 项目管理

成功并不是不允许犯错误，而是不能犯同样的错误。

测试用例：
1、保持代码的简洁
2、将测试用例视为文档（比文档更直观、更详细、更有效、更有价值，并且永远是最新的）

编写测试用例：
1、测试例运行失败
2、重构代码、重构测试用例

测试/代码 步骤：
1、编写一个测试用例；
2、编译这个测试用例；
3、编写足够的测试用例编译所需要的代码；
4、运行测试用例，测试失败；
5、编写足够的测试用例通过所需要的代码；
6、运行测试用例，测试通过；
7、为达到代码简洁清晰的目的，重构代码，一次且仅一次；
8、重复以上步骤。

采用尽量小的步骤、经常编写测试用例、采用尽量小的步骤。
写小的测试用例、少的代码、使测试通过。
做一次修改、如果测试失败、一定是这个修改引起。

测试什么：积累的过程！——学习已有的开源项目。

如何开始：用测试框架（如jUnit），调用部件库、方法、功能编写代码。

测试的挑战：
1、测试用户界面：用户界面与后台业务逻辑分离
2、在一个小的空间中做测试
3、测试Web
4、测试需要运行速度足够快

不允许做修改的计划就不是一个好的计划。

故事卡片分类注意：
1、商业价值以及其他能帮助客户决定优先级的事情；
2、开发团队的开发速度。

每次迭代开始时，预留一些时间，审查上一次迭代工作。
每次迭代开始时，做迭代计划，通常为半天到两天。
迭代计划是发行版本计划的缩影。

迭代计划中涉及的工作：
1、演示并讨论上一次迭代中所完成的工作。  <1H
2、讨论下次迭代中应包括的内容。 1H-2H
3、任务探讨。 4H-8H
4、迭代计划验证。 4H-8H
    一次做一项任务
    装满您的袋子
（时间估算依据8-10的项目）

估算是一种艺术。需要经验，没有经验靠猜测。
讲求速度！

XP方法中：没有分析阶段、设计阶段、测试阶段和维护阶段。
XP方法中：重要的就是计划和实施计划。
    计划中：
        客户陈述他们希望实现的功能（故事）
        开发人员努力将其变成现实（迭代）
       
两者都要清楚项目的进展情况（对上一次迭代的审查）
    计划的实施：
        写出我们希望实现的功能（测试）
        努力将其变为现实（代码）
       
确保我们已经清晰的理解了我们实现的功能（重构）

2、10分钟——估算优先级和范围：必须有的；没有会造成很大损失的；有了会更好的。
3、 5分钟——最初承诺的时间表：开发团队对每一次迭代的大概时间都要做出承诺。
4、10分钟——第一次迭代：开发人员看是否需要将故事分解成任务，并接受任务、配对；质量保证人员决定各个配对何时通过测试；管理员与市场人员进行沟通-添加故事/随时回答开发人员问题。

5、 5分钟——计划第二次迭代：调整期望的效率和估算；开发团队需要知道他们要做的工作；业务团队要知道他们所期望的结果。
6、10分钟——第二次迭代：同4；业务人员开始考虑在将来的展示会上如何展示预期产品。
7、 5分钟——发布版本和新的承诺时间表：展示会及下一版本产品宣传。
8、 5分钟——大型展示会。

多数谈话都是在有证人的情况下，某个人发表的长篇大论。
——Margaret Miller

任何软件开发项目的成功都直接与沟通成正比！

为了让他们了解你现在的一切，你会：
为他们写文档吗？
写每周状态报告吗？(我甚至被要求每天写工作报告)
如果在同一座办公楼里工作，给他们发过电子邮件么？
如果你很关心他们的近况，你会安排一间会议室，邀请所有你关心的朋友，然后规定他们答应你在最短的时间里做很多的事情吗？

——很遗憾，这些事情我都碰到过，但是我希望你不再会这么做！

XP通过以下4种实践帮助和促进开发人员做面对面的沟通：
1、结对编程（并经常改变配对）——通过口头讲述和解释代替大多数的文字文档，通过配对传播信息：应对人员流动风险。只在需要文档的时候编写最需要的文档，将更多的时间放在查看代码和与人交流上，会收获更大！

2、每天早上召开站立例会——提出自己的困难；找到能帮助自己的人；发布开发和准备过程中的惊喜；确保每天开始时都在做正确的事情。不要过分讨论细节问题！让牛人说话和分享，而不要神秘感或者有所保留；控制例会时间。

3、计划（实质上就是与客户的相互之间的谈话）——交流、沟通、倾听。客户和开发人员沟通。
4、鼓励即席沟通的团队气氛和环境——四处看看，当人们遇到棘手的问题寻求帮助时、在同班陷入困难时拉他一把，帮助需要帮助的人！工作场所布局合理，不要隔间！要白板！要大桌子！

沟通沟通沟通沟通！