标签：诸葛亮 定义 无法 遇到 人力 同学会 应对 状态 网络
1.团队成员
- 郑西坤 031602542 （队长）
- 陈俊杰 031602504
- 陈顺兴 031602505
- 张胜男 031602540
- 廖钰萍 031602323
- 雷光游 031602319
- 苏芳锃 031602330
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件是要为用户提供一个可以在线组队的地方，让他们学习生活都可以有个伴。
- 定义清楚。主要是实现通过发布拼帖与加入组队两个功能实现在线组队。其余的还有聊天功能等。
- 对典型用户和典型场景有清晰的描述，切合问卷调查与用户场景分析来进行开发。
2. 是否有充足的时间来做计划?
- 有。每个阶段都有每个阶段的任务，问卷调查、需求分析、原型设计及修改等，从十月份开始，到目前已有两个月的i时间。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 一般会在开会时收集不同的意见，进行讨论后投票决定。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 设想的时候感觉还是很不错的，但是在实现的时候没有考虑到成员的自觉性，也没有考虑到卡法的实际难度比想象的高。
- 在定制目标的时候，对各种东西的衡量还是要保守一点。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 服务器与数据库部分大都已经完成。还有一些功能的实现未完成。
- 计划还是比较完善的，但是由于执行不周、不够自觉导致未能达到预期效果。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 计划的时候安排了一些附加功能的实现，但是后来发现与主要功能实现的时候有与其差不多的功能，那样再实现附加功能就多余了。
3. 是否每一项任务都有清楚定义和衡量的交付件?
- 大部分都有，因为在发布任务时给了较清晰的要求文档。
4. 是否项目的整个过程都按照计划进行?
- 一开始有按计划进行，但是后期随着开发难度加大以及成员自觉性降低，就逐渐跟不上计划。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 有。可以说起了一定的作用吧。但是后期难度高的同时成员自觉性也降低了，所以缓冲区并没有达到预期效果。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 对任务进行更为明确的时间安排，制定每个时间点需要完成什么目标。
- 多集合队员一起出来开发，减少成员自觉性不够带来的影响。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 实际开发没有跟上理想开发进度，主要是执行方面的问题。
- 还是需要多督促、多集合开发，对队员的要求更严格一点，不能太宽松。
资源
1. 我们有足够的资源来完成各项任务么?
- 时间上来说应该还是足够的。
- 人员上来说7个人也差不多。但是每个人都没有开发经验，所以在时间的分配上还不够合理，开发进度的把控也不准确。
- 开发过程中，可以咨询教师、助教等，但我们并没有咨询。网络资源可以说是相当丰富的，但是有好多都不是完全正确的，参考起来有点麻烦。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 在任务的时间估计方面，主要是根据分配人物的难易程度，但都会预留出一些时间来应对各种可能出现的情况。前期的开发还很生疏，所以基本上是两天开一次会，前期精度是两天，后期Alpha阶段冲刺每天都要汇报进度，所以后期精度是一天。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
- 用户测试的时间按照目前的进度来说可能会不够。软硬件资源是足够的。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
- 任务的分配是按照队员会做什么且想做什么来分配的。能力不足的同学分配的任务比较简单，学习能力比较强的同学会分配难度高一点的（也有考虑一些同学的开发愿望）。所以虽然会有这样的情况出现。（对能力不够的同学来说，任务让比较强的人来做效率会比较高，但是比较强的队员需要去完成其他难度高的任务）
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
变更管理
1. 每个相关的员工都及时知道了变更的消息?
- 有创建项目开发的群组，所以有什么变更消息都可以即使通知到，开会的时候也会具体说。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 在Alpha冲刺开始前有进行开会讨论来决定冲刺时间里的主要任务。
3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?
4. 对于可能的变更是否能制定应急计划?
- 如果项目功能等需要变更都会在开会的时候进行讨论。
- 在人员安排方面的变更一般是延迟任务截止的时间、减小工作量或者进行各模块人员调整。
5. 员工是否能够有效地处理意料之外的工作请求？
- 部分员工可以。在提出其他工作请求的之后，一般都会先进行该工作请求。但是部分员工可能无法实现。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 团队没有应急方案，只能在一次次开会时讨论。
- 应急方案要提前制定。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作团队讨论的时候就开始了，在进行需求分析的时候完成的，是由团队所有成员一起讨论、由需求分析的同学和做界面原型设计的同学来实现。
- 时间应该是合适的。完成的设计也是所有成员认可的，所以人也是合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有。在早期需求分析的时候，对一些功能是否需要存在有不同的意见。
- 采用少数服从多数解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
4. 什么功能产生的Bug最多，为什么？
- 服务器方面。因为比较难，所以在实现的时候经常会产生错误。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 代码会由队长进行审核，发现个别队员没有规范，主要没有使用要求文档里规定的命名。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 发布了要求文档之后，交上来的代码还是有些不规范。
- 对队员进行强调，不规范的代码退回整改。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
- 只有一个大概的测试计划。在测试阶段会开会讨论具体计划（根据时间情况决定）。
2. 是否进行了正式的验收测试？
3. 团队是否有测试工具来帮助测试？
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 都是使用手动代码测试。将遇到的BUG进行改进。
- 作用很小，耗时耗力。改进：首先要对bug进行记录分类，其次要改进代码测试的方法。
5. 在发布的过程中发现了哪些意外问题？
- 虽然还未发布，但是在目前的app运行情况与理想还是有点不一样，因为一些操作都需要代码实现，但是惯性使然让我们觉得这个操作本来就有。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
3.你觉得目前最需要改进的一个方面是什么?
事后诸葛亮
标签：诸葛亮 定义 无法 遇到 人力 同学会 应对 状态 网络
原文地址：https://www.cnblogs.com/hizxk/p/10051367.html
