蹒跚前进中的项目-Vol 1.开发模型及项目管理

 

• 前言

 

断断续续工作块有二十四个月，可以说刚入门了。经历了三四个完整的项目流程：做过开发，做过调研，做过测试管理，做过咨询，做过维护。工作很杂所以看到的东西也不少。

工作实践中，不乏很多问题，引发很多思考。我将逐步从开发模型，管理方面，编码方面，测试进度、上线准备以及其他相关小的方面，自己的相关想法和感受记录下来，愿与君探讨亦留作回顾。

希望在将来的某一天可以回过头来，重新总结和点评这些事儿。文中有许多地方还是很篇虚，可能是因为工作经验的不足吧，希望各位前辈可以指出。

 

• 软件工程模型及项目管理

在没毕业的时候，一直认为：一个成功的项目是因为有一个好的技术模型、好的架构和好的人员。等到今天我才明白，其实成功的项目大部分都是因为有好的开发模型、可以监测进度预估分享，激励成员等一系列管理上的手段，而非技术上有多么的出彩。

传统的瀑布模型

记得我毕业那年面试，在陆家嘴的某场面试里曾经和面试官讨论过以下的问题：瀑布模型虽然很土，并且无法预估风险、不能承受较大的改动、任何错误都会集中在较后的工序中体现出来，例如在需求阶段对某个需求点认知比较模糊，因为缺少必要的沟通和修改，导致一直到交付才发现这个问题。但是日本人对瀑布模型加以改进成为V字模型，某个必要的设计工序都会有一个对应的测试工序，而不是瀑布模型一样，只有一个集成的测试工序（换句话说，将这个工序拆分成各细更有针对性的测试周期了）。所以可以说明一个问题，其实在软件开发中，编码和设计的不足大部分是可以靠测试把关，而国内大多数项目组都不看中测试，让人觉得很纳闷……

 

转到我的工作中，我的项目组使用的开发模型应该属于增强型的瀑布模型：

需求收集--需求分析--概要设计--详细设计--编码---测试---上线--维护；并且在概要设计和详细设计阶段中均有评审阶段；下面我讲逐一介绍一下：

• 需求收集：

输入：客户需求

输出：需求收集文档-通常为RS（需求说明书）

与客户确认基本的需求，并给出大约的工期作为销售价格的一个评估参数；

• 需求分析：

输入：需求收集阶段的RS、客户需求、现在系统文档；

输出：功能说明书（FS）

结合现有的工件或系统或构建，进行相应的需求拆分，归类，给出一个更更准确的工期参数，作为销售价格的一个评估参数；

• 概要设计：

输入：FS，RS文档

输出：概要设计说明书、数据库设计文档、画面说明书

根据不同德需求点，设计每个业务处理流程，颗粒大写，多半是根据用户的一次操作来分割的，比如一个录入、一次审核以及之后的系统自动处理流程之类，通常在这个阶段已经把前后台的处理接口定下来了，数据库的表机构也定下来了，当然画面也定下来了（不只是画面原型）

• 详细设计

输入：概要设计说明书、数据库设计文档、画面说明说

输出：详细设计说明书

根据输入工件书写每个处理流程的具体操作，主要包括:其他系统析构接口，必要的判断分支、数据库表操作、也可能把代码都贴了进来……

应对变化的策略是，如果在编码阶段发现明显的需求修改，则直接按照正确的理解作，而通常这个动作不会影响需求分析的

• 编码

输入：概要设计说明书、详细设计说明书、数据库文档、画面说明书

输出：应用程序

开发工作大同小异，后台业务处理的开发主要是数据库和业务操作参考的是详细设计说明说和数据库文档；而UI团队依靠之前概要设计中的接口参数和画面说明书进行开发。

• 测试

输入：几乎全部文档

输出：测试报告（后来我提议的……之前几乎是靠EXCEL来记录和分派）

测试工作并不出彩……几乎是没有的，现在有所改进了……

