【Beta阶段】M2事后分析

先上照片，最后一次开会了啊。。。

计划

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

答：没有全部做完，到目前为止，我们的还有几个实验的报告生成功能没有上线。这几个实验的数据处理文件已经写出来了，但是由于实验报告生成功能最后整合人员刘乾同学任务量比较大，没有多余的时间完成这几个实验的整合。同时由于后期物理实验本身的停止选课，项目经理于是优先考虑了论坛方面的发展与测试。

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

答：没有，有了第一阶段的经验，在第二阶段中我们做的每一件事都发挥了或多或少的价值。

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

答：是的。经过第一阶段之后，没有了关于学习上的任务。项目经理对每个人安排的任务都是根据每个人的能力安排的，不需要时间来学习。除此之外，每个人的任务都是可以定义任务的大小和完成质量。比如，关于一个数据处理的任务，根据第一阶段的经验，完成一个数据处理任务大概需要花2~3个小时（根据实验的难度），而最终完成的数据处理文件都有规定模板（强制要求的注释，代码格式），因此这个任务完成的质量很容易区分。

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

答：整个项目的过程不完全按照计划进行。在β阶段的迭代开发过程中，我们的课程上的压力达到了极点，有很多课程都有大作业需要做，因此原本计划在某个时间完成的任务，我们推迟了完成。这就是一个风险，差一点就导致我们的软工项目停滞不前，但是大部分团队成员选择熬夜也坚持将软工项目一点点向前推进，虽然速度比较慢，但是我们还是在尽我们最大的努力去完成。

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

月25某一门考试之后的那一周。缓冲区作用挺大，前端人员实现了实用小工具界面。我们也有时间尽量找bug，完善我们的项目。

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

答：暂时没有下一次迭代开发的计划。

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

答：第二阶段学到了很多东西，主要是思想上或者说是感性上学到了很多东西。在第二阶段开始的时候，团队中大部分成员都有课程上的压力，但是我们没有放弃，我们努力突破自己，突破的不仅仅熬夜，突破是自己的心理承受能力。一次次的压力让我们不断学会承受，让我们强大。如果历史重来一遍，我们会选择早点完成其他课程上的任务，让这一阶段有足够的时间让我们完成开发。

资源

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

答：资源永远是不够用的，这次软工项目让我更深刻的认识到了这一点吧。资源+劳动力=生产价值，正是在有限的资源内最大发挥人的工作潜力，才能体现一个项目的价值。在本项目中，我们多次调整了资源紧缺（尤其是人力资源和时间资源）与需求的冲突问题，尽可能去精简计划，保留其中的核心部分，并寻求捷径加以实现，以保证在资源不足够的情况下仍能将各项任务完成到一个可以令人满意的状态。

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

答：β阶段有很多课程的大作业临近截止，时间资源相对紧缺并且处于极端不稳定的状态。因此我们只好动态估计各项任务所需的资源，即采用两路并行的策略，将主站功能的完善和新功能的前后端工作分开，在最开始的scrum meeting中将整体的工作规划布置下去，尽可能将流水线的工作模式划分为工作碎片，依据每个人的需求动态地将大任务划分为一个个小任务从而得以估计时间需求。项目的工作是围绕人展开的，因此工作中的时间需求和任务规划也要重视这一点。通过一段时间大家的磨合，我们也对彼此的工作模式有了一定了解，在任务的部署和分配上，对每个人工作所需时间资源的估计也可以做到更加准确。具体来说，我们估计时间资源并分配任务的方式是大教堂计划思想与人文思想相融合的。

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

答：均不足够。对于不需要编程的资源没有低估难度，在UI方面投入比较大，并且为了减轻前端逻辑的压力直接采用了现有的成熟方案，节省了大量的时间在其上进行优化与改进。

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

答：整个团队的人员配置已经比较精简了，每个人所负责的任务也相对较合理，所以每个人在团队中所扮演的角色都是无可替代的。目前整个团队的负荷已经达到饱和状态，这也是拜本学期各大高压课程所赐吧。

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

