无论是在代码中使用清晰的名称或解释性注释，还是在请求请求描述中为审阅者提供上下文，在Trello卡上作为描述或注释，在Basecamp上作为文档还是在项目中使用任何其他工具。 把它写下来。
一个古老的拉丁谚语非常简洁地总结了这篇文章： Verba volant，scripta manent。 口语词飞走，文字留下。
在太多的会议中，一遍又一遍地谈论和讨论事情，只是一周或一个月后进行相同或相似的讨论。 多次讨论问题不仅浪费大量时间，而且大多数需要讨论上下文的人都不在电话或会议中（例如，在项目管理会议中的开发人员，反之亦然）。
- 记录下来，以供所有人查看已做出的决定
- 避免在以后的时间再次进行相同的讨论
- 让不参与讨论的人知道已经做出了哪些决定
使注释可供项目中的每个人使用-涉众，项目经理，开发人员，设计师，实习生以及其他所有人。 通常没有必要将信息保密，我们都在同一个项目/产品上工作，而我们的目标是使其更加出色。 让人们看一下笔记，并鼓励他们在不了解或认为未考虑重要事项的情况下发表评论。
在利用修饰，估计，计划，每日站立，回顾和回顾的敏捷项目中，以下每个步骤都与写下内容有关：
- 整理：写下对故事重要的一切。 提供足够的上下文，以便每个人都可以了解其目的和预期结果。
- 估计：一个团队无法估计一个故事或进行长时间的讨论，并且对预期结果有很多疑问，这表明并非所有相关信息都可以书面形式提供（或者书写得不够清晰）。
- 规划：如果团队在规划过程中发现需要PO回答的问题，则这是另一个信号，表明并非所有相关信息都可供需要它们的每个人使用。
- 每日站立：在这里写下的内容包括核对已完成的任务和下一步将要处理的任务，还包括在发现障碍物时需要他人帮助的注释。
- 回顾：幸运的是，我从未见过因为实现结果而以另一种方式使故事被拒绝。 但是我从这样的故事中听到了。
- 回顾性：在这里，团队应该对他们无法获得的信息或决策过程过于模糊以至于某些人不能参与所有讨论而提出他们的担忧。
如果您浏览该列表，您会发现，越早将所有信息提供给所有人，则整个过程越便宜。 想象一下您花了两个星期来编写故事的情况，然后在评论中发现它不能解决问题。 您刚刚花了很多钱。
而且，由于您已经在会议中讨论问题，因此无需花很多时间就可以写下正在谈论的内容。
