有些人认为敏捷不需要文档，甚至不支持任何形式的文档化。在 CIO 杂志上的一个敏捷案例研究中声称，这是一个误解。Frans Bourmar 最近写了一些关于敏捷方法与文档化的内容 ，而Ian Cooper 据此写道：“该是’拨乱反正’的时候了”。
Ian 首先从敏捷宣言讲起。敏捷宣言指出有价值且可工作的软件胜于详尽的文档。他指出，敏捷宣言是一套基本原则和标准，用于检验某个过程是否敏捷，而不是一个具体的方法论。他以下面三种开发过程方法为例，来解释这些原则是怎样发挥作用的：
要理解这个警示，必须记住非敏捷方法论常有文档驱动开发的特征，因为在写代码之前，它需要以大量的文档作为输入。很多情况下，软件开发团队执行相应的过程步骤，只是因为方法论要求他们这样做，尽管它们几乎没有什么价值。结果，很多开发团队完全放弃了这些方法论。敏捷试图避免漫无目标的文档产物，而再次把焦点放在软件开发过程的关键产物上，即代码。不幸的是，很多人没有认识到应该抛弃什么，从而使那种即兴而为式或纸上谈兵式的有限文档成了目标，这些人基本上没有对瀑布式过程（如 SSADM）进行完整的实践。
回想一下水晶方法是如何处理文档：
水晶方法把开发看作是一系列的协作游戏，而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型，以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而，值得注意的是，这些文档没有模板，描述也可不拘小节，但其目标一定要清晰，那就是满足下次游戏就可以了。我总是将这些思想以下面的方式向我的团队成员表达：通过它们，你只要了解你明天加入这个团队所要知道的内容就行了。
而极限编程是如何对待文档的呢？
与水晶方法相比，XP 认为在团队内外，文档都不必太多，并把它看作是需要交付给客户并由客户付费的故事。我觉得这样做的目标就是通过与其它特性集合进行对照评估，来减少多余的文档数量。XP 更依重于开发人员之间的直接交流来传递相关的知识而不是依靠写好的文档，而结对编程使其成为可能：因为通过结对，你就可以和其它人分享对系统的理解，而消灭“死角”，也就很少需要文档来记录这些知识了。另外，代码与测试也被看作是描述软件实现细节的文档，它没有更新不及时的问题……总而言之，就是团队必需的东西或者客户想要的东西。
在你的敏捷项目中，应该有多少文档呢？对你来说，多少算多，多少算少呢？
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论