zoukankan      html  css  js  c++  java
  • 第01组 Alpha事后诸葛亮

    目录

    组长博客

    一.总结思考

    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.设计/实现

    6.测试/发布

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

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

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

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

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

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

    8.总结

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

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

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

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

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

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

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

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

    讨论照片

    二.答辩总结

    ①贡献比例

    ②现场答辩得分

    53.1分

    ③回答其他小组对本小组的提问

    1.如果借出去的东西遭到破坏,应该怎么办?(第二组)
    如果遭到破坏之后,借出者向我们反映的话我们会联系借用者让他们私下解决,我们只起到一个平台的作用,对于具体的破坏程度与赔偿事宜还是得当事人来解决,平台会对破坏者进行信用分数的扣除

    2.个人信息是否能得到安全保障?(第三组)
    能得到安全保障,对于使用者的用户密码我们只是在登陆的时候拿去与教务处对接匹配,并不会私自保存

    1. 对于用户的信用评级有没有一个比较客观的方法来完成?(第四组)
      每次借还的时候我们会让借用者拍照留底,若借出者发现有损坏并且平台人员核实之后会酌情扣除借用者的分数

    4.暂无问题(第五组)

    5.上午演示的时候,感觉不是单纯的网络问题 ,做过压力测试吗?(第六组)
    实情是福哥对我们服务器进行了攻击;没做过压力测试

    6.永福搞你们,你们有没有把他锤爆?(第七组)
    暂时没有,但四十米大刀在快递来的路上了

    7.你们后端是怎么协调租借流程的?(第八组)
    讨论得出的啊,就几个人商量一下出来的

    8.想问一下你们的分工是怎么做的,感觉ppt中每次alpha进度有一定进度。(第九组)
    分工就是按照个人能力来分配的,每次都有进度是因为我们把任务分的很细,细水长流

    9.今天早上演示时候说是网络问题,但我觉得会不会是程序的问题?或者说是服务器的问题?(第十组)
    不是程序的问题,是服务器的问题,服务器被福哥攻击了

    10.并发的问题,你们的接口写完没测试性能的吗?(第十一组)
    目前还未做相关方面的测试,下一阶段做

    11.后端的最大并发多少?敏感信息是否加密传输?(第十二组)
    最大并发还未做,敏感信息例如账号密码暂时还未加密传输,之后会补充优化

    PSP

    学习进度条

  • 相关阅读:
    去掉字符串不需要的HTML标记(正则表达式)
    js 注册命名空间(registerNamespace )
    动态DNS负载均衡
    Juery 动态移除js、动态添加js
    UpdatePanel 后台注册脚本失效
    FCKeditor的fckconfig.js配置 中文说明
    C# world模板中写信息
    Jquery 操作table行增减
    用jQuery解决跨域访问
    Request.ServerVariables(HTTP_REFERER) 获取方式注意
  • 原文地址:https://www.cnblogs.com/fzu-Z9h/p/11924041.html
Copyright © 2011-2022 走看看