知乎问题：敏捷开发需要写哪些文档？
回答：
作者：张恂老师
链接：https://www.zhihu.com/question/21974683/answer/94217626
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
太极敏捷的一个基本原则：
敏捷开发只写有价值（business value）的文档。
没什么价值的文档，那是浪费，你写它干嘛呢？
那什么文档是有价值的呢？具体来说，不同的行业、不同的领域、不同的项目、不同的产品。。。所要求的敏捷开发文档的种类有所不同。一刀切的做法不是敏捷，而是教条。
第二条敏捷价值观：
Working software over Comprehensive documentation
一般来说，敏捷开发比 CMMI、ISO 9001 等标准体系所要求的文档种类和数量要少很多。过去许多企业为了尽早尽快拿证，囫囵吞枣、照搬照抄，搞了许多看上去很成熟的文档、步骤和流程。而敏捷开发让你有机会重新思考，重新反思、检视这些标准的开发过程，看看这些文档是否真的适合自己的企业和团队，真的有价值，这是敏捷开发在认识的一大进步。许多过去人们认为必要的文档其实是可以减少、简化与合并的。
关于敏捷文档，敏捷大师 Scott Ambler 有一篇著名的文章详细探讨了这个话题：
Agile/Lean Documentation: Strategies for Agile Software Development
建议大家细读。敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊？
概要设计文档、详细设计文档是源自传统软件工程的说法。
如今传统的 Word、PDF 版的详细设计文档通常可以省略，大部分这类文档可以结合代码注释用工具自动生成，Web/HTML 版的详细设计/代码参考文档才是更好的做法。
在敏捷开发中，需求文档、概要设计（改成架构设计）文档通常是不能省略的。
作者：陈志宏
链接：https://www.zhihu.com/question/21974683/answer/55367743
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
文档问题其实是一个比较棘手的问题。“敏捷对文档是轻视的，但绝对不是不需要”。敏捷宣言里的4句话，已经包含了解决的办法。
《敏捷宣言》：
1、个体和互动 高于 流程和工具意即沟通胜过文档（设计文档、软需、测试案例）。在一个团队可以面对面的工作环境中，如集中办公，无论是架构和开发、开发和测试、业务和架构都能够通过简单便捷的方式进行沟通，那么文档什么的可以轻视，不必按照国际标准的文档格式写大而全的设计文档。但是重要且必要的交谈记录，为了避免遗忘，一定要记录，好记性永远不如烂笔头。
2、工作的软件 高于 详尽的文档意即软件胜过文档（包括设计、软需）。结构合理、脉络清晰的软件成果可以替代绝大部分的功能描述性文档，除非开发的东西一蹋糊涂，只有他一个人能看懂。但是敏捷中开发的代码是共享的，是可以结对编程的，这样就减轻了代码的完全独立性与完全个性化，减少了文档的必要性。但是大型的文档一定要有必要栏目、简要的流程说明，具体的功能可以略写。文档的繁简度，以程序脉络和流程分类是否达到让第三方开发人员足够清晰、快速、全面的了解为准。这是一个度，要根据团队的实际能力来把握，或者是团队的平均水平来把握。
3、客户合作 高于 合同谈判意即可与客户随时沟通的环境胜过一次性大而全的文档（业务需求）。软件的开发一个复杂且变化的过程，需求再全，都有可能在开发时遇到讨论需求时没有客户未考虑清楚的地方，甚至是需求相反的地方。因此，沟通非常重要，能够与客户保持随时随地的顺畅沟通非常重要。这比传统的标准需求文档强很多，更能体现客户的实际需求。但是所有重要且必要的沟通记录，一定要通过文字保存下来！
4、响应变化 高于 遵循计划意即推翻传统的由设计文档来引导开发的观念（设计文档）。毕竟先设计好再开发，是基于设计已经非常完善了，这个阶段已经结束了，但实际情况是这样吗？设计直到开发结束才算结束。因为一开始就设计好的东西，往往由于设计人员疏于实际的开发很久，不了解具体的内容，或者开发人员直到开发到某个阶段才发现遇到某技术问题，需要重新做具体设计。敏捷中认为不可能预测到未来所有的东西，应该有更加合理、更加宽限的态度去包容去承认去响应这些变化。设计文档应该是概要式的，只要到具体某个迭代周期了才去完成最详尽的设计。
小结，按传统的项目流程就是：
谈需求的时候，客户合作 高于 合同谈判；
设计的时候，响应变化 高于 遵循计划；
开发的时候，个体和互动 高于 流程和工具；
交付验收的时候，可工作的软件 胜于面面俱到的文档。
扫一扫
1309
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
