如果敏捷是反文档的,为什么会发布一个宣言?
2001年,17位软件开发、测试人员(其中包括Ward Cunningham、Jim Highsmith、Alistair Cockburn以及Bob Martin)共同发布了《敏捷宣言》,并正式提出敏捷开发方法,作为传统文档驱动、重量级软件开发过程的替代方案。《宣言》提出了以下基本原则:
似乎预见到这种简单可能会导致误解,《敏捷宣言》也对此进行了澄清:“也就是说,虽然右边的东西有价值,但我们更看重左边的东西。”
即便如此,业内对敏捷开发方法的误解和困惑仍然存在。“over”被“instead of”所取代,原本《敏捷宣言》的意图是“最好把更多的注意力放在软件上,而不是把时间花在过于详细的前期文档上”,现在似乎变成了“让我们完全抛弃文档,并希望我们记住讨论的所有事情。”
采用传统IT项目方法的团队会在项目的早期阶段定义并记录需求。随后,这些需求将会被提交给开发人员,开发人员收到需求后便立即开始实施。
虽然敏捷开发方法是作为这种文档驱动开发过程的替代方法而创建的,但它并不打算完全消除内部文档。由于软件开发在本质上是动态的,因此,敏捷开发更重视工作软件而非综合文档。
敏捷开发方法中没有任何内容会阻止团队创建项目所需的文档。事实上,在某些情况下,文档是绝对需要的:将用户故事添加到待办事项列表中,以及创建流程图、做会议记录等。敏捷只是——敏捷只是建议在这方面团队要聪明一点。
文档应该“刚刚好”。太多或过于全面的文档会浪费时间,而且开发人员很少相信详细的文档,因为它通常与实际代码不同步。另一方面,经验表明,文档太少始终是困扰沟通、学习和知识共享问题的根源。
敏捷文档的创建和维护对某些人来说是“不可避免的灾难”,但对另一些人来说,这是一项愉快的任务。同样,会有一些合理的理由让你相信,值得在敏捷文档上投入时间:
虽然以上所有的理由可能都是文档化的合理理由,但我们总是问自己这样一个问题:我们目前需要的最少可交付量是多少?
敏捷中工作软件的迭代交付有效地取代了很多(尽管不是全部)全面的前期需求文档。其理念是尽可能保持文档的简单和轻量级,特别是在项目的早期阶段。那么在什么情况下值得在文档中投入时间呢?
一个常见的敏捷实践是尽可能推迟所有可交付文档的创建,在实际需要交付文档之前创建文档。例如,系统概述和支持文档最好在软件开发生命周期(SDLC)的结束时编写。从本质上讲,这种方法是在等到信息最终确定后再捕获它。
另一种敏捷文档的策略是持续文档化。在整个项目中编写可交付文档,在更新代码的同时更新文档。这种方法符合敏捷的方法,即持续生成潜在的可交付的解决方案。
然而,由于需求可能在项目的过程中不断发展,因此需要相当多的时间来让可交付文档的保持最新状态。从敏捷的角度来看,这又是一份“沉重的负担”。
在实践中,敏捷通常会推迟编写文档,直到他们有时间这样做,实际上,即使他们最初决定持续更新文档,也会逐渐转向文档的后期实践。
“我们接受文档,但不接受数百页从未维护过以及很少使用的大部头。”— Jim Highsmith
敏捷开发方法绝不是反文档的。它只是提醒团队不要编写多余的文档,并且在必要时尽可能保持文档的简单性。通过敲定某种格式和细节级别的,允许更改并能交付足够价值的文档,以保持团队在正确的方向上前进。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。