Alpha冲刺总结
基本情况
- 队名：创造404
- 组长博客
- Github
- 答辩总结：
界面仍需优化，还需要通过公众号解决电子书的问题
1、价格有格式要求吗，比如我输入12.089
答：有要求必须是数字格式小数点后保留两位
2、轮播图展示的图片如何选择
答：轮播图主要用于美化界面、可以是广告位、也可以是通知、由我们自己设定
3.手机号和qq号的绑定如果没有验证的话，如果验证绑定者身份
答：我们有注册功能，可以绑定，那天由于我的账号注册过了所以没有演示、根据openid绑定
4.如果有多人同时出售同一本书，可否有价格排序功能，新旧程度可否排序
答：现在还没有这项功能，b阶段可能会考虑。
5、用户信用分权重计算公式
答：目前采取的是累加法，b阶段会改成平均法，为了防止恶意刷分，同一对用户之间只有3次有效评价。 - 讨论现场
评估
- 本次作业贡献分值
| 任务 | 人员 | 分值 |
|---|---|---|
| 全栈、后端组长、负责安排任务、链接前后端、云函数编写、小程序框架搭建、答辩 | 林志航 | 13 |
| 前端组长、负责页面UI设计、交互设计、安排前端任务 、编写部分文档 | 张峰 | 12 |
| 前端、负责页面UI设计、交互设计 、编写部分文档 | 饶皓迪 | 9 |
| 前端、负责页面UI设计、交互设计、ppt 、编写部分文档 | 蔡沿江 | 10 |
| 前端、负责页面UI设计、交互设 、编写部分文档 | 廖善怡 | 9 |
| 燃尽图、后端数据库 、编写部分文档 | 杨文龙 | 10 |
| 后端数据库 、编写部分文档 | 邢明炜 | 10 |
| 后端数据库 、编写部分文档 | 陈探宇 | 9 |
| 后端函数调用 、整合博客 | 苏鸿鹏 | 9 |
| 后端函数调用、api接口 、编写部分文档 | 李兴瀚 | 9 |
| 总分 | 100 |
- 本次作业贡献比例
计算方法 得分/总分*100%
| 人员 | 比例 |
|---|---|
| 林志航 | 13% |
| 苏鸿鹏 | 9% |
| 张峰 | 12% |
| 邢明炜 | 10% |
| 杨文龙 | 10% |
| 蔡沿江 | 10% |
| 廖善怡 | 9% |
| 陈探宇 | 9% |
| 饶皓迪 | 9% |
| 李兴瀚 | 9% |
总结思考
2.1 设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们主要提供一个大学生二手书交易平台——“手手书”，将需要出售的二手书籍的信息，进行整合、分类并发布在“手手书”平台上以供需要购买二手书籍的同学进行参考。在功能定位方面定义的很清楚。典型用户主要是福大在校学生，典型场景是对有买书和卖书需求的学生提供一个平台以供他们进行交易，各取所需。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
目标基本达到了。原计划的功能基本实现，还剩积分功能，评价功能和一些小的完善。已按照交付时间交付，完成alpha阶段的任务。就目前而言，用户的的数量还没达到预期，因为这段时间主要忙开发，对宣传这块没有过多的关注，相信在不久的将来用户数量可以达到预期。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
一致，目前的用户都很乐意用我们的产品，认为“手手书”不仅方便而且环保。我们离目标更近了！
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
要善于使用代码管理工具，慎用全局变量。再者，要加强团队之间的沟通和联系。
如果再来一遍，我们会提前设计好整个程序的框架，比如具体几个页面，几个数据库等等；并且合理规划好时间。2.2 计划
- 是否有充足的时间来做计划?
有充足的时间进行计划
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
统一在组会上提出各自的想法，组员对每个人提出的不同想法进行评价，对某个想法持相反意见的双方（或者多方）之间讨论协商出一种最优的方案，如果仍是各持己见，则各自完整地阐述出自己的想法，然后通过投票方式进行表决。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大体上我们的进度都按照原计划进行，有一些小细节或者是突发状况可能是计划的时候没有想到的，还需要在实现的过程中步步改进、步步完善。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有发现，也确实没有做过什么没价值的事情，即使是编程过程中，可能出现了一些错误、bug，但是这些错误都为我们后续的编程打下基础，在后续的编程、以及组员之间协作方面，我们便会避开这些错误，以防出现更大的麻烦，所以在实践过程中都是有价值的。
- 是否每一项任务都有清楚定义和衡量的交付件?
是的，在需求分析阶段，我们就已经确定好我们要完成哪些任务，以及组员之间各自需要完成的任务。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目整体上基本按照计划进行，部分任务由于计划没有做好，存在临时更改的情况。当时没考虑到恶意刷信誉分的风险，因为当时只把用户定义为校内学生人群，想当然认为这个群体不会进行这种行为。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，缓冲区的作用大概就是其他组在疯狂赶进度的时候，我们则是在对程序进行优化以及完善一些功能，而不是为了赶任务而赶。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
对整体布局考虑更加全面，增加缓冲区长度。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们全员都参与到了小程序开发，学到了对小程序开发流程的熟悉掌握、人员的分配以及组织，还有成员之间的相互配合。如果历史重来，我们会在最初对原型的设计更加完整，计划做的更加全面，留出修改的余地。
2.3 资源
- 我们有足够的资源来完成各项任务吗？
对于小程序开发，我们所需要的主要是人力资源和时间资源，我们大家都比较积极并且愿意花费精力在这上面。其次就是在扫描isbn码上的金钱耗费，也只是比较少的。所有我们还是有足够资源来完成各项任务的。
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
我们是按照前后端分组分工，然后人力方面就是按照各个任务的难度分配，同时，做完自己的任务也可以为同组其他人提供帮助。这个估计较为准确。
- 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
对于小程序的测试，我们是在功能基本实现之后，将人力统一投入，用不同的手机进行测试，软件资源足够，但是硬件资源而言，受制于诸多因素，我们无法做到将所有机型，系统涵盖其中，不能完全保证其普适性。不需要编程的资源方面，美工设计和文案都是比较合理预估，并没有低估难度。
- 你有没有感到你做的事情可以让别人来做（更有效率）？
这个自然，各个人的优势不同，我们的分配虽然已经尽可能按照个人意愿和个人优势，但是不可能尽善尽美，所以难免会发生这种事情。但是，我们作为一个团队，互帮互助，共同进步，也能将自己的任务完成得比较好。
- 有什么经验教训？如果历史重来一遍，我们会做什么改进？
经验教训：虽然任务是委派给每一个人单独来做，但是如果要尽可能地提高效率的话，最好还是大家聚在一起做项目，这样既能相互交流进度，又能避免自己注意力不集中而划水。
改进：可以将原型页面做得好看一些，不然后期修改会稍显麻烦。
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 测试/发布
- 团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
团队有测试计划；在每个阶段结束时正式的验收测试。
- 团队是否有测试工具来帮助测试？
团队有利用微信开发者自带测试工具等来帮助测试。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从软件本身出发，争取能更优化下用户体验。从软件实际运行的结果看这些测试工作是有用的。通过每两天一次的测试来辅助修改代码，及时检查出运行问题及时改正，以免一步错步步错。
- 在发布的过程中发现了哪些意外问题？
我们团队在发布小程序时，因为是第一次操作，所以最开始会一直卡在证书方面，后面查阅了很多也问了其他已发布程序的团队。后来发布好了后，发现不能通过关键字查找小程序，但是可以通过完整的名字查找小程序。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
软件的开发过程中，测试这一环节是必不可少的。一款产品即使测试完毕发布后，仍然会出现或多或少的问题，这就体现了在测试环节付出了多少，决定了最后遇到的问题是大是小。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。
2.7 团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队之中角色的确定是通过各个成员各自所擅长的与所感兴趣的方面作出选择之后，再互相讨论协调考虑各人的学习能力与代码能力之后，才定下前后端的基调。并在初次分配角色后再进行细微的调整，如一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务，在各人各自的角色上尽量做到人尽其才。
- 团队成员之间有互相帮助么？
有互相帮助，一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务。在前后端对接的过程中，团队前后端成员互相协助，共同完成对接。成员之间也会互相提出意见，并协助该模块成员完善该功能。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队成员在遇到项目管理、合作方面的问题时，团队成员先是互相表达清楚自己的观点，若遇到决定性的问题便会在站立会议时全团队进行讨论，并表决出最终结果。
- 我感谢组长志航对我的帮助，因为有很多我没做完的事情，他都帮我完成了，而且也教会了我很多东西。
2.8 总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为我们的团队处于可管理级。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于磨合的阶段，正向规范的阶段迈进。在alpha冲刺中，已经逐渐地形成了规范化的过程，接下来需要继续保持。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队的分工更加合理，团队的协作能力大大提升，团队的沟通更加流畅，团队的关系更加和睦。
- 你觉得目前最需要改进的一个方面是什么?
最需要改进的是团队不同方面的整合，前后端的交互还需要加强。
- 对照敏捷开发我们做的最好的是：
1、主张简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。我们一开始就把交易二手书当成首要任务，而且一直没有增加我们不需要的额外功能。
2、高质量的工作：我们小组会选择一段连续的时间，大家一起进行编写工作，效率很高，编写出来的代码质量也很高。