3.3.2.1   一个员工离职了，可是部分系统的帐号仍然在活动中！

当各个系统的用户帐号没有集中管理起来之前，每个系统都各自拥有一套独立的管理程序。员工入职要建立多个帐号，员工离职要分别的删除，如果管理员忘记了在某个系统中删除帐号，就会造成人离开了，帐号仍在。可能会导致系统的非授权访问，造成信息泄漏。

群英汇通过将各个系统的认证和用户信息整合，解决了这个问题。当有新员工入职，只需要在用户管理平台上注册一次，各个应用的帐号就都开通了（当然还需要对应的权限设置）。当员工离职，只需要在用户管理平台上删除帐号，其它各个应用的帐号自动关闭。

3.3.2.2   没有帐号整合前，每个人都要记好几个口令...

很多人的口令都设置的非常简单，原因是口令太多，怕记不住。这也导致口令被轻易破解。

群英汇集中用户管理系统，解决了这个问题。用户只需要记忆一套用户名/口令就可以了。当用户在集中管理平台中修改口令，各个关联系统的登录口令全部更改（实际上口令仅在一处维护）。

3.3.2.3   在不同的平台跳转，需要频繁的输入用户名和口令...

在使用多个系统的时候，需要频繁的认证，这不仅是麻烦、用户体验不好的问题，更重要的是安全性上的问题，尤其有的系统的登录采用的不是 HTTPS 协议，就更加的雪上加霜。多次口令在网络中暴露，以及采用非加密协议进行口令认证...

群英汇采用单点登录的实现方案，解决了这个问题。因为使用群英汇单点登录系统后，多个系统的切换只需要认证一次，而且是在加密的 HTTPS 信道内完成的。

3.4.3.1   团队中的邮件沟通中有很多有价值的东西没有保存下来...

这是使用邮件沟通的弊病，即知识保存在邮箱中，随着人员变动而流失。

引入邮件列表系统，可以解决这个问题。因为邮件列表中的讨论全部在Web上存档，可以随时查阅邮件列表的历史归档。

3.4.3.2   用户查看邮件归档需要登录，口令从哪里获取呢？

传统邮件列表软件没有完善的用户管理系统，并且认证口令是写在 cookie 中进行认证非常不安全，这也就是为什么 Mailman 要每个月改一次口令，也就是为什么用户在想看需要授权的邮件归档的时候，却找不到口令的原因。只能到信箱中去翻看每月一次的口令通知邮件。

群英汇邮件列表系统解决了这个问题。因为群英汇对邮件列表系统的整个认证系统进行了彻底的改造，并支持单点登录系统。这样用户如果通过了单点登录，并且具备相应权限（如属于列表的订阅用户），就能直接查看列表归档了。

3.4.3.3   邮件列表的原有的管理员授权太简陋，仅凭口令来判断管理员？

传统邮件列表软件没有完善的用户管理系统，超级管理员和列表管理员仅仅通过预分配的口令进行认证，并且每个列表的管理员口令只有一个，超级管理员的口令也只有一个。在需要设置多个管理员授权时，难保不口令泄漏，造成管理上的风险。而且口令维护也是一个管理负担。

群英汇邮件列表系统解决了这个问题。因为群英汇对邮件列表系统的整个认证系统进行了彻底的改造，并支持单点登录系统。对于超级管理员，需要集中管理平台对用户身份的二次认证（检查用户授权），对于列表管理员，则通过比对列表配置中的管理员邮件和登录用户的邮箱做出判断。

3.5.3.1   新员工入职，有什么快速入门手册么？

编写一个入门手册容易，但是维护起来很难。要内容翔实、信息更新及时就更难了。

引入群英汇知识管理平台，在维基的框架下建立新员工入手册，让每个人的智慧都可以成为新员工的引领。您可以预见当有这么一份入职宝典提供在新员工面前，新员工将会对新工作多么期待。

3.5.3.2   我的电话号码改了，怎么更新内部网站上的信息这么难？

很多公司内网的维护都是由秘书或者行政人员进行的，更新自己的联络方式，也要走一个复杂的、缓慢的、望而生畏的流程。最终导致文档的过时，文档的腐烂。

引入群英汇知识管理平台，可以解决这个问题。因为网页内容的维护，授权用户都可以进行，甚至每个登录用户都能够修改。页面修改的门槛降低了，内容的时效性自然增强了。害怕内容被改坏？因为维基内置版本控制，可以找回任何一次的修改。

3.5.3.3   谁的 IP 又和我的冲突了？

