第01组 Alpha事后诸葛亮

Posted 2020-11-22 zaynq

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了第01组 Alpha事后诸葛亮相关的知识，希望对你有一定的参考价值。

一.总结思考
二.答辩总结
个人PSP
学习进度条

组长博客

一.总结思考

1.设想和目标

①我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的借呗app定义得很清楚，要解决的是“学校活动室借还困难与线下物品借还困难”的问题。

典型用户
a.需要短时间使用某件物品的有(租)借入需求的用户。
b.想将闲置物品借出共享的有(租)借出需求的用户。
c.想提高管理、分配活动室/物资效率的管理者和被繁琐借用流程所扰的借方。

典型场景
技术图片

②我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?

功能还差几个未完成，例如“消息模块”的推送学校、学院通知的功能，和数据分析功能。
已经按照原计划交付时间交付了，还未达到原计划的用户数量。

③用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

接受程度按照周六早晨的答辩来说和我们的预想大概一致，我们离目标更近了

④有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

学到了在做规划的时候不能将饼画的太大，目标还是得定在可实现范围内
如果历史重来一遍，我们会更加细化考虑预设的软件功能，在能力所致范围内给大家带来更多的惊喜功能。

2.计划

①是否有充足的时间来做计划?

从布置团队作业开始，我们就通过会议讨论好了大致的分工和APP要做的方向，但是过程中做计划的时间不多，但随着项目的完善，我们也在不断改善自己的计划。

②团队在计划阶段是如何解决同事们对于计划的不同意见的？

通过会议讨论，大家提出各自的意见，觉得合理可行的即通过，在项目的实际进行过程中，在产品经理画好大致框架的情况下，UI和前后端各自视情况而定，大佬说的都对。

③你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

林睿（组长）：原计划的任务是总体进度的跟进和博客，算是做完了，不过期间由于考试等原因改过几次进度
邓泽源：分析算法基本完成，加权优化还在改进中，为什么没做完，因为要考试要恰饭要睡觉要秃头的啊 靓仔
张庆焰：原计划的前端和与后端的交互基本上完成，没做完的有部分UI图还没做好
姚彬锟：完成社区界面的设计和还有登陆界面
朱宏 ：原本想把数据分析做好，结果生活还是太难了
蔡雅菁：产品经理的工作完成，主要任务是计划“借呗”app的整体框架与细节、做ppt和写计划书
吴洁敏：原计划的UI界面基本上做完了，没有完善好，打杂工作没做好，组长大大赛高
周鑫煌：有。没做完还能为什么？当然是因为没时间啊！书不用读吗？作业不用写吗？考试不用复习吗？（灵魂三问）
王景弘：原计划的UI设计工作最后都做完了
陈展鸿：原计划的内容没有完全做完（因为还有beta冲刺），只能说alpha冲刺内容已经做完
陈观鸿：前端任务完成百分之八十，还有一部分前后端对接任务还没完成，因为前后端对接不太会

④有没有发现你做了一些事后看来没必要或没多大价值的事?

林睿（组长）：貌似没有
邓泽源：真的想不出来，大概是没有吧
张庆焰：由于之前有过安卓项目经历，所以并没做什么没必要或者没多大价值的事
姚彬锟：完成的任务基本都是提前已经设计好且必须要完成的任务，那些琐碎而没多大价值的事情我们在设计阶段就已经排除了
朱宏 ：.感觉画再多的ui，最后也会被实现的复杂性打倒
蔡雅菁：好像没有？个人感觉我们组分配任务还挺合理的，每个人都完成自己的分内之事，然后不断学习
吴洁敏：有，之前设计的UI界面中有的部分并没有设计好，有时写博客太过拖拉，效率不高
周鑫煌：发现没有去研究运用一些设计模式，投入的时间大部分在重复的垃圾代码上，再多的代码量也显得没有价值。
王景弘：的确有一些事是事后看来没必要的，例如前一两例的UI设计，因为刚刚入门所以对很多要求都不甚明了，直接导致做了大概四五个小时的废版，然后推倒重做，后面想来如果做之前有充分的沟通交流就不会这么浪费时间了
陈展鸿：没有，做的全都是有意义的事，每一个模块都有其特定的功能
陈观鸿：都挺有价值的，这得归功于大佬带的好，我就完成了他说的部分，没有多余部分，zqy太猛