• 我的感受
  1. 对于开发人员的验收测试：纵观我们这个事业部，可能是我们项目组独有的工序，既在一个bug修改后，会有一个专职人员对该bug重新进行验收测试，以保证单个模块是通过的，当然这些测试是没有什么文档和计划的， 完全是依赖测试人员的责任心和经验。
  2. 关于评审：通常是由PM主持，而且也会邀请其他经验丰富的同事评审。如果没有这些条件则是集体评审。我觉得评审是个好的方法，但是过度的依靠经验毕竟是不可取，因为没有必要的评审参考的依据，今天评审说这个能做，过了几天到了开发了发现评审的结果本身是由问题的，当然这个是无法避免的吧？而集体评审的投入和产出比更是低的可怜……花在评审的时间可能就要占据整个设计阶段的15%……
  3. 关于测试：没有必要的参考依据的测试时漫无目的和低效率的。而只是依靠运气和测试人员的经验进行的测试计划更是让人觉得很愚蠢……我依旧坚信，测试才是检验程序是否符合需求的最有利的保障。而高优先级用例的覆盖率和通过率是评估一个系统稳定性最好的参数！而不是今天改了10个BUG，测试了一下，之后10天没有发现新的bug，所以得出系统更加稳定了，这样自欺欺人的逻辑。
  4. 需求分析，概要设计，详细分析的关联：我一直很奇怪为什么需求分析的时候很多东西根本没有彻底弄明白，或者说弄明白的成本太高，就通过FS文档发布了。然后转交概要设计人员进行设计，而这大部分设计人员，也不会把需求弄的彻底明白的情况下，开始加上自己的想象，画出了画面，写出了流程（流程多半是没问题的，因为有需求文档作为保障），写出了数据库设计。其实这些我觉得很正常，但是为什么前后台模块的接口也会在这个阶段设计出来，并且还定型发布给前台的团队进行开发。而详细设计阶段，可以说根本只是后台团队的文档，和UI团队一毛钱关系也没，这样导致了大量的在详细设阶段发现，某个功能的输入参数不够需要调整接口，某个输出字段太少需要调整，如果这些问题是在编码阶段发生的，通常还不会去更新文档……挖了一个巨大的黑洞给后人。在我学习Java时，我记得在某本书上看到过这样一句话（可能是《重构》：“别太早的发布接口，除非你考虑得非常成熟！”所以我觉得这个接口设计应该挪到详细设计中，并且需要进行足够必要的与UI团队的沟通！！
  5. 需求分析阶段：做的大量工作，可能是弄清客户的本意，而每个需求点短短500字真的可以表达出客户隐藏的一些需求嘛？可以通过这些字传达并没有参与客户讨论的人员知晓嘛？很多领域（domain）知识、用词也没有特地去整理，导致新加入的实习生看到系统界面一脸茫然……而且需求分析阶段，PM把预测影响的程度（即工期）放在第一位，而理解客户想要的以及客户所应用的领域知识放在最后一位。这让我十分困惑？难道需求分析只是告诉用户“这个可以有，这个真没有？”
  6. 应对需求变化：大部分需求变化都是体现在UAT阶段的，客户发现这并不是我想要的，或者说客户在没看到系统前根本不知道他想要什么（我觉得这个很正常），从而更修或者说是细化了需求。如果这个改动不大，只是改改几行代码，调整一下UI布局，通常被当成一个BUG一样处理，而通常不会修改和维护任何文档……如果比较大，则会提议放入下一个大版本，或者作为另外一个项目进行改进。但是把问题拖到下个版本就不是问题的喽？
  7. 工具的使用：在我没有进这个项目前，这个团队曾经自己开发过一个小工具进行bug管理。在第一个项目上线后，我向PM介绍了JIRA从而，项目组踏上了使用专业管理工具进行项目管理的时代。而数据库文档设计，还是依靠word。进度统计依旧是excel，其他文档不是excel就是word。管理这些文档又有一个excel。虽然会有牛人反驳我说excel和word用的好可以出神入化，但是我想如果word和excel用的出神入化需要花多少精力？而且书写文档通常不是最费时间的，管理和维护才是最费时间的！所以我还会继续寻找适合我们项目组的工具逐步淘汰手工维护工具。比如这次在我们临时的测试小组（很感谢那两位负责的实习生）努力下，PM接受了他之前质疑很久的Testlink，因为另外一个项目也用，效果并不好。好的工具需要的使用，更需要一个好的团队进行支持！再次我再次感谢大侠姐帮我承担了很多测试案例分析和编写，让我有时间可以去部署和安排这一次的测试计划，而我们的成功是对我们最好的肯定！
  8. 绩效考核：这个词一直听说，但是感觉和我浑身没关系……我们加班基本属于是没工资的（如果那10多块钱也能叫加班工资）但是会统计你的加班时间，项目组内部福利是折扣4倍抵扣迟到和调休（双休日的加班是乘以4倍计算的，就是一毕一调休），而一个月迟到次数大过3次就是6倍的加班时间抵扣，超过则上报给人事部扣工资。这个应该是惩。而奖没说过一周加班超过多少小时也乘一个更大的系数，我曾经会为了多做点事情主动加班，而现在的加班机制，让我觉得不公平，甚至气愤……如果一个团队光惩不奖，就会有成员和我一个心态，如果我哪天做了PM我一定会重新来读一遍我今天的心态。

零零散散说了这么多，感觉这样的开发诚然很没有效率，但是纵观整个事业部，我项目竟然还处于比价好的管理氛围中。

今天先写到这里，这次是将整个周期都写了出来，以后会挑一个两个点单独详细的写。

如果各位前辈有什么指教和教诲或者批评都请指出哦！

评论

4 楼 coral0212 2010-05-06  

好贴,已收藏,对以后有借鉴作用,感谢楼主,

3 楼 coral0212 2010-05-06  

楼主看起来是个测试经理的角色,对项目管理理解的比较透彻,不过有些问题还是没有突出的暴露出来,比这些更加让人头痛的问题

2 楼 akiraray 2010-04-11  

g81997842 写道

兄弟，你是担任什么角色的？

打杂的

1 楼 g81997842 2010-04-11  

兄弟，你是担任什么角色的？