事后诸葛亮（团队）

Posted 2021-01-23 youberight

项目名称：大学生信用培养平台

大学生信用培养平台

队名：

我们还可以抢救一下

小组成员：
队长：苏华 180320063
队员：范媛媛180320074
队员：赵晓南180320078
队员：陶涛 180320076

1)设想和目标

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

• 我们完成的一个信用培养和记录的网站系统，提供学生信用的记录功能，设计并提供许多有趣的信用活动供学生参与，从而主动吸引和引导学生培养自己的信用素质。我们认为定义的还是很明确的，对用户场景的描述也很清晰(可参考我们项目之前需求报告中的用户场景章节)

2. 我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

• 我们在Alpha冲刺阶段的目标是完成用户管理模块（注册、登录、忘记密码、修改个人资料）和活动管理模块（活动发布、活动报名、同意报名、开始活动、活动结束、活动评价），虽然还有些bug但目前已基本全部完成。项目按照要求在Alpha冲刺截止时间前提交了，总体来说我们达到了目标。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

• 目前处于Alpha冲刺，后一阶段还未开始。

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

• 因为项目并未发布出去，用户量还不知，但我们请了其他的小伙伴来使用我们的系统，整体活动流程和我们事先的预想的没有太大出入，但有些地方还不够完善，还有所欠缺，比如页面布局不够美观吸引人等等，总体来说我们更接近了目标但还有距离。

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

• 前期我们花了很长时间在讨论项目框架的搭建上，回顾冲刺后期阶段我们发现，前期工作很重要，考虑越详细越全面，能很大程度上减少后期的修改代价。另外一开始安排整体进度时，未考虑到有些模块难度，时间安排紧凑，导致项目不如预期，好在后期冲刺赶上进度，以后应该会注意这块。
   

2)计划

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

• 在项目冲刺前期我们花了很长时间来讨论计划，而且基本每天也会在午休时间进行当天项目的讨论以及之后的安排，所以做计划的时间还是很充足的。

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

• 在计划阶段，队员之间有不同意见时，我们会进行商讨，然后进行适当调整。

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

• 在前期原计划工作基本都会延后到第二天，到后期队员之间配合也越来越好，项目进度也都赶上甚至提前完成，基本上原计划工作也都做完了。

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

• 我们基本每天都在忙于完成项目的一些基本模块的功能点，并没有做太多其他的工作。

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

• 我们每日安排的任务基本都有比较清楚的定义，比如完成登录功能，就要实现登录页面，用户输入正确用户名密码可以进入系统主页。关于衡量的交付件，就是每日在完成功能时，所有人进行该功能的测试，没有问题或者BUG就继续后面的功能。

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

• 整体来说，项目是按照计划进行的。虽然前期一些工作并不能按计划当日完成，但通过中后期调整渐渐赶上进度。整体来说没有太大波澜。

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

• 在冲刺阶段中期，我们留了一天的缓冲区，用于解决前期的一些遗留问题，同时为后期的一些工作做准备，缓冲区用于调整整个项目的进度。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 缓冲区放在中期我们觉得能起到一个承上启下的作用，是个不错的选择。但在前期出现问题，能立马进行调整，能使得有些地方能立马得到解决，而不用延到中期。

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

•  计划通常来说只是基线，很多时候并不能按照这个剧本走，因此要留一个缓冲区进行调整，我们在前期时计划时很多时间节点都定得比较死，当天项目完不成后续就会不断堆积，如果再来一遍，我们大概会把计划调整得更加灵活。
   

3)资源

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

• 人力资源：我们团队有4个人，大家都有一定的开发基础；
• 设备资源：四人都有自己的电脑，足够用来完成各自的开发任务；
• 时间资源：时间上稍微有些紧张，大家都有其他课程的作业以及各自实验室的任务，不过时间嘛，挤挤还是有的。

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

• 团队分配好各自的任务后，组员先进行自我评估，团队再结合整个项目进行总体评估，由于是主观评估因此精度不是很准确。

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

• 测试的时间有点不足，由于时间比较紧，团队没有专门的测试人员。

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

• 由于每个人负责各自的模块，所以要做的事情都差不多，总体来说，只要团员互帮互助，效率就能提高。

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

• 遇到问题如果自己花了很多时间都不能解决，就要尽早提出来，大家一起解决，团队的交流和沟通是非常有必要的，否则就会降低效率。

4)变更管理

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

• 我们有三个队员在一间宿舍，并且建了一个团队的qq群，有新变更马上就能通知到所有队员。

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

• 在时间较紧急的情况下，按功能的重要性，把较重要的功能分为“必须实现”的功能，把可以暂时缓一缓的分为“可以推迟”的功能。

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

• 我们的项目的出口条件定义就是：项目能够达到《需求报告》中的要求。

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

• 项目需求分析的时候有考虑到一些可能变更并在设计阶段做出了相应的设计，面对需求变更，希望能够做到改动量最小化。

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

• 如果说有额外的工作请求，我们大家都会一起讨论并统一意见作出相应的计划。

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

• 如果重来一遍，我们会设专门的测试人员和美工。

