第09组 Beta冲刺 总结

1.基本情况

• 组长博客链接：https://www.cnblogs.com/yydswlt/

• 答辩总结：Beta冲刺结束了，但是项目还未结束，功能还需要继续完善，针对老师提出的新问题再进一步的改善，早日获取真实数据量。

• 全队谈论照片：

• 工作流程：

  • 制定计划：确定Beta冲刺目标及计划，合理安排进度任务及负责人
  • 需求分析和定义：代入用户自身提出对现有成果的改进和提出新的需求
  • 软件设计：确立新增及修改的软件结构，各个模块的功能，概要设计和详细设计
  • 编码与单元测试：实现已做的设计，写出正确的，容易理解和维护的程序代码
  • 集成和系统测试： 通过各种类型的测试来提高软件质量，使软件达到预定的要求

• 组员分工比例：

  姓名	分工	比例
  魏霖涛	文档	9
  叶飞扬	后端，测试	14
  何坤杰	后端，测试	14
  肖少东	后端，测试	15
  张郑峰	前端，测试	15
  宋静慧	原型	7
  罗彤	文档，后端	10
  柳越	文档	6
  赖彪	文档	6
  刘惟凝	美工	4

2.总结

2.1.设想和目标

• 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  • 我们这款软件的目的在于在校大学生收集考证、竞赛信息，并帮他们规划相关路线并推荐相关信息的小程序，定义清晰
  • 典型用户为福大在校大学生
  • 典型场景为对于各项竞赛证书报名信息感到毫无头绪或者对于报名竞赛了解较少
• 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
  • 原计划功能已全部实现包括：证书，竞赛模块，组队模块，聊天模块，及对应的路线提醒模块。
  • 原计划交付时间为11月30日，还未到时间
  • 已开始逐渐开放测试，暂有十几个用户
• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  根据现有情况来说，总体是比较符合预期的，我们已经快接近目标了。
• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  暂无

2.2.计划

• 是否有充足的时间来做计划?
  我们大概用了一个小时来做详细的计划，我们在Beta阶段的设计阶段基本上确定了每个人的任务，在设计阶段，规划所需时间，以及完成时间。在开发过程中我们在组会上相互沟通，大家在PM的统一协调下对自己的计划进行微调。
• 团队在计划阶段是如何解决同事们对于计划的不同意见的？
  在组会上大家在PM的统一协调下提出并解释自己对计划的不同意见，大家讨论后由PM权衡利弊决定方案的修改与否，开放讨论，鼓励头脑风暴，最好多分支，多细节，多提问，对于一些问题都有所准备
• 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  原计划的功能已完全实现，剩余开放测试的调试及后续的修改优化。
• 有没有发现你做了一些事后看来没必要或没多大价值的事?
  我们所做的工作基本上全部投入使用，只有一些微调，基本没有无用功。
• 是否每一项任务都有清楚定义和衡量的交付件?
  是的。我们每一项任务都有明确的交付标准，对于开发者来说，主要是代码、文档和apk文件。对于PM来说，主要是博客、Issue管理等。
• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  整个过程大体是按计划进行的，但是项目的周期过于短加上时间上的冲突。导致项目的进度较慢这是没预想到的。
• 在计划中有没有留下缓冲区，缓冲区有作用么?
  存在缓冲区。我们将最后的一轮冲刺作为测试阶段，它同时也发挥了缓冲区的作用。我们在最后一轮进行了一些针对前几轮冲刺阶段暴露出的问题的修改。
• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  将来的计划依然会留出足够时间的缓冲区，用于测试和弥补开发阶段的失误。同时会进行准确的每日任务分配，尽可能不要出现某几天疯狂加班补进度的情况
• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 制定一个完整计划的重要性，及相对应的计划更新
  • 如果重来一次，我们会更加详细的制定计划，争取能应对多种情况

2.3.资源

• 我们有足够的资源来完成各项任务么?
  在人力上我们有10个人，2个前端，3个后端，其他组员辅助开发，在整个项目完成的情况看来人力是充足的，在物力上也够充足。
• 各项任务所需的时间和其他资源是如何估计的，精度如何?
  首先，大体的人员分布由第一次站立会议讨论得出。然后在每次站立会议中，每个人说出自己上一轮完成的任务，然后再自己估计下一轮完成的任务，总体来说精度十分准确。
