问题一：该案中Team的沟通平台建设有问题，没有建立组间协调的基本准则，和监督手段，这样会出现没有完成的工作可以提交甚至是移交给下一个环节。
　　问题二：该案中没有说是否采用了配置管理工具，但很显然配置管理规范是没有做的。
　　问题三：该案中的Team Leader 没有起到疏通流程，接收反馈，改进过程的作用。
　　问题四：该案中尚没有建立很权威的软件质量标准。
　　高质量的工作=过程+管理+技术
　　首先，过程。应该说现在很多软件公司的工作流程都很不完善，需要过程改进。而且更多的时候需求管理和配置管理是过程改进的关键和瓶颈所在。需求管理和配置管理不善就会直接的给开发和测试工作带来负面影响，尤其给测试和开发人员的沟通增加了障碍。导致效率不高，就如本案中提到的问题点。那么配置管理的过程是什么呢？如下图
　　
　　当项目组有越多的成员的时候，制定一个规范的流程就显得越发的重要。
　　第二，管理。所谓“无规矩，无以成方圆”，在做好管理之前制定一套合理的管理规范是必须的，流程有了，但是管理不善也是会功亏一篑的。配置管理，可以说是时间、人、工作内容的全面管理。
1.时间，时间管理主要是及时的向配置管理库中提交更新的内容，从而避免在Build的新版本的时候有遗漏，而导致本案中提到的，测试人员在回归的时候发现提交的缺陷根本没有改的状况，重新再Build一个版本，那自然是人、时、力的极大的浪费。
2.人，作为所有数据的处理和操作主体，是管理的关键，一个误操作就可能使很多人的工作成果付之流水，所以付给不同角色的人不同的权限是很关键的，曾经有一个项目经理给所有的人员只能提交，不能删除的权限，还谓之约“糖公鸡”策略。（意思是不但不拔毛，还粘毛）这不是不信任谁，而是在极大程度上保护大家的劳动成果。
3.工作内容，工作内容可以说是工作质量和工作的主体了，同时也是大家交流的主要对象。对于工作内容的管理主要注意下面几个方面。
* 注释，很多程序员再写代码的时候，不做注释，一个程序员一种风格，这就给读代码，尤其是交叉检查代码带来了困难，人的记忆能力总是有限的，老人家常说“好记性，不如烂笔头”相信时间久了，代码的易读程度就会受到影响。所以代码要求注释。
* 更新说明，在做更新的时候要写说明，我们都知道，变动的代码是极有可能跟很多其他开发人员写的代码有关联的，那么代码的变更势必需要相关联的代码也跟着变更，如果没有，那当然就会出现，提交的缺陷修改完成了，又引入了新的问题的状况。关联复杂的情况下定位问题是很不容易的。由此可见更新的说明对于沟通是多么的重要，当然它也是有帮助记忆的作用的。
* 代码状态，这个是内容管理很重要的一部分，这个状态既能标示一个开发人员的工作里程碑，也能给Build新版本提供一个依据。从而保证Build的每一个新版本是开发人员确认过了的有效的一个版本。
　　第三，技术。开发工程师和测试工程师的技术水平也是决定版本质量的关键，甚至决定性的因素，开发人员不比说了，资深开发人员和刚毕业的开发人员会出现的Bug都很大区别。但经验都是积累出来的。测试人员的水平是很需要提高的，一个同行把测试分为验证和确认两种，（CMMI中也有这样两个过程域）。验证，主要来做数据结构，系统架构，逻辑结构的严谨的验证，从而保证算法、逻辑的严密和准确。确认，主要来看这个系统是否满足了客户的业务需求。我想着不无道理。这样能更深层次，或者更有依据的来保证软件的质量，我们直接就做确认了，确认正确的结果可能是一个假象，就像2+2=4,但公式如果写成2*2=4两个的结果是一样的，但是实现确实完全不一样的。不论是开发人员还是测试人员，在软件质量保证上的目标是一致的，技术要求也是一致的。
　　技术指标的制定，这个笔者也不能给出什么建议，只知道没有最好，只有更好，我们需要不断的提高技术水平。技术提高，不耻下问很重要，一个技术难题很可能其他同事已经解决了，而你不知道，就还需要钻研很久。一个相同的功能，很可能多少个开发人员就有多少种实现，何不大家沟通一下，选个最好的呢？配置管理也是，如果你有更好的解决办法，也别忘了跟我们共享一下。
　　说的可能有点远，但在任何时候做正确的事情，都比坚持错的效果要好。配置管理，从现在开始吧！