5)设计/实现

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

• 系统的设计工作是由我们小组的四个成员不断的开会来讨论决定的，基本是在系统开发初期的前几天设计完成。小组的成员都是很熟悉的人，大家在讨论的期间基本没有什么意见的冲突，是合适的人。

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

• 在设计活动进程的管理时，团队讨论初期就设定了几个活动流程，后来在开发的过程中发现参与者与发起者对于活动的控制不一样。团队进而又对该需求进行了详细的分析，设计出了比较好的活动流程控制。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 团队使用了UML来对系统的类进行分析，在设计过程中绘制了用例图来明确系统需求。使用单元测试，对系统后台实现的函数进行测试。UML工具帮我们更加明确了系统功能，类间关系。单元测试帮助我们在开发过程中更好的排错测试。这些工具都起到了很大的作用。随着项目的进行，UML文档也在不断的更新，这些区别的产生原因在于我们增加或删减了部分的功能，还有一部分原因是由于当初设计考虑情况的欠缺。需要部分更新UML文档。

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

• 在活动流程控制的过程中产生的Bug最多。因为活动流程涉及到两个用户，发起者与参与者对于相同的活动状态有着不同的操作，控制较为复杂。系统发布后发现，用户只有在重新登录后才能收到新消息。这个原因在于我们在开发的过程中，都是在不同的用户之间切换，没有考虑到两个用户同时在线的情况。

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

• 我们从以下几个部分对代码进行了审查：代码符合需求和规格说明。代码可读性较好。代码功能块划分较好，易维护。设计遵从常用的设计模式。较少存在重复无用的代码。开发过程严格执行了代码规范。

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

• 我们学到在开发初期，必须多花时间做需求分析，在需求分析过程需要站在用户的角度，考虑多种情况的发生。如果历史重来一次，我们会在更加认真的做前期的需求分析。
    

6)测试/发布

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

• 有的，团队在开发过程中，对每一个新开发的功能点都会进行测试。最终开发完成后，还进行了一次完整的系统测试。

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

• 进行了。团队对整个系统编写了规范的测试用例，并在系统开发完成后对系统进行了全面的测试。对测试出的问题进行了改正与复测。

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

• 使用myeclipse中自带的Junit jar包，其余大多是我们团队成员自己进行的黑盒测试。

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

• 我们团队在开发过程中，没新开发一个功能点，会进行一次自测，然后发布给团队另外三个成员进行互测。测试是很有用的，在我们四个人的测试中，总是能发现开发没有想到的情况，根据测出来的错误，系统进行了改进。

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

• 发布较为顺利没有发现什么意外的问题。
   

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

• 这个过程中，我们意识到了测试的重要性，测试总是能测出很多自测时没有意识到的错误。如果历史重来一遍，我们会尽可能学习一些测试工具的使用，使得我们的测试更加完备些。

7)团队的角色，管理，合作

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

• 我们根据每个人的擅长方向不同，分配等量的工作，以大家兴趣为主要依据来进行任务分配。每个人都发挥了自己的优势和特长，男女搭配，干活不累，所以我们的合作是高效的。

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

• 那必须的。一个项目的完美完成离不开项目成员每个人的努力，是集体智慧的结晶。每个成员都是这个项目的一环，离开谁都不行，环环相扣，自然离不开相互合作和帮忙，团队成员配合默契，气氛友好和谐。这也是我们项目组能很好完成项目的最大优势。

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

• 在项目协作完成过程中，肯定会出现意见分歧的情况，每个人对项目的理解和看法，基于此我们采取求同存异，以投票的方式选出最优的解决方案，遵循少数服从的原则，所以当团队中出现意见分歧时，归根结底还是要保持沟通和信息的对称，让每个人都可以发表自身看法，碰撞出创意的火花。

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 感谢我们队的每一位成员。 从最开始的选题到如今快要收尾，我们项目组经历了很多，很感谢各位队友的积极配合和互相鼓励，千言万语都不能表达我对各位的感谢。这段时间，我们团队经历过困难和绝望，我们凭借着永不言败的精神以及互相鼓励挺过来了，攻克了一道道问题和困难，也经历过欢声笑语，那是项目进度赶上预期的时候，大家都很开心，这段时间大家都表现的很优秀。总之，还剩最后一个阶段，大家不要虎头蛇尾，继续保持这个状态，继续加油，为我们的项目完美收尾继续努力，冲鸭，各位！

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

• 开发团队作为一个整体，遇到问题就要及时解决，不要觉得这个问题很简单问了会丢人，如果历史再来一遍，我们会继续保持这种状态。

8)总结:

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

• 我觉得团队目前状态更倾向于CMM。

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

• 我们团队目前的阶段应该是过了磨合期进入规范期。

 你觉得团队在这个里程碑相比前一个里程碑有什么改进? 

• 队员之间交流更加无障碍，对软件开发整个过程更加熟悉。

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

• 注重开发过程中的测试，学会多种测试工具。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 

• 快速反馈。我们在开发过程，每天都会利用午休时间进行讨论，有好的Idea时、想法或者思路时就会进行讨论，如果觉得可行就去动手实践。