软工_Alpha阶段事后分析总计

1.设想和目标

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

我们的软件主要解决狼人杀玩家在游戏时的一些痛点。因为之前自己对于游戏中那些不方便的地方有过体验，而且在前期做过调研，所以要解决的问题和典型用户和场景都有比较清晰的了解。

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

在开始之前，由于订立了比较激进前沿的技术栈选择方案，用了很长的时间在各种技术的学习熟悉上。在关于计划方面，虽然也很认真的做了规划，不过慢慢做下去发现可能跟最开始说好的不太一样。。。

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

团队成员都很敬业和谐，基本上没有什么分歧，不过有时候因为其他科的繁重作业而对计划的执行有些拖延

1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

因为Alpha阶段设立的目标就是发布内部测试版本。在克服了各种各样的困难之后。。。似乎没有时间发布给用户进行测试了。

2.计划

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

计划赶不上变化，最初计划是在Alpha版本开发结束后进行iOS和Android版本的同步上线。但是目前来看，中间选择座位和房间设置还有没有解决Bug，界面也没有达到可以面对用户无情的指责的地步。。。主要还是因为高估了我们上手一个新技术的时间，一共一个月的开发中可能有三周的时间都花在了熟悉新技术，验证新技术上，留给我们开发的时间已经不多了。虽然最后加班加点赶回了很多进度，但是离上线还有那么一周左右的工作量。

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

可能自己在学习方面应该尽快上手，不应该看了那么多的是讲解视频和博客，因为最后都差不多忘了。

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

这点做得并不够好，后面赶进度的时候大部分都是自己在完成自己负责的部分的改进，并没有很好的分拆每一项任务。

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

还是之前说的，学习时间大大超出了预期，还有之后的编译实验，压缩了做项目的时间。

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

如果说有的话，就算是从第四周周末到项目展示的周四这几天的时间吧。最后项目能差不多做完，对亏了这几天的缓冲区，我们在缓冲区的时间中做出了卓越的工作。

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

将来会留下更多的缓冲区使得我们的项目推进的更从容。因为Alpha阶段毕竟学习占去了三周的时间。

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

关于计划，我觉得如果能重来一遍，我会在最开始时规划时定义更详细的每日计划，这样能够更好的控制项目的进度

3.资源

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

在人员资源上，我们小组只有四个人，而且我们的任务相当庞大，这就导致了我们时间的紧张和工作的繁忙。上天多给我们几个人吧。。。

在开发资源上，很多技术文档都是英文，也有很多甚至没有技术文档，所以自己摸索的东西很多。

在相应的设备资源上，我们有一个组员的电脑一直没有能够装上开发环境，只有一台电脑开发安卓端，一台电脑开发iOS端，一台电脑开发后端，有时候有些局限。而且iOS开发者账号还需要自己买，服务器也不能方便的外网访问。这些都只能自己解决也占用了很多时间。

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

最开始大部分任务估计也就是根据大概估计的时间来算的，实际完成的时候会发现难度大大超出预期，基本都要花接近一倍的时间来实现。估计精度并不高

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

上面也说了，基本上没有哪种资源是足够的。。。我们都是在克服一个又困难中走过来的。反而文案方面，是最简单而估计最准确的。

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

文档方面我花的时间实在是很多。不过也没办法自己就是想的比较多。。。可能这方面能交给队友就好了。

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

多找点队友啊！缺人的影响不是盖的。

4.变更管理

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

每天的小组会议（虽然后来够十次了以后就犯懒没有写会议记录），再加上后来的半结对编程，还有全部托管在GitHub上的代码和实时更新的API文档，所有组员都养成了良好的习惯实时同步。这点我们做的很好。

4.2 我们采用了什么办法决定"推迟"和"必须实现"的功能？

我们着重于完成基本功能和几个之前的用户调查中用户反响较高的杀手级功能，因为有了调研，所以我们做决定的时候也更简单。

4.3 项目的出口条件（Exit Criteria – 什么叫"做好了"）有清晰的定义么？

这一点可能 并没有定义。

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

是的，我们并没有预期到之前学习阶段的进度拖延，之后在分析了项目进度和目标后，果断采取了全员结对共同公关的方案，取得了良好的效果。

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

比如说后端，我们对于后端的需求经常修改变换，而后端能够一直非常好的完成前端的需求。

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

计划总赶不上变化，在项目之初，有时候并不能很好的考虑到之后的变化，那么就先开始工作起来，等到慢慢熟悉，再变更起来也不是什么麻烦事。最重要的就还是不要有太多的畏难情绪，最重要的就是要动起手来。

5.设计/实现

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

设计主要是我来完成的整体的技术选型和架构设计的。这个不好评价自己，看看其他人是怎么说的吧。

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

这个问题有些多，虽然在确定设计方案之后，我大致都进行了相应的技术验证，但是由于之前并没有了解，难免会出现一些模棱两可理解不清的问题。这些问题随着大家对于技术的熟悉了解都自然而然的解决了。

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

这些工具没有用到，但是我们使用了MockUp软件进行了原型图的设计，不过最后看来实际做出来的结果和原型图还是有一些差距的。

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

在有关WebSocket通讯的方面Bug比较多，网络方面的Bug也是难免的，在发布之前就发现了加入房间和选座位部分的Bug，可能是异步服务器处理的问题。

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

因为是各自开发，并没有对其他人开发的模块进行代码复审。不过在程序中公共的数据处理部分，代码经过了三名前端开发人员的共同检查。

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

我觉得我们应该更好的从一开始就贯彻持续集成的理念，这样对于软件Bug的回滚以及错误管理都是一个很好的解决方案。