06组团队项目-中期总结

[陈伟雄102101229]

一、团队名片

(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要改，后面这个阶段只会更累，后面的考试更多。

• 林振杨

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

• 陈世玮

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

• 林高颖

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

• 华恺

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

• 杨艺钊

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

• 陈艺

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