06组团队项目-中期总结

林振杨102101234 2023-11-20 08:45:18
    • 一、团队名片

      (2.1) 团队名片

      队长博客

      img

      • 现场答辩总结

        • 很多东西好没考虑完全
          • 比如结账方式、问题等,解决方案目前是优先做一个担保账户
          • 还有就是主题颜色问题,目前计划是再提供一个主题颜色选择,可以自由切换背景颜色(不知道能不能实现),无法实现的话就直接更改背景颜色
          • 还有就是地图问题考虑一下怎么实现
      • 团队讨论

      img

      姓名具体分工得分比例
      陈艺后端122%
      杨艺钊前端117%
      黄鹏伟前端115%
      陈伟雄文档,部分原型110%
      林高颖原型105%
      林振杨原型101%
      陈世玮后端70%
      华恺原型60%
      800%

      二、总结思考

      2.2.1 设想和目标

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

      • 我们的软件目的是解决可能存在的校园代替服务。目的十分明确也一直以此为目的开发。典型用户和典型场景描述的很清楚了,在第一次博客中描述的很清晰:典型用户->学生,典型应用场景->时间紧张、身体不便、懒等等

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

      • 有一说一,其实我们的目标任务已经完成了,已经实现了发布任务、查看任务、接受任务、筛选任务,其他的一些本来就不是主要要实现的功能(比如付款和抽成)。按照原计划提交了(大概)。都还没有发布哪来的用户。

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

      • 作为内侧人员目前大概的流程已经完成了,但是还有一些功能需要优化,比如说查看任务界面还没有实现。反正离原来第一次冲刺的目标很近了。

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

      • 原型设计一开始没有沟通好,很多布局每个人都有自己的想法且不够完善。所以在优化美化原型时给前端带来了巨大的工作量。如果还能那个再来一次的话,一定要直接让原型做美化,同时让前端给出意见,边做边改,争取原型一次过。

      2.2.2 计划

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

      • 有。但是计划不是很完美的样子,所以后面重构了。

      2.团队在计划阶段是如何解决组员对于计划的不同意见的?

      • 开会时直接提出然后一起讨论可行性,最后通过投票表决。

      3.原计划的工作是否最后都做完了? 如果有没做完的,为什么?

      • 原型还没做完,前端要等原型,后端倒是差不多。为什么呢?我也想知道。

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

      • 选了粉色的主题色。然后被批斗了。。

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

      • 前后端的对接比较清楚。但是前端和原型的沟通就没有那么频繁了。

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

      • 没有,完全想不到前端要重构,为什么没有估计到?因为之前没有做过,第一次做小程序没有什么经验。

      7.在计划中有没有留下缓冲区,缓冲区有作用么?

      • 没有

      8.将来的计划会做什么修改?(例如:缓冲区的定义,加班)

      • 开会先让每个人说一下自己的想法和进度统一协调。

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

      • 先认真了解怎么做比较合理

      2.2.3 资源

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

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

      • 急的话就加急做呗,资源估计真不擅长。精度是没有的。

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

      • 人力资源是嘎嘎够的,对于那些不需要编程的资源难度是没有低估的。

      4.你有没有感到你做的事情可以让别人来做(更有效率)?

      • 有一些事让别人来做更好,因为自己多少不擅长

      2.2.4 变更管理

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

      • 开会时通知或者直接qq群聊天

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

      • 分析利弊然后投票

      3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

      • 能跑起来就是完美的。至少目前很好。后面的话就是用户体验该功能然后给出评价,根据这个评价来判断。

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

      • 以前是没有的,这就导致前端重构,以后的话,,下次开会讨论一下

      5.组员是否能够有效地处理意料之外的工作请求?

      • 不是很有效

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

      • 如果能重来一遍我想硬气一点。

      2.2.5 设计/实现

      1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

      • 设计小组有三个人,谁做的工作量相对比较少就谁做。

      2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?

      • 先有一个人做出来,然后在做一个改进版比较

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

      • 目前还没有

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

      • 没啥区别,大致过程没有变化所以不需要更新。

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

      • 发布任务的时候。有时候发布不了,需要重新登录。bug那么多,怎么可能都想好,见招拆招。

      6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

      • 还没代码复审

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

      • 这些好像提前做出规划能规避不少坑。下次应该专门让一个人来调查这些状况。

      2.2.6 测试/发布

      1.团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?

      • 有一个粗略的。人工测试。

      2.团队是否有测试工具来帮助测试?

      • 计划用,看看能不能找到合适的。不行就人工测试。靠用户反馈bug

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

      • 目前还没做这个。

      4.在发布的过程中发现了哪些意外问题?

      • 老铁还没发布别太荒谬

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

      • 那就从现在开始找测试软件吧

      2.2.7 团队的角色,管理,合作

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

      • 根据个人特长进行分工。有的人人尽其才,有的人不是很尽

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

      3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?

      • 直接沟通解决

      4.每个成员明确公开地表示对别人帮助的感谢

      • 我感谢陈伟雄对我的帮助,因为他制作的PPT美观实用,也让我明白了讲成语的坏处。

      2.2.8 总结

      • 陈伟雄

        • 很多细节的地方确实根本没有讨论过,在期中总结后才一语惊醒梦中人,更加明确了我们的目的:应该着重与软件的功能与开发,并将用户体验视作信条(再也不死鸭子嘴硬了呜呜,以后谁提付款的茬我骂谁,公益软件好吧,其他功能上的批评和意见欢迎指出)。还有就是冲刺时间和很多科目的考试冲突啊,我做的是真想die啊(比如今天做了一天实验还要写博客)
      • 黄鹏伟

        • 尽管不知道为什么要叫Alpha冲刺,但是是可以经历完找个过程可以说是很痛苦,每天都得写代码,写代码就算了,写完还得重构,相当于白写,每天写代码写到头昏脑胀,看到那一堆标签和样式就头疼,明明每天都干了很多,但是却并没有推进多少。这个阶段又有穿插七七八八的考试,每次都得挤时间复习,其他科目的学习也还没推进,完蛋了,真的完蛋了。究其原因,自己确实是垃圾,技术落后,每次都得学,学还学很慢,就没有几天是能安稳地睡着,课明明就不多,却干了不下于课程表满课的事情,真的服啦,后面还有一个月的痛苦生活,完蛋啦。基本流程是已经闭环了,但是还有一堆bug要改,后面这个阶段只会更累,后面的考试更多。
      • 林振杨

        • 经过软工冲刺,我深刻理解到团队合作的重要性。每个人都有自己的长处和短处,只有通过有效的沟通和协作,才能发挥出最大的效果。同时,我也认识到了时间管理的重要性,合理安排时间,提高工作效率。此外,我还学会了如何面对困难和挑战,坚持不懈,才能取得成功。
      • 陈世玮

        • 在冲刺过程中,需求和优先级可能会发生变化。我学会了灵活应对这些变化,及时调整自己的工作计划和代码实现。采用敏捷开发方法,能够快速响应变化,并在团队中与其他成员紧密合作,确保项目的整体进展。
      • 林高颖

        • 在设计原型时,要尽量保持界面简洁明了,避免过多的冗余信息。通过合理的布局、清晰的导航和易于理解的操作流程,帮助用户快速上手,降低使用难度。
        • 原型设计是一个不断迭代的过程,需要根据反馈和测试结果,不断优化和完善设计方案。在设计原型时,要考虑到后期的修改和维护,尽量避免过于复杂的设计
      • 华恺

        • 经过软工冲刺,我深刻理解到团队交流的重要性。能积极有序交流的团队才是一个好的团队,队员之间交流想法不仅能启发灵感还能增进感情,提高工作效率。积极向队友寻求帮助也让我们可以互相学习,一起进步。
      • 杨艺钊

        • 在这次挑战中,我领悟到项目的需求和优先级随时可能变动。我学到了灵活应对这些变化的重要性,随时准备调整工作计划和代码实现。通过采用敏捷开发方法,我能够迅速适应变化,并与团队紧密协作,确保项目整体顺利推进。
      • 陈艺

        • 在这次α冲刺轮中,我们团队经历了一次紧张而高效的迭代。老师的抨击虽然在当时让人感到沮丧,但回头看,这种批评实际上是推动我们进步的动力。我们在这个过程中学到了许多宝贵的经验教训。
...全文
12 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

120

社区成员

发帖
与我相关
我的任务
社区描述
2023福州大学软件工程K班
软件工程 高校 福建省·福州市
社区管理员
  • kevinkex
  • Devil angel
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