第08组 Beta冲刺 总结

目录

• 一、基本情况
• 二、总结思考
  • 2.1设想和目标
  • 2.2计划
  • 2.3资源
  • 2.4变更管理
  • 2.5设计/实现
  • 2.6测试/发布
  • 2.7 团队的角色，管理，合作
  • 2.8总结

一、基本情况

• 队名：在学了在做了
• 组长博客：点这里
• 作业博客：在这里
• 组员人数：9人
• github仓库链接
• 答辩总结
  该次贝塔大家都很积极，增加了新的内容，美化了界面 good
• 全组讨论的照片

• 工作占比

姓名	占比	分工
周天	4.5%	UI设计、ppt制作、博客编辑
陈曼	18%	前端页面、数据库
陈昕滨	4%	视频制作
李少荣	5%	前端页面、ppt汇报
林荣胜	40%	后台管理、前端页面
王梓鹏	10%	前端页面
杨立芬	17%	前端页面
张晓晗	1%	博客编辑
郑瀚曦	0.5%	博客编辑

二、总结思考

2.1设想和目标

• ①我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  想要解决当代大学生对于时间需求高的问题，通过充分调动大学校内资源让大家生活更加高效；是，定义的很清楚；有，典型用户就是大学生，典型场景就是食堂带饭、电动车载人和打印店打印等。

• ②我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
  基本达到目标了：Beta版本预计的评价与星级、后台管理、正则判断、界面美化等都完成了，但是TAG还未加入、信誉积分部分未完善，消息界面也仍在进行中；时间上来说按照原计划交付时间提交了；对于Beta版本我们并不对用户数量做高要求，用户量还需在正式发布后进行推广获得。

• ③用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  Beta版本预想基本一致，因为目前的用户就是开发人员，为了能达到发布后且适用的效果，还需要进一步完善；显然离目标更近了。

• ④有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  完成度没达到最好；如果重来一遍，试着每个板块都去派负责人去安排。

2.2计划

• ①是否有充足的时间来做计划？
  充足，但变化来的可能比计划快。

• ②团队在计划阶段是如何解决同事们对于计划的不同意见的？
  大家积极交流，各抒己见，最后大家一起分析取舍，让一个计划最终敲定的更为合适。

• ③你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  否，因为画图遇到困难了，麻了。

• ④有没有发现你做了一些事后看来没必要或没多大价值的事?
  有，比如我画的有的图压根儿不会被实现。

• ⑤是否每一项任务都有清楚定义和衡量的交付件?
  显然不是，有时要根据变化来交代要干啥。

• ⑥是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  基本按照计划进行；意外主要是踩坑，大家睡眠严重不足；目前暂时没有未估计到的风险，决定该项目之前大部分风险都已考虑到，选题答辩时听取同学的意见，风险估计更加完善了。

• ⑦在计划中有没有留下缓冲区，缓冲区有作用么?
  不急做的就放一放，先搞需要的，缓冲还是有用的。

• ⑧将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  能修改的和其他班一样吗？

• ⑨我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  如何发现所需解决所需；如果历史重来，建议换班。

2.3资源

• ①我们有足够的资源来完成各项任务么?
  基本足够，队员肝的能力和效率是猛的。

• ②各项任务所需的时间和其他资源是如何估计的，精度如何?
  由于没有以前的开发经验，所以估计的内容是边做边估计的，精度较为一般，还是有些bug。

• ③测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  测试的时间，人力和软件/硬件资源不怎么足够；对于不需编程的资源未低估难度，确实还不错。

• ④你有没有感到你做的事情可以让别人来做（更有效率）?
  说不定，毕竟未知数太多。

• ⑤有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  协调好每个人的职责，尽量保持资源利用的高效，让整个项目能够稳步进行。

2.4变更管理

• ①每个相关的员工都及时知道了变更的消息?
  及时，大家积极交流，有啥问题或者变动都在群里说了。

• ②我们采用了什么办法决定“推迟”和“必须实现”的功能?
  采用了本组预期加上老师意见以及测试组建议综合考虑法。

• ③项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  有，测试无bug、操作逻辑正确无误就是了。

• ④对于可能的变更是否能制定应急计划?、
  可以的，大家还是很积极的。

• ⑤员工是否能够有效地处理意料之外的工作请求？
  在学了在做了，可以的没问题。

• ⑥我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  我们学到了如何做一名合格的打工人；如果重来，我们会更积极的推进计划，定好细致的需求。

2.5设计/实现

