这些管理方法之所以如此失败，是因为使用它们的管理人员不理解软件项目的基本原理。这一原理被称为项目管理的铁十字，约束着所有项目必须做出权衡，无法突破。
质量、速度、成本、完成，你只能任选3个，没法4个全要。可以要求高质量、快速、低成本，这样的话项目就做不完。也可以要求低成本、快速地完成项目，那样的话质量一定不会好。布鲁克斯定律'指出：为延迟的项目增加人手反而会使它更加延迟。
一种非常适用于大型任务的技术是三元估算。这种估算由3个数组成，这3个数分别对应最佳情况、正常情况和最坏情况。这些数都是对信心的估计：最坏情况是指你有95%的信心认为能完成该任务的时间，正常情况仅具有50%的信心，最佳情况仅具有5%的信心。
故事遵循一组简单的指导原则，这组原则的首字母缩写是 INVEST。
•|：独立（Independent）。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
• N：可协商（Negotiable）。这是我们不在卡片上写下所有细节的另一个原因：我们希望开发人员和业务人员之间可以就这些细节进行协商。
• V：有价值（Valuable）。用户故事必须对业务具有明确且可量化的价值。
• E：可估算（Estimable）。用户故事必须足够具体，以允许开发人员进行估算。
• S：小（Small）。用户故事不应大于一到两个开发人员可以在一个选代中实现的工作量。
• T：可测试（Testable）。业务部门应该能够提出用户故事的测试标准，通过这些测试就能表明用户故事己经完成。TDD 可以描述为以下3条简单的规则。
• 先编写一个因为缺乏生产代码而失败的测试，然后才能编写生产代码。
• 只允许编写一个刚好失败的测试——编译失败也算。
• 只允许编写刚好能使当前失败测试通过的生产代码。肯特•贝克很久以前就提出了敏捷的4个价值观：勇气、沟通、反馈和简单。
人使用和控制工具，不能让工具控制和使用人。
分解、合并和穿刺
合并故事很简单。你可以将几张故事卡夹在一起，把它们当作一个故事对待，只需将所有故事点相加即可。
拆分故事会更有趣，因为你需要保持故事的 INVEST 原则。
穿刺是一个元故事，或者叫“用于估算故事的故事”。之所以称为穿刺，是因为我们经常需要开发一个长而很薄的切片，来打穿系统的所有层。QA病
然而，这还不是最糟糕的。把QA工作放在流程的尾端还会带来更糟糕的问题。如果QA处于流程尾端，组织如何知道他们是否做好了自己的工作？很简单，看他们能发现多少缺陷。如果 QA 发现了很多缺陷，他们显然做得很好，QA 经理可以吹嘘自己团队发现了多少缺陷，以此作为 QA 团队尽职尽责的明确证据。
于是，发现缺陷被认为是好事。
还有谁能从这些缺陷中获益呢？老程序员有这样的说法：“你可以给我设定任何交货期限，只要别要求软件正常工作就行。”还有其他人能从缺陷中获益吗？那就是那些需要去满足交货最后期限的开发人员。
什么话都不用说，什么协议都不用写，双方都明白，他们都能从缺陷中受益。一个缺陷的“黑市经济”出现了。这种“疾病”渗透到许多组织中，哪怕暂时还不致命，这种“疾病”毫无疑问使组织逐渐虚弱。