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