标签：瀑布流 不用 综合 代码量 安卓 目标 验收测试 最大 滑动
目录
我们的借呗app定义得很清楚，要解决的是“学校活动室借还困难与线下物品借还困难”的问题。
典型用户
a.需要短时间使用某件物品的有(租)借入需求的用户。
b.想将闲置物品借出共享的有(租)借出需求的用户。
c.想提高管理、分配活动室/物资效率的管理者和被繁琐借用流程所扰的借方。
典型场景
功能还差几个未完成，例如“消息模块”的推送学校、学院通知的功能，和数据分析功能。
已经按照原计划交付时间交付了，还未达到原计划的用户数量。
接受程度按照周六早晨的答辩来说和我们的预想大概一致，我们离目标更近了
学到了在做规划的时候不能将饼画的太大，目标还是得定在可实现范围内
如果历史重来一遍，我们会更加细化考虑预设的软件功能，在能力所致范围内给大家带来更多的惊喜功能。
从布置团队作业开始，我们就通过会议讨论好了大致的分工和APP要做的方向，但是过程中做计划的时间不多，但随着项目的完善，我们也在不断改善自己的计划。
通过会议讨论，大家提出各自的 意见，觉得合理可行的即通过，在项目的实际进行过程中，在产品经理画好大致框架的情况下，UI和前后端各自视情况而定，大佬说的都对。
林睿（组长）：原计划的任务是总体进度的跟进和博客，算是做完了，不过期间由于考试等原因改过几次进度
邓泽源：分析算法基本完成，加权优化还在改进中，为什么没做完，因为要考试要恰饭要睡觉要秃头的啊 靓仔
张庆焰：原计划的前端和与后端的交互基本上完成，没做完的有部分UI图还没做好
姚彬锟：完成社区界面的设计和还有登陆界面
朱宏 ：原本想把数据分析做好，结果生活还是太难了
蔡雅菁：产品经理的工作完成，主要任务是计划“借呗”app的整体框架与细节、做ppt和写计划书
吴洁敏：原计划的UI界面基本上做完了，没有完善好，打杂工作没做好，组长大大赛高
周鑫煌：有。没做完还能为什么？当然是因为没时间啊！书不用读吗？作业不用写吗？考试不用复习吗？（灵魂三问）
王景弘：原计划的UI设计工作最后都做完了
陈展鸿：原计划的内容没有完全做完（因为还有beta冲刺），只能说alpha冲刺内容已经做完
陈观鸿：前端任务完成百分之八十，还有一部分前后端对接任务还没完成，因为前后端对接不太会林睿（组长）：貌似没有
邓泽源：真的想不出来，大概是没有吧
张庆焰：由于之前有过安卓项目经历，所以并没做什么没必要或者没多大价值的事
姚彬锟：完成的任务基本都是提前已经设计好且必须要完成的任务，那些琐碎而没多大价值的事情我们在设计阶段就已经排除了
朱宏 ：.感觉画再多的ui，最后也会被实现的复杂性打倒
蔡雅菁：好像没有？个人感觉我们组分配任务还挺合理的，每个人都完成自己的分内之事，然后不断学习
吴洁敏：有，之前设计的UI界面中有的部分并没有设计好，有时写博客太过拖拉，效率不高
周鑫煌：发现没有去研究运用一些设计模式，投入的时间大部分在重复的垃圾代码上，再多的代码量也显得没有价值。
王景弘：的确有一些事是事后看来没必要的，例如前一两例的UI设计，因为刚刚入门所以对很多要求都不甚明了，直接导致做了大概四五个小时的废版，然后推倒重做，后面想来如果做之前有充分的沟通交流就不会这么浪费时间了
陈展鸿：没有，做的全都是有意义的事，每一个模块都有其特定的功能
陈观鸿：都挺有价值的，这得归功于大佬带的好，我就完成了他说的部分，没有多余部分，zqy太猛有的有，有的没有，有的部分在前期做的时候并没有考虑完善。但有项目经历的前后端大佬的部分做的会比较好。在开始真正编写代码之前，前后端人员有进行详细的沟通，并制定了前期的计划，例如制定了一些接口的规范、所使用的技术规范，总体而言，对于每一项任务都有较为清楚的定义。
首先我们制定了一些计划，并且有按照计划一步一步实现，但是在开发的过程中难免会遇到一些重要但是开始没有计划到的内容，于是就会脱离计划去完成那些重要内容，项目并没有出现大的意外，风险嘛，目前还没估计，因为项目还没真正完成，所以还没考虑。
有留下一些时间用于前后端交互和修改debug，就是尽早的打完代码。有作用，让前后端交互和改bug的时间不会挤到最后。
目前一些核心的界面及后端基本上已经完成，在此基础下，会尽快完善剩余的一些界面，规划好deadline，再扩展缓冲区做debug，以防最后匆忙慌乱。还准备在项目最终完成前留下一些用户测试的缓冲区，以完善一些功能。
学到了要留下缓冲区做前后交互和debug，不能将计划制定的刚刚好。
如果历史重来一遍，我们会更细分各自要做的任务，让前后端人员更加轻松一些，将任务分配的更平均一些。并且要在一开始就细分好每个任务的deadline，让项目有条不紊的进行。
我们有足够的资源来完成各项任务（但时间资源有些稍微不充分）
我们所需的时间是根据人员的分配以及个人能力估计的，精度大致相同
测试的时间和资源都足够，对于不需要编程的资源未低估难度
对于时间分配来说，由于碰上了考试多的一周，所以时间分配上不是特别充裕
如果历史重来一遍，我们会对时间安排更加上心，不会拖到时间不够的时候才完成
是的，我们建立了群聊，每次有什么比较重要的变更都会艾特相关成员通知，确保每个人及时收到消息。
我们严格的对每个界面进行设计，如果有x->y，也就是必须先有y才可以做x，那么必须实现的就是x，可以推迟的就是y。当然有一部分y是拓展的功能不是app主要部分的话，我们也会推迟。
我们认为进行测试完，总体功能都能实现，不出现明显错误的情况为做好了。做好了后仍然会进行优化。
没有什么特殊的应急计划，遇到了就是加班加班加班。
我们规定请求都转到组长那里处理，这样减轻了开发人员的压力，让他们有大部分时间花在自己那一部分的开发，然后意料之外的事情大家会一起思考解决。
考虑的东西还是不够多，很多地方考虑的仍然不够细致，如果历史重来一遍，我们会对每一块内容进行更加细致的分析，前期准备做的更好。
设计工作从Alpha之前的十天就已经开始准备了，设计人由 周鑫煌，张庆焰，陈展鸿三人为核心开展，其余组员提意见和建议，在alpha冲刺前，就已经完成了大致的项目结构。我觉得是一个合适的时间，也是合适的人。
在前端设计中，会产生和UI图的布局有少许差别的情况，算是模棱两可，此时的话，就会以前端设计为主，等项目成型后，再由美工去提意见，然后进行修改，小问题的话，就先做出来，然后再去扣细节。
使用过单元测试来测试API的对接是否可用。
项目开始的UML比较没有那么的细致，现在的细节比较多，这些去别的产生是由于随着开发进行，有一些功能被我们去放弃，而有一些细节部分，又被我们加上去，所以产生了区别。是应该更新UML文档。
首页布局上出的BUG比较多，主要是因为布局相对复杂。UI需求是一个Header(作为广告位) + Tab(切换类别) + 瀑布流列表，最初想通过ViewPager实现，后来发现这样做会造成滑动冲突，导致Header无法上滑被隐藏，换用RecyclerView后基本能实现想要的效果，但是瀑布流有时item的尺寸又会出BUG，改了蛮久。发布后发现服务器对高并发的处理能力不是很强，只要一秒200次请求，服务器响应时间就变得很长，这时再请求，就会导致前端误以为服务器无响应，而只简单的报告网络异常。主要还是因为开发的时候测试规模比较小，没有考虑过高并发的情况。
由两位大佬亲自审查，严格执行了代码规范，从常规项和安全性两个角度进行审查。
常规项：代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。所有的代码是否简单易懂？代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释是否存在多余的或是重复的代码？等等
安全性：所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？在哪里使用了第三方工具，返回的错误是否被捕获？
从这几个方面开始入手。
会加强对功能的强化和细节方面的处理，希望能在beta冲刺有所进步
是否进行了正式的验收测试？
有一个测试计划，由前后端一起执行，进行了非正式的验收测试。
有，我们利用JUnit测试工具。
目前没有做关于软件性能的测量。下次一定。
发现通过我们的发送请求给教务处的时候，对安全性的封装还不够，不影响使用，但会影响软件安全性，正在修改中
我们不会将接口暴露出来，也会做好封IP准备。
先根据每个人实际已掌握的技术特长安排相关的前端（后端）主要负责人，带着一些没有接触过实际项目开发的同学一起进行学习开发，再保证不影响开发效率的情况下共同进步。还有一些同学负责文档编写，ppt制作等，虽分工不同但人尽其才。
团队中的技术大佬带着技术小白共同进步学习。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们认为目前团队还处于CMMI一级，执行级的档次。因为大部分同学没有太多开发经验，很多开发上的问题还是第一次接触，还是只能奔着实现项目需求出发。希望未来可以继续努力，锻炼出更强的软件综合开发能力，往更高一级水平迈进。
处于规范阶段，因为队内有前端后端技术大佬，在项目等实际开发落地上少走了很多弯路，但是对一些开发规范例如接口文档的编写等方面还需要进一步加强。
团队分工配合更加明确，项目的初代版本功能已经基本实现。
改进关于用户信息加密的部分，因为绑定用户学号涉及到用户的教务处密码。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我觉得我们小组做的最好的原则是“避免不必要的开销”。因为从产品设计阶段开始，我们便致力于减少不必要的时间浪费。例如最初的产品设计，我们就从实际可行性出发，不去幻想一些天马星空的需求，从是否能实现或规定时间内能否学会为基础进行设计，避免花费大量的时间去画饼但最后技术上却无法实现而改文档需求。
53.1分
1.如果借出去的东西遭到破坏，应该怎么办?（第二组）
如果遭到破坏之后，借出者向我们反映的话我们会联系借用者让他们私下解决，我们只起到一个平台的作用，对于具体的破坏程度与赔偿事宜还是得当事人来解决，平台会对破坏者进行信用分数的扣除
2.个人信息是否能得到安全保障？（第三组）
能得到安全保障，对于使用者的用户密码我们只是在登陆的时候拿去与教务处对接匹配，并不会私自保存
- 对于用户的信用评级有没有一个比较客观的方法来完成？（第四组）
每次借还的时候我们会让借用者拍照留底，若借出者发现有损坏并且平台人员核实之后会酌情扣除借用者的分数
- 暂无问题（第五组）
- 上午演示的时候，感觉不是单纯的网络问题 ，做过压力测试吗？（第六组）
实情是福哥对我们服务器进行了攻击；没做过压力测试
- 永福搞你们，你们有没有把他锤爆？（第七组）
暂时没有，但四十米大刀在快递来的路上了
- 你们后端是怎么协调租借流程的？（第八组）
讨论得出的啊，就几个人商量一下出来的
- 想问一下你们的分工是怎么做的，感觉ppt中每次alpha进度有一定进度。（第九组）
分工就是按照个人能力来分配的，每次都有进度是因为我们把任务分的很细，细水长流
- 今天早上演示时候说是网络问题，但我觉得会不会是程序的问题？或者说是服务器的问题？（第十组）
不是程序的问题，是服务器的问题，服务器被福哥攻击了
- 并发的问题，你们的接口写完没测试性能的吗?（第十一组）
目前还未做相关方面的测试，下一阶段做
- 后端的最大并发多少？敏感信息是否加密传输?（第十二组）
最大并发还未做，敏感信息例如账号密码暂时还未加密传输，之后会补充优化
标签：瀑布流 不用 综合 代码量 安卓 目标 验收测试 最大 滑动
原文地址：https://www.cnblogs.com/zaynq/p/11924748.html
