小团队的敏捷开发-第六章
以下这些都是我遇到过的一些情况。前面几个情况明显违背了水晶项目体系，而随后的几个情况则对违背意图以及边界情况等问题进行讨论。
“我们扎根在一个地方并在此进行了为时两个星期的迭代——但是为什么我们还是失败了”
这个问题的责任应该有执行发起人来承担，他本应该安排团队与实用户有更多的交流。
“两名开发人员被一条走廊以及一扇锁上的门给分开了”
如果你希望水晶项目管理体系能够给你提供保障的话，这将成为重要因素。水晶项目管理体系的成功实施取决于人们在开展项目的时候，是否每天进行高频率的少量信息交换以保证人们有足够的能力完成手头的工作。
“我们用这个大型基础结构进行了初次交付”
有的时候的确要花费很长时间构建一个大型的基础结构，以交付第一个同时也是最小的功能性。这就是我们允许增量周期最长可以达到3个月的原因水晶项目管理体系以从运行的代码以及活跃的用户中得到的反馈为基础。他们建立小型的基础构架，在发展系统功能的同时再发展基础构架短期的迭代以及交付周期对团队有利的四大理由：
1.避免写下过多的设计细节内容
2.获得对设计决定做出的真实反馈
3.找到并解决在开发过程中出现的问题
4.养成交付的习惯
“我们的第一次交付是关于数据表的一场演示”
这样不好，每一个交付周期后团队应当交付可运行的、通过测试的、且至少在原则上对用户有用的代码。使用敏捷开发意味着我们要学会如何将开发任务分为不同的“块”，这些细分的任务“块”还应该可以端对端地结合到一块，同时还要要求演练整个开发过程以及当不断的发展的功能性增加时，团队应当构建出适当的构架以满足发展的要求。
“无可用用户，但一名测试工程师下周即将加入我们团队”
测试工程师并不是用户，既不是经理也不是监督者“曾经在这个领域工作”。你的用户专家使你的用户界面设计生效或者失效。一名测试工程师能够对你的测试进行详细的检查然后告诉你代码是否已经遭受损坏，但是他并不能够告诉你，现在所设计的系统是否能够使用户满意。
“一名开发人员拒绝对他的设计进行讨论或者拒绝向其他成员展示他的代码。”
人们乐意对他们的代码进行讨论是个人安全体系特征的一部分内容。问问你自己，你和您的团队成员们怎么才能开展一次不含侮辱性，同时还能允许不同人发挥不同能力的设计讨论会，并且仍然能够交付出合格的系统。
“用户希望我们一次就能将所有功能都交付到他们桌子....”
的确有某些类型的系统用户不能被太多次新系统的交付所打扰，特别是在更换用户界面时，但是你应该邀请一名用户来评审并且试用系统，对您在技术以及使用设计方面的决定给予反馈。一旦系统的某部分通过了设计、测试以及接收，您就可以放心地去设计系统的其他部分了。在您不能够持续交付系统的更新内容给所有用户时可以使用水晶项目管理体系。通过寻找一名“友善”的用户或者将各种版本的系统配置给同一个人来对流程进行改正。
“我们有一些小于用例的里程碑事件，还有一些大于用例的里程碑事件。”
在水晶项目管理体系的词典中执行类别Blob并不是“有趣”的里程碑事件，而是执行或测试新的交流指令，或是执行、测试和集成一对HTML标识符。
“我们写下一个基本概念和系统的设计方案。我们都坐到了一起，这样应该就可以了吧。”
我发现在项目的启动阶段，用例非常的有用（随着系统的逐渐完成，它的作用会越来越小），因此我当然回推荐大家使用它们，但是，许多团队喜欢使用既不是用例又不是特征列表的特性列表和需求大纲。有一些团队甚至可以全部使用口头的协议。如果你们都坐到了一起，那么你们也许会达成共识制定出彼此都认可的角色目标列表和/或用户经历、用例摘要或特性列表作为您的需求“目录”
“谁拥有这些代码”
XP体系拥有一个非常强大的所有者模型；任何两名成员坐在一起工作，并且在对改变系统任一行代码的问题上达成协议。这种对必须有两人同意改变的部分进行安全检查（也必须运行所有的测试模型）的所有权模型是很明显的公共模型。许多我采访过的水晶项目管理体系下的下面团队采用了这种政策：“可以改变它，但是要让我知道”
“能否让测试工程师编写测试？如何对图形用户界面（GUI）进行回归测试？”
回归单元测试应当由开发人员而不是由测试工程师来编写并使用。团队里有了测试工程师，开发人员便能够晚上回家休息，并知道白天对系统的更改不会出乎意料地摧毁系统。
“最佳迭代周期为多长？”
我不清楚是否存在一个通常意义上的“最佳”迭代长度，但是我们必须牢记，如果迭代时间过长、过短或者不变都会产生不同的消极后果。
