第一次迭代心得
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
- 我们的项目是社区电商平台,解决的自然就是社区范围内的线上商品交易问题,对于社区的定义,我们将它理解为一个地理相近范围,或者更加细分为一个相近地理范围内的同好群体
- 典型用户就是有购买意愿的买家和有闲置出售意愿的卖家,场景按角色不同,有搜索商品,浏览商品,发布心愿,购买商品等(买家),搜索心愿单,发布商品,接受订单并发货等(卖家)
2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
- 在第一次迭代中,我们完成了对电商平台部分的搭建,也就是对于一个买家,他能完成一个从发现商品到购买商品的过程,而对于一个卖家,他也能完成从发布商品到完成订单的过程,只是在微信支付的实现上遇到了申请api流程上的非技术性困难
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量来说,因为作为电商平台的一个基础功能,支付功能遇到了一些问题,所以小程序并没有发布上线,用户也就是小组内成员
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 在最初的迭代计划书中,对一些需求的细节化并没有做到全面,出现了开发过程中有一些具体需求还出现争议的情况,如果历史重来一遍,要模拟用户的使用过程,完全地演绎一遍需求,做到任何一个细节都是按计划书进行
计划
1. 是否有充足的时间来做计划?
- 作为初接触项目的学生,开发过程中遇到很多技术堡垒,再加上其他课业的一些任务要完成,时间显得还是有些不足
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
- 咨询指导老师,在结合老师意见的情况下再次讨论,最后由pm敲定最后方向
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
- 微信支付要企业用户进行申请,显然,我们并不具备这个条件
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 目前来说,还是没有的
5. 是否每一项任务都有清楚定义和衡量的交付件?
- 是的,作为后台,交付件就是前台可使用的接口
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
- 主要就是在开始没有意识到域名申请的时间花费,在要用到的时候才去进行申请手续,导致项目进度滞停了一段时间
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
- 第一次验收后的一个星期就起到了一个缓冲区的作用吧,在这个缓冲区内我们看到了很多项目的不足并及时进行了改进
8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
- 衡量接下来的三周时间内我们确实能做到哪些,对进度进行适当修改
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 在这种时间紧凑的项目中,时间安排真的很重要,要在开始前对时间进行科学的规划,能并行的任务尽量并行
资源
1. 我们有足够的资源来完成各项任务么?
- 在互联网时代,我觉得技术资源是无穷无尽的
- 但时间资源有些不够,我们在有些问题上没有做到完美
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
- 大致估计其难度,因为经验问题精度不太准确
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 对于这样的项目五人的规模已经足够,人手再多反而增加了交流成本
- 文档之类的,因为是各人负责自己的部分,所以负担不显得很重
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
- 这个或许不应该我自己来说吧(笑)
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 在这个方面我觉得我们的团队做的挺好的,如果历史重来一遍我希望回溯得更久一点让我先好好学学java吧
变更管理
1. 每个相关的员工都及时知道了变更的消息?
- 是的,团队在一天之内基本上都有一次直接面对面的机会
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 先团队内部达成一致意见,然后找知道老师确认
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
- 因为是微信小程序,能用就是做好了
4. 对于可能的变更是否能制定应急计划?
- 会临时开会决定的吧
5. 员工是否能够有效地处理意料之外的工作请求?
- 意料之外的东西还是挺多的,我觉得我们都很好地解决了
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 团队的及时沟通是很重要的,我觉得在这方面我们没什么需要改进的
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
- 需求分析阶段,由全组成员和指导老师共同决定
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
- 各人说一下自己的想法然后出一个最终方案
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
- 使用了UML
- 对开发工作的起到了很大的指导作用
- 和最初的相比,现在的UML增加了很多细节,是在开发过程中发现然后更新的
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 没有哪里最多,都有一些或大或小的bug吧
- 测试的时候因为自己就是开发人员,所以会惯性地自己做了什么就去测试什么,没有设身处地地作为一个用户去测试
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
- 采用了项目小组互相审查的形式
- 还是有一些地方有一些瑕疵,但都及时地进行了修改
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 像我们一个小组有两个后台的情况,代码风格保持统一很重要,大家都要遵守一个共同的代码规范
测试/发布
1. 团队是否有一个测试计划?为什么没有?
- 基本就是全部代码整合完毕后,实际地用手机来测试一下各个功能
2. 是否进行了正式的验收测试?
- 是
3. 团队是否有测试工具来帮助测试?
- 用不同型号的设备来测试程序的界面
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
- 主要就是小组成员内部自己使用一下程序感受一下性能
5. 在发布的过程中发现了哪些意外问题?
- 没有
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 时间仓促,对测试工作没有太大的重视,没有进行系统地测试
团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
- 大家都是初次接触项目,自己也不太懂自己适合什么,但还是按照大家自己的意愿来进行了分工
2. 团队成员之间有互相帮助么?
- 有
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
- 线下一起编码解决问题
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 初始级吧
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 比起最开始更有配合默契,知道自己要完成到哪个程度
你觉得目前最需要改进的一个方面是什么?
- 编码规范
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作,面对面交谈。嗯,我们喝遍了学府的咖啡品种
- 需求的变化。到了每个新功能模块,我们都会找到计划书中和实际情况有些出入的需求并加以修改