一、设想与目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

•  我们的软件主要是为了帮助那些对于挑礼物有选择困难症或者忙于工作与学习，没有时间为他人挑选礼物的人。用户通过输入被赠送人的年龄生日信息或爱好或理想价位等，软件将会根据条件为用户推荐出最合适的礼物。软件操作简单，可使用于广大人群。

2. 是否有充足的时间来做计划?

• 是，在做这个项目之前，我们进行了广泛的人群调研与需求分析，同时小组间对于本项目的各项功能是否有实用价值进行了深入的讨论。

3. 团队在计划阶段是如何解决成员对于计划的不同意见的？

• 是，对于挑选礼物，我们模拟了主要的三大类典型用户与对应的典型场景。分别是恋人之间、朋友之间、亲属之间互送礼物的需求。

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

• 是，我们通过课余时间或者晚间与周末闲暇时间进行团队的探讨与计划安排。

5.团队在计划阶段是如何解决同事们对于计划的不同意见的？

• 在计划阶段对于计划的安排，首先我们会对团队成员的时间和擅长内容进行了解，然后再根据队员实际情况进行计划的安排。如果对于计划队员间有不同的意见，我们会请他们各自讲出自己意见的理由，然后考虑是否能有两全齐美的计划安排。如果没有，将由队员进行举手表决，最后由少数服从多数来进行安排。队员间有不同意见是难免的，但一个团队的计划安排不应该由强权主义来决定，我们会理性的进行兼顾各方的民主安排。

二.计划

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

• 我们计划第一阶段完成核心功能推荐礼物以及登陆注册界面，两项都有完成但是博客提交上稍迟了一天，演示那天组长不在也推迟了。还没做完的是购物车以及支付功能和礼物收藏，beta阶段主要做这几个。没有做完的原因是因为实现起来难度大呗，而且功能较多，alpha阶段大家状态都不是很好。

2. 有没有发现你做了一些事后看来没必要或没多大价值的事?

• 这倒是没有，对于我们组来说，时间相对紧迫。要求的任务都一直做来不及了，没有时间再去做一些吃力不讨好的事。但是早期我们一直在源代码上花时间琢磨，结果参考代码乱七八糟的以前也没学过java ee ,一直运行不了，询问了其他学校软件工程的同学，中南大学，福州大学还有我们学校的软件工程，最终都没有结果，我们就重新自己写了。这也不算是没必要吧，琢磨知识的过程.

3. 是否每一项任务都有清楚定义和衡量的交付件?

• 没有每项，代码的提交我们在冲刺阶段也没有每天签入，导致分数也偏低，成员之间分配任务的话很清楚，但是时间观念不强，效率偏低。

4. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

• 没有完全按照原计划，我们犯了一个错误，就是太依靠核心成员，所以中间由于一些原因主力成员的缺席导致我们进度拖缓，团队模式由一开始的功能模式有点退化为主治医师模式，因为我们一开始是要参考老师给的源代码在那个基础上进行完善改进，后来发现行不通。而且我们一开始开会讨论构想的功能太多而复杂，后面在实现的时候发现很难做到。项目出现的意外就是我们在敏捷冲刺阶段代码不够完善，还有中间几天组长的缺席也算是意外吧，风险就是没估计到迟交博客，那几天刚好很多事，成员之间没有互相提醒，没有人监督，这个下次我们一定会注意。

5. 在计划中有没有留下缓冲区，缓冲区有作用么?

• 没有考虑。缓冲区有作用，比如项目出现问题，可以稍微缓一缓，修复呗

6. 将来的计划会做什么修改？

• 会留缓冲区，应对紧急情况。成员之间建立起互相监督的机制，提高效率。我们学到了什么? 如果历史重来一遍, 我们会做什么改进?我们应该分配好时间，不能拖拖拉拉，和队名一样，不能太依赖组长，而且每项任务要定义清楚，组员之间有什么想法及时反应，每天都应该有明确的目标。

7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 要及时完成计划中的任务。

三.资源

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

• 资源问题的话，说不够也不够说足够也足够。首先，不够的话，我们一开始有一些资源，就是老师给的参考代码，但是毕竟自己团队对代码的规范跟标准与别人的不一样，所以大部分都看不懂，资源也就差不多都没用上了。还有缺少就是时间资源吧，因为大三课程较多，尤其是实验课最多，除了课余的讨论时间，也就仅仅一两天时间去做项目。要说足够的话，我们最好的资源就是有一位在编程方面比较擅长的组长、还有擅长界面设计的队友、拥有PS技能的人员、擅长博客编写的人员；虽然时间资源不够，但是我们有丰富的精神资源，熬夜写代码，写博客，队友之间互相鼓励、支持。

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

• 组长会将每个人的任务分配好，基本是按一天完成几个任务，任务精度级算是精确到每天。

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

• 在测试方面相对薄弱，因为我们是手动测试，找出bug再解决，测试方面的资源有限，花的时间相对较少。对于美工设计我们还是相对比较重视，做出来的界面相对较美观，觉得其做起来也是并不容易，在文案方面也是相对重视，花费了好多时间在上面，包括博客撰写、任务分配等等。

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

