• 课程名称：软件工程1916|W（福州大学）
• 作业要求：事后诸葛亮（团队）
• 团队名称：葫芦娃队
• 作业目标：对这次Alpha冲刺阶段进行事后诸葛亮总结。
• 作业正文：事后诸葛亮(葫芦娃队)

---

目录

一、设计和目标
二、计划
三、资源
四、变更管理
五、设计/实现
六、测试/发布
七、团队的角色，管理，合作
八、总结
九、会议照片
十、交换组员的交接和培训方案

一、设计和目标

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

我们的游戏主要用来加强感情娱乐开黑，用于缓解压力，增进关系。
对于定义，我们觉得很清楚
对于用户场景，描述详细

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

在本次Alpha冲刺阶段，我们小组的预期目标是在两个阶段（两周）里面完成这个游戏Demo的设计。其中，第一阶段（第一周）的目标为：完成最小基础场景的搭建、角色以及角色功能的设计。其中角色的设计部分包括外形的设计，而角色功能的设计包括角色的跳跃、移动、飞行等一系列操作的设计。然后第二阶段（第二周）的目标为：对关卡进行设计与搭建以及进行游戏测试和感想调查。在关卡的搭建上，需要实现前期设计的关卡功能，而在游戏测试中需要达到游戏流畅不卡顿。感想调查则是对游戏进行建议并且提出实质性的建议然后进行讨论后对游戏进行改进。
对于用户数由于游戏未发布，用户目前是开发人员。

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

软件工程质量有提高在项目成果上，因为实现了项目雏形。衡量方式是至少有个产品可以使用了相较于之前的文档而言。

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

由于游戏只在开发测试阶段，因此还没推广，没有用户量。由于我们已经实现了游戏的基础玩法，距离游戏大成的目标已经更近一步了。

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

要提早进行开发，前期文档花费时间较多。
如果能重来，我们一定一定提前学好技术栈（笨鸟先飞）。

---

二、计划

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

是，在具体开发项目前已经历过长时间的需求分析和项目设计，组员也经历了多次讨论，游戏的玩法已经在开发前完全敲定，组员分工也事先得到合理安排。

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

我们采取求同存异的方针，先统一组员都赞成的设想。对于不同的意见，采取折中的办法，尽量做到所有人都能接受。如果实在无法统一意见，那么采取少数服从多数的原则。

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

我们采取求同存异的方针，先统一组员都赞成的设想。对于不同的意见，采取折中的办法，尽量做到所有人都能接受。如果实在无法统一意见，那么采取少数服从多数的原则。

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

学习Unity时，由于视频是英语口述，且没有字幕，所以一个视频需要反复看几遍才能大致理解，后来发现某网站有自动字幕功能，且还能自动翻译，问题就解决了。
另外就是BUG调试重复（因为没有头绪，也不好做调试，进度就卡在了调试），花费了队员时间。

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

是的，基本都有

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

按计划进行，意外是项目中使用github for unity,来进行unity项目的源码管理，但是这个插件没有提供克隆到本地的功能，而直接从github网页上下载又无法运行，后面查明了是git lfs（大文件管理）方向的问题，最后用用gitkraken和其的提示的帮助文档，下载了相应文件解决的克隆本地的问题。

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

有的，用于查缺补漏，以及任务交接。

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

根据新队员掌握适当分配任务。学习一下局域网的实现，并考虑一下工期是否能实现

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

学习了Unity制作简单游戏，学习了Github管理代码，学习了开发前的文档撰写，学会了Markdown写博客。
学会了团队协作以及时间管理。
如果能重来，我们会多看视频早准备。

---

三、资源

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

有，开发用的Unity已经很成熟，有大量教程可以学习。并可针对具体任务提供具体教程

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

各项任务的分配是以难度划分人力等资源的，还综合了个人的意愿和擅长方向。

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

人力资源充足，小组有7个成员。游戏需要的素材使用的是CorgiEngine资源包上已设计好的组件，所以暂时没有美工上的问题，但是如果以后要拓展游戏玩法。文档、博客的编辑有专门组员来做。

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

有，一些同学学习能力不是很强，需要别人的帮助。

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

加强团队交流，对于新掌握的知识，尤其需要引路人的指引。队长对与团队成员学习进度把控很重要。

---

四、变更管理

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

我们小组一般如果在项目上有很大的变更，会第一时间在小组的qq群和微信群中通知所有小组成员，因此组员接收消息都会比较及时，但不能保证确实每个人都受到热销。

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

由于我们小组开发的是游戏项目，游戏玩法是整个游戏的核心。因此我们把游戏的基础玩法列为必须实现的功能，在α阶段必须实现游戏的基础玩法。而一些扩展功能，例如更多样的游戏玩法或者联机等功能，我们决定推迟至β阶段来实现。

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

在需求报告里的性能、界面需求等模块中有比较清晰的定义。

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

没有应急计划，但能通过具体分析具体解决。

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

没有意料之外，如果有的话就是协助调试BUG了。能处理额外的工作请求，不过花费时间。

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

队员间的沟通很重要，及时的沟通能避免一些不必要的麻烦。如果能重来，我们会制定应急计划，加快应对变更的速度。

---

五、设计/实现

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

设计是由大家讨论完成的。一开始大家就讨论了地图的数量，需要的基本的要素（比如场景里的一些小机关，小物品、道具之类），以及地图的风格。但是地图的轮廓没有定型。差不多应该在合适的时间完成了。

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

有。有时候感觉各方面都可以的设计，却有不同组员提出两个方案。组内讨论就解决了。

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

有用uml分析过我们的项目。先前的uml文档确实大致前期指导了我们完成了部分脚本框架的开发，之后还是在细节方面对其做了很多的补充。基本是测试驱动，我们先完成了大致框架，再向其中添加我们想到的东西，一添加足够多的部分，我们就进行测试，功能有没有实现。所以我们的进展还算顺利。

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

