快乐就队——Beta冲刺答辩
一、设想和目标
1.做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
主要是提供一个一站式通知发布、接收平台以及简单的备忘录功能，详见需求规格说明书。
2.项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)
原计划的通知订阅、发布，群组管理、备忘录等主要模块的功能基本都已实现。前端由于技术水平和冲刺时间所限，没有做更多拓展，只是完善了错误提示。后端用了多个微服务和redis缓存数据库，算是一种拓展。
3.和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
在任务管理和进度跟踪上有提高，通过吸取alpha阶段使用看板的经验，本次冲刺开始前大家都有在看板上填写好自己的任务卡片，生成的燃尽图也更符合预期。以及每天通过共享文档收集组员的工作进度和工作时长，统计贡献度起来更加轻松和准确。
4.设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
初期设想的用户量不多，可能两三百人左右。因为我们的项目核心功能就通知的订阅、发布以及备忘录，比较简单，所以用户基本能接受。
5.有什么经验教训? 如果历史重来一遍，我们会做什么改进?
经验教训是功能的实现不能拘泥于原型，界面布局根据使用的组件库以及要实现的功能，可以灵活调整，终极目标还是提升用户体验。
二、计划
1.和alpha阶段相比，每天是否时间规划的更好?
每名队员在开始项目前，为冲刺不同阶段指定了相应计划以及时间。同时每天有相应插件统计时间和记录。可以有效跟踪各成员时间。
2.团队在beta阶段是如何解决队友对于计划的不同意见的？
这次计划大家都按自己既定计划进行，没有产生分歧。
3.你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
前端群通知管理和群成员管理在同一个页面，业务逻辑和布局相对复杂一些，beta冲刺期限内来不及完成，但加班完成了。
4.是否每一项任务都有清楚定义和衡量的交付件?
前端模块功能上能正确获取数据并展示，页面布局上在调整窗口大小时能达到一定限度的响应式的效果。
后端由于比较完善，所以对于每一项交付任务定义和衡量较为容易，交付过程轻松。
5.项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有遇到什么大的意外。
6.在计划中有没有留下缓冲时间，缓冲时间有作用么?
前端稍微加了两天班来完善一些细节。
7.我们学到了什么? 如果重来一遍, 我们会做什么改进?
如果能重来会直接按、划分好具体任务项来分配工作，而不是先按功能模块分，每个人再自己分任务项。
三、资源
1.有足够的资源（可以是时间、开发资源等）来完成各项任务么?
前端时间不太够，后端时间是足够的。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
前期在看板卡片上填写预期工作量，使用wakatime插件统计编码时间，每天开会时填写到表格。精度比alpha阶段靠人工估计要提高了很多。
根据Alpha的经验来进行估计，大多数任务的实际花费时间少于预计时间。一方面可能由于Alpha阶段项目完成度较高，使得部分任务花费时间较少，另一方面可能是组员设置的任务较为简单。
3.和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
前端时间不太够，按模块分配工作但各模块工作量不同，导致每个人完成任务的时间点不统一。本次对于美工（页面布局）虽然没有低估难度，但仍然花了比较多的时间。
后端有了Alpha做的单元测试铺垫，新功能可以很快验证和测试。
4.变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
新组员开发过程主要是以做中学加上其他人员帮助，同时后端给出清晰的开发流程，使得组员能很快适应，同时由于Alpha阶段后端较为完善，某些复杂工作对于新组员是透明的。对于完成效率来说如果未变更自然会更高，但是由于后端比较完善，因此体现出来不会是很大差别。
5.有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
换人虽然对后端那边整体进度的影响不是很大，但如果没有换人这个环节，被换的组员本人以及其他后端组员的负担也会小一些。如果重来会劝说团队中参与度低的组员主动申请换组。
四、设计/实现
1.项目是否经历重构？为什么需要重构？
对于前端，在具体规划任务时发现很多功能都还不完整，所以是以完善功能为主，没有更多的时间去考虑重构。
对于后端系统进行一定构架重构，从单体应用到微服务式的架构。在原来后端架构中，个别功能的变更就使得整个项目需要重新编译、部署，各个业务都在一个应用中处理。通过将按业务划分微服务，各业务模块可以独立升级，并且一个服务出现错误也不会导致整个系统崩溃。
2.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
单元测试，有效，可以有效追踪低对于功能的修改产生潜在影响。UML由于新增功能需要更新文档内容。
3.什么功能产生的Bug最多，为什么我们在设计/开发的时候没有想到这些情况?
前端页面数据绑定如果绑定的是有返回值的方法，就会出现该方法在后台被一秒数十次调用的情况，原因是我们对Angular的了解还不够深入。
4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
前端使用ng lint命令检查后提交，后端有用阿里巴巴代码规范插件等。
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一定要跟组员强调提交的规范性和严谨性，不能因为是warning而不是error就选择忽略。以及顺手开启IDEA内置的提交代码前格式化代码的选项，这样即使每个人的代码风格有不同，也能基本保证项目整体代码风格的统一。
五、测试/发布
1.和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
前端还是采用人工来测试。后端测试工作需要应为微服务的引入而经行特殊的测试，因此通过构造相应微服务的桩模块模拟对远程微服务的调用。而通过API接口测试来实现对微服务之间调用的测试。
2.团队是否有一个测试计划？
后端有比较完整的测试计划。前端工程模块化程度较高，每名组员先负责自己模块的测试，确定没问题了才提交。在冲刺结束后也有安排互相测试模块。
3.团队是否有测试工具来帮助测试？
前端虽然Angular有集成测试工具，但限于开发水平，几天的冲刺时间还是只能满足功能的实现，所以没有使用。
后端新引入了Mockito，为微服务测试打桩。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
前端：有通过浏览器内置的开发者工具来监测网络请求、方法调用等，但对性能优化的帮助不是太大。如果改进的话应该要使用类似后端JProfile那样的更专业的工具。
后端：通过单元测试来测试代码是否能预期经行。这些测试工作可以检验新引入功能对原有功能影响。测试框架有时候不能很好的表现测试的目的，可能需要使用一些测试模拟真实环境测试的程序。
5.在发布的过程中发现了哪些意外问题？
部署的云服务器是用的是很便宜的学生配置（单核，2G RAM），在测试访问时有遇到卡顿等问题。
6.我们学到了什么? 如果重来一遍, 我们会做什么改进?
还是应该先保证功能的实现再考虑性能优化，稳扎稳打，否则可能适得其反。
六、团队的角色，管理，合作
1.团队的每个角色是如何确定的，是不是人尽其才？
每名组员的角色与alpha冲刺时是相同的。换入的新组员因为原来是做Android，对Java更熟悉些，由后端大佬带着参与后端的完善和测试，也算是人尽其才。
2.团队成员之间有互相帮助么？
和之前一样，开发过程中遇到困难会在群里求助和讨论。例如后端迁移到微服务后接口文档和前端请求URL都发生了变化，后端组员专门录屏给前端组员讲解新后端项目的配置和接口文档的使用，可以说是组内互助的典范了。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
一般直接私聊沟通，有需要大家一起讨论的，就找相关组员方便的时间开语音或视频分享来讨论。
七、总结
1.组员们自我总结
- 叶博宁：在本次beta冲刺中我有以下收获：1.在前端上的编码能力得到了锻炼，但对Angular框架的了解还是很皮毛，对一些需求的实现比较依赖现成组件；2.团队管理和协作能力有一些提升，主要体现在对看板的利用更加有效。但在工作进度把控上还是常常缺乏紧迫感，一些时候反而是志峰在督促我去推进工作。
- 沈志峰：通过本次冲刺也意识到自己在相关领域的不足，同时工作中容易产生遗漏。在项目管理过程中还有很多需要向组长学习。
- 赵伟男：熟悉了微服务的相关概念和使用方法；更加深入地了解SpringBoot的邮件服务和文件上传功能模块；积累了团队合作开发、团队成员沟通的宝贵经验，对软件开发的整个流程也有了完整的体验。
- 陈赐：通过本次冲刺学到了很多关于框架的知识，也体会到了良好的项目管理给开发带来了很大帮助
- 郑澜：通过本次冲刺不仅在时间管理上有所收获，学会了更好地规划自己的时间；同时也理解到了项目开发过程中不是把功能和界面做出来就完成了，后期还要进行不断优化以改善用户体验。
- 岳逾先：通过本次冲刺让自己得到了锻炼，对前端和开发一个项目有了新的认识。
- 张必润：在本次冲刺中意识到了自己对移动端适配还有很多不了解，因时间原因本次冲刺也没有完善移端适配，对于这个会再进行学习和实践。
2.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
beta阶段相比alpha阶段有所提升，可以介于二级（管理级）和三级（定义级）之间。
3.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得在规范阶段，因为整个开发还是基于原型中设计的功能来实现，没有条件做更多的突破。
八、提高软件工程的质量
1.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码质量管理通过平时边跑边测，保障每一个功能模块正确性，而不是写完某个功能模块才来一次性测试。代码通过规范检查插件进行审核，同时后端有一套规范进行约束。
还是要强化组员在代码规范上的自觉意识，即使自己敲代码不注意空格、空行、换行，在提交前用快捷键顺手格式化一下，对其他看代码的组员来说也会友好很多。
2.整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
前端把一些经常重复出现的组件属性封装成类来精简代码。比如table经常用到的data、pageSize、pageIndex、total、loading等属性，封装成一个TableParamModel类，只需要一行就可以初始化好所有的类属性。
后端通过业务划分方法，分离成几个微服务。但微服务内架构设计还是遵循原有的结构。通过按业务划分，将原本单体应用分成可独立升级的服务模块，使得各业务之间解耦，同时编译部署更加独立。
3.其它软件工具的应用，应该如何提高？
应该多向原本代码水平较高的同学学习其他辅助工具的使用经验，比如wakatime编码时间统计工具就是从被换出的一凡那里学习来的，在实际冲刺中对每天统计工作量起到很大帮助。
4.项目管理有哪些具体的提高？
对看板的使用更加熟练，冲刺开始前就督促组员添加好卡片并估计工作量，最终生成的燃尽图比alpha冲刺时的更接近理想的一条斜线。
5.项目文档的质量如何提高？
组员一起讨论明确了每日任务文档的收集项，将收集的数据直接用于编写每日冲刺记录博客，可以省时省力。
6.对于人的领导和管理， 有什么具体可以改进的地方？
不论是遇到需求变更还是bug，保持理性平和的沟通都是非常重要的。
九、项目展示