• 没有，因为每个人都有自己擅长的方面，该做测试的人员做测试，该美工的人员做美工，开发人员做开发，如果交换一下就不一定做得来了，所以还是每个人都做自己擅长的，能做得来的才能节省时间更有效率。

5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 分配时，应该更加明确些，具体到某一点的哪些内容，否则会出现队员做了相同的事，而产生了无用功浪费了人力物力。同时沟通真的很重要，队员间要多多加强沟通，防止因为误解队员的意里而产生误会。       

四.变更管理

1. 每个相关的成员都及时知道了变更的消息?

• 每个成员都知道项目进行中的变更信息。我们小组的工作内容都发布在微信群上。小组成员都可以收到信息。为了保证，信息通知的灵活性，我们小组还有一个讨论组。每个人都可以及时通知和获得紧急信息。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

• 首先，在接手项目的时候，我们小组就开过会讨论，并确定了项目的核心功能。并且讨乱了该功能实现的难易。“推迟”和“必须实现”是这样界定的：1、核心功能中容易实现的必须在 alpha 版本实现；2、核心功能中有技术难点的推迟到 beta 版本实现。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

• 小组对项目出口条件的定义是：项目能够满足《毕设导师智能分配系统》的需求。一定的用户先体验，反馈良好。

4. 对于可能的变更是否能制定应急计划?

• 对于重大的变更，我们暂时没有应对计划,但是，我们有应对数据库变更的计划。我们对数据库进行了备份，能够在需要的时候使用恢复备份以及扩展数据库。

5. 成员是否能够有效地处理意料之外的任务请求？

• 能够。如果得知意料之外的任务请求，我们会经过小组讨，论接受挑战。然后我们将在 beta 版本完成请求！

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 首先应明确整个开发过程大体要做哪些事，将较大的模块落实到个人负责，如文档由某成员专门负责。

五.设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

•  设计工作是在Alpha阶段冲刺的时候开始的。由我们的队长领导，团队成员一起讨论来完成。在适合的时间，适合的人员中完成了适合的事情。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 有的。原型设计的时候，每个人对于某一内容的实现方式有不同的想法，界面的风格，颜色的搭配，等有了很大的分歧，最终是通过投票进行选择的。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 有运用单元测试，基本都是每个人测试自己的模块，在遇到实在不懂得问题，大家一起讨论，在测试结果符合后再合并到一起。测试过程没有采用工具，基本是手工测试，遇到问题就修改

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

• 因为每个人测试自己的模块，所以有些人的不是很了解。就登陆界面来说，在登陆的时候会出现第一次正确密码可以登录，以后再次登陆就会失败。后来修复了。其他的还有就是侧滑框的实现不是很理想。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 开发人员不多，所以能够严格执行代码的规范。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 学到了很多能力都是发掘出来的，只有去尝试，才能够进步如果重来一次，让组长更多地给其他组员加油打气写代码，指出代码不规范的地方，并说明该怎么写。

六.测试/发布

1. 团队是否有一个测试计划？为什么没有？

• 有测试计划

2. 是否进行了正式的验收测试？

• 也不懂什么是正式验，但是都有收针对各项功能都进行了测试

3. 团队是否有测试工具来帮助测试？

• 没有用到测试工具

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

• 各个模块的测试分配给各个测试组员，这些组员进行用例测试。从软件实际运行的结果来看，这些测试工作还是挺有用的，比如可以测试出一段JavaScript代码或PHP代码对于边界数据的处理是否合乎期望，测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。改进的方面，对于测试大家都不是很熟悉，所有并不是非常到位，所以下次会进行改进

5. 在发布的过程中发现了哪些意外问题？

• 在发布过程中确实出现了一些意外，发布的时候有点晚，在博客提交的时候完了一天。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 从测试中，我们也学到了测试对于整个开发过程是十分重要的，在平时自己写程序的时候没有发现这点，在这次团队开发中学到了很多，虽然做得不是很好，下个阶段会慢慢改进的。

七、总结:

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

• 产品核心的挑礼物功能已经实现，成熟度还不是很好。

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

• 磨合过了，要到规范阶段了，来点走心的，虽然我们组这阶段表现不佳，我们成员之间感情越来越好，这种情感高于我们的分数。配合也默契，有种共患难的感觉哈哈哈，我对我们接下来的表现也很有信心，希望我们越做越好。

3.你觉得目前最需要改进的一个方面是什么?

我觉得我们应该预先估计到一些可能出现的问题和情况，才不至于有时候出现问题大家都很惊慌，甚至悲观的想要放弃，做你害怕的事，可能你会发现，不过如此。还有时间观念很重要，效率要提高，除了敏捷冲刺阶段每天的站立会议，我们自己也有另外开会讨论，感觉效果还不错，大家一起讨论问题解决问题，氛围也比较轻松，我觉得面对面交流很有用，大家又是同一个班的，机会其实特别多。

4.照片

八、团队成员在Alpha阶段的角色和具体贡献:

团队作业10——事后诸葛亮分析