第03组 Beta冲刺 总结
Beta冲刺总结
基本情况
- 队名：创造404
- 组长博客
- Github
- 答辩总结：
Beta阶段主要完成了搜索排序、手动加书、电子书奖励机制这些功能，除此之外还完善了插入约束，对界面进行了美化。接下来仍需修改bug，增加手动isbn加书功能。 - 全组讨论照片
评估
- 本次作业贡献分值
| 任务 | 人员 | 分值 |
|---|---|---|
| 全栈、后端组长、负责安排任务、链接前后端、答辩、ppt、测试 | 林志航 | 15 |
| 前端组长、负责页面UI设计、交互设计、安排前端任务 、编写部分文档、测试 | 张峰 | 14 |
| 前端、负责页面UI设计、交互设计 、编写部分文档、测试 | 饶皓迪 | 8 |
| 前端、负责页面UI设计、交互设计 、编写部分文档、测试 | 蔡沿江 | 8 |
| 前端、负责页面UI设计、交互设 、编写部分文档 | 廖善怡 | 8 |
| 燃尽图、后端数据库 、编写部分文档、改bug、测试 | 杨文龙 | 14 |
| 后端数据库 、编写部分文档、改bug、测试 | 邢明炜 | 13 |
| 后端数据库 、编写部分文档 | 陈探宇 | 8 |
| 后端函数调用 、编写部分文档、测试 | 苏鸿鹏 | 8 |
| 后端函数调用 | 李兴瀚 | 4 |
| 总分 | 100 |
- 本次作业贡献比例
计算方法 得分/总分*100%
| 人员 | 比例 |
|---|---|
| 林志航 | 15% |
| 苏鸿鹏 | 8% |
| 张峰 | 14% |
| 邢明炜 | 13% |
| 杨文龙 | 14% |
| 蔡沿江 | 8% |
| 廖善怡 | 8% |
| 陈探宇 | 8% |
| 饶皓迪 | 8% |
| 李兴瀚 | 4% |
总结思考
2.1 设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们主要提供一个大学生二手书交易平台——“手手书”，将需要出售的二手书籍的信息，进行整合、分类并发布在“手手书”平台上以供需要购买二手书籍的同学进行参考。在功能定位方面定义的很清楚。典型用户主要是福大在校学生，典型场景是对有买书和卖书需求的学生提供一个平台以供他们进行交易，各取所需。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
目标基本达到了。原计划的功能基本实现，alpha阶段没完成的积分功能和评分机制也都完成了。已按照交付时间交付，完成beta阶段的任务，剩下的就是发布的问题了。就目前而言，用户的的数量还没达到预期，但是已经离目标很近了，上架了第一个版本后，用户量增加了不少。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
一致，目前的用户都很乐意用我们的产品，认为“手手书”不仅方便而且环保，用户量有了一定程度的增加。我们离目标更近了！
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
要善于使用代码管理工具。再者，要加强团队之间的沟通和联系。
如果再来一遍，我们会提前设计好整个程序的框架，并且合理规划好时间。
2.2计划
- 是否有充足的时间来做计划?
有充足的时间进行计划
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
每天的十分钟会议上提出各自的想法，组员对每个人提出的不同想法进行评价，对某个想法持相反意见的双方（或者多方）之间讨论协商出一种最优的方案，如果仍是各持己见，则各自完整地阐述出自己的想法，然后通过投票方式进行表决。最终我们的想法都能达成一致，并取得成效。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大体上我们的进度都按照原计划进行，有一些小细节或者是突发状况可能是计划的时候没有想到的，还需要在实现的过程中步步改进、步步完善。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有发现，也确实没有做过什么没价值的事情，因为beta阶段主要是对于alpha阶段的改进冲刺，是有目的性的对我们的程序进行改进，所以就会更加专注我们要做的东西，不会去浪费时间于一些无意义的事情，即使是编程过程中，可能出现了一些错误、bug，但是这些错误都为我们后续的编程打下基础，在后续的编程、以及组员之间协作方面，我们便会避开这些错误，以防出现更大的麻烦，所以在实践过程中都是有价值的。
- 是否每一项任务都有清楚定义和衡量的交付件?
是的，在alpha答辩之后，我们就立即开会讨论，确定好我们要完成哪些任务，以及组员之间各自需要完成的任务。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目整体上基本按照计划进行，部分任务由于计划没有做好，存在临时更改的情况。当时已经想到一种好的定义信誉分的方法，但没考虑全面，因为当时没考虑阶段性问题。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，缓冲区的作用大概就是其他组在疯狂赶进度的时候，我们则是在对程序进行优化以及完善一些功能，而不是为了赶任务而赶。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
对整体布局考虑更加全面，增加缓冲区长度。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Beta阶段我们全员都参与到了小程序开发，通过对alpha阶段老师以及测试组提出的问题对小程序进行改进，增加了新的功能，学到了对小程序开发流程的熟悉掌握、人员的分配以及组织，还有成员之间的相互配合。如果历史重来，我们会在最初对代码进一步规范，提升交互能力。
2.3 资源
- 我们有足够的资源来完成各项任务吗？
有的，对于资源问题，其实并没有什么问题。对于小程序开发，我们所需要的主要是人力资源和时间资源，对于这个软工实践大作业，虽然我们并没有开发经验，但是这是我们以后工作必须接接触的，所以我们大家都比较积极并且愿意花费精力在这上面。其次就是在扫描isbn码上的金钱耗费，也只是比较少的。所有我们还是有足够资源来完成各项任务的。
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
我们是按照前后端分组分工，然后人力方面就是按照各个任务的难度分配，同时，做完自己的任务也可以为同组其他人提供帮助。这个估计较为准确。
- 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
在beta冲刺阶段，我们我们在测试方面投入了大量的人力，我们一步步更新优化小程序，并且同时进行测试，对于人力资源是完全足够的。软件和硬件资源的话，因为我们不可能拥有所有机型进行测试，难免遗漏，但是问题不大。对于美工与文案的估计也是比较正确的。
- 你有没有感到你做的事情可以让别人来做（更有效率）？
这个自然，各个人的优势不同，我们的分配虽然已经尽可能按照个人意愿和个人优势，但是不可能尽善尽美，所以难免会发生这种事情。但是，我们作为一个团队，互帮互助，共同进步，也能将自己的任务完成得比较好。
- 有什么经验教训？如果历史重来一遍，我们会做什么改进？
经验教训：虽然任务是委派给每一个人单独来做，但是如果要尽可能地提高效率的话，最好还是大家聚在一起做项目，这样既能相互交流进度，又能避免自己注意力不集中而划水。
改进：可以将原型页面做得好看一些，不然后期修改会稍显麻烦。
2.4 变更管理
- 每个相关的员工都及时知道了变更的消息?
组内积极沟通，每个相关的员工都及时知道变更信息。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
判断其实现难度、目前进度和功能对于项目的影响大小来决定是否“推迟”的功能，通过软件的需求分析、基础功能和选题报告中来决定“必须实现”的功能。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
达成原型和选题报告中的要求且能够实现。
- 对于可能的变更是否能制定应急计划?
能及时制定应急计划，当场发现问题，随机应变做出相应的应急措施。
- 员工是否能够有效地处理意料之外的工作请求？
可以，组员们都很有责任心，随叫随到。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了如何应对突发状况、统筹全局进行应对。如果历史重来一遍，我们会提前预估完成各个功能的所需代价来避免不必要的前段界面改动，在分工方面能更考虑成员的特长来分配。
2.5 设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
需求分析报告时设计的，前端与后端人员都有参与，团队开会讨论，集中意见，然后组长整合做出设计。是合适的时间，合适的人。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，是按照需求来进行设计的。如果遇到无法实现或难以实现的再根据具体情况修改。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了UML帮助设计，在开发实现的过程中使用了单元测试，这些工具很有效，UML可以让任务变得清晰、具体，单元测试提高了debug效率和项目的便捷性。
- 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
现在的UML比开始更加丰富、合理，功能的增改变动产生了这些区别，要更新UML文档。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
对于书籍发布和下架的Bug最多，因为需要对多个数据库进行更新，且更新的约束很多。在发布后发现了积分更新和发布约束的bug，因为设计/开发时对该方面的测试疏忽了。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
前端Code Review前端， 后端Code Review后端，对每一个模块、单元后进行代码复审，频率上，前期约3天/次，冲刺阶段2天/次。严格执行了代码规范。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了，设计时要基于实际，这样才能让开发更加顺利。在开发过程中，要进行实时变通的调整。如果重来一遍，我们将更合理安排设计和开发之间的权衡，二者需要根据实际进行变动，开发所碰到的问题是更加具体的，在设计阶段应该考虑更为周全。
2.6 测试/发布
- 团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
团队有测试计划。进行了正式的验收测试.
- 团队是否有测试工具来帮助测试？
团队有利用微信开发者自带测试工具等来帮助测试。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从软件本身出发，争取能更优化下用户体验。从软件实际运行的结果看这些测试工作是有用的。有试着用测试工具帮助测试，但基本都是靠自己研究探索，毕竟缺乏经验。没有进行正式的验收测试，就目前完成的软件来说，仍存在着一些小小的问题，也还没有达到令人满意的程度，因此还在尝试完善优化软件。
- 在发布的过程中发现了哪些意外问题？
我们团队在alpha阶段发布了小程序时，克服了证书方面的问题。在beta阶段发布小程序时由于小程序需要发布信息，但是只有企业用户才能发布此类小程序，所以目前改进版的手手书还只能使用体验版。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学会了在一定程度上测量并跟踪软件的效能，并在测试的过程中发现了一些开发时欠缺考虑的问题并加以优化和改进。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。
2.7 团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队之中角色的确定是通过各个成员各自所擅长的与所感兴趣的方面作出选择之后，再互相讨论协调考虑各人的学习能力与代码能力之后，才定下前后端的基调。并在初次分配角色后再进行细微的调整，如一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务，在各人各自的角色上尽量做到人尽其才。
- 团队成员之间有互相帮助么？
有互相帮助，一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务。在前后端对接的过程中，团队前后端成员互相协助，共同完成对接。成员之间也会互相提出意见，并协助该模块成员完善该功能。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队成员在遇到项目管理、合作方面的问题时，团队成员先是互相表达清楚自己的观点，若遇到决定性的问题便会在站立会议时全团队进行讨论，并表决出最终结果。
- 我感谢杨文龙对我的帮助，因为在数据库的约束和查询上，我们学到了数据库约束和数据库插入查询等等。如果历史重来一遍，我会提前就学会开放文档上的数据库部分。
2.8 总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为我们的团队处于可管理级。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于规范阶段和磨合阶段之间，但是还是离规范有一定的距离，在Beta阶段，我们吸收总结了alpha冲刺中的错误经验，使得我们的队伍规范化的程度更高，接下来需要继续保持。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队的分工更加合理，团队的协作能力大大提升，团队的沟通更加流畅，团队的关系更加和睦。
- 你觉得目前最需要改进的一个方面是什么?
最需要改进的是团队不同方面的整合，前端成员在Beta阶段帮不上什么忙，后端成员工作压力大。
