3.没有将事物分解的足够小

　　对于将事物分解成小的、易接受的块，我是坚定支持者。

　　为什么如此重要的一个主要原因，是这样做可以避免延期。

　　延期经常发生在当我们对大型的可能困难的任务感到畏惧的时候，或者我们不知道接下来该做什么的时候。

　　如果你能将大项目分成很多小块，这将使项目看起来很容易完成，并有一个明确进展步骤。

　　我经常看到，没有给之前的软件项目考虑足够的工作，人为的创造了积压工作或工作项目。

　　我创造了一个长期的积压类型：fatlogs。Fatlogs积压没有分解成足够小，并且经常对于要完成什么非常模糊。

　　当试着理解和解释他们的时候，Fatlogs是出了名的难以估算和浪费时间。关键是fatlogs被分解成更小的可操作的积压工作给敏捷开发团队或大量的时间将被浪费。

　　很多时候，我发现fatlog 的创造者可以很容易的将工作分成小的易于解释和理解的积压工作，即使对于软件开发知之甚少。

　　我时常建议敏捷开发团队，他们应该彻底拒绝fatlogs 并将其送回到某条链上。

　　如果你不能花足够的时间来清楚地说明你想要什么，那么它就没那么重要。

　　但这也不足以豁免开发团队。 开发团队应该将他们得到的任何积压工作分解成小块任务。

　　4.没有设置标准

　　当你订一块牛排的时候，服务生问你的第一件事是什么?

　　显而易见，他们问你你想如何完成它。

　　如果厨师不知道你想要完成的牛排的制作标准，厨师就必须决定他或她的制作标准是什么。

　　你可会得到一个完美的牛排，或者一个让你难以置信的牛排，或者介于两者之间，完全取决于为你烤制牛排的人。

　　这不是一个烤制牛排的好方式，同样也不是制作软件的好方式。

　　在大多数软件项目中，我经常遭遇到大量的在烤制时没有定义的牛排。积压工作当时间耗尽的时候，经常被“做”。

　　对于一个敏捷开发团队，做任何积压工作有一个明确的标准是相当重要的。

　　这意味着，产品所有者应该定义一些可接受性测试。测试是手动测试还是全自动测试没有关系，与团队指定的标准是否能达到其测试目标有关。

　　缺乏标准，好比父母对孩子所提的问题“我应该吃多少豆子?”时所做的回答：“吃饱就行”一样。

　　没有制定标准会导致负面情绪，并为什么在手指指向的方向没有做正确的事。

　　我发现，如果你详细的告诉某人你对他的期望是什么以及评判的标准是什么，你将会比仅仅分配给他们任务得到更好的结果，牵着他们的鼻子说，“好好干。”

　　5.不要为了团队而建立团队

　　团队是一个奇怪的组织，特别是敏捷团队。

　　有很多的变数，会影响到团队的行为和交互。有太多的方式组建一个健康的团队，亦有很多方式创建很烂的团队。

　　一个健康积极的团队具有协同作用，一个不健康的消极团队比其团队成员各干各的好不了多少。

　　关键是有一个健康的团队，能让每个团队成员都变得很自主。无论你的政见如何，你也许会同意以下观点，当一个国家入侵另一个国家，并建立了一个并非由公民选举的政府来管理人民，肯定有问题的。

　　同样的问题发生在敏捷开发过程中。

　　我并不是说团队不应该有责任制。但如果你想以敏捷的方式管理一个软件项目，你必须让团队在达成共识的基础上自我组织以及自我管理。

　　当团队老大总是监督和干扰的话，团队互动变得非常困难。

　　自然而然的，团队时常有他们自己的开发节奏，领导力和角色(称之为准则)。

　　然而，当外部力量直接干扰团队工作时，他们没有权力决定他们自己的命运，团队成员就会开始意识到他们需要好自为之。

　　额外的敏捷开发资源

　　我发现在这些议题中发现好的资源是相当困难的，但这里有一些书，我发现了一些和我上面描述的有用的期刊的地址。

　　Succeeding with Agile: Software Development Using Scrum-这本书专注于Scrum 但它同样适用于不同种类的敏捷项目。 Mike Cohn和我时常在大部分敏捷主题上达成一致。

　　Agile Retrospectives-我发现这本书对于团队回顾能得到启发，这些想法将真正有助于打破障碍，帮助团队解决他们自身遇到的问题。

　　Scrumban 和 Kanban and Scrum - 两本书都提供了丰富的信息，关于combining Scrum and Kanban以及对于解决上述提到的问题，提供了好的解决方案。

　　你认为如何?我错过了任何的敏捷项目真凶?与他们打交道的任何有用的提示?

　　让我们从下面的评论中寻找答案。