这样的抱怨在公司中屡见不鲜。并非团队的人太多了，超出网段内IP地址的容量，而是限制需要使用 IP 地址的地方太多：虚拟机，无线网络，...

也许 DHCP 是一个解决方案，但是DHCP 有时候在设计固定IP地址分配时，管理负担太重了。 为什么不用维基页面建立分配规则呢？在维基当中创建一个关于IP地址分配的SOP（标准作业流程/规范），每个人在需要 IP 地址的时候，更新这个列表，就可以让类似的抱怨减少甚至消失。

3.5.3.4   研发制定的代码规范，很少有人看，更不要说参照执行了，为什么？

很多公司的代码规范往往使用 Word 写成，常常数年也不更新一次，用过时的，有待商榷的，或者不完整的代码规范来要求开发人员，不被遗忘才怪。

引入群英汇知识管理平台，在维基的框架下建立代码规范，并在规范中适当的嵌入犯规的代码，相信不久一份生动的活的代码规范就此诞生。

3.6.2.1   Subversion 的帐号和口令管理，是用户和管理员都头痛的问题

下面的问题时时在搔扰着 Subversion 的用户：

• 情景一：用户抱怨，太多的密码要记，又多了SVN的用户名和密码！
• 情景二：口令太多，干脆起个最简单的...
• 情景三：我忘记口令了，如何找回？还是要麻烦管理员？
• 情景四：管理员分配的口令太难记了，我要修改难道要告诉管理员我的新口令？

群英汇的解决方案：将 Subversion 和集中管理平台整合。

3.6.2.2   分支多了，授权成了管理员头痛的问题

对于商业软件开发，代码库往往需要精细的授权。Subversion 因为独特（或者说有缺陷）的分支方式，需要对每个分支单独授权。当一个代码库分支众多时，授权成了管理员最头痛的问题。

• 事实一：SVN的分支和里程碑是以目录复制的方式实现的。
• 事实二：SVN的目录授权设置在单独的配置文件中。
• 事实三：对于主线（trunk）目录的授权，如果不一一的为每个分支、每个里程碑单独设置，实为安全漏洞！
  • /branches/1.x/
  • /branches/2.x/
  • /tags/1.0.1/
  • /tags/1.0.2/
  • ...

群英汇的解决方案：为 Subversion 增加泛路径授权功能。即：可以在授权路径中加入通配符

例如：

• /branches/*/src/敏感模块/
• /tags/**/敏感模块/

3.6.2.3   Subversion 的授权文件修改太容易出错！

管理员在进行 Subversion 授权的时候，经常会导致 Subversion 崩溃：

• 事实：SVN对授权的语法要求非常严格。任何语法错误都导致SVN服务器不能工作！

• 下面的配置文件有几处错误？

  [groups]
  admin = &admin, admin1, admin2
  group1 = @group2, user1
  group2 = user2, @group1
  
  [aliases]
  admin = jiangxin
  
  [/]
  @admin = rw
  
  [/trunk]
  $authenticated = rw
  
  [repos1:/]
  * =
  user1 =
  @group1 = r
  @admin = rw
  
  [repos1:/trunk/src]
  * =
  @group1 = rw
  @visiters = r
  

群英汇的解决方案：开发了 Subversion 图形管理后台，提供图形化授权和权限检查。

• 提供用户权限检查的页面

  

• 提供角色管理的界面

  

• 授权管理

  

3.6.2.4   版本库功能扩展

情景再现：

• 情景一：有的开发人员不喜欢写提交说明，且“屡教不改”，当配置了代码提交邮件通知后，大家都重视了。
• 情景二：通过邮件列表对代码进行讨论，代码书写的规范性变强了。

群英汇解决方案：通过钩子扩展Subverison 功能，例如增加代码提交的邮件通知，就可以解决以上问题。因为当开发人发现自己的代码提交差异和说明被广而告之的话，自然就会注意提交说明的写法以及编程规范。

群英汇的版本控制管理后台，还可以通过钩子实现更多的版本库功能扩展：

• CapCheckMergeInfo ：禁止低版本SVN客户端提交
• ReadonlySvnMirror ：只读SVN镜像
• CaseInsensitive ：客户端文件名大小写不敏感
• CommitLogCheck ：检查提交说明
• EolStyleCheck ：换行符风格检查
• EmailNotify ：邮件通知配置
• TracPostCommit ：与Trac整合
• AllowRevpropChange ：允许版本属性修改

图例：Subversion 功能扩展的管理界面：

3.7.2.1   无法量化项目进度，项目经理“底气不足”

没有明确的项目进展轮廓，项目经理难以制定里程碑，迭代开发，加大员工的积极性和自信心。

