Heaven Fire团队 OrderStyem(点餐)APP 项目 Postmortem 结果
一、设想和目标
1. 用户为什么需要点餐APP？而我们的软件又解决了用户的什么需求？
- 答：当然是为了缩短点菜、下单、买单的时间，提高餐厅用餐效率以及服务体验。
- 而使用我们的软件可以节省人力成本，迅速下单，操作简单，界面友好。
2. 是否有充足的时间来做计划?
- 答：有，虽然时间比较紧张，但我们的计划比较充裕。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 答：首先每个团队成员先把自己的想法说出来，然后一起分析该设想是否合理可行，最后得出统一意见和做法。
如果历史重来一遍, 我们会做什么改进?
- 答：我们会考虑加一些比较有技术性的东西，因为目前我们成型的产品相对来说还是比较粗糙的。
二、计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 答：原计划的工作全部做完了。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 答：没有，因为我们每一步都是按计划、按流程走的。
3. 是否每一项任务都有清楚定义和衡量的交付件?
- 答：是。
4. 是否项目的整个过程都按照计划进行?
- 答：是。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 答：没有，因为每个sprint周期中已经计划好每个成员要完成的任务。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 答：不做修改。
如果历史重来一遍, 我们会做什么改进?
- 答：我们每个sprint周期的计划都很符合我们团队，所以应该不会在改进。
三、资源
1. 我们有足够的资源来完成各项任务么?
- 答：有些任务没有，比如结算页面，我们曾设想采用微信支付之类的支付方式，因为没有足够的资源，所以最后讨论不通过这个设想。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 答：各项任务所需的时间无法精确估计，因为这要具体到领任务的人实现的情况。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
- 答：不够。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
- 答：感觉下单和结算的设计由专业人员设计会更好。
如果历史重来一遍, 我们会做什么改进?
- 答：争取多获得一些资源。
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
- 答：通过网络方式可以迅速传达变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 答：我们没有“推迟”的功能。
3. 项目的出口条件 （Exit Criteria – 什么叫 “做好了”）有清晰的定义么?
- 答：做好了就是完成计划中所有任务。
4. 对于可能的变更是否能制定应急计划?
- 答：基本上没有，一般团队讨论后解决。
5. 员工是否能够有效地处理意料之外的工作请求？
- 答：不能，因为每天的计划和行程都排满了，抽不出其他时间去处理意料之外的工作。
如果历史重来一遍, 我们会做什么改进?
- 答：对于消息变更方面处理的挺好的，不需要改进。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 答：设计工作在开始sprint周期前有团队成员共同讨论完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 答：有，每个团队成员先把自己的想法说出来，然后一起分析该设想是否合理可行，最后还是看实现该功能的人如何解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 答：团队运用了单元测试（unit test），同时我们还用了光影魔术手帮助ui设计，很有效。
4. 什么功能产生的Bug最多，为什么？
- 答：登录、注册功能产生的bug最多，因为涉及到在线数据库跟本地代码的关联，通过检测，把发现的bug都修正了。
5. 代码复审 （Code Review）是如何进行的，是否严格执行了代码规范？
- 答：有规范代码，但并没有严格执行代码规范的要求。
如果历史重来一遍, 我们会做什么改进?
- 答：规范代码会严格执行代码规范的要求。
六、测试
1. 团队是否有一个测试计划？为什么没有？
- 答：有，针对一些类进行AndroidTestCase测试，以及在执行时找bug。
2. 是否进行了正式的验收测试？
- 答：没有。
3. 团队是否有测试工具来帮助测试？
- 答：没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 答：用AndroidTestCase进行测试，可以修正一些程序的bug。
如果历史重来一遍, 我们会做什么改进?
- 答：加个正式的验收测试。
时间： 2024-12-12 19:33:27