一、设想与目标
1. 我们的软件要解决什么问题？
是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是为了方便日常生活在饭馆点餐，除去了服务员-客户这一流程，转由线上点餐，支付，节省了沟通成本。
2. 是否有充足的时间来做计划?
是，在做这个项目之前，我们进行了广泛的人群调研与需求分析，同时小组间对于本项目的需求，接口文档参数一起进行了详细讨论，尤其接口文档的交流十分关键，直接影响后期前后端后台对接的时间成本花费。基于alpha阶段的工作，beta阶段吸取了之前的教训，效率上有所提高，时间相对充裕。
3. 团队在计划阶段是如何解决成员对于计划的不同意见的？
每晚8点在群内说明自己的今日完后进度，0点说明自己次日的目标计划，由组长记录整合，归档。
团队成员对开发中的哪个环节存在疑问在或建议在群内提出，并@相应负责人，不知道负责人时，统一@组长。出现冲突时，组长听取冲突双方意见后做最终决策，组员依然反对则在群内发起投票以多数服从少数为原则。
二.计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
否，考试等因素干扰，进项目预估进度误差等、
前期主要问题在于后台跟微信公众平台的对接，以及申请服务号（未通过）花费了不少时间。
后期前端出现了一些状况导致前后端对接时间不得不延后。
我们计划beta阶段完成用户端点餐流程
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
前期仓库捣鼓了不少时间，本来是使用svn做项目管理，发现课设要求用git，又不得不切换项目管理工具。
期间也写了一些一点用处也无的流水文档
3. 是否每一项任务都有清楚定义和衡量的交付件?
否，问题出在交流理解上，一千个读者有一千个哈姆雷特，对于同样一份文件，组员理解上可能存在偏差又未及时发现，后期弊端显现
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本按照计划，就是支付功能最终无法完整实现（没有申请到服务号，判断错误）。一开始想法太过乐观与理想化了。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有考虑。缓冲区有作用，比如项目出现问题，可以缓一缓
6. 将来的计划会做什么修改？
会留缓冲区，应对紧急情况。成员之间建立起互相监督的机制，提高效率。
加强组员交流，减少理解偏差
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
后台学到了与微信平台对接的方法
大家学到了项目开发有时不是一个人的事情，一定要相互配合好，每个人都是这之中非常重要的一环，做事不能一意孤行。
要及时完成计划中的任务。任务分配应该合理而明确。
三.资源
1. 我们有足够的资源来完成各项任务么?
唯一的资源问题就是没有申请到服务号的资格导致后台状态低迷（后台留了支付接口但是却苦于那个麻烦的商户号），后面才重整旗鼓
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
每晚8点在群内说明自己的今日完后进度，0点说明自己次日的目标计划，由组长记录整合，归档。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的话，之前有说过，我们在测试方面相对薄弱，因为我们是手动测试，找出bug再解决，测试方面的人力资源足够而软件资源有限，导致测试花费好多时间。美工问题主要在app端，因开发经验上的不足导致app端界面出现一些误差，不能达到预期效果
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有的。博客文档理论上应让每个人参与进来更好。但是这次项目的博客主要由我和夏阳负责编写。
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这个阶段我们学到很多东西，在团队方面学会合作互相帮助，在项目上面，学会如何测试，如何美工，如何编程。如果历史重来一遍，分配时，应该更加明确些，具体到某一点的哪些内容，否则会出现队员做了相同的事，而产生了无用功浪费了人力物力。同时沟通真的很重要，队员间要多多加强沟通，防止因为误解队员的意里而产生误会。
再者就是要提前准备好申请服号所需的资料。以及开发流程需要的技术
四.变更管理
1. 每个相关的成员都及时知道了变更的消息?
能，得益于eolinker，每个成员都及时知道项目进行中的变更信息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
在刚接手项目的时候，我们小组就开过会讨论，并确定了项目的核心功能。并且讨论了各个功能实现的难易。“推迟”和“必须实现”是这样界定的：1、核心功能中容易实现的必须在 alpha 版本实现；2、核心功能中有技术难点的推迟到 beta 版本实现。后来也是按照这个方法完成了项目。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
小组对项目出口条件的定义是：项目能够满足《毕设导师智能分配系统》的需求。一定的用户先体验，反馈良好。
4. 对于可能的变更是否能制定应急计划?
对于重大的变更，我们暂时没有应对计划,但是，我们有应对数据库变更的计划。我们对数据库进行了备份（备份在eolinker上），能够在需要的时候使用恢复备份以及扩展数据库。
5. 成员是否能够有效地处理意料之外的任务请求？
可以。如果得知意料之外的任务请求，我们会经过小组讨论接受挑战，争取完成任务。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了为防变更而制定应急计划，既对数据库进行备份。如果历史重来一遍，首先应明确整个开发过程大体要做哪些事，将较大的模块落实到个人负责，如文档不能只由一个人或两个人来负责，应该是大家共同参与进来。
五.设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在Alpha阶段冲刺的时候开始的。由我们的组长领导，团队成员一起讨论来完成。在适合的时间，适合的人员中完成了适合的事情。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
关于这一点请参考上文一.3
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有运用单元测试，UML测试，等测试工具。这些工具很有效，大大的提高了测试的效率，降低了手工测试的工作量。同时有的测试工具还有提供一些小问题的解决办法。为我们减轻了很多负担。但测试出现的大多问题都会记录下来然后团队讨论解决方案。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
因为进行代码测试时，大家会把出现的问题记录下来共同解决。所以经过统计出现bug最多的是坦克的移动攻击，因为它实在有些复杂。发布之后主要的问题在服务器上，运行环境变成了linux系统，多少会存在一些隐蔽的问题刚开始没能发现
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在代码开发之前我们就有规定代码编写的规范问题，所以为代码复审带来了很大的便利。代码复审的工作由参与代码编写的人员来执行，互相检查彼此的代码然后找出问题，再共同解决。因为参与开发的人员不多，所以能够严格执行代码的规范。
六.测试/发布
1. 团队是否有一个测试计划？为什么没有？
没有。我们是开发一部分功能就先进行测试，测试无误后才继续进行后续的开发。
2. 是否进行了正式的验收测试？
有对每一部分功能进行正式的验收测试
3. 团队是否有测试工具来帮助测试？
有。postman、mock接口等
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
各个模块的测试分配给各个测试组员，这些组员进行用例测试。从软件实际运行的结果来看，这些测试工作还是挺有用的，比如可以测试出一段JavaScript代码或PHP代码对于边界数据的处理是否合乎期望，测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。改进的方面就是大家应该在如何运用测试软件上多做些学习，这样可以保证正确的执行测试任务同时节约时间提高效率。
5. 在发布的过程中发现了哪些意外问题？
出现的意外有，发布的时候有晚点，在博客提交的时候完了一天。
服务器配置不当，端口开放调试问题等
七、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
用户端已经基本完成（支付接口没有商户号id无法进行真实支付操作）
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合过了，到了规范阶段了，经过alpha阶段队员们之间熟悉了很多，有问题也会直接指出，不以规矩不成方圆，凡事还是规范化做起来效率较高，不用顾虑太多其他因素，规则定在那里就去执行。
3.你觉得目前最需要改进的一个方面是什么?
我们都在做自己擅长的虽然效率提高，但是也缺乏探索和创新能力，没有积极主动地去往自己不会的领域发展，多方面的发展自己。还有就是需要多多学习思考，不能一味依赖于他人，要善于主动去寻找问题，而不是等问题出现了才急忙应对
八、团队成员在Alpha阶段的角色和具体贡献:
| 名字 | 角色 | 团队贡献分 | 可验证贡献 |
|---|---|---|---|
| 付夏阳 | DEV、PM、TEST | 22 | 后台开发、博客编写 |
| 温铭淇 | DEV | 21 | 后台开发、博客编写 |
| 伍欣怡 | DEV | 20 | 前端开发 |
| 钟秋爽 | DEV | 19 | 页面设计 |
| 陈炜铖 | DEV | 18 | APP端开发 |
142
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