⑤是否每一项任务都有清楚定义和衡量的交付件?

有的有，有的没有，有的部分在前期做的时候并没有考虑完善。但有项目经历的前后端大佬的部分做的会比较好。在开始真正编写代码之前，前后端人员有进行详细的沟通，并制定了前期的计划，例如制定了一些接口的规范、所使用的技术规范，总体而言，对于每一项任务都有较为清楚的定义。

⑥是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

首先我们制定了一些计划，并且有按照计划一步一步实现，但是在开发的过程中难免会遇到一些重要但是开始没有计划到的内容，于是就会脱离计划去完成那些重要内容，项目并没有出现大的意外，风险嘛，目前还没估计，因为项目还没真正完成，所以还没考虑。

⑦在计划中有没有留下缓冲区，缓冲区有作用么?

有留下一些时间用于前后端交互和修改debug，就是尽早的打完代码。有作用，让前后端交互和改bug的时间不会挤到最后。

⑧将来的计划会做什么修改？（例如：缓冲区的定义，加班）

目前一些核心的界面及后端基本上已经完成，在此基础下，会尽快完善剩余的一些界面，规划好deadline，再扩展缓冲区做debug，以防最后匆忙慌乱。还准备在项目最终完成前留下一些用户测试的缓冲区，以完善一些功能。

⑨我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

学到了要留下缓冲区做前后交互和debug，不能将计划制定的刚刚好。
如果历史重来一遍，我们会更细分各自要做的任务，让前后端人员更加轻松一些，将任务分配的更平均一些。并且要在一开始就细分好每个任务的deadline，让项目有条不紊的进行。

3.资源

①我们有足够的资源来完成各项任务么?

我们有足够的资源来完成各项任务（但时间资源有些稍微不充分）

②各项任务所需的时间和其他资源是如何估计的，精度如何?

我们所需的时间是根据人员的分配以及个人能力估计的，精度大致相同

③测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间和资源都足够，对于不需要编程的资源未低估难度

④你有没有感到你做的事情可以让别人来做（更有效率）?

⑤有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

对于时间分配来说，由于碰上了考试多的一周，所以时间分配上不是特别充裕
如果历史重来一遍，我们会对时间安排更加上心，不会拖到时间不够的时候才完成

4.变更管理

①每个相关的员工都及时知道了变更的消息?

是的，我们建立了群聊，每次有什么比较重要的变更都会艾特相关成员通知，确保每个人及时收到消息。

②我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们严格的对每个界面进行设计，如果有x->y，也就是必须先有y才可以做x，那么必须实现的就是x，可以推迟的就是y。当然有一部分y是拓展的功能不是app主要部分的话，我们也会推迟。

③项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

我们认为进行测试完，总体功能都能实现，不出现明显错误的情况为做好了。做好了后仍然会进行优化。

④对于可能的变更是否能制定应急计划?

没有什么特殊的应急计划，遇到了就是加班加班加班。

⑤员工是否能够有效地处理意料之外的工作请求？

我们规定请求都转到组长那里处理，这样减轻了开发人员的压力，让他们有大部分时间花在自己那一部分的开发，然后意料之外的事情大家会一起思考解决。

⑥我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

考虑的东西还是不够多，很多地方考虑的仍然不够细致，如果历史重来一遍，我们会对每一块内容进行更加细致的分析，前期准备做的更好。

5.设计/实现

①设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作从Alpha之前的十天就已经开始准备了，设计人由周鑫煌，张庆焰，陈展鸿三人为核心开展，其余组员提意见和建议，在alpha冲刺前，就已经完成了大致的项目结构。我觉得是一个合适的时间，也是合适的人。

②设计工作有没有碰到模棱两可的情况，团队是如何解决的？

