【Alpha阶段】M1事后报告

 

 

设想和目标

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

答：我们的软件要解决的是包括北航在内的全国高校物理实验的问题。定义比较清晰，对典型用户和典型场景有比较清晰的描述，在需求规格说明书中有。

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

答：项目经理第一周花了较多的时间进行整体的规划与设计，在后期细化任务的时候至少提前三天根据不同的执行力和效率将大任务细分为小任务。所以还是有充足的时间用来做计划。

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

答：计划阶段我们曾经就使用什么语言的后端框架产生过分歧，最终解决方法也很简单，无条件服从框架设计者的建议。

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

答：用户量达到了预想，活跃用户量超过了预期目标。经验教训就是：软件开发是以用户需求为核心进行主导，不是以技术核心为主导，需要在行动前调查清楚用户的真实需求。如果重来一遍，我们会考虑让大家自由选择任务的种类与范围，根据自己的能力选择。

计划

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

答：没有全部做完，到答辩展示为止，一直也没有做完1091实验处理的支持。没有做完是因为错误地估计了处理实验数据与报告所需要的时间，并且后期根据用户投票动态优先选择了1021作为杀手级实验，所以1091实验处理暂时搁置。

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

答：有。因为安排的失误，项目经理在过程中让某位同学去收集预习报告，但是由于该同学收集的方式方法不对，所以导致预习报告的质量较差，最终没能发挥其价值。

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

答：并不是。关于一些学习的任务虽然项目经理有要求交付一些demo但是由于涉及领域过大，项目经理本身也无法衡量那个demo做出是否是该学习成本带来的比较好的成果。其他任务都有较清楚的定义与交付结果的说明。

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

答：整个项目的过程不完全按照计划进行。我们的前端工程师在项目中需要去给编译老师的mooc视频加字幕，而由于其本身的 性格特点，在加字幕时耗费了比较多并且比较整的时间，所以最后前端有一个预定界面没有做出。这项风险本身是没有在考虑范围内的，这属于队员的突发性事务。

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

答：留下的唯一的缓冲时间在于冲刺结束后到11.11号这几天，缓冲区比较有用，对大家造成的压力也不会过大。

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

答：未来计划将考虑到每个人每天合适的时段与技术能力，争取还是在固定领域范围内进行分配任务。加班这点本身估计在β阶段要常有了，编译课设和其他科目考试的压力随之而到，还有像队员参加了像冯如杯这样的比赛，每周都要开组会，所以时间相比α阶段少了很多。

 

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

 答：在团队开发的过程中可能会遇到之前定的计划或任务不合理的情况，这种情况下需要动态调整局部计划，将计划调整合理，不能一直根据过时的计划严格执行，那样执行效果会有很大折扣。如果重来一遍，我希望能在最开始的时候就制定好每个人合理的学习范围，早点开始学习相关知识。

资源

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

答：我们之前是没有足够的资源的。最终是项目经理花钱购买了域名，买了阿里云的2G内存的服务器（不是9.9！）并且完成了域名备案等工作。考虑到域名和推广的便捷性，最终没有使用老师发放的服务器。

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

答：各项任务的时间和学习成本均控制在一天4小时范围内可以完成的情况下，估计方法就是根据经验和大致的熟练度以及孜孜不倦的跟踪进度、报告与重新估算，精度相对比较高。

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

答：在网站上线前对于主流的十个浏览器进行了全方位的黑盒测试，并且进行了5次服务器压力测试。最终在优化Latex编译的情况下能够支持无延迟并发16个人同时生成实验报告，在更换服务器内存为2G后，能支持到40人以上。对于不需要编程的资源略微低估难度，但是在UI方面投入比较大，并且为了减轻前端逻辑的压力采用了前端友好的方案实现。

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

答：实话来说，如果再有人能帮我（项目经理）做点模版替换的代码就好了，锅太多有点累啊。

   

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

答：暂时没有什么太多这方面的经验教训… 

 

变更管理

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

