《敏捷项目管理:快速交付创新产品》-读书笔记105-第11章 敏捷项目的规模化扩展-8

「20211113」今日音频

音频内容：11.3 组建大型敏捷团队（11.3.4 知识共享和文档）。

若客户和开发人员交互以共同制定规范并产生某些形式的永久记录（文档、笔记、草图、故事卡片和制图）时，文档是交互的副产品，文档可能很有价值；若客户和业务人员一起编写给开发小组的需求文档，文档是交互的替代品，文档可能成为一个障碍。交互减少会通过增加文档数量来补偿，但结果可能并不理想。

假设有两个项目，第1个项目会提供1000页的详细产品规格说明，但不能与客户或用户接触；第2个项目提供50页的规格概述，但不断与客户接触。你会选择管理（和负责）哪个项目？理解来源于文档和交互或信息和对话的二元组合。这并非说不需要文档，而是说只有文档还不够。

知识分为显性知识（写下来的）和隐性知识（记在脑中的）。隐性知识存在于人的头脑之中，不能通过把知识从人的头脑中写到纸上来传递。南希・迪克松说：“隐性知识的传递可以通过移动具有这种知识的人来实现。这是因为，隐性知识不仅是事实，而且是这些事实之间的关系，即人们如何结合一定的事实来应对特定情形的方式。”隐性知识的传递，可以先简要地概括一个最佳实践，再结合为转让人和受让人提供的面对面交流的机制。

敏捷方法和以文档为中心（或以模型为中心）的方法之间的问题并不是文档过多或没有文档的问题，而是正确组合文档和交互方式以促进理解和沟通的问题。敏捷人士倾向于交互方式，传统方法主义者倾向于文档。

《敏捷宣言》提到的“可工作的软件”原则包括两个关键组成部分：一是可工作的软件对于评估真正的成功很重要，但并没有说文档不重要。二是“详尽”的意思是“重量级”而不是精简文档。敏捷人士淡化的是大量的传统文档，而不是文档本身。

合规文档，无论是为食品和药品管理局或萨班斯法案准备的，还是内部控制所需要的，都是执行业务的成本。合规文档在团队内部沟通信息方面没有什么价值——它基本上只是管理开销。

文档既可能非常有价值，也可能浪费时间。对100人团队非常有价值的文档，对6人团队可能完全是浪费时间。敏捷文档的指导原则如下：

• 根本问题是知识转移——理解而不是文档。

• 知识转移需要人与人的交互，特别是在知识的复杂性增加时。

• 文档应该刚刚足够，但不能不够。

  使用概括文档而不是详细文档。

• 高品质且可读的代码和测试用例，特别是当测试用例可以自动实现时，或许符合详细文档的需求。

• 模型是一种形式的文档。

  保持模型轻量级和刚刚足够。

  仅开发对开发团队有用的模型。

  和团队一起开发它们。

• 文档应该尽可能地非正式——白板、挂图、数码照片、维基等。

• 交互的、动态的文档对于敏捷项目非常重要：

  维基、web2.0。

• 可行的软件是开发目标之一，促使该软件的改进是目标之二。

  考虑用刚刚足够的文档来支持两个目标的实现。

• 文档需求因行业、公司和项目的不同而各异。

• 永久文档是组织愿意花费金钱和时间保存的文档。

  可行的纸质文档是在项目中使用但不保存的文档（可能会非常不正式）。

  不要混淆这两类文档。

• 用户文档应该和故事一样被确定下来，并由客户团队排列优先级。

文档的设计应该遵循精简、刚刚足够的原则。文档因项目规模和类型不同而不同。总之，不是文档的问题，是理解的问题。

本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本gongzhong号拥有，任何人不得未经授权转载。