在前端设计中，会产生和UI图的布局有少许差别的情况，算是模棱两可，此时的话，就会以前端设计为主，等项目成型后，再由美工去提意见，然后进行修改，小问题的话，就先做出来，然后再去扣细节。

③团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

使用过单元测试来测试API的对接是否可用。

④比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

项目开始的UML比较没有那么的细致，现在的细节比较多，这些去别的产生是由于随着开发进行，有一些功能被我们去放弃，而有一些细节部分，又被我们加上去，所以产生了区别。是应该更新UML文档。

⑤什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

首页布局上出的BUG比较多，主要是因为布局相对复杂。UI需求是一个Header(作为广告位) + Tab(切换类别) + 瀑布流列表，最初想通过ViewPager实现，后来发现这样做会造成滑动冲突，导致Header无法上滑被隐藏，换用RecyclerView后基本能实现想要的效果，但是瀑布流有时item的尺寸又会出BUG，改了蛮久。发布后发现服务器对高并发的处理能力不是很强，只要一秒200次请求，服务器响应时间就变得很长，这时再请求，就会导致前端误以为服务器无响应，而只简单的报告网络异常。主要还是因为开发的时候测试规模比较小，没有考虑过高并发的情况。

⑥代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

由两位大佬亲自审查，严格执行了代码规范，从常规项和安全性两个角度进行审查。
常规项：代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。所有的代码是否简单易懂？代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释是否存在多余的或是重复的代码？等等
安全性：所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？在哪里使用了第三方工具，返回的错误是否被捕获？
从这几个方面开始入手。

⑦我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

会加强对功能的强化和细节方面的处理，希望能在beta冲刺有所进步

6.测试/发布（3分）

①团队是否有一个测试计划？为什么没有？

是否进行了正式的验收测试？
有一个测试计划，由前后端一起执行，进行了非正式的验收测试。

②团队是否有测试工具来帮助测试？

有，我们利用JUnit测试工具。

③团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

目前没有做关于软件性能的测量。下次一定。

④在发布的过程中发现了哪些意外问题？

发现通过我们的发送请求给教务处的时候，对安全性的封装还不够，不影响使用，但会影响软件安全性，正在修改中

⑤我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们不会将接口暴露出来，也会做好封IP准备。

7.团队的角色、管理、合作

① 团队的每个角色是如何确定的，是不是人尽其才？

先根据每个人实际已掌握的技术特长安排相关的前端（后端）主要负责人，带着一些没有接触过实际项目开发的同学一起进行学习开发，再保证不影响开发效率的情况下共同进步。还有一些同学负责文档编写，ppt制作等，虽分工不同但人尽其才。

② 团队成员之间有互相帮助么？

团队中的技术大佬带着技术小白共同进步学习。

③ 当出现项目管理、合作方面的问题时，团队成员如何解决问题？每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

8.总结

①你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

我们认为目前团队还处于CMMI一级，执行级的档次。因为大部分同学没有太多开发经验，很多开发上的问题还是第一次接触，还是只能奔着实现项目需求出发。希望未来可以继续努力，锻炼出更强的软件综合开发能力，往更高一级水平迈进。

②你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

处于规范阶段，因为队内有前端后端技术大佬，在项目等实际开发落地上少走了很多弯路，但是对一些开发规范例如接口文档的编写等方面还需要进一步加强。

③你觉得团队在这个里程碑相比前一个里程碑有什么改进?

团队分工配合更加明确，项目的初代版本功能已经基本实现。

④你觉得目前最需要改进的一个方面是什么?

改进关于用户信息加密的部分，因为绑定用户学号涉及到用户的教务处密码。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我觉得我们小组做的最好的原则是“避免不必要的开销”。因为从产品设计阶段开始，我们便致力于减少不必要的时间浪费。例如最初的产品设计，我们就从实际可行性出发，不去幻想一些天马星空的需求，从是否能实现或规定时间内能否学会为基础进行设计，避免花费大量的时间去画饼但最后技术上却无法实现而改文档需求。

讨论照片

技术图片

二.答辩总结

①贡献比例