事后诸葛亮

目录

• 一、会议照片
• 二、设想和目标
• 三、计划
• 四、资源
• 五、变更管理
• 六、设计/实现
• 七、测试/发布
• 八、团队的角色，管理，合作
• 九、总结
• 十、贡献比例

一、会议照片

二、设想和目标

• 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  • A：制作一个微信小程序，能实现多种小游戏。基于时间选择增添多款经典小游戏，如2048、见缝插针等。定义较为明确。是一款能丰富用户闲暇生活，操作简单，放松大脑的益智小游戏集合。
• 2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?
  • A：我们还未完全达成目标，原定的功能实现了自制2048游戏和论坛功能的简易版本，还有引入游戏外链。由于未完成整体软件，所以目前还没有任何用户。但是有内部测试版，目前为开发人员测试，目前正在测试小游戏的整体开发流程。
• 3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  • A：由于未对软件进行发布，所以用户量和用户对功能的接受程度无法估计，所以我们并没有离目标更近。
• 4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  • A：在交付软件之前，所有人都要有紧迫感，要有压力，有适当的压力才会有动力，才能更好的完成软件。如果历史重来，我们将制定严格的计划进程，将任务落实，给予所有人适当的压力，在deadline前完成软件。

三、计划

• 1.是否有充足的时间来做计划?
  • 在Alpha冲刺开始之前，大家的大致分工任务便已分配下去，因此开始各自学习开发所要用到的技术、工具等。Alpha冲刺开始之后，会议讨论上大家一致达成在Alpha冲刺结束前实现基础功能的计划，转而进入了Learning by doing的状态。而后由于各自的任务不同，主要是各自制定个人的规划。
  • 但是由于团队缺少前端技术人员，要学习技术所花费的时间较长，导致项目进度较慢。
• 2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
  • 少数服从多数。
  • 团队成员投票决定。
• 3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  • 有的完成了，有的暂未完成。
  • 时间上，在Alpha冲刺中后期有期末考试，一定程度上被剥削了一些时间，导致计划没有实现；
  • 技术上，团队成员之前并没有使用过相应的开发工具，开发语言也基本没有接触，心有余而力不足，
  • 技术不够导致一些问题难以解决，原定计划没有实现；
  • 经验上，缺少开发经验，不知先做什么再做什么，效率降低。
• 4.有没有发现你做了一些事后看来没必要或没多大价值的事?
  • A：首先是Alpha冲刺初期，前端页面很多是靠自己设计，代码全程靠自己手写，又由于技术受限经常卡住导致浪费了很多时间，后来懂得借鉴前人的优秀作品，站在巨人的肩膀上，效率得到了提高；再者是缺少经验，提前学习了某些技术但在实际开发中并没有用到，对此次开发而言浪费了时间。
• 5.是否每一项任务都有清楚定义和衡量的交付件?
  • A：一开始并没有仔细考虑这个问题，导致最后各部分整合的时候出了些问题。
• 6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  • 并没有都按照计划，有的部分由于技术等原因暂未实现。
  • 项目的开发与团队成员的考试冲突，时间安排不到位。
• 7.在计划中有没有留下缓冲区，缓冲区有作用么?
  • 没有留下，只是计划在Alpha冲刺结束前实现基础功能。理想很美好，现实很残酷。
• 8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  • 会计划提前一天或两天完成，以留下伸缩的余地，解决一些突发事件等。
  • 以及会更多考虑短期计划的制定，减少拖延症的发生。
• 9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 制定计划不要刚刚好，应该要有缓冲的余地，否则遇到问题将会很头疼
  • 同时也要学会时间管理，考虑制定短期计划，否则容易拖延导致最终计划不能实现。
  • 如果历史重来一遍，我们会决定在Alpha冲刺结束前一天实现我们的计划，同时会细分计划，做短期计划制定，循序渐进。
  • 学习新知识的能力还需进一步提高。

四、资源

• 1.我们有足够的资源来完成各项任务么?

  • 我们有一台自己的服务器，网上也有很多资源。

• 2.各项任务所需的时间和其他资源是如何估计的，精度如何?

  • 各项任务所需的时间和资源是根据大家公认的难度来进行估计的，精度一般。

• 3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

  • 人力资源：我们的成员配置较为合理，因此人力资源也是足够的；
  • 软件/硬件资源：充足，每人都有对应一台设备进行编码设计，同时有一台云服务器为项目进行线上部署；
  • 美工设计/文案都有做比较充分的准备，没有低估难度；

• 4.你有没有感到你做的事情可以让别人来做（更有效率）?

  • 团队内部分工明确，各自有自己负责的模块。所以没觉得让别人来做会更有效率。

• 5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

  • 团队时间管理不到位，导致项目进度的拖延，如果历史重来一次，要向罗老师学习，做好时间管理。
  • 前端技术的学习花费时间较长，需加快学习进度，或抱到前端大神的大腿。

五、变更管理

• 1.每个相关的员工都及时知道了变更的消息?
  • 我们会在群内进行通知，定期通过腾讯会议开会，并确保每个人都能知道并正确理解
