该帖子同步发自：(riverstone的博客  访问该博客)

　　各类大大小小的软件项目数不胜数，而运作这些项目的团队更是参差不齐，对于很多中小团队而言人员流动是家常便饭，对此很难控制，所以如何在动荡的团队中保持项目的可持续性就成了项目负责人必须思考的命题。

　　我一直在小公司工作，当然也遇到过这样的问题，以下结合实际谈谈自己的看法：

　　先说错误的做法，很多负责人会自然而然地想到“文档”，这种说法无可厚非，文档的重要性更是不言而喻的，只是有两个问题：

　　1.文档维护代价很大，对于中小型团队来说按时交付是排它性的第一要素，很少团队有文档工程师，文档的撰写及更新都由设计、开发人员自行维护，而需求的变更、尤其是细节的变更会很频繁(请别相信前期充分的需求调研、优秀的架构可以保证整个生命周期内需求不变更，这是很天真的)，相关人员很少有精力去确保文档与实现100%对应;

　　2.文档说明不了一切，开发人员接手未曾了解过的模块他需要知道三点：模块的需求、目标，模块的架构设计、模块的代码实现，只有充分了解以上三点才能做开发或维护，而文档无法清晰地阐述这些，因为文档是死的;

　　基于以上原因，我觉得文档只能部分解决持续性运作。

　　我认为解决的方案是多种手段地组合：

　　1. 三个会议，分别对应三个要点，要求团队所有成员参与：

　　 需求分析会议，项目负责人把当前版本要完成的功能需求一一告知各个成员，这点与Scrum中的Sprint计划会议有部分类似，目的是为使所有成员都了解需求;

　　 高层设计评审会议，模块负责人在完成设计后向全体成员阐述设计思想，一方面是项目负责人可以评审设计是否合理，另一方面所有成员也知晓了模块地设计;

　　 回顾会议：模块负责人在交付代码后向全体成员说明编码概要及重点，让所有成员都对其代码所有了解;

　　只要不是项目成员整体离职，那么这三个会议几乎就可以解决可持续性问题，另外它对代码质量管控、成员表达能力、设计编码能力都可以做到有效地考评;

　　2. 文档，文档自然还是要的，并且也是很重要的，当然一定要注意同步;

　　3. 编码风格，统一编码风格，尽量使用大家都看得懂的结构及算法，不要刻意标新立异;

　　4. 注释，对接口代码及重要逻辑片段加上注释，同时要保证注释与代码的同步，对注释同步的代价远低于文档地同步;

　　我之所以这么认为并非是我藐视文档，相反地对于文档我相当重视，只是我们不是微软，实在是没有这么多的财力、精力可以花费在文档上，在中小团队中总是要有所取舍。另外再重申一点：文档是死的，人是活的。

　　补充敏捷宣言：

　　个体和互动 高于 流程和工具

　　工作的软件 高于 详尽的文档

　　客户合作 高于 合同谈判

　　响应变化 高于 遵循计划

　　也就是说，尽管右项有其价值，我们更重视左项的价值。