团队作业6——事后分析
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们需要完善软件的基本功能，在结束Alpha阶段之后开会明确各方需求并重新进行了任务分配。
- 我们达到目标了么?
按照原本的计划我们基本达成目标。24点游戏的小程序可以正常进入并进行游戏，同时分数的录入与排序也能够正常进行。
- 和上一个阶段相比，团队软件工程的质量提高了么？
团队在经过了之前Alpha阶段的磨合，对各自代码和编程思路都有了一定的了解，在沟通上面的效率有所提高。
- 用户量和我们事先的预想一致么?我们离目标更近了么?
由于我们只能开发体验版的微信小程序，用户量受限为15人，需要在微信开发者通过微信号将用户进行录入。
- 有什么经验教训?如果历史重来一遍,我们会做什么改进?
需要注意代码方面的细节问题（中英文符号的区别等）以及讨论时间的安排（人数多时一起讨论效率较高）。
计划
- 是否有充足的时间来做计划?
有。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
开会商量择优处理。
- 你原计划的工作是否最后都做完了?如果有没做完的，为什么?
否，因为时间原因和开发难度原因部分功能未实现，只是做出了大致必要的功能。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，第一次团队开发，难免会绕一些弯路，做一些后面觉得没必要的事情。
- 是否每一项任务都有清楚定义和衡量的交付件?
是。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，在开发后期产品基本成型后，出现了很多BUG，改完这一处，另一处BUG又来了，因为功能涉及的逻辑很复杂，然后组员对编程语言不是很熟悉，不过大致问题都得到了解决。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
按找流程继续走下去，会预留缓冲区。
资源
- 我们有足够的资源来完成各项任务么?
我们努力学习的咸鱼小组一共6位队员，主观上队员学习动手能力强，客观上项目安排时间较合理，所以各自分配的任务也不紧凑，足够来完成各项任务。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
在任务中因为我们每周都会进行总结，冲刺阶段天天总结，这样时间上安排即使一次做不好也会及时总结发现到问题在下次不会再犯，所以时间上安排越趋合理，我们估计时间和其他资源主要通过需求分析预测，主要将时间安排在代码的编写以及debug阶段，测试部分主要是人工测试，会比较快。估算精度误差不超过一天，即原来安排当天完成的任务一定当天完成。
- 测试的时间，人力和软件/硬件资源是否足够?对于那些不需要编程的资源(美工设计/文案)是否低估难度?
人力资源/硬件资源还是比较足够的。对于那些不需要编程的资源我们一开始以为比较简单，但实际操作中出现的问题难度超出了我们的估计，小测序排版上也花费了不少功夫，尽管最后按时完成。
- 你有没有感到你做的事情可以让别人来做（更有效率?
这种问题可以适当向组长提议，但是如果其他人的任务已经在进行，如果交换的话还需要进行交付可能会花费更多的时间，所以又需要考虑更多的细节，所以即使有这种感觉最好是请教你认为能更有效率完成的那个人来让自己变得更有效率。
- 有什么经验教训?如果历史重来一遍,我们会做什么改进?
通过这次我收获到了队员合作的重要，代码规范的重要，各队员编写的代要让其它队友也能看得懂才行，不能写一些不合规范的代码，历史重来，我们可能要改进一下开发效率上的问题，虽然能够按时完成，但是效率不算太高，在冲刺阶段一开始不太适应。
变更管理
- 每个相关的员工都及时知道了变更的消息?
是的，每次作出决定我们都会在群里进行通知，务必让成员确认。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据决策中重要程度的不同来决定。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
至少需要可以按照与设计流程相一致的使用方式使用即可出口。
- 对于可能的变更是否能制定应急计划?
由于项目工程量较小，一般遇到问题可以立即进行解决，故未制定。
- 员工是否能够有效地处理意料之外的工作请求？
大部分时候可以。突发事件往往是意想不到的，但是大部分问题在设计的初步阶段基本都考虑到了，就会自然的有相对的措施。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在刚刚出现24点小程序这个设想的时候，是由组长完成的。是合适的时间，合适的人。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计工作后的设计结果并没有是否清晰，大多数问题都是在开发阶段解决的。就算遇到模棱两可的问题，只要经过简单的讨论就可以得出结果。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
主要是人工测试。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
主要是限制用户输入的bug比较多，要规定用户输入一个正确的数学表达式才能够进行计算。一次标志位比较多。但标志位引发的错误不易被发现。在开发的时候我们主要是去实现功能的，没有考虑到这些数字的多次使用情况，把情况过于理想化导致没有考虑到这些可能出错的环节。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们严格执行了代码规范，在复审上没有话太多的功夫，主要是对有BUG的部分代码进行了多次审视试图修复。
测试/发布
- 团队是否有一个测试计划？为什么没有？
团队有测试计划，在项目的需求分析阶段，我们就做好了测试计划，编写了相应的文档，在该测试计划下，我们的测试才更有目的性，更高效。
- 是否进行了正式的验收测试？
系统测试之后，我们有进行了正式的验收测试，由最终用户直接进行体验，反馈问题。
- 团队是否有测试工具来帮助测试？
没有。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 我们主要是测试人员手动测试，直观感受页面的滑动的流畅度，答题提交的速度，最终结果的判定来跟踪软件的效能，初次开发小程序，不熟悉相应的测试工具，故没有采用相应工具进行测试。
- 这些测试有用，初期项目的题目刷新卡顿严重，用户体验并不好，做了相应改进之后问题得到解决。
- 改进的地方是，我们没有采用相应的工具测试该项目所能承受的并发量，运行速度等。手动测试有限，有些bug容易被忽略掉。
- 在发布的过程中发现了哪些意外问题？
因为我们没有企业认证，所以项目无法正式线上发布，现阶段，我们只是通过体验版让用户使用。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级，已管理级
- 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
团队在进行了测试的阶段之后，仅在现有基础上进行优化调整，暂时未能做出拓展功能，处于规范阶段。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
在团队任务分配方面更加规范和明确，大家彼此之间也更熟悉，相较上一个阶段感觉更加顺利。
- 你觉得目前最需要改进的一个方面是什么?
组内成员提出问题之后及时回应，提高效率。
附件：
CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
- 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
- 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
- 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 目前，公司需要申请的就是已定义级别，通常称为CMMI3。由此，我们可知CMMI3是CMMI其中的一个等级。
- 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
- 优化管理级
可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。
博客要附上全组讨论的照片:
团队成员在Alpha阶段的角色和具体贡献:
| 姓名 | 角色 | 团队贡献分 | 贡献 |
|---|---|---|---|
| 吴安冬 | 程序管理 | 23 | 部分代码，工作分配 |
| 吴梓华 | 发布管理 | 22 | 部分代码，博客撰写 |
| 赵玮锋 | 用户体验 | 21 | 用户调查，测试 |
| 庾艺锋 | 项目开发 | 26 | 主要代码，测试 |
| 白军强 | 产品管理 | 25 | 部分代码，测试 |
| 王泽鑫 | 项目测试 | 24 | 测试，反馈 |