• 2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
  • 我们针对产品的核心定义进行筛选，分清核心功能和附带功能，分为两个发布版本，确定优先级。
• 3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  • 我们产品的出口条件是：能正常操作无bug
• 4.对于可能的变更是否能制定应急计划?
  • 若出现突发变更，我们会根据项目当前的状况和剩余时间制定应急计划
• 5.员工是否能够有效地处理意料之外的工作请求？
  • 若出现意料之外的工作请求，我们会制定应急计划，让组员尽可能有效地处理
• 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 这次alpha冲刺体验，具有重要意义，也收获颇丰，不管是技术方面，还是团队写作方面，但是我们也还有许多不足之处，如果历史重来一遍，我们就能多避免出错，并有更好的安排计划

六、设计/实现

• 1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  • 设计工作是在小组会议上不断讨论决定的。由组长牵头讨论，大家共同商讨，最后由组长决定。时间一般是晚上9点过后，这时候大家都在家里，可以通过腾讯会议线上开会。
• 2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  • 没有。
• 3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  • 使用单元测试，对已实现的函数进行测试。单元测试帮助我们在开发过程中及时排错，更轻松地排错。
• 4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  • 没有区别。项目开始后还未对UML文档进行过更新。
• 5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  • 游戏撤销功能产生bug最多，主要还是因为测试的次数不够多，造成一些撤销多次后直接报空的错误。
  • 发布bug：2048小游戏页面适配问题，导致无法正常运行游戏。
  • 原因：缺少小程序开发经验。
• 6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  • 代码会由队长进行审核，主要要求规范命名和接口，还有git提交规范。
• 7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 我们刚开始学习软件开发，要多花时间在学习编程上。如果历史重来一次，我们会在更加花时间在软件开发上，更完善地完成Alpha版本的设计。

七、测试/发布

• 1.团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
  • 有一个比较简单的测试计划，主要是对所要实现的功能进行多次访问处理。
• 2.团队是否有测试工具来帮助测试？
  • 有试着用测试工具帮助测试，但基本都是靠自己研究探索，毕竟缺乏经验。没有进行正式的验收测试。
• 3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  • 测量效能主要有小程序是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从小程序本身出发，争取能更优化下用户体验。
• 4.在发布的过程中发现了哪些意外问题？
  • 发布的过程中，也是因为版本的问题，没有统一规范的原因，导致了最终代码整合的时候出现了难以解决的困难，基本上每次遇到的困难都是新的困难，都是令人意外的，之前没出现过的问题。
• 5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 小程序的开发过程中，测试这一环节是必不可少的。一款小程序即使测试完毕发布后，仍然会出现或多或少的问题，而这就体现了在测试环节你付出了多少，就决定了你最后遇到的问题是大是小。而测试也是需要有技巧性，有针对性的去测试你的小程序，而不能照搬其他人的测试方式，小程序都有各自独有的特点。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。

八、团队的角色，管理，合作

• 1.团队的每个角色是如何确定的，是不是人尽其才？

  • 有某方面基础的组员优先安排，有意愿做某方面的组员优先安排。

• 2.团队成员之间有互相帮助么？

  • 团队成员注重交流，互帮互助，一直是我们的作风

• 3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

  • 当出现这方面的小问题时，我们会在群内交流，提出各自的看法，当问题较大时，我们会召集开会，商讨解决方案

九、总结

• 1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  • 我觉得团队目前的状态还处于第一档次，即初始级。也是刚刚起步，正学会走路但是走的不快的状态。
• 2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  • 我觉得团队现在刚刚要从磨合阶段跨出去，走向规范阶段。
• 3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  • 相比于前一个里程碑，团队现在在队员沟通这方面做得更好了，基本上遇到难以独自解决的问题都会是多人一起合力解决，不再像当初自己一个人埋头苦干，独自探索了。
• 4.你觉得目前最需要改进的一个方面是什么?
  • 目前最需要改进的地方是，团队没有开发前端的技术人员，缺乏一个时间管理大师。
• 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
  • 做得比较好的敏捷开发的原则有
  • 面对面交谈
  • 每隔一段时间反省自己，并作出相应调整
  • 围绕有积极性的个人构建项目，并且信任他们能够完成工作。
  • 主要在Alpha冲刺阶段，两天一次的站立会议会督促着每个人是否有积极完成自己的任务，而且本组成员基本上的基础都是比较少的，每个人都会遇到大大小小的问题，解决这些问题只有当面交流，现场调试修改的效率才是最高的。而在这个项目中，基本也是围绕着学习能力比较强的大佬们，辅助他们来完成主要的功能。当然除此之外，合作的部分也是占着很重的比例。

十、贡献比例

姓名	角色	工作内容	贡献分
林泽鸿	前端	2048小游戏和论坛模块，测试	20.5
李玉	前端	个人设置模块，博客撰写，测试	20
梁鸿健	UI	UI设计，用户体验，寻找背景bgm，测试	19.5
刘彦享	后台	个人模块，游戏模块，测试	20.5
龙俊健	后台	游戏模块，论坛模块，测试	20