| 任务 | 人员 | 分值 |
|---|---|---|
| 全栈、后端组长、负责安排任务、链接前后端、云函数编写、小程序框架搭建、答辩 | 林志航 | 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% |
我们主要提供一个大学生二手书交易平台——“手手书”，将需要出售的二手书籍的信息，进行整合、分类并发布在“手手书”平台上以供需要购买二手书籍的同学进行参考。在功能定位方面定义的很清楚。典型用户主要是福大在校学生，典型场景是对有买书和卖书需求的学生提供一个平台以供他们进行交易，各取所需。
目标基本达到了。原计划的功能基本实现，还剩积分功能，评价功能和一些小的完善。已按照交付时间交付，完成alpha阶段的任务。就目前而言，用户的的数量还没达到预期，因为这段时间主要忙开发，对宣传这块没有过多的关注，相信在不久的将来用户数量可以达到预期。
一致，目前的用户都很乐意用我们的产品，认为“手手书”不仅方便而且环保。我们离目标更近了！
要善于使用代码管理工具，慎用全局变量。再者，要加强团队之间的沟通和联系。
如果再来一遍，我们会提前设计好整个程序的框架，比如具体几个页面，几个数据库等等；并且合理规划好时间。2.2 计划
有充足的时间进行计划
统一在组会上提出各自的想法，组员对每个人提出的不同想法进行评价，对某个想法持相反意见的双方（或者多方）之间讨论协商出一种最优的方案，如果仍是各持己见，则各自完整地阐述出自己的想法，然后通过投票方式进行表决。
大体上我们的进度都按照原计划进行，有一些小细节或者是突发状况可能是计划的时候没有想到的，还需要在实现的过程中步步改进、步步完善。
没有发现，也确实没有做过什么没价值的事情，即使是编程过程中，可能出现了一些错误、bug，但是这些错误都为我们后续的编程打下基础，在后续的编程、以及组员之间协作方面，我们便会避开这些错误，以防出现更大的麻烦，所以在实践过程中都是有价值的。
是的，在需求分析阶段，我们就已经确定好我们要完成哪些任务，以及组员之间各自需要完成的任务。
项目整体上基本按照计划进行，部分任务由于计划没有做好，存在临时更改的情况。当时没考虑到恶意刷信誉分的风险，因为当时只把用户定义为校内学生人群，想当然认为这个群体不会进行这种行为。
有留下缓冲区，缓冲区的作用大概就是其他组在疯狂赶进度的时候，我们则是在对程序进行优化以及完善一些功能，而不是为了赶任务而赶。
对整体布局考虑更加全面，增加缓冲区长度。
我们全员都参与到了小程序开发，学到了对小程序开发流程的熟悉掌握、人员的分配以及组织，还有成员之间的相互配合。如果历史重来，我们会在最初对原型的设计更加完整，计划做的更加全面，留出修改的余地。
2.3 资源
- 我们有足够的资源来完成各项任务吗？
对于小程序开发，我们所需要的主要是人力资源和时间资源，我们大家都比较积极并且愿意花费精力在这上面。其次就是在扫描isbn码上的金钱耗费，也只是比较少的。所有我们还是有足够资源来完成各项任务的。
我们是按照前后端分组分工，然后人力方面就是按照各个任务的难度分配，同时，做完自己的任务也可以为同组其他人提供帮助。这个估计较为准确。
对于小程序的测试，我们是在功能基本实现之后，将人力统一投入，用不同的手机进行测试，软件资源足够，但是硬件资源而言，受制于诸多因素，我们无法做到将所有机型，系统涵盖其中，不能完全保证其普适性。不需要编程的资源方面，美工设计和文案都是比较合理预估，并没有低估难度。
这个自然，各个人的优势不同，我们的分配虽然已经尽可能按照个人意愿和个人优势，但是不可能尽善尽美，所以难免会发生这种事情。但是，我们作为一个团队，互帮互助，共同进步，也能将自己的任务完成得比较好。
经验教训：虽然任务是委派给每一个人单独来做，但是如果要尽可能地提高效率的话，最好还是大家聚在一起做项目，这样既能相互交流进度，又能避免自己注意力不集中而划水。
改进：可以将原型页面做得好看一些，不然后期修改会稍显麻烦。
每个相关的员工都及时知道变更信息。
判断其实现难度、目前进度和功能对于项目的影响大小来决定是否“推迟”的功能，通过软件的基础功能和选题报告中来决定“必须实现”的功能。
达成原型和选题报告中的要求且能够实现。
现场决定直接改，随机应变做出相应的应急措施。
可以，随叫随到。
学到了一个团队该如何协作完成项目。如果历史重来一遍，我们会提前预估完成各个功能的所需代价来避免不必要的前段界面改动，在分工方面能更考虑成员的特长来分配。
需求分析报告时设计的，前端与后端人员都有参与，团队开会讨论，集中意见，然后组长整合做出设计。是合适的时间，合适的人。
几乎没有，设计阶段都是比较确定的，有弹性空间。如果开发阶段遇到问题了，再进行具体的项调整修改，
使用了UML帮助设计，在开发实现的过程中使用了单元测试，这些工具很有效，UML可以让任务变得清晰、具体，单元测试提高了debug效率和整个项目的鲁棒性。
现在的UML比开始更加丰富、合理，功能的增改变动产生了这些区别，要更新UML文档。
书籍发布的bug较多，因为要填写较多的信息，对填写的信息要进行约束，并与后端数据库进行交互。发布之后没有重要bug，进行完整测试通过后才发布的。
前端Code Review前端， 后端Code Review后端，对每一个模块、单元后进行代码复审，频率上，前期约3天/次，冲刺阶段2天/次。严格执行了代码规范。
我们学到了，设计时要细致，这样开发任务会很明确。开发实现时，要根据具体情况进行适当的调整。如果重来一遍，我们将更早的开始实现工作，因为开发时会遇到比较多的问题，这些问题相比于设计阶段的一些设想是更加真实、贴切实际的。
2.6 测试/发布
团队有测试计划；在每个阶段结束时正式的验收测试。
团队有利用微信开发者自带测试工具等来帮助测试。
测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从软件本身出发，争取能更优化下用户体验。从软件实际运行的结果看这些测试工作是有用的。通过每两天一次的测试来辅助修改代码，及时检查出运行问题及时改正，以免一步错步步错。
我们团队在发布小程序时，因为是第一次操作，所以最开始会一直卡在证书方面，后面查阅了很多也问了其他已发布程序的团队。后来发布好了后，发现不能通过关键字查找小程序，但是可以通过完整的名字查找小程序。
软件的开发过程中，测试这一环节是必不可少的。一款产品即使测试完毕发布后，仍然会出现或多或少的问题，这就体现了在测试环节付出了多少，决定了最后遇到的问题是大是小。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。
团队之中角色的确定是通过各个成员各自所擅长的与所感兴趣的方面作出选择之后，再互相讨论协调考虑各人的学习能力与代码能力之后，才定下前后端的基调。并在初次分配角色后再进行细微的调整，如一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务，在各人各自的角色上尽量做到人尽其才。
有互相帮助，一些成员做完自己的任务后又去帮助任务相似的其他未完成的成员协助完成任务。在前后端对接的过程中，团队前后端成员互相协助，共同完成对接。成员之间也会互相提出意见，并协助该模块成员完善该功能。
团队成员在遇到项目管理、合作方面的问题时，团队成员先是互相表达清楚自己的观点，若遇到决定性的问题便会在站立会议时全团队进行讨论，并表决出最终结果。
我感谢我们小组每一位成员对我的帮助，因为大家都很积极，向我提出建议，指出我的错误。让我学到了很多东西，编写小程序更多的靠的是团队协助的能力，如果没有大家的共同努力，我们是无法完成的。
我认为我们的团队处于可管理级。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪。
处于磨合的阶段，正向规范的阶段迈进。在alpha冲刺中，已经逐渐地形成了规范化的过程，接下来需要继续保持。
团队的分工更加合理，团队的协作能力大大提升，团队的沟通更加流畅，团队的关系更加和睦。
最需要改进的是团队不同方面的整合，前后端的交互还需要加强。
1、主张简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。我们一开始就把交易二手书当成首要任务，而且一直没有增加我们不需要的额外功能。
2、高质量的工作：我们小组会选择一段连续的时间，大家一起进行编写工作，效率很高，编写出来的代码质量也很高。
原文：https://www.cnblogs.com/cyj-12138/p/14013289.html