敏捷开发是否可以不写文档？

[LeaPraThink]

公司已经践行了一段时间的敏捷开发，作为质量管理经理，我被老板指定为敏捷转型的负责人。但是因为之前一直做的是瀑布模式，敏捷也是看了一些书和视频后自己摸着石头过河，所以现在有几个问题希望能和大家一起交流一下

1、敏捷开发是否可以不写文档？

敏捷更提倡采用面对面交流的方式来代替传统的全面的文档

诚然，用嘴说当然比写下来更快，效率更“高”，但是在实际使用中，我们发现采用面对面交流的方法，有时候“说”的人不一定能完整地阐述自己的意思，“听”的人也不一定能够完整地理解说的人想要表达的意思。信息在口头传递的过程中很容易失真，而万一不巧发生了问题，又缺少记录在佐证自己前期的观点。

其次，在瀑布里面那种大而全的文档或许拖累了当前的项目进度，但是当项目组涉及人员变更的时候，完善的文档将是一个很好的知识传递工具，否则对于一些项目成员变更频繁的团队，工作的交接会是一场灾难。

我认为文档也是组织资产的一种沉淀和积累，目前我个人的实践模式是让大家在一轮sprint完成后，留一部分间隔时间让大家专门去补文档，但是我发现这种事后补出来的文档往往质量不高，一些过程中的问题没有得到完整的描述，从开发角度来说，一份事后补齐的文档往往对公司有用但是对个人作用不大，因此也不太愿意花费太大的心思去保证质量。再加上为了“敏捷”起来，我目前要求的文档是在瀑布的基础上做了较大的“阉割”形成的，因此目前公司的文档库感觉积累了一堆很尴尬的东西在那儿。

2、测试提前介入，究竟需要怎么介入？

我不知道别的公司是怎么样，但是就我们公司目前所处的条件来说，在拆分story的时候是很难保证独立性的，我们公司没有那种能够前后端通吃的人，因此一个完整的story往往需要拆分成前端、后台、甚至数据中台三个task，而story与story之间也很难保证低耦合性，这就导致了我感觉很难实现那种完成一个story，提测一个story，测试立即就某个story开展测试

实践过程中，我发现如果硬推所谓的“测试提前介入”，开发往往会辩解到这个问题是因为xxx没有开发完成导致的，或者开发在提测之前就会直接指明当前这个story虽然开发完成了，但是其中的xx功能、xx功能是不可用的，因为他们依赖于另外一个待开发或者开发中的story

这样就很容易导致测试工作的混乱，甚至发现了bug也不知道是否应该在bug系统上向开发提出，即使提出bug，开发也不管不顾，或许在几个story都提测以后，bug自然就消失了，开发再将bug打回，白白浪费了人员成本

[m0_52198724]

写评论拿积分。我说下我的看法，首先，敏捷开发不等于不写文档，而不是瀑布模型那样冗长全面的文档，而事前就关键部分，关键环节作出说明，不是事后补文档（要求熟悉关键部分）。其次，提前测试当然指story完成后进行的测试，如果你实在拆分story时无法保证独立，那就选择重要里程碑，在里程碑完成时进行测试。敏捷开发更多是一种理念，不能把项目搞乱，又提高效率。

[愤怒的叶子]

不管是什么形式的开发，文档肯定是必不可少的，有书面化的描述与靠人的记忆与经验完全是两码事，短期内可能可以维持项目的正常运作，但是一年以后随着团队的变动，业务的变化，没有文档，想追溯都难，敏捷不是不写文档的借口

[叫我 Teacher 周]

敏捷不需要文档？那只能说你们没有理解敏捷到底是什么。而且很多人只是觉得快就是敏捷。