答：实话说饶弯子的地方是有的，而且还不少。如果不考虑能力方面提升的话，我们会在时间规划上做一些改进，在课程选择上有所取舍吧。

变更管理

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

答：大部分时候是的，得到通知的员工会进行相关的反馈，如果一段时间内得不到反馈，会再次进行联系确认该员工收到了变更的消息。

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

答：我们通过社交网络建立了用户反馈机制，通过用户的反馈及时调整功能实现的优先级，优先处理热门实验和用户期待度较高的功能。

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

答：当压力测试和兼容性测试完成并且这两个测试基本没有问题，我们就认为可以发布了。

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

答：还没有……

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

答：这个可以处理，项目经理给定工作请求时会通过结对编程的方式给予一定的新手入门和指导，从而能够有比较好的处理问题的能力和针对具体问题有着具体的解决方案。如果还有别的问题或者突发情况，我们会在scrum meeting中讨论，确定下一步的计划。

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

答：这一点上我们觉得做的还是相对较好，重来一遍我们会更加注重团队之间的互动与联系，并且可能考虑更加方便与即时的方式对消息的变更进行通知与推送等。

设计/实现

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

第二阶段开始之前，所有人开会讨论了一下第二阶段我们网站可以考虑的一些发展方向，包括各种功能的添加和原有功能的扩充等，所有人各自发表了自己对网站前景的见解，最后通过讨论，确定出意见一致的发展方向

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

感觉这个阶段并没有明显的遇到这种情况，因为关于设计，我们开会的时候都详细地讨论过各种方面的可能性，也经过充分的磨合和考虑，至于具体的架构或前端画面设计我们就全权交给负责人来定夺，他们觉得这样好就是好，我们充分地信任他们的能力。

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

由于上阶段所做的测试不够充分，所以我们在这个阶段加强了对测试的力度，通过更加全面和完整的方法去进行网站各种功能的测试。

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

本阶段数据计算核心部分bug较少，主要是经过了不少开发者或用户的测试了。这个阶段的主要问题在于论坛的各种权限问题，某些权限的用户在使用时会面临按钮的显示问题或一些功能无法正常使用的情况。还有就是论坛的一部分功能还需要进一步完善，论坛的显示也有一部分bug。我们的负责人们将会尽快完善这些bug。

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

代码复审是由严格的管理层次进行的，数据处理的主程序员、前端工程师、后端工程师的代码都需要经过我的复审。大部分代码是遵从代码规范的，没能做到所有的都严格执行代码规范。

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

其实我觉得，我们团队从项目开始到结束，各个方面做的都蛮好的，大家的自律性也都比较强，而且对产品也都希望能做到越精致越好，我觉得这是我们团队的优势。如果历史重来一遍，我们还会走现在的路，也许我们会更加精进各个方面，但是我们还是会按着现在的轨迹走。

测试/发布

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

按照我们的计划，我们会在开发完成后进行黑盒测试，之后线上进行压力测试。对于实验处理文件的单元测试已经做了，对浏览器的兼容性进行了回归测试和黑盒测试。对于网站架构单元测试和回归测试由于人力和时间关系并没有做太多。

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

进行了正式的验收测试，我们测试了基本大部分大众浏览器的每个界面的显示与功能情况。

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

在压力测试时，我们首先使用了安全分析和攻击工具burpsuit来模拟高并发请求，我们发现在1G内存时，其并发请求处理的最大数是6,之后服务器端的mysql服务会崩溃，我们分析mysql的错误日志，发现这个崩溃的原因是因为mysql在申请innodb_buffer的时候无法申请到内存，也就是说，报告生成这个操作吃尽了1G内存，之后为了使并发量提高，我们修改了mysql的配置文件，将innodb_buffer_pool_size的大小从16M改为8M，之后再测试时，其并发峰值到达了16，有了显著提高。

之后，为了进行准确的压力测试，我们使用了siege进行并发压力测试，使用top监视服务器运行状态，使用wireshark监视网络流量。大体测试结果如下图：

上图为对网站页面的普通get请求的测试。

测试结果

上图是对报告生成的并发测试。

测试结果。

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

