手机网络竞拍软件开发纪实-优快云博客

首选，我要说明的是我没有做过android，到目前为止可能连配置开发环境都是问题，开发方面就是hello word，。我感觉我们开发组内手机设计就一个拿得出手。但是在这种情况下我要去做一个手机项目的管理；

简单描述一下这个项目的背景：由于客户要求我们开发一个手机网络竞拍的软件，简单过程就是在网站后台专门的用户把要拍卖的商品发布到网络上，（不方面说明具体的拍卖的什么商品），这个商品有很多属性（最多的时候400项左右，但是绝大多数就是有那么几十项），单纯的必填项就不少，这些做一下约束就可以；下一步就是管理员审核填入的商品属性是不是正确，是不是符合实际情况；再下一步就是把审核通过的商品发布到手机端进行网络竞拍，（竞拍过程在手机端实现）；最后，管理竞拍结果，拍卖商品给谁，或是不符合竞拍底价流拍。就是就是这么简单。

下面是我们的开发流程，以及出现的问题，希望我们以后在开发这样的项目时别再出现这样的问题，下面我就从以下几个方面来说明我们的整个开发流程。首先，需求分析，技术讨论，开发过程，需求变更和测试，后续问题。

第一，需求分析；我们借这个项目大概是201111月初，在需求分析的时候这个项目小组的人全体出动，这样是为了我们能更精确的了解客户的需求以及每个人都可以进行思考拿出自己的看法，方便我们对客户需求更加充分，想的更加全面；其实这个需求客户完全没有自己的注意，只告诉我们我们要把***商务化，也就是网络实现我们的交易模式；把实际操作流程和模式告诉我们一遍，我们只能一直半解的了解了这些信息。经过几个小时的讨论，我们也说出了我们自己的想法，最后给出用户的结论是我们回去研究这个网络模拟过程，再看看别的商家有没有类似的实现，我们也好借鉴，我们的重中之重是必须设计的系统满足他们的实际操作流程，把他们的实际过程网络电子化。接下来我们整理需求的整理需求，调查资料的调查资料，就一周时间必须给对方一个需求设计文档，根据这个需求满足客户的整个流程，为了保险起见我们把所有的流程整理成页面，页面画到文档里；为了更加保险我们把这些页面用简单的工具设计出来，所有的页面可以根据流程自由的流转。从用户登录到系统默认主页面，再到点击什么按钮连接到什么功能界面，我们经过一周工作后去和客户进行下一步的沟通，把我们所做的工作展现给客户，演示我们的整个流程，这些客户没有什么异议。我感觉这个时候客户心目中都不知道这些怎么回事，只知道模拟他们的实际操作流程一直就OK，大部分和对方讨论的问题是需要哪些字段展示，很有前面说过有很多项不可能全部展示，经过几轮的讨论后我们把这些细节问题定下来，这样我们的需求分析完成，形成简单的需求分析文档。时间马上就11月低了，接下来制定我们的开发计划，这时候客户告诉我们我们要在2012年的元月5号上线，看看有没有什么问题。靠，问题当然有了就是时间不够吗，客户是上帝没有办法我们答应了元月15号上线。同对方讨论开发计划，他们好像知道那么一点设计，给我们说按三步走，第一要没有数据的demo，设计环境中满足流程；第二把我们的实际数据放到demo中，初步版本；第三添加美工设计图，完成上线。我一听差点怒了，我们开发还是你们开发，自我好对方PK后，前面两步合成一步（12月底完成），后面美工和测试同时进行。就这样算是说定了，把开发计划订到15号，完成上线。我们在需求分析和制定开发计划的同时开始考虑技术难点，靠我们的经验和心目中的设计流程讨论那里可能是我们的难点实现并进行研究，这个时候都12月初了，接下来是我们的开发；

第二，开发；由于前期技术实现的调研比较充分，对困难也有了相当充足的准备，在这一行业里由于前期的工作经验积累不少，所以开发起来比较顺利，基本上根据计划按着开发计划服务器管理端和手机客户端同时进行，由于时间比较紧，开发时间短，这样对我们的系统设计有一定的影响，比如数据库的设计，要是时间充足的话肯定可以设计出一个更加优化的数据库来，为了节省时间我们的设计可能是比较麻烦但是代码和设计上是最省时间的，这也好归功于我们以前对这一行业设计的经验。手机端也根据我们的计划紧张的进行，由于这方面的经验少，设计也没有考虑那么多，所以在后期我们也到了手机的弊端（耗电和网络流量）。紧张的工作是大家基本上没有休息，每周只休息一天，可能晚上还要加班什么的，到了12月底，我们带数据的系统流程总算成型了，虽然有很多地方要优化，不过毕竟成型了，服务器端和客户端可以配合着走通整个的设计流程。接下来是需求变更和测试，这方面的问题几乎给我们的设计带来灾难，亏我发现的及时否则我们会陷入很被动的境况中。

第三，需求变更和测试；由于时间问题，当我们的系统流程完成之后，把一些具体细节和需求对了一遍，认为设计还算合理；于是下面我们把两步的工作：美工设计和测试并为一步来做。这是把我们设计的流程布置到客户的服务器端，对方在服务器端下载客户端安装到手机上，可以完成客户端的工作，于是我们的客户和我们的测试人员同时进行测试，我们自己的测试人员真的不敢恭维，大部分问题都是对方不专业的测试人员测试出来的。（呵呵，这样看起来我们自己的测试人员可能更不专业）。这个时候我烦了一个错误，认为我们的流程基本设计差不多了，往下的不是问题了，于是我忙别的去了，每天听到我们的编码与客户讨论的不易热乎，想到这样不错和对方充分讨论把问题暴露到上线以前总比以后强，于是我忙别的去了。有一天我们的设计人员说我们的时间恐怕不够了，我纳闷为什么我们都设计基本差不多了，就剩后期的美工和细化了为什么两周时间还不行，赶紧讨论，结果我们编码人员说，我们测试这一天对方给我们提出无数的更改，让他们测试每看到一个问题，就会给我们代码人员说，这样不行了，和我们当初想的不一样，那样不行了，当初我们需求的时候没有沟通到位，我们的人员态度还真不错，对方每提一个问题都按着对方的要求给对方改，结果一天对方提出了一个和我们设计违背的问题，和我们底层构成冲突该不下去了，这是才给我说，我知道这些问题后没有说什么，立刻给对方发了一封邮件关于需求变更的要求：1.不要每发现一个问题提一次，经过一段时间，综合到一起给我们提出；2.就是把问题根据紧急情况分成等级；3.所有的问题都先给我提，我在讨论把问题的难度以及重要性过一遍再给出修改计划。并且立刻给对方打了电话要对方终止这样的做法，否则这样对我们是灾难，我强调以后对方意识到这一点问题的严重性，好了我把他们提出的问题总汇起来，根据难度以及重要性分别对某个问题恢复修改计划，把一些不管紧要的问题统统滤掉，把比较难而又必须改的找出一种折中方案可以简单设计完成功能又可以满足要求，这样我们的测试和bug修复走上正轨，我们看到曙光。接下来就是上线了，上线后我们的问题更加麻烦。

第四，上线；