chanceEasy Summary

chanceEasy 项目总结

讲课内容

今天分享的内容,主要是总结ChanceEasy第一阶段从需求分析到系统部署的整一个软件开发过程,每一个阶段所使用的工具、方法、和面临的问题和解决方法。

  • 需求分析
  • 数据库设计
  • 开发过程
  • 系统测试
  • 系统部署
  • 个人总结
  • 讲课过程中,希望大家积极参与讨论

需求分析

  • 方法:通过口头交流获取需求,分析单据信息,形成需求,实现页面原型,供用户确认;每次调研前的计划文档、调研后的总结文档;经过多次修改,形成确认版本,针对每个页面做详细开发注释文档
  • 产物:流程图+页面原型+调研文档
  • 优点:由于界面清晰可见,可以跟用户很好的进行沟通
  • 缺点:文档规范性、可读性、可修改性、准确性、完整性(哪些要填哪些不要填)
  • 经验总结:
    • 流程图:必须准确无误、添加必要注释、能准确无误描述需求、(并需要和客户确认)
    • 静态页面:尽量能够让这些前台代码能够在开发时使用,减少开发时间
    • 开发文档:必须有非开发者检查、保证文档的准确性、可读性、无二义性
    • 调研文档:由于需求跟改较快、文档过多、维护艰难
    • 没站在客户的角度看问题、没形成数据流图

数据库设计

  • 方法:由每个模块的负责人提前设计好各自模块的数据库关系,根据页面原型,统一讨论各个模块的设计,并完成数据库关系图和Google文档、页面注释
  • 产物:系统数据库关系图+Google文档+页面注释+状态文档
  • 优点:能够清楚的知道数据库表间关系、数据库表字段定义可以直接导入
  • 缺点:由于多人讨论,数据库表间关系、字段准确性很难确定;没进入实际开发,有些设计不合理
  • 经验总结:
    • 必须有人检查该过程所形成文档、确保文档的准确性、不然实际开发时,该文档并没有起到很好的作用
    • 比较特殊的字段,必须写清楚为何这样设计
    • 字段必须统一
    • 充分考虑数据库的拓展性,为需求添加做准备

代码封装

  • 方法:根据之前开发经验,统一讨论需要封装的内容,并落实给每一个人。并完成相关文档
  • 产物:Ruby+Js的API文档
  • 优点:加快开发速度、有利于技术的提高
  • 缺点:无
  • 经验总结:
    • 缺少代码质量监控,不能保证封装的代码已在使用->Redmine代码监控、Yammer通知
    • 不能一味符合功能需求->果断摒弃不适合功能
    • 代码封装应该交给经验较为丰富的开发者
    • 在实际开发之前,必须把代码封装任务完成->待封装代码文档
    • 共用性代码、文档准确性,详细性

开发过程

  • 方法:先大概讲下业务流程,开发者通过流程图、页面注释、数据库设计进行开发
  • 产物:页面原型(每个页面的页面注释、所用到的数据库关系、表字段、单据)
  • 优点:开发者能够明确获得开发时所需要的所有信息
  • 缺点:维护这份文档比较困难、需要耗费时间长
  • 开发总结:
    • 每天的三分钟会议无法获取进度且浪费时间,通过使用Yammer汇报进度、一周总的进度汇报
    • 代码质量->使用Redmine代码评审功能
    • 开发结果与需求不符、目标不明确
    • 由于实现的需要,有些问题已经跟原来需求相符->开发时间太长、再确认比较麻烦

系统测试

  • 方法: 各自负责页面进行测试、各自负责模块测试、负责人集成测试、用户验收测试
  • 产物:测试文档
  • 优点:
  • 缺点: 需要大量的人工测试
  • 经验总结:
    • 经验不足,无法确定测试需要时间、没有明确的测试目标
    • 没有自动化测试(测试驱动开发)

系统部署

  • 方法:配置待部署服务器、部署前准备工作、每一个人的培训安排
  • 产物:部署计划、部署文档
  • 优点:
  • 缺点:

个人总结

  • 计划的安排合理性->先试用、看是否安排合理
  • 进度的把控
  • 代码质量监控
  • 任务完成情况把控
  • 状态调整
  • 解决问题->发现问题转变
  • 目标不明确->为了完成任务而做任务、导致不思考、没动力、没状态
  • 如何兼顾技术提高和项目进度合理(头脑风暴、技术讨论会)
  • 实验室可以形成自己的代码库
  • 决策失误
  • 技术提升的三个阶段暑假培训、培训师弟、项目管理

实验室面临的问题

  • 培训方案
  • 项目压着我们,变成开发工具、学习不到东西

Comments