怎样做好敏捷开发

（1）管理层和员工之间有必要有信赖。你能够在没有信赖的情况下完结作业，但它将是高成本的，低效的，离散的，令人伤脑筋的。在信赖度低的情况下你将很难完结任务，除非信赖度提高。
要说的是，当人们对灵敏感到痛苦时，简直100%的时间都缺乏信赖。
（2）假如你想取得好的结果，你有必要有一个技术结构，这样管理层以为是“小改动”的改动实际上是一个小改动。有些人以为灵敏意味着“不超前考虑”——你不应该借口说麻烦，你应该为持续的生产力做方案，这意味着明日的“小改动”不是一个6个月的项目。

这并不是发起某种特定的语言、结构、数据库，而是说，从体系层面来看，你的规划希望是你将在很长一段时间内涵这个东西上进行“sprint”，你不应该需求重大的从头规划。
（3）你有必要对细节、“完结的定义”等有现实的希望。例如，“完结sprint”是否意味着开发人员将一个功用扔给测验人员？或者这是否意味着测验人员说该功用已准备就绪？假如是后者，测验人员将需求在冲刺（sprint）“完毕”之前很久就看到产品。那么在此之前，测验人员会怎么做呢？当测验人员进行测验时，编程人员会做什么？
关于这个，并不存在一个特别正确的答案，但是团队有必要就一些实在的东西达成共同。我曾经在一些团队中作业过，咱们经常完结冲刺（sprint）中应该完结的2/3，但咱们做得很好，没有让工作陷入困境，所以咱们坚定地交付了功用。但是假如冲刺中有15个项目，只要14个项目完结，那肯定会有人会大发雷霆。
（4）假如项目在高速推动时，我以为固定长度sprint是一个问题，而不是一个解决方案。有时，你能够在两天内将一个功用放在客户面前，但由于该进程，他们有必要等待两周。假如有多个团队有必要与自己的sprint保持共同，那么一个小小的推迟可能会滚雪球般地变成一个大的推迟。
记住，完成灵敏的两条规则：
1.要做的事能容易改动
2.改动现状