第一次迭代心得
设想和目标
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 中的哪个档次?
- 初始级吧
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 比起最开始更有配合默契，知道自己要完成到哪个程度
你觉得目前最需要改进的一个方面是什么?
- 编码规范
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作，面对面交谈。嗯，我们喝遍了学府的咖啡品种
- 需求的变化。到了每个新功能模块，我们都会找到计划书中和实际情况有些出入的需求并加以修改
