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

2020-09-16 11:43:45 920 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

什么叫敏捷开发？前言软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大阅读详情

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

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

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

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

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

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

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

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

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

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

...全文