7.2.1 翻阅以往所有的记录，这是否存在浪费时间的嫌疑？

[GreyZeng]

原文地址

第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当人，对牵涉到的技术机密、安全性等信息要采取必要的保护措施。——7.2.1 推动信息共享与沟通、

​ 作者在此部分提出在项目开发时所有的信息都要保留下来，甚至是自己修改的低级bug也要保留下来，以便共享和学习所有的经验。我的问题就是真的有必要去保留所有信息吗？首先，一个项目，多个开发人员，多次开发和修改必定会产生极为大量的信息，不可否认的是信息必定会有很多重要信息，但是同样也会包含大量的冗余的信息，例如，我今天修改了这个“笔误”，他明天也修改了一个“笔误”，这些信息的存在是否会有使信息冗余使总结复盘工作量无意义的增加的嫌疑呢？其次，文档、交流、决定等基本就用于团队的不断迭代开发查阅上，团队项目总结上，或许也需要给用户一份实时的总结文档，那么我们是否应该对所有的未经过处理的记录进行一系列的总结，以便更轻易和系统来分析和总结项目，而不是去翻阅以往所有的记录，这是否存在浪费时间的嫌疑？然后，信息的共享和沟通，也会用于给后来的同事学习经验，相比于一份完整不加以处理的信息，经过总结和归纳的文档或者说信息是否会更好，以及是否会带来更高的效率呢？所以我觉得或许经过分析和总结删除掉同类型和无意义的信息后的文档或许或是一个更好的选择。

[GreyZeng]

信息保留并公开是很重要的一个环节。

信息，不仅包括最终的整理好的总结文档，更要包括开发过程中的开发文档。信息不止包括面对用户的总结，不止包括项目结束之后的总结文档，更应包括在开发过程中的不断所更新的文档。比如任务分配的issue信息，bug修改的issue信息，落实在人头上，既能够将任务细化分配到位，也能够作为一种问责的依据，依据过程中的分配信息来进行落实bug追责。同时不断更新的所有文档，也是一种思考的记录。保留下这些信息并公开，既能够便于队友之间需要交互的信息的及时理解，也能够有利于开发者回顾思考过程，再一次审视当时的思考是否到位。最终的用户文档和开发者文档进行共享很重要，记录了思考过程、任务具体分配的信息进行保留和公开也很重要。
原文地址

[SoftwareTeacher]

我今天修改了这个“笔误”，他明天也修改了一个“笔误”，这些信息的存在是否会有使信息冗余使总结复盘工作量无意义的增加的嫌疑呢？

---

团队可以分析所有的 ‘笔误’ 的bug，看看产生这种笔误的原因是什么，可以去解决底层产生笔误的原因。 从这点来说， 保留并分析所有的记录， 是有好处的。