• 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  测试的时间和人力总体来说是够的，对于不需要编程的资源，文案有点低估了难度，但是重在学习，可以努力提升。
• 你有没有感到你做的事情可以让别人来做（更有效率）?
  没有，我认为我们小组每个人都在自己的职位上充分发挥了自己的用处，可以说每个人都对自己的任务尽心尽力，注入了自己的心血。
• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  • 当项目进度与学科考试冲突时，项目会停滞
  • 如果历史重来一遍，我们会更加细化分工

2.4.变更管理

• 每个相关的员工都及时知道了变更的消息?
  每个相关组员可以及时知道变更的消息。如果需要负责模块间协作进行变更，我们往往会在每轮站立会议中全组共同讨论，规范变更内容，以减少额外的沟通成本；对于一些紧急变更，我们会在团队qq群进行沟通与通知。
• 我们采用了什么办法决定“推迟”和“必须实现”的功能?
  从待实现的功能角度分析：一是用户当下最需要的功能，就是我们“必须实现”的功能。二是受制于当下情景，一些功能只能延迟上线。
• 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  • 兼容性：对于几乎所有主流版本都能够实现兼容。
  • 易用性：按钮功能明确，功能入口醒目，弹窗提示易懂。
  • 稳定性：所有功能都能正常运行，进行常规操作时几乎不出现运行时Bug。
  • 及时性：后端能及时更新信息变化，并反馈给前端。
• 对于可能的变更是否能制定应急计划?
  能。在进行每轮站立会议时，一些组员会提出一些意见和建议，当经过讨论被采纳后，我们会制定应急计划，将任务分配到人并约定好完成变更的DDL。
• 员工是否能够有效地处理意料之外的工作请求？
  能够有效的处理，我们在开发过程中也出现了许多意料之外的请求。对于意料之外的请求，我们的团队成员都比较积极主动，空闲的员工会主动接下请求并有效的处理好，在大家都没空时，也会积极沟通协作处理好请求。
• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 变更可能是团队开发中必上的一课。开发过程中，很难保证一切工作都能如计划一般如期进行，且开发过程中也会发现当初计划的不足。
  • 历史重来一遍，我们会更加审视计划，尽量减少变更。如果有所变更，团队成员需要更及时地提出困难，更早的分配任务和DDL，尽量保证其对正常开发任务的最小影响。

2.5.设计/实现

• 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  设计工作是在Beta阶段开始前的一次会议进行的，这个时间比较合适。是由PM来主持会议，组员一起讨论完成的。
• 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  模棱两可的情况也有，比如前端的导航栏设在下面还是侧面，前后端交互的格式是什么样的。这种问题由于没彻底完善，如果把格式定死的话，碰到新的问题不好处理。这种问题我们一般是通过开发过程中前后端进行讨论来明确。
• 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  团队有用到单元测试，在后端中，每个模块都有相应junit测试，尤其是在用户的头像上传和聊天中，由于涉及了文件传输与websocket，测试项目最多，其他模块的测试比较简陋。
• 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  uml文档在原先的基础有一些改动，首先是增加了一个路线模块，用户能将自己中意的比赛加入路线，然后提供一个路线日历、规划以及提醒功能，然后取消了原先的竞赛报名功能。除了以上问题，其他小差别uml不打算更新了，因为整体的项目框架与诸多细节已趋于完善。
• 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  聊天模块。由于websocket接口与平常开发的用的http/https大不相同，加上各种队伍、用户之间的复杂逻辑，导致该模块多次重写，bug繁多，项目阴影
• 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  代码复审：首先第一个步骤是检查了代码能否运行，看看有没有实现预期的功能，逻辑是否正确。然后是简化代码，检查是否有多余的或者是重复的代码，尽可能做到简单易懂。其次是检查模块化，因为后端使用的是分布式框架，尽可能的降低模块间的耦合。具有一定的代码规范，括号位置、变量名和函数名、行的程度还有缩进都尽可能的做到了规范化。
• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  • 我们学到了团队协作时怎么进行代码管理，学到了怎么写代码方便他人阅读，学到了接口说明文档的重要性。
  • 如果历史重来一遍，会更加规范代码，做好测试

