chanceEasy Summary
chanceEasy 项目总结
讲课内容
今天分享的内容，主要是总结ChanceEasy第一阶段从需求分析到系统部署的整一个软件开发过程，每一个阶段所使用的工具、方法、和面临的问题和解决方法。
- 需求分析
- 数据库设计
- 开发过程
- 系统测试
- 系统部署
- 个人总结
- 讲课过程中，希望大家积极参与讨论
需求分析
- 方法：通过口头交流获取需求，分析单据信息，形成需求，实现页面原型，供用户确认；每次调研前的计划文档、调研后的总结文档；经过多次修改，形成确认版本，针对每个页面做详细开发注释文档
- 产物：流程图+页面原型+调研文档
- 优点：由于界面清晰可见，可以跟用户很好的进行沟通
- 缺点：文档规范性、可读性、可修改性、准确性、完整性（哪些要填哪些不要填）
- 经验总结：
- 流程图：必须准确无误、添加必要注释、能准确无误描述需求、（并需要和客户确认）
- 静态页面：尽量能够让这些前台代码能够在开发时使用，减少开发时间
- 开发文档：必须有非开发者检查、保证文档的准确性、可读性、无二义性
- 调研文档：由于需求跟改较快、文档过多、维护艰难
- 没站在客户的角度看问题、没形成数据流图
数据库设计
- 方法：由每个模块的负责人提前设计好各自模块的数据库关系，根据页面原型，统一讨论各个模块的设计，并完成数据库关系图和Google文档、页面注释
- 产物：系统数据库关系图+Google文档+页面注释+状态文档
- 优点：能够清楚的知道数据库表间关系、数据库表字段定义可以直接导入
- 缺点：由于多人讨论，数据库表间关系、字段准确性很难确定；没进入实际开发，有些设计不合理
- 经验总结：
- 必须有人检查该过程所形成文档、确保文档的准确性、不然实际开发时，该文档并没有起到很好的作用
- 比较特殊的字段，必须写清楚为何这样设计
- 字段必须统一
- 充分考虑数据库的拓展性，为需求添加做准备
代码封装
- 方法：根据之前开发经验，统一讨论需要封装的内容，并落实给每一个人。并完成相关文档
- 产物：Ruby+Js的API文档
- 优点：加快开发速度、有利于技术的提高
- 缺点：无
- 经验总结：
- 缺少代码质量监控，不能保证封装的代码已在使用->Redmine代码监控、Yammer通知
- 不能一味符合功能需求->果断摒弃不适合功能
- 代码封装应该交给经验较为丰富的开发者
- 在实际开发之前，必须把代码封装任务完成->待封装代码文档
- 共用性代码、文档准确性，详细性
开发过程
- 方法：先大概讲下业务流程，开发者通过流程图、页面注释、数据库设计进行开发
- 产物：页面原型（每个页面的页面注释、所用到的数据库关系、表字段、单据）
- 优点：开发者能够明确获得开发时所需要的所有信息
- 缺点：维护这份文档比较困难、需要耗费时间长
- 开发总结：
- 每天的三分钟会议无法获取进度且浪费时间，通过使用Yammer汇报进度、一周总的进度汇报
- 代码质量->使用Redmine代码评审功能
- 开发结果与需求不符、目标不明确
- 由于实现的需要，有些问题已经跟原来需求相符->开发时间太长、再确认比较麻烦
系统测试
- 方法： 各自负责页面进行测试、各自负责模块测试、负责人集成测试、用户验收测试
- 产物：测试文档
- 优点：
- 缺点： 需要大量的人工测试
- 经验总结：
- 经验不足，无法确定测试需要时间、没有明确的测试目标
- 没有自动化测试（测试驱动开发）
系统部署
- 方法：配置待部署服务器、部署前准备工作、每一个人的培训安排
- 产物：部署计划、部署文档
- 优点：
- 缺点：
个人总结
- 计划的安排合理性->先试用、看是否安排合理
- 进度的把控
- 代码质量监控
- 任务完成情况把控
- 状态调整
- 解决问题->发现问题转变
- 目标不明确->为了完成任务而做任务、导致不思考、没动力、没状态
- 如何兼顾技术提高和项目进度合理（头脑风暴、技术讨论会）
- 实验室可以形成自己的代码库
- 决策失误
- 技术提升的三个阶段暑假培训、培训师弟、项目管理
实验室面临的问题
- 培训方案
- 项目压着我们，变成开发工具、学习不到东西