第一次迭代心得体会
社区电商平台 小豆芽小组
设想和目标：
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的项目是社区电商平台，解决的自然就是社区范围内的线上商品交易问题，对于社区的定义，我们将它理解为一个地理相近范围，或者更加细分为一个相近地理范围内的同好群体。
典型用户就是有购买意愿的买家和有闲置出售意愿的卖家，场景按角色不同，比如买家：有搜索商品，浏览商品，发布心愿，购买商品等，卖家：搜索心愿单，发布商品，接受订单并发货等；
2. 我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
在第一次迭代中，根据原计划我们是需要实现作为买家的买商品和作为卖家的卖商品，到第一次迭代为止我觉得我们这两个基本功能是实现了的，除了一些小瑕疵外；由于我们的小程序并没有发布，所以现在的用户只有我们内部的几个成员能用。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量来说，因为作为电商平台的一个基础功能，支付功能遇到了一些问题，所以小程序并没有发布上线，用户也就是小组内成员
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在最初的迭代计划书中，对一些需求的细节化并没有做到全面，出现了开发过程中有一些具体需求还出现争议的情况；如果历史重来一遍，我们会在提出需求的时候考虑我们现在的需求是否在我们的能力范围内能够做的，或者是是否在现有条件下能够做的，因为我们提出的需求就由于一些硬方面不行，造成了提出的需求不能完成。
计划
1. 是否有充足的时间来做计划?
感觉每次做的计划不是特别多，就可以在规定时间内完成，还能提高效率。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
咨询指导老师，在结合老师意见的情况下再次讨论，最后由pm敲定最后方向，但是感觉我们小组很少有不同的意见
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本上都做完了，只是我们的项目有一个难关：微信支付要企业用户进行申请，显然，我们并不具备这个条件
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
目前来说，还是没有的
5. 是否每一项任务都有清楚定义和衡量的交付件?
是的，作为前端，交付件就是传给后台所需要的数据以及给用户该有的提示
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
主要就是在开始没有意识到域名申请的时间花费，在要用到的时候才去进行申请手续，导致项目进度滞停了一段时间；然后还有低估了这一次迭代计划的工作量，前几周工作量少，使得最后一周左右的工作量陡然增大。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
第一次验收后的一个星期就起到了一个缓冲区的作用吧，在这个缓冲区内我们根据第一次验收的结果进行了相应的bug的修复以及代码的规范。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
衡量接下来的三周时间内我们确实能做到哪些，对进度进行适当修改
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这种时间紧凑的项目中，时间安排真的很重要，而且要根据整体的工作量进行合理的安排，否则就会发生前几周轻松，后几周赶工的状态了；
资源
1. 我们有足够的资源来完成各项任务么?
在互联网时代，我觉得资源是足够的；
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
由于对任务所涉及的知识了解不够，很难估计
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
对于这样的项目五人的规模已经足够，人手再多反而增加了交流成本，文档之类的，因为是各人负责自己的部分，所以负担不显得很重，测试部分，感觉还不知道该如何测试，所以没有估计过；
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
我觉得到现在了，多少都学到一点，还是自己作比较有效率；
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
资源很多，但问题在于我不知道哪些资源对自己有用；要是历史重来一遍，我会选择好好学学前端语句；
变更管理
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. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
合作方面一直很融洽，要是有问题会一起线下解决
总结:
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
比起最开始更有配合默契，相处更加融洽
你觉得目前最需要改进的一个方面是什么?
编码规范，同意编码风格
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我觉得做的最好的就是团队之间每天都有面对面的交流时间，而且编写代码之类的都是在一起的，非常融洽。
