目录

一、设想和目标

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

• Nav（内福）—— 专属于福大人的学习、工作、生活、娱乐的指引式平台，帮助新生更快适应大学生活。
• 定义清楚，选取了大学生最相关的几个方面进行实现。
• 典型用户：想要更加快速全面了解大学生活的福大新生、福大学子。
• 典型场景：面对学习、住宿、安全上的问题可以到生活须知板块了解一些通识；对于专业学习、职业发展有困惑可以到学习社区进行资讯浏览；对于校内出行或者建筑指引有需求的可以使用校园地图的导航功能；在娱乐天地板块可以进行日常分享，交流交友等。

2. 我们达到目标了么？原计划的功能做到了几个？按照原计划交付时间交付了么？

• 达到了目标，原计划的功能全部实现，按照原计划交付时间交付。

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

• 有所提高，对照上一阶段，大概成长了30%，主要从人员、效率、质量等指标来衡量。
• 在团队协作方面更加娴熟，能够以更高的效率在日常沟通交流中打成共识和交接。三个群进行联系，降低了组织耦合度，协作效率提高50%。
• 在项目文档的编写上更加规范迅速，大家都更加重视文档类的工作，能够更加用心花时间去形成良好的文档报告。文档质量提高30%。
• 在代码开发方面，技术更加熟练，开发效率更高。效率提高30%。

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

• 尽量能够进行充分沟通，并进行想法实现设想后进行新功能开发，避免反复修改，重复工作。 

二、计划

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

• 有，在alpha冲刺结束后，beta冲刺开始前的一两周时间内时不时地进行讨论交流，对于beta阶段所要求的任务工作有了初步的判断。在正式开始冲刺之前，组长会在召开了“凡事遇则立”的会议后，听取各方的意见和建议，花费一天的时间仔细地做计划。

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

• 尽量以协调统一为主，衡量利弊、效益和可行性后，在不同意见中找取一个平衡点，择优听取。

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

• 原计划的工作最后都做完了，得益于我们合理的计划和团队成员的共同努力。

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

• 无。

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

• 是的，在任务开始前进行内容详细的制定，并在最后收付时进行验收。

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

• 按照计划进行。
• 出了意外的话最多也就是在做原计划外的新功能时，可能面临一些原计划的改动。
• 没估计到的风险也就是在最后阶段可能由于新功能的加入导致时间有些紧张。没预估到的原因是设想中只打算完成原计划工作量。

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

• 有，缓冲区为2-3天的预留时间，起到了一定的作用，让我们的收尾工作能更加从容。

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

• 继续实行缓冲区计划，留出2-3天于最后进行收尾，甚至可以进行加班。

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

• 详细的计划有助于整个项目有序地推进，计划的严格执行能让项目减少很多意外，让人省心。
• 改进：可以适当留出余地进行拓展开发，即原计划外的工作。

三、资源

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

• 有充足的人力、时间、硬软件资源。

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

• 依据以往类似开发经验和进行初步调查研究后进行估计，有一定偏差，精度可达80%。

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

• 足够，基本上由开发人员一手承担，组员的能力和知识储备都足够，于是测试没有遇到太大问题。
• 对于美工设计、文案等工作确实低估了难度，因为缺少经验，对于很多事情都是想当然，导致错估。

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

• 组员之间的能力水平难免会有差异，每个人擅长的地方也不一样，不可能要求每一项任务都做得又快又好，这样就失去了团队协作的意义。只要整体效率保持在线即可。

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

• 在不需要编程的资源上需要多加重视，投入更大的力度。

四、变更管理

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

• 是的，助教和组长等第一时间通知每个相关的组员。

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

• 评估指标。根据功能的成本、必要性、难度、创新性、用户群体等指标进行评估。
• 商讨决定。根据组员的工作能力、完成效率等方面进行权衡讨论决定。

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

• 功能的实现可用，测试的通过，文档的形成，开发人员的认可，答辩的结果。

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

• 是的，有应急人员和计划，确保最小化变更的影响。

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

• 是的，面对突发的请求，都能较好地完成，会通过灵活变通，协调时间来达成目的。

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

• 人员变更正常不过，我们要时刻做好心理和物理准备。
• 改进：让每个成员做好自己工作的总结和规划，以面对可能到来的人员变更。

五、设计/实现

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

• 由组长/小组长完成，一般在任务开始阶段，是合适的人选，有较好地组织能力和设计才能。

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

• 有的，团队最后采用先协商，实在遇到解决不了了由负责人决定。

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

• 是的，运用了单元测试、UML、Axure等工具，工具十分有效。
• 在类图的设计、接口的设计上做了一些修改。
• 有的是在听取老师的意见后进行修改，有的是根据实际开发情况进行修改。

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

• 涉及到数据量较大的功能，因为牵涉到数据，功能实现较为复杂。
• 对于这方面的开发缺少足够的经验。

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

• 由不同的组员进行阅读复审，执行了代码规范。 

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

• 设计不是一成不变，但肯定要有合理的初设计，方便后续进展。
• 改进：对于设计进行回看，尽量考虑周全。

六、测试/发布

1. 团队是否有一个测试计划？

• 是的。

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

• 是的。在最后收尾阶段花了1-2天的时间进行了多方位的测试。

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

• 是的。使用了JProfiler等测试工具。

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

• 测试要先制定要测试的方向和内容，要尽可能的覆盖全面。
• 改进：对于测试应该早日提上议程，尽可能地将问题解决在开发阶段。

七、团队的角色，管理，合作

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

• 根据每个人的能力、兴趣和团队的需要确定，做到了人尽其才。

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

• 互相帮助是再正常不过了，我们是一个team。

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

• 协商讨论为主，提出各自的看法，试图打成共识。若遇到实在无法解决的问题，有负责人拍板。

八、总结

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

• 已管理级(Managed)。

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

• 规范。

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

• 明确了任务细节和时间。

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

• 计划制定方面。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

• 小组内设定专人、管理者进行这方面的审查，适当减少其其它工作量，负责代码质量的保证。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

• 请教有经验的开发者，在摸索中前进。

3. 其它软件工具的应用，应该如何提高？

• 汲取行业大牛的开发经验，学习优秀团队的开发过程。

4. 项目管理有哪些具体的提高？

• 人员的配置和时间的安排。

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？ 

• 计划开发后台管理，记录用户使用数据。

6. 项目文档的质量如何提高？

• 认真学习，规范书写，仔细审查。

7. 对于人的领导和管理， 有什么具体可以改进的地方？

• 在协商和决策方面做更好的权衡，杜绝犹豫不决的现象。

8. 对于软件工程的理论，规律有什么心得体会或不同意见？

• 软件工程是一门理论和实践性都很强的课，需要多多体会领悟其中道理。