答：大部分时候是的，但有些时候（比如联系不上的时候）没法通知到全部。

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

答：我们根据初期的用户投票和问卷调查，决定了推迟某些实验的处理，提前了一些比较热门的实验的处理的优先级，根据用户

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

答：这一点我们项目做得不够好，没有足够明确的清晰的出口条件

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

答：这个没有….

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

答：这个应该可以处理，项目经理给定工作请求时会通过结对编程的方式给予一定的新手入门和指导，从而能够有比较好的处理问题的能力和针对具体问题有着具体的解决方案。

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

答：这一点上我们觉得做的还是相对较好，重来一遍我们在这方面会更加积极与更加注重结对编程。 

 

设计/实现

 

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

答：因为团队项目的需求早就提前确定好了，是由项目经理和框架设计者一起完成的。

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

答：有，我们团队的处理方法是一起找一些demo。或者谁有经验听谁的，比如框架就完全交给邢浩来做，前端交给鲁聃，Latex生成PDF的可行性和有效性是由我提出的。

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

答：设计上我们使用了MockPlus进行原型设计，但是在测试方面非常遗憾，我们本次没有使用除黑盒和灰盒测试外并没有设计标准的单元测试来保证数据处理的正确性，这是本次团队项目中最大的失误。

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

答：数据处理部分产生的BUG最多，因为本身没有进行单元测试。每个数据处理文件最终版都有约600行左右，所以没有单元测试的情况下很难保证其正确，尤其是它还要涉及到与Latex文本文件的交互时。在设计与开发时一开始是为了减少队员的学习成本，预想着是项目经理最后来做测试…最后发现邹老师说的真对，谁负责的谁做单元测试最好，否则代码交付的质量很难保证。

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

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

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

答：针对我们项目本身的特点，我们觉得测试先行是比较好的方式。在开发程序完成之前，需要先经过测试才可以成功交付。

测试/发布

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

答：原先是打算开发完后测试的…后来发现黑盒测试好做，单元测试被忽视了，一开始计划没到位。

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

答：进行了正式的验收测试，测试了10个浏览器上约40项的显示效果与功能情况。

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

答：做压力测试时使用了一个本来是用来攻击网站的工具，一开始观察了一下运行xelatex时所耗内存，后来发现居然有200M有余，最后发现三个无延迟并发服务器就宕机了，数据库的连接会被冲毁。在比较了pdflatex、lualatex等多种编译系统后，使用了内存占用最小的编译系统pdflatex，它一次运行占用约20~30M。在压力第二次测试时还是比较乐观，30次并发无延迟网站服务崩溃，但是服务器没有宕机。第三次测试时表明16个并发无延迟生成报告操作是支持的最高上界。最终我们在前端使用了2s以内随机延迟的post请求时间来减缓同时并发的数据量，最终认定可以发布。

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

答：我们团队没有跟踪网站的效能，是不足之处。

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

答：发布后遇到了几次因为服务器阿里云内置扫描程序而导致内存过小的情况，这种情况用户访问延迟非常高，后来通过一些优化手段大致解决了这个问题。

 

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

 答：测试先行是有必要的，如果历史重来一遍，即使有学习成本我们也要每个开发人员都进行单元测试。

总结

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

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

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

答：我觉得我们团队目前还是处于磨合阶段，虽然我很想说我们团队进入了规范阶段，但是确实没有。整个目标与框架的设计有几位队员还是不太理解 ，目前了解整个流程与工作路径的人只有我和前端工程师和后端工程师、数据处理组的组长，还有两位同学目前没有参与过一个流程的开发来，下个阶段会逐步引导他们体会完整地操作流程。

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

答：既然没有前一个里程碑，我们这个里程碑所做之事是种奠基，也是一种开创。我认为我的团队在本个里程碑中展示出的团队协作是相当不错的。

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

答：最需要改进的就是测试的方面。

讨论照片：

 

 

项目经理大出血，大家一起庆功宴（看我的表情TuT，笑得最欢的是吃的最多的！！）