引入群英汇的项目管理平台，项目的需求和报告的bug尽在系统的管理之中，可依通过路线图视图查看当前项目的进展情况：还有哪些需求没有实现，哪些bug没有修复。有了这个功能，项目经理就可以有些地制定项目里程碑，使项目迭代有序地进展下去。同时还可以通过活动视图查看项目每天的进展情况，以及这些进展都是由哪些成员完成的。

3.7.2.2   开发和测试不协调，影响项目进度和度量

测试人员提交bug后不能及时得到处理，使测试工作陷入堵塞状态，从而也影响的产品的发布，使项目进展陷入焦灼状态。

引入群英汇的项目管理平台，可以有效解决开发和测试脱节的问题。测试人员发现bug后，可以登录到redmine提交bug，同时bug的指派者将收到一封提醒邮件，使消息及时性得以实现。同时所有的这些bug也会在路线图中显示，一旦这些bug影响的项目的进度，可想而知，解决这些bug就成为了势在必行的事情了。

3.7.2.3   需求杂乱无章，开发无从下手

太多的需求糅杂在一起，没有一个清晰的分类，使开发人员无从下手。

引入群英汇项目管理平台，系统提供了问题分类的功能，同时提供了处理相关问题的几种策略：关联，重复与，阻挡等，可以大大简化工作流的处理。另外，系统还提供了可供定制的过滤器功能，大大方便用户查找需求和bug。

3.7.2.4   团队缺少一个沟通平台，配合不默契

团队之间以及团队内部缺少一个讨论的平台，成员之间不能有效互动，工作效率及其低下。另外，一些经常遇到的问题，项目核心成员一遍又一遍的给新手解说，太浪费核心成员的精力了，有没有一个一劳永逸的方法？

群英汇项目管理平台可以为每一个项目配置一个讨论区，项目成员可以自行建立不同话题的讨论区。这样，项目核心成员可以将常见问题FAQ写成贴子发到讨论区，供新手学习，一劳永逸。同时由这么一个团队的讨论平台，项目成员之间的交流也增多了，工作效率也将大大提高。

3.7.2.5   缺陷发现过晚，加大了项目的风险和成本

众所周知，项目中bug发现的越晚，修复的难度和成本都将会提高。那么有没有一种途径可以更早地暴露bug呢？

群英汇项目管理平台的代码评审功能可以很好地解决这个问题，它为尽早发现bug提供了一个很好的切入点。可以针对每一次代码提交建立评审任务，相关人员收到邮件通知后，对代码追行进行评审，这样可以在代码级别上控制软件的质量，大大减小了项目的风险。

3.8.2.1   公司已经成立了测试部，但客户负面反馈依然不断

以前客户反应我们公司的产品bug多，系统老崩溃。于是公司成立了测试部，开展测试活动，希望测试人员发现bug，而不是让用户发现，从而将bug扼杀在襁褓之中。结果却是测试人员发现的bug还没客户发现的多。

群英汇测试管理系统专门用于进行测试过程的管理，它可以将测试过程从测试需求，测试设计，到测试执行完整地管理起来。同时还提供了好多测试结果的统计和分析，使我们能够有效地开始测试工作和分析测试结果。

3.8.2.2   测试用例繁多，查找犹如大海捞针

公司的测试资产全部是纸质文档，测试工作枯燥无味，而且大量的测试用例在查找时犹如大海捞针，浪费青春。

群英汇测试管理系统可以很好地管理测试用到的所有资产，同时省去了纸质的文档，使测试工作脱离了枯燥，实现了信息化。另外，提供了大量过滤器用于进行测试资产的查找，从而是测试工作高效、有序。

3.8.2.3   缺陷跟踪不健全，开发、测试脱节

测试人员提交的bug长时间没有回应，同时bug的状态也混乱不清，造成测试陷入堵塞状态。

群英汇测试管理系统实现了与群英汇项目管理平台的无缝整合，同时支持项目管理平台的多项目，可以准确跳转到项目管理平台的具体项目中报告bug，而且这些bug将会与相关的测试用例建立关联，完美解决了bug跟踪混乱的局面。

3.8.2.4   缺乏有效的测试结果分析和报告

测试需求的覆盖度模糊不清，项目中一些重要的模块没有大量测试，使项目的潜在风险大大增加。

群英汇测试管理系统提供了精确和全面的测试需求覆盖度分析以及测试用例的执行状态记录。另外，提供了直观、丰富的测试结果图表分析，使测试的结果一目了然，项目的质量尽在心中！