主要BUG产生在插件的水土不服。游戏场景没有什么重要bug，因为我们过程中做了很多测试，bug在其中就得到解决。经验不足。

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

先由编写者进行自审，而后组长粗审，我们的脚本代码比较规范，基本都说明了，一个函数是干什么的。

---

六、测试/发布

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

有大概的计划，因为测试对于我们的游戏相当重要，基本都是一步步测试过来的。但unity的单元测试部分还处在学习阶段，还不能对每个应该测试逻辑都进行相应的单元测试。

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

进行了部分但是不够与高效和严谨。我们对最后的功能进行了一个罗列，通过untiy测试插件一个个完成了对其中列出了功能模块的测试，并且反馈到表格上

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

有。目前只是使用了unity自带的Editor Tests Runner进行单元测试

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

软件效能，使用unity内建工具像是 CPU Profiler、Memory Profiler、或是 5.3 才有的 Memory Analyzer，但是我们没有对其深刻的学习理解。从软件实际运行的结果来看，游戏能保证一定的帧数。所以希望之后贝塔阶段能让团队中的几人人深入理解并进行测量。

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

暂时还没有发布，项目已经导出，供用户进行随意测试，暂时没有太大问题。

---

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

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

组内一开始采取任务分配制，每个人可以自主认领自己的任务，这样每个人都可以找到适合自己能力的任务。而没有被分配出的任务最后由组长分配，与组员协商，能者可以多接受任务获得更高的贡献度。

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

在Unity上开发游戏是我们组之前从未接触过的，因此基本上我们都是从零开始，边学习边开发，遇到不会的难题我们会交流讨论，共同进步。

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

我们的项目管理者是组长，由组长统筹兼顾各个组员的任务，如果组员在任务分配或者合作方面出现问题，主要方式还是靠沟通来解决。

---

八、总结

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

初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

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

磨合

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

比以前相比工作分配的更加有序些，明白了交流的重要性。

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

能更合理的分配工作，与交接，从而充分调动人员的积极性，同时保证工作方向的统一性与工作时间的相对平衡。

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

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
在比较早的阶段完成大概游戏玩法的demo。
2.经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

鉴于unity与游戏迭代开发的性质，一个功能添加就能在单个场景游戏中体现，而且各种角色功能可以分的比较小而快完成。

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

提高可读性、可维护性、可变更性。
可读性：不要编写大段的代码，合理使用释义名称与注释
可维护性：预测可能发生的变化
可变更性：
通过提高代码复用提高可维护性
利用设计模式提高可变更性
以职责为中心，根据职责分配行为决定类
复审时，针对这几点严格复审与交流修改
同时要让人员清楚认识到到代码规范对后续测试的重要性

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

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

由于我们小组对架构知识量不足，首先先从规范的架构学习理解，并对代码进行复审，对不符合要求或者不好理解的部分进行让大牛与原代码编写者合作进行重构，衡量的方式的就是越少的代码的抱怨，质量就越高。

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

对新手从基础教程入手，老手复审他的使用，并提出建议来改进他的应有技术与规范。

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

深刻明白了项目重要的事先准备，以及事后收尾的测试部分。

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

我们的游戏项目在之后要计划给其他同学用户试玩，吸取他们的游戏意见进行改进，对用户建议实现进行权重分析排序，在有限时间有效的完成用户需求提升可玩性。

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

安排重视文档编写工作，有良好沟通能力的人编写文档，从新手，其他人的角度去复审。

对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

在领导和管理方面，就目前的情况来看，我认为需要改进的地方有这些。1.在管理软件的具体功能的生命周期方面可以加以改进，将每个方面的生命周期尽可能具体的展现出来。2.规格说明书可以更加细致并且具有更加良好的阅读性，使得开发和测试人员不会因为模棱两可的语句而产生歧义。3.应当主动协调并决定各种需求的优先级，而不是直接将任务摊派下去，这样就使得所有任务的优先级一样了。4.带领其他成员确保项目保持功能，时间以及资源的合理平衡。在绩效考核方面，现在的贡献度就是一个很好地绩效考核策略。

对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

在软件开发的过程中，设计模式是非常的重要，当时在上设计模式的课时，觉得这个课程非常的枯燥无聊，也不知道学了有什么用。然而在软件开发过程中，却发现，如果选择了正确的设计模式，会使软件开发事半功倍，同时软件的稳定性以及可扩展性也会非常好。还有就是关于软件测试部分，对于软件也是至关重要。因为软件测试可以发现一些平常根本察觉不了的bug，从而大大提高软件的可靠性。还有就是软件开发的瀑布模型有很大的缺点，那就是如果使用瀑布模型开发软件，后期需求如果有较大更改的话，整个开发会变的非常的麻烦，甚至要推倒重做。同时敏捷开发的缺点也十分的明显。敏捷开发由于是在每一个阶段都进行一轮的开发，测试与发布，这种开发模式可以很好地适应用户需求的变化，但是对于开发人员来说工作量非常繁重。总而言之，就是每种开发模式都有自己的缺陷，只能说没有最好的开发模式，只有适合的开发模式。

---

九、会议照片

---

十、交换组员的交接和培训方案
在进行组员交接的安排上，首先对新进来的组员举行一个欢迎仪式。然后对他介绍我们的项目（小人大作战）的详细情况。然后让他阅读一下之前发过的博客，其中重点是需求文档和设计文档。
然后具体对我们组被交易的组员（欧福源）目前的工作进行介绍然后让他们两个重点进行任务对接。
培训方式，以任务分配的针对性教程为主，包括官方教程与项目文档和资源包教程的针对内容。