（1）使用浏览器插件firebug监控响应和资源请求时间，将某些资源做缓存处理。

（2）使用top监视报告生成的资源消耗，我们发现一开始使用的latex框架消耗资源巨大，之后我们更换了轻量级版本，使其效率提高了几倍。

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

发布时由于服务器端部署比较复杂，涉及到一系列数据库视图操作，恢复数据操作，改变结构操作，所以为了避免出现操作失误，我们在部署当晚12点暂时关闭对外服务，备份镜像和数据库，进行新服务的部署。

由于在服务端上wecenter的安装完后和远端git仓库的最新版本之间存在不可自动合并的冲突，这时我将服务器端代码下载到本地，想进行手动合并，然而我为了方便又直接reset HEAD –hard了，结果这样之后，线上程序跑不起来，并且完全不知道哪个地方出了问题，并且reset到某一log后并不是原来的文件，所以我把刚才下载的代码手动在本地合并后覆盖掉服务器端的文件，这才解决了问题。

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

熟练使用git ，relog功能。

总结

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

答：我觉得团队目前的状态属于已定义级别，有维护的标准文档，有严格的代码复审流程，团队协作比较协调。

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

答：我觉得我们团队目前处于规范阶段。

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

答：整个团队在这个里程碑与前一个相比，改进最大的地方是配合分工更加默契：在前一个里程碑中，我们必须不断确定彼此的分工，由项目经理进行每天的任务调度和安排，项目的管理更人工化，而在这一阶段，我们团队中每个人的任务基本上可以保证传递实现，即一个人的任务完成后需要交付给下一个人，每个人拿到他人交付下来的任务后才能在此基础上完成自己的任务，管理自动化更高。虽然可能会出现一环接不上，整体停滞的问题，但是根据实践的总体情况来看，效果还是不错的。

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

答：受限于Beta阶段时间的极度压缩，即使在努力赶工，但是新做的许多物理实验还各自缺少一小部分内容，不足以发布。由于PDF转HTML太吃服务器资源，最终被迫放弃了这一想法，这一想法的放弃意味着我们必须放弃手机端的客户，这是一个重大的损失。我们目前正在思考措施挽回手机端的客户，并且能够实现需求文档里所述。

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

答：我觉得我们团队目前处于规范阶段。我们的团队通过会议公开讨论流程和工作方式，整个团队的目标更加现实和明确。这个阶段中，我们逐步建立属于我们这个项目的分工规定，协调调度更加自动化，项目经理在上一阶段的分配任务的工作逐渐被流畅的合作模式代替，成员之间的配合更加默契。

相比于α阶段，我们改进了什么？

相比于α阶段，我们最终改进了几个部分：

1、全员使用git：这一点我认为是一个最大的进步，共同进步才是进步。α阶段团队commit只有项目经理和前后端工程师在做，而β阶段团队所有队员在github上都直接参与了团队项目的开发。这是集体的进步：）

2、注重单元测试：β阶段严格遵守了开发就要测试的原则，对后端的数据处理进行了大量的单元测试并且部署了自动运行单元测试的drone.io。

3、团队协作模式的改进：从中心依赖制度变更为互相依赖的类环系统，加强了每个人对团队项目的影响力。

4、时间的合理安排：项目经理在统筹兼顾各个成员的课业压力后，合理安排开发时间在编译实验稍微空闲的时间段，最终也取得了不错的效果。

相比于α阶段，我们保持了什么特点？

1、一如既往的好的用户体验度：在第二阶段的开发中，我们不论是在选择论坛、注册页面的改写以及前端小工具的制作中，我们都保持了跟α阶段一样的一如既往的好的用户体验，这样的用户体验是前端工程师下辛苦捉摸与设计的。

2、紧跟用户需求：网站始终以用户需求为第一驱动力，所以一直在跟进用户需求，在用户反馈Bug后尽可能快速解决，最终影响力扩大到了其他学校，甚至有高中的学生，大学的物理老师等。

3、调研：在计划好β阶段的任务后，我们又进行了一轮调研，最终根据实际用户需求调整了开发计划，最终确定了优先级最高的几个feature来做。