2.6.测试发布

• 团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
  • 我们团队有较为完善的测试计划:
    • 在开发阶段，由前端、后端各自构造小规模数据验证功能的正确性
    • 在测试阶段，前端、后端、测试组三者共同运行，用开发人员的统一认证账户获取数据，详细测试各个功能是否正确运行。
    • 在验收阶段，进行小规模的压力测试，保证对于用户量较多的情况下能及时响应请求。
  • 正在逐步开放测试
• 团队是否有测试工具来帮助测试？
  团队有借助jmeter、jprofiler来做些测试
• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  根据用户的请求响应速度与正确性来测量。通过实践我们肯定了这些测试工作是有用的，只有“防患于未然”才能带给用户更好的体验。唯一的不足就是我们的错误处理机制还不够完善，否则我们可以更快地定位bug所在。
• 在发布的过程中发现了哪些意外问题？
  暂无
• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  对于我们来说，印象最深刻的应该是测试出问题以后修改问题，如果重来一遍，我们会更加注重错误处理这一部分，提高代码质量。

2.7.团队的角色，管理，合作

• 团队的每个角色是如何确定的，是不是人尽其才？
  • 首先，确定好团队的大致分工，将开发工作分为三类：前端、后端、文档组，另外还有一名PM
  • 经过讨论、商议、自愿分配，最终确定了这四类工作的人数和人员
  • 每位同学都进行自己自愿选择的工作和擅长的领域，可以说人尽其才。
• 团队成员之间有互相帮助么？
  团队成员的互相帮助是必不可少的。无论是同部门之间的相互扶持，还是跨部门的会议讨论，商议工作，都是团队成员互相帮助的体现
• 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
  目前来说，我们团队没有遇到这方面的障碍。不过，在出现相关问题的苗头时，我们会及时在站立会议中提出，共同商议，是否需要更换岗位，重新分配工作，或者重新计划相关任务。
• 个人感谢

2.8.总结

• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  我们团队应当属于CMMI的第二级，即管理级。我们不仅能够遵循第一级“执行级”中的所有内容，实现目标，团队成员也能遵守计划，权责到人，避免完成任务的随机性，保证了成功率。
• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  我们团队应当已经进入规范阶段。团队成员可以公开讨论流程和工作的方式，自动建立起了一些成文或不成文的规则。大家都有更强的集体意识，愿意在工作中互相支持，互相尊重，互相欣赏。
• 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  这是我们团队的第一个里程碑，相对于团队成员初相识时的一盘散沙，我们已经共同经历了两周的开发过程，增进了互相的了解，更加团结，更加上进，也更加为团队和项目着想。
• 你觉得目前最需要改进的一个方面是什么?
  最需要改进的可能是计划方面的问题。在Beta阶段时，我们的需求不断改变的，在稳定测试阶段进行了许多额外的开发任务。这些任务本可以在一开始就确定好，但是我们并没有想到这些问题。原因可能是大家都第一次开发此类软件，且也是从零开始开发，没有原型系统支持，再加上第一次没有考虑那么全面。在下一个阶段，我们会改进计划，且落实到执行。

3.具体事例及符合原则

• 业务人员和开发人员在项目开发过程中应该每天共同工作
  每一次冲刺我们都是密切交流，前后端模块联系紧密，测试组文档组也跟进进度，团队成员一起沟通交流自己的想法。
• 以有进取心的人为项目核心，充分支持信任他们
  我们充分相信前后端开发组的人员，并给于他们适当的支持
• 无论团队内外，面对面的交流始终是最有效的沟通方式
  进行多次站立会议
• 可用的软件是衡量项目进展的主要指标
  边修改边测试，实时掌控软件进度
• 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
  在开发过程也提出了相对应的新要求，并作出改变
• 持续关注卓越的技术和优良的设计，会增强敏捷能力
  全组成员在开发过程中不断学习，不断提高自己
• 时时总结如何提高团队效率并付诸行动
  每轮的站立会议都会总结
• 只有自我管理的团队才能创造最优秀的架构，需求和设计
  组员按照相应的计划一步步的进行项目的开发与测试

第09组 Beta冲刺 总结

原文：https://www.cnblogs.com/vcfghch/p/14058330.html