Scrum敏捷开发随笔

使用敏捷开发已经一段时间了，感觉效率的确不错，这里面个人感觉主要的就是沟通协调问题。

先说下所谓的敏捷，Scrum完全打破了传统的软件开发流程。

1、不写文档。

2、不写架构设计。

当然，我感觉这不是完全绝对的，但总的来说，要抱着最小浪费时间去做。

先说下不写文档。

scrum认为，所有开发过程中的中间件都是没有价值东西，客户只想要可运行的软件，这就是客户的需求，满足了客户的需求，这个软件就是成功的。所以对于中间文档我们要省省省...甚至不写。

但是要是这个文档是有用的，甚至是客户价值的组成部分，那就又变了。

这种文档可以按照验收的方法去写。

不写架构

第一，业务需求是多变的。之前的架构写得再好，中间需求一变，架构还的改动，费时费力；很多需求可能是无用的，早期可能规划了，后期又会发现用不上，如果架构里边考虑了这些无用需求，就会过于庞大。

第二，架构设计很难判断是否正确、完备。本来以为很好的设计，到了编码的时候发现不是那么回事。
敏捷的这些假设，整体上非常普遍，所以不在那些还不知道是否可行的东西上浪费时间，是敏捷不做架构的出发点。

但是如果彻底不写架构设计，又可能返工，怎么办呢？当然是本着“最小浪费”原则来做架构设计。写相对稳定不变的，重构成本很高的，能看出对错的。不写概念性的那不太准的，很容易扩展的，说不清对错的

最后是Daily Scrum

为什么说不要超过15分钟，因为开会时间长，往往不是沟通充分的表现，而是沟通不充分，只能赶在会上沟通的表现。