Post by "Zoe", 01-22-2007, 17:32
-----------------------------------------------------
虽然我工作过的地方不多，但是感觉上问题比较相似，包括以下几个方面：
(一) 项目人员配备不齐：主要指没有专职的测试人员和配置管理人员。直接表现就是软件测试工作没有专人管理和执行；软件相关文档的编写无法保证。细节表现在：
1. 提交测试的项目，没有足够的（或者根本没有）项目相关说明文档。即使都是网站项目，规模不大也应该配备基本的项目文档（如需求规格说明书等）
2. 项目人员对于软件测试的认识不够全面，比如网站测试都只进行功能测试，而测试人员可能在完全不了解项目的情况下被通知进行测试，且没有留出足够的测试时间。
3. 测试由部分员工利用空闲时间完成，除了测试覆盖率不能保障外，发现的错误也不易被准确的记录下来，或者记录下来的错误也不能书面确认被修改，常常通过“口头传递”的方式提交错误和修改报告。导致的问题可能是：一些错误没有被发现、发现的错误没有被记录或者修改、修改以后不被回测而导致错误没有被及时关闭、测试文档不完整等。
4. 项目都没有基本的项目文档（如需求规格说明书，详细设计说明书，用户手册等），甚至很多项目只有代码，也有些可能代码都不齐全，还存在项目文档或者代码的版本混乱等问题。从这些项目的结果可以看出，项目执行时是没有专门人员负责编写和维护项目文档的，这种情况无论是对项目的开发、测试、发布、维护、升级或者在其他地方复用都会产生很大的负面影响。
(二) 对“ 文档化”的重视度不够：文档工作常常被认为是项目开发中优先级最低的，也可能根本不被列在项目计划中。常通过“口头表达”的方式来决定软件的功能或者直接告诉开发人员“做成这个样子”。这样带来的问题可能包括：
1. 只有在场的人知道详情，
2. 团队协作的概念在这里起不到任何作用，
3. 最后开发出来的系统与最先的想法差距很大，
4. 程序被改来改去始终无法确认。
5. 其他开发人员、测试人员、维护人员、甚至用户都将面对一个陌生的，没有任何参考资料的程序。
6. ……
(三) 项目计划常被更改：关于这方面我并不清楚是不是大部分项目都是这样，但是就我最近参与的两个项目来看，起初订立的项目计划时间一拖再拖，执行步骤常被变更，这样可以看到的直接影响就是：项目文档被忽略，测试时间被压缩，项目质量得不到保证，项目的控制者或者关注者不能准确知道项目的近况以及未来可能的情况。
(四) 项目多为外包或者“单干”项目，整体和团队意识不足：很少进行“开发团队”应该具备的活动，如定期会议和组员交流。
1. 我看到的一些外包项目，对于测试和文档的部分执行的比较弱：现在外包项目似乎是由执行项目的单位进行自己测试，然后由公司内部进行简单的测试的方式进行评审和检查，而对外包项目项目文档的要求似乎也没有统一标准，执行项目的单位按照自己的方式开发项目，最后提交结果。实际上，正因为是外包的项目，项目文档和测试工作应该是更被公司关注的方向。
2. 公司内部开发的项目，组成人员之间的联系并没有特别定义，人员职责定义并不明确。比如可以这样说：假如现在需要获取最新的数据库版本，那么找那个人员去获得并没有被定义出来，显然随便找个版本是不合理的。其实我认为作为项目开发团队的每个人，应该需要获得该项目的各组成部分当前的情况，还包括过程进展、变更以及技术上的如整体设计架构等信息。目前我看到的两个项目的感觉，项目组的会议很少，即使有也只是部分人员参加。项目周报、会议记录等进度文档都是在有点“半自动”的情况下被完成。（所谓半自动，就是在被催促或者想起来才写的情形）。
3. 这两种情况联系起来，可能会造成的一种情况：就是项目开发结束后，假如再需要该项目的相关信息，可能就不容易找到了。或者即使是参与该项目的人员也说不清楚一些信息，就会造成项目的可持续性缺失。
(五) 没有专人维护项目文档模板：目前公司目前的项目文档并不全面，一些文档模板混用（如测试分析报告和测试日志报告），模板内容定义不清晰（如《详细设计说明书》），没有将最需要获取的内容记录下来。而且项目文档的模板其实需要根据项目的情况进行相应的调整，文档模板如果设计的比较好，可以帮助项目组的成员更简便的完成项目文档，写出了的文档也具有更多的参考意义。因此一个专门维护模板的人员也是相当必要的
根据上面提出的几个方面，对比以往工作中的一些经验和我在实际工作中的想法，提出以下一些方面的意见：
首先想先说明一下我的立足点：我是从如何可以方便的工作，提高效率的角度来思考和改进一些工作方式。在以前我的工作中，曾经出现过项目文档过多造成项目组人员麻烦的事情，因此“项目过程和设计文档化”的思想也不能片面的走形式，包括测试在内的质量保证工作，其实是为了使项目开发进程更顺利更高效而实施的。
具体意见如下：
首先是人员配备的问题：
1. 项目中应该指定专门的职责，负责管理项目中有关工件（一般包括文档和代码）收集以及项目开发相关的资料的发布工作（也就是配置管理人员）。
a) 并不需要某个人只做这一件事情，但是一定要定义具体的获取方法：如何时，从何人处，获取何工件。也就是说，将工件获取工作程序化，让参与项目的每个人都知道，每个项目成果都是需要被保留下来的。
b) 由该人员负责从相应人员处定时或者按计划的取得工件（当然还包括版本控制的内容在内）
c) 所有项目的公开信息，都从该人员处获得：比如开发人员想获得最新的需求文档，那么可以很容易知道从哪里可以得到。
2. 项目中应该定义专门的职责，负责项目内部与组员沟通、团队会议、协作、任务分配和跟踪等工作，可以说就是项目的协调人。
a) 这个职责也不需要专门的人来担任，只是需要明确由谁来做这些事情，包括项目进度的跟踪在内的项目现状，都需要被准备的记录和定义下来，并且应该将这些信息发布给参与项目的每个人
b) 在现有工作基础上，进行频繁项目团队会议可能不太现实，每个人的时间好像都很紧迫，但是交流和讨论对于项目开发来说十分重要，我参与的项目即使开会了，也是没有主题，没有会议记录，或者人员参与不全。似乎是想起来开会就开个会。
i. 其实项目例会应该不会花去太长的时间，大家说说自己的工作进程，分配一下下周（或下个阶段）的任务和目标，然后说说自己工作遇到的问题和想法。这些内容对于项目进度控制和质量控制以及问题解决都是十分有好处的。大家聚在一起说情况，总比一个一个去问效率要高一些吧。
ii. 我建议有关项目的例会、会议内容、会议记录规范等相关工作的过程应该写入项目计划，并强制执行。
3. 项目中应该指定专门的职责负责进行测试的工作，应该是专职的测试人员。从目前公司人员配备的情况看，这似乎不太可能，但是我想提出一个办法，可以暂时满足目前我手上两个项目的测试，但是如果开发的项目比较多，就建议增加专职测试人员。
a) 目前公司采用的测试都是让部分员工利用空闲时间“试用”一下产品，开发人员自己可能在产品成型以后进行一些“自测”，如前面所述，这样的测试工作并不是很有保证的。
b) 为了暂时缓解这种情况，我的建议是，由专门的人员书写测试用例（应该是十分全面的用例，而不是只执行正确步骤的用例），然后分发给可以进行测试的员工，按照以往的方式进行测试，并按提供的文档填写测试结果，并将测试结果文档提交给指定的人进行汇总。
c) 与原来大家盲目点点选选测试相比，这样可以提高测试覆盖率，增加测试可靠性。而且因为具有统一的文档格式，返回的文件可以作为测试文档被保存，该文档的模板应该包含包括回测信息在内的各项内容。该文档将被提交给对应的开发人员进行错误修改，然后进行回测，可以比较有效的保证修复的错误被关闭
d) 如果在一个项目中配备一个专门的测试人员，那么这个人员应该在需求分析阶段就参与到项目中，并在此阶段对项目文档进行静态测试。该人员可以兼职担任前面提到的1，2两个职责，但不建议一个测试人员同时参与多个同时进行的项目。
有关项目文档的建议：
如前面所述，合理的项目文档可以帮助项目开发过程更顺利更高效，对于项目开发成果的保存和再利用都提供有效的保证，有关项目文档化的建议如下：
1. 首先建立全面的文档定义和规则：
a) 项目文档的模板设计
b) 填写规则的描述
c) 根据项目特点，确定必须填写的文档
d) 通过评审确定并切实执行
2. 专人管理文档模板：包括模板发放、维护、更新和变更，需要定义该人员职责。
3. 应该在项目启动前明确项目文档的意义：感觉上目前公司的项目好像只是因为要评审或者检查才会重视一些相关的文档，比如详细设计说明书好象是不需要经过评审的，但这个文档却是项目开发过程中比较重要的参考内容，因此明确项目需要提交的文档和文档的质量非常重要。
有关项目过程的建议：
项目过程控制方面，这部分的情况我只能对项目过程可见性的问题提出一下自己的想法，主要还是和前面说的两个：人员配备和文档管理的方面相关。
项目开发过程中的很多活动，比如周会、例会、项目阶段通报等详细的事情，都应该被仔细的定义到项目计划或者其他文档中，有参照性才会执行的顺利，现在好像很多事情都是大家想起来才做，没有真正成为项目的规范执行过程，而起也没有专人管理和监督。
具体的细则是需要通过评审、会议或者讨论的方式订立的。
原文来自：http://blog.csdn.net/nicehope33/archive/2007/01/22/1489828.aspx |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图