标签：style blog http os 使用 strong 数据 ar 2014
售前扔过来一单后，一个项目就算开始了，开始的主要工作就是和他们做需求调研。做一些PPT，带上笔，本子还有各种参考，客户的各种文档，各种表格接踵而至，这是比较耗精力的段时间，当然也是最有激情的一段时间，常常在这时会激发我无限的想象，天马行空的跟客户探讨他们的需求
，这个时候最能表现出我过往无数项目阅历的时刻了，我觉得我的表现欲就是在这个时候养成的
。不管再怎么天马行空，也要看着钱，人，时间确定需求，最后定下一份双方可以接受的《需求概要说明书》。
拿到一份需求概要后，我会大致阅读里面的大的需求点，大致阅读完后，接着我会创建几个用例图，然后详细阅读每一个需求点，完善每份用例图，在这个过程中一般需要多次与客户进行需求沟通和确认，有时也需要状态图的辅助。一般的需求基本上两三天左右就可以将所有用例图都画完，有些需求比较复杂的话，就需要跑到客户那里，每一点进行沟通来完成用例图，我的经验中最长的在一周左右。定完后就要花两三天时间写一份《详细需求说明书》。
在画用例图跟客户进行沟通时，有时客户并不理解我所表达的内容时，我会使用Axure做一些原型帮助沟通，在整个用例的沟通过程中，会发现很多需求不明确，逻辑冲突，实现与客户期望不符的情况，这些都是非常常见的，用例和原型可以帮助我在项目的初期就发现这些风险，有些可以立刻想到解决方案，有些则会跟团队进行头脑风暴，有些需要跟客户沟通做出妥协，遇到每种情况时，我都有一套自己的办法，这行干久了，这方面的经验还是要牢靠的，这个时期能搞定的事情往往对于未来开发过程会有着实的帮助。
大部分情况下是先完成用例图，用例完成后我会跟测试人员过一遍，然后测试人员就根据这份用例去写测试用例了，一般我会留三天到一周的时间给测试写测试用例，具体要看系统的复杂度。
趁这段时间，我会补齐所有的原型设计，画原型就象是画漫画（我20岁前就一直画漫画），要考虑每页布局，每格画面和每个场景。用Axure画完整个系统后，我就会直接发布到Axure在线上，然后把网址发给客户，跑过去跟他再进行每个操作，每个界面的确认。一般这个时间比较短（做的原型也比较粗糙，最初做原型时非常细致，客户误以为系统已经做好了，还引起了一些小误会，囧）。
跟客户沟通完后就完成了最初的系统需求阶段，我会招集团队将它们分为1+1+1或2+1+1的小组，即1个开发人员或2个开发人员+1个测试+1个前端，我将原型设计和用例给团队成员进行讲解和演示，在这个过程中我会用Axure原型与前端人员进行界面方面的交流，在这个过程中我有时会使用状态图来与我的团队理解每个业务流程的状态变化，使用序列图来确定各类之间的交互方式和时机，在讲解完毕后，基本都可以确定下来前端和后端交换数据的DataService接口协议和VO数据结构等细节。
前端我们一般使用Jquery,Extjs或Angular，主要是看项目是互联网应用还是传统企业应用，互联网应用一直都是使用JQUERY和众多插件，而EXTJS是企业应用的首选，最近几个项目在尝试使用Angular，但是困难重重，主要是还是前端设计思想上不容易转变。做前端的，软件工程学的确实不怎么地…
在确定下所有细节后，我开始创建工作项，由于我们一直以为都使用TFS，所以往往就是加入积压工作项，将项目切为好区域和迭代后将相应的功能归进去，划好优先级指派给相应的人员去完成。
项目初级时需要使用到组件图进行系统组件规划，在这个过程中我发现了有些组件是可以重用的，如SSO，用户中心，权限控制，授权，日志还有一些界面，在几年的项目经历中，我将这些系统设计为组件，将系统设计成为松耦合的系统，各系统间使用API进行交互，统一登陆，统一用户已经成为最普通最必须的场景，每个系统之间耦合时往往会保存冗余数据在应用系统中，这也使得每个组件可以独立进行升级或技术更迭。
初期时我使用的是瀑布开发，全部都投入进去开发，对于一些我们比较熟悉的业务交付还是非常快的，客户也比较满意。但是自从使用工作流做复杂的业务系统后，恶梦就开始了，由于我们对业务系统不熟悉，摸着石头过河，发现开发完后很多地方数据库结构和程序设计的非常有问题，但是调整已晚，程序在流程执行中，处理某些环节的逻辑和退回，退回任意步骤执行一些业务逻辑来说，
悲剧了，时常出现莫名其妙的错误。统计报表的数据也是比较混乱，因为各种取值计算公式取值经历了N次需求变更，导致基本找不到哪里的数据取错了。有的是测试环境没问题但是生产环境中有问题。
后来我们开始实践敏捷开发，我将整个系统分成若干组件，再将功能点的先后顺序进行排列，由于每次我都在前期每大量的设计，所以这个环节的切换是比较顺畅的，每个功能组被我切分成一周最多两周就可以完成的功能，为了控制大家的进度和质量，也像模像样的要求开发人员每天早上半小时写小纸条，写好一天的计划，下班前进行回顾，在代码方面强制必须写单元测试。开始有些人极不适应，有些人扬言要离职，我给他们说承诺给我一个月，一个月后看结果再批他们的离职申请，一个月后项目的质量奇迹般的上来了，大家也很有激情，由于定期跟客户进行版本确认，问题往往很快得到发现和纠正，后来的项目中我们都不约而同的选择了敏捷。现在大家的领域设计的能力也得到了提升。
客户验收的成功率有时还是要靠嘴来说，也要看客户的心情，有时心情一好签个字就过了，有时心情不好就麻烦了，所以找客户验收前看看黄历还是有必要滴
。
开发过程中锁定主线，创建分支是每个迭代必不可少的部分，分支的数量根据小组个数不同而定，其本上是N+1即N个小组就创建N个分支，让每个小组做自己的事情，那加的1是什么？就是上一个版本的Hotfix，如果客户发现故障需要紧急处理时，就需要在hotfix这个版本上进行处理，紧急投产（被客户报故障12小时不处理是要扣很多很多钱滴 
!），最后合并时也要先合并hotfix，然后再合并其它小组的版本，这个过程通常跟大家一起来参与，一般两小时内就可以搞定，合完后打个标签即得到一份新的待发布版本的代码。
我们没有使用自动化布署到生产环境，但是有自动化布署到测试环境，因为生产环境可不是让我们随便布署的，在每个版本发布前一周，我都会发布一个全量的程序，同时与上一个版本的全量用Beyond Compare进行比较，拿到一份增量，然后将数据库的变更也生成一份增量的脚本，由于数据库我一直使用RedGate Sql Source Control结合TFS进行管理，所以生成增量非常的容易，直接使用SQL Compare从Head版本到上一次发布的版本进行比较即可生成优质的SQL变更脚本，还有Marger进来的SQL。最后将增量+全量+脚本打个包，写一份投产文档和影响范围后放到客户指定的位置，数据中心运营部会有人自动来取滴。
一周后的星期六，去到客户现场，指导运营人员将包投到准生产上，验证系统，没问题后就可以投到生产上了。这一天基本上是最漫长的一天，各种投产时的异常情况处理，熬夜通宵那是常有的事儿。终于顺利回家睡觉后下周一还必须要找人在现场支持，每一次上线都是一颗石子丢到水里，有时只是泛起一些涟漪，有时就是扑通溅起水花，那几万人的操作压力，在10台前端，10台缓存，2台DB也挺累的，他们手动操作的覆盖率经常可以达到我们单元测试覆盖率和集成测试覆盖率之上，今天大家都在等待着，成功就聚餐
，故障就加班
。哈哈！
转眼三年过去了，有开心也有烦恼，有快乐也有失意，但是学到了很多东西，也积累很多实践，这些体验非常有趣。接下来准备和几个小伙伴一起做公司，体验更多的东西，售前，财务、市场，推广，服务这些都想体验一下，
学海无崖苦做舟，路漫漫而修远，我还要继续求索。
标签：style blog http os 使用 strong 数据 ar 2014
原文地址：http://www.cnblogs.com/biyusoft/p/3931804.html
