敏捷开发的一些思考

我的新书《Android App开发入门与实战》已于2020年8月由人民邮电出版社出版，欢迎购买。点击进入详情

（1）管理层和员工之间必须有信任。你可以在没有信任的情况下完成工作，但它将是高成本的，低效的，离散的，令人伤脑筋的。在信任度低的情况下你将很难完成任务，除非信任度提高。

要说的是，当人们对敏捷感到痛苦时，几乎100%的时间都缺乏信任。

（2）如果你想取得好的结果，你必须有一个技术框架，这样管理层认为是“小变化”的变化实际上是一个小变化。有些人认为敏捷意味着“不超前思考”——你不应该借口说麻烦，你应该为持续的生产力做计划，这意味着明天的“小变化”不是一个6个月的项目。

这并不是提倡某种特定的语言、框架、数据库，而是说，从系统层面来看，你的设计期望是你将在很长一段时间内在这个东西上进行“sprint”，你不应该需要重大的重新设计。

（3）你必须对细节、“完成的定义”等有现实的期望。例如，“完成sprint”是否意味着开发人员将一个功能扔给测试人员？或者这是否意味着测试人员说该功能已准备就绪？如果是后者，测试人员将需要在冲刺 （sprint） “结束”之前很久就看到产品。那么在此之前，测试人员会怎么做呢？当测试人员进行测试时，编程人员会做什么？

关于这个，并不存在一个特别正确的答案，但是团队必须就一些真实的东西达成一致。我曾经在一些团队中工作过，我们经常完成冲刺（sprint）中应该完成的2/3，但我们做得很好，没有让事情陷入困境，所以我们坚定地交付了功能。但是如果冲刺中有15个项目，只有14个项目完成，那肯定会有人会暴跳如雷。

（4）如果项目在高速推进时，我认为固定长度sprint是一个问题，而不是一个解决方案。有时，你可以在两天内将一个功能放在客户面前，但由于该过程，他们必须等待两周。如果有多个团队必须与自己的sprint保持一致，那么一个小小的延迟可能会滚雪球般地变成一个大的延迟。

记住，实现敏捷的两条规则：

1. 要做的事能轻易改变
2. 改变现状