某零售项目实践---项目

一、项目简介

零售改造项目是个长周期的一个项目，第一个上线版本计划完成需1年时间；内部开发测试，使用迭代式开发。

二、项目过程

2.1、项目前

项目动员，必须的。而后，项目组员分工、人员安排、总体计划等一一落实到位。

2.1.1、需求调研

具体是，项目前期，需求各区域调用阶段，需求人员奔赴各地的同时；搜集上来的人员已经开始根据实际情况，分优先级排期实现。当时，也曾担心；为什么这个阶段没有安排技术人员去客户现场，便于做系统需求分析及后续设计？这就牵涉到，具体的业务系统的数据模型设计的问题。不清楚这个担心是否多余。但从项目收尾总体看，领导对业务的把握非常准确，每个阶段产出什么，什么时间开始某个需求的调研，什么时间开始安排测试，等等。

2.2、开发测试

2.2.1、产品需求

根据产品需求文档或是wiki，开发人员直接对接需求人员，每一小组总能有具体的需求负责人，这个负责人承接调研的需求，并汇总安排优先级并负责讲解需求。有时，这个人员也会直接出差到各地搜集实际业务情况，并在内部与领导、业务熟手一起讨论，只有经过这些过滤下的需求，才形成开发人员面对的需求。

2.2.2、开发

开发，建模；开发，遇到一些共性问题，比如系统间数据同步，异步处理等需架构团队提供支撑。说到这里，也有个问题。就是项目开发之前，这些业务系统已经分的非常明确，将一个零售系统分解成几个业务系统，每个业务系统各司其职。问题是，为什么这样分？这牵涉到架构系统分解，也许这直接出自领导们以往的系统经验，来自业务主体域。所以架构团队实际上对业务总体上需要来自上层业务架构的指导。后续一些非主体业务系统，更多的来自系统建设性的分析设计，比如，服务化的处理、异步处理、缓存使用、公共组件服务的开发等等。这需要技术架构的支撑，并且在个别场景上需要较为高度的抽象能力模型设计，特别是对多依赖，高并发这类公共的基础设施。

2.2.3、测试

前期，测试团队也挺困惑的。因为这也牵涉到非常深的业务知识，并且一个业务的验证可能跨越多个子系统。

首先，前期开发阶段，测试人员是没有参与进来，所以安排测试也只是一个非常简单的基础验证，比如，能不能点击，响应；页面是不是展现的完整。后续，越来越多的功能叠加进来，也慢慢感觉这个时候，需要调整一下，测试人员也必须和开发、产品对接。不是开发完毕了，产品人员再回头过来和测试人员讲解相关需求。这样定会拉长整个开发周期。

后续调整中，测试人员加大业务知识的学习与培训，并在后续开发中直接参与与开发人员的需求讨论会议。

      同时，还有一个过程，在于开发提交的测试，测试部署问题统一化问题，这里面牵涉到部署工具、代码集成测试、相关规范制定需要架构团队支撑。

2.3、预生产验证

培训，再测试阶段已经开发通过和使用方沟通，讲解业务处理流程。同时讲解完毕，即在预生产环境验证。及时反馈相关问题，持续改进。整个团队进入快速响应期。对开发、测试、产品都是一个不小的挑战。一方面需要为下一个版本叠加进新需求，一个方面需要为上一个版反馈过得问题持续改进。

培训，这个粘性人需要对我们目前的系统有较好的把握，同时对使用方的实际场景熟悉。以便处理其中的一些使用习惯差异，以及不同架构、流程实现下的区别。主导业务产品走向。

     这个阶段，需要偿还我们欠下的哪些组织债务呢？

1、培训是否到位，是否前期打过预防针。对我们使用方实际场景，前期调研形成的需求是否与场景相一致。

2、我们的核心流程处理，使用方是否理解。交付一个强大但使用方难以理解使用的产品，是否是一个必须。

2.3、交付生产

完事具备，只欠上线。

鉴于运维团队与开发团队是隔离的，上线时的各种技术债务都在这个阶段提现的淋漓尽致。

1、配置是否正确。

2、安装文档是否表述清晰。

3、系统架构文档是否完备。

这还是在上线遭遇的安装配置。上线后，验证，测试，开发人员基本验证功能。后续运行中的债务慢慢在后续优化来偿还。