• ①设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  一些界面的图是冲刺期间由周天完成的，数据库部分的设计是由林荣胜和陈曼在alpha冲刺期间完成的；以当前成效来看是合适的时间及人选。

• ②设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  有，比如部分跳转逻辑有些许问题；大家一起讨论后敲定怎么做就去着手解决了。

• ③团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  有用过UML，有一定效果，主要起参考作用。

• ④比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  区别并不多；产生原因主要是实现效果和预期内容有一定差异；仍需要更新以便更好的开发。

• ⑤什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  小程序端发起认证审核，后台接收用户传来的审核请求，同意请求后再对用户进行微信通知，这个功能bug最多。因为自己在测试的时候，使用的是同一个openid进行测试，但由于该通知为一次订阅消息，所以在第一次正常发出通知后，后面的通知发送都是随机事件。
  在发布后，发现备注的长度过长，会在很多地方产生界面冲突的问题。因为在测试的时候都是简简单单的写几个字作为备注。

• ⑥代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  当时是花晚上的时间在活动室进行复审，部分执行了代码规范，剩下的需要改进的需要在后面继续完善。

• ⑦我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  学到的主要是发现并且完成需求，大家对于分工和需求都有了更好的认识；如果重来，我们会时间穿梭直接猛学，让完成度能足够高。

2.6测试/发布

• ①团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
  并没有一个测试计划，因为大家都是直接体验开发的成效，没有去额外制定一个确切的计划；没有进行正式的验收测试，目前仅是简单的操作测试。

• ②团队是否有测试工具来帮助测试？
  我们并没有用测试工具来帮助测试。

• ③团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  利用测试版进行效能测量；实际运行来看，这些测试工作可能对于后面的跟进修改会比较有用；需要改进的是一些bug和功能。

• ④在发布的过程中发现了哪些意外问题？
  严格来讲，目前项目并未发布；倒是因为小程序的一些条例，让我们正式发布遇到了点困难。

• ⑤我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  不同的队员学到不同的内容，大家小程序云开发的能力都有了一定的提升；如果重来，我们会提前制定一个时效性的测试计划，同时加快进度完成任务。

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

• ①团队的每个角色是如何确定的，是不是人尽其才？
  角色是按照讨论时大家的意向进行决定的，个人对某个板块了解的比较多的也会影响决定因素；显然并不是人尽其才，因为仍有些地方比较吃力，并非套话，我是相信队伍的本事不止如此的。

• ②团队成员之间有互相帮助么？
  有的，一个人可以走更快，一群人可以更远；线上线下讨论、私聊等都起到了不错的效果。

• ③当出现项目管理、合作方面的问题时，团队成员如何解决问题？
  大家都很积极认真，这点提高了一定的效率，对于项目管理、合作方面的问题都是讨论可以解决的。

• ④每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
  我感谢周天对我的帮助， 因为他对我制作视频提出很多宝贵的建议；
  我感谢林荣胜和王梓鹏对我的帮助， 因为他们精心录制了视频使得制作变得很方便；
  我感谢李少荣对我的帮助， 因为他上台对视频进行了很细致的解说。
  我感谢每一位对我的帮助， 因为任务推进的过程中大家都在鼓励我。

• ⑤我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  这次冲刺中，我们在团队的分工、协作、管理等方面学到了不少：分工的过程中要根据每个人的想法
  能力进行分工，只有各尽其才，团队才会走得更快更好；如果重来一遍，我们的团队于组长的视角来看是没问题的，即使这样的话大家在部分地方仍然会吃亏吃力。

2.8总结

• ①你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  处于初始级(initial)：
  工作无序，项目进行过程有计划的更变，可能会暂时性放弃。Beta所完成的是提出的一些要求，但是还有少部分未完善，其他的预计是后面可以继续跟进修改。希望发布/测试期间可以达到可重复级(Repeatable)。

• ②你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  处于规范阶段：经过整个Beta冲刺，大家磨合的都还可以，对于每个人负责的细致部分，还是有一定的规范。

• ③你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  目前(Beta)和上一个里程碑(Alpha)相比，推进的内容更多，而且大家的技术能力都有更好的提升，团队协作能力和时间管理能力++

• ④你觉得目前最需要改进的一个方面是什么?
  技术方面，因为Beta预计实现的内容并没有完全搞定。

• ⑤对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
  a.简明为本——它是极力简化不必要的工作量的技艺。
  大家在讨论每个功能和需求的时候，都会再次讨论这个功能是不是我们完全所需的，我们会把真正需要的给确定下来。
  b.业务人员和开发人员在项目开发过程中应该每天共同工作。
  同一个专业，同一片天空。