总归是来到最后一章，也结束了这个学期的学习生活
有些团队指定某个成员担任项目资料管理员，负责协调文档/代码仓库。其他团队成员的查找资料时，可以首先找这个人。通过阅读正在处理的材料，好的资料管理员还能发现正在迫近的重复。当项目对一个资料管理员来说太大时（或是在无人愿意担任这一职务时），可以指定多人负责工作的各个方面
围绕功能、而不是工作职务进行组织。如果用户突然决定变更数据库提供商，只有数据库团队受到影响。如果市场部门突然决定使用现成工具来实现日程安排功能，只有日程小组受到影响。这种分组方式能够极大地减少各个开发者的工作之见的相互影响、缩短时间标度、提高质量、减少缺陷的数据。每个团队都知道他们自己要对特定的功能负责，所以他们更会觉得自己是他们的工作成果的主人。
大型项目的团队需要额外的资源：负责索引和存储代码及文档的资料管理员、负责提供常用工具及环境、并进行运行支持的工具构建员
bug被发现越早，进行修补的成本就越低。在编写产品代码的同事编写测试代码。
事实上，好的项目拥有的测试代码可能比产品代码还要多。编写这些测试代码所花的时间是值得的。
即使是目标最明确的团队对项目中的重大改动也有可能会遗忘。要确保每一个人都主动的监视环境、代码的变化。可以指定一个监测员来持续检查项目的变动。保证项目的变化进度。
什么是杰出的团队？人们希望和他们一起开会、因为他们知道自己将看到的是准备充足、精彩的演出。他们制作的文档新鲜、描述明确、一致。团队使用一个声音说话。甚至拥有幽默感。（希望在这样的团队里，但是要保证自己足够的优秀）
无处不在的自动化。让计算器去做重复、平常的事情。因为他们比我们做得更好。我们有更重要、更难的事情要处理。每天思考一下，现在手里有哪些事情可以自动化解决。
注重实效的程序员，一定较为完善的测试自己的代码，以免以后由别人找到自己的bug的羞耻感。我自己也一样。一定要一直保持这种羞耻感，不害怕别人测试我的代码。但是要竭尽全力保证自己代码的正确性。
提示：早测试、常测试、自动测试。bug发现越早，进行弥补的成本越小。
项目测试的主要三个方面：测试什么？怎么测试？以及何时测试？（任何产品一旦开始存在，就需要进行测试）
在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户预期的项目注定是失败的，不管交付的产品在绝对的意义上有多好。
与用户交流期望：“曳光弹”、“原型与便签”可以促进这一过程，两者都让团队构造用户能看见的东西。
给用户的东西要比他们期望的多一点。给系统增加某种面向用户的特性所需要的一点额外的努力，将一次一次在商誉上带来回报。因此，随着项目进展，听取用户意见，了解什么特性会使他们真的高兴。你可以相对容易地增加，并让一般用户觉得很好的特性：a. 快捷键 b 彩色化 c 日志文件分析器 d 自动化安装 d 检查系统完整性地工具 etc. 所有这些特性都是相对表面的，而且实际上不会因为特性肿胀而给系统带来过度的负担。只要记住，不要因为增加这些新特性而破坏系统
注重实效的程序员不会逃避责任。相反的，他们乐于接受挑战，乐于使我们的专业知识广为人知。
不要怀着猜忌心理阻止要查看你的代码的人；出于同样的原因，你应该带有尊重对待他人的代码。
标签：项目,小工,用户,程序员,测试,团队,第二篇,代码 From： https://www.cnblogs.com/Arkiya/p/17021482.html