06组团队项目-中期总结

[102101215华恺]

• • 一、团队名片

    (2.1) 团队名片

    队长博客

    

    • 现场答辩总结

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

    • 团队讨论

    

    姓名	具体分工	得分比例
    陈艺	后端	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.每个成员明确公开地表示对别人帮助的感谢

    感谢
    我感谢陈伟雄对我的帮助，因为他帮我们决定了原型设计的大致方向并提高了示例，大大减轻了工作压力。

    2.2.8 总结

    • 陈伟雄

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

    • 黄鹏伟

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

    • 林振杨

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

    • 陈世玮

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

    • 林高颖

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

    • 华恺

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

    • 杨艺钊

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

    • 陈艺

      • 在这次α冲刺轮中，我们团队经历了一次紧张而高效的迭代。老师的抨击虽然在当时让人感到沮丧，但回头看，这种批评实际上是推动我们进步的动力。我们在这个过程中学到了许多宝贵的经验教训。