第01组 Beta冲刺总结

组长博客链接：戳这里

答辩总结

总体过程非常顺利，展示了大家整个beta冲刺的一个结果，柯老板也为我们提出了建设性意见，后续的final版本也改为web端功能的持续完善

全组讨论的照片

贡献分比例

总结思考

设想和目标

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

• 我们的软件从当今课前课间点名占用时间长、点名效率低、准确性一般、误点几率高这些痛点切入，解决了老师上课点名环节较为繁琐以及效率低下的问题，让点名效率得到提高、误点纪律大大降低，并节约了用户的时间。

• 软件的定义比较清楚，因为我们的软件是从教师和学生的日常生活中得到灵感的，每个人都有切身的体会和经历。

+我们对用户画像和场景分析做了较为全面的定义，即面向有课堂考勤需求的教师，在高校课堂上进行课堂点名，以达到统计学生考勤情况、统计平时分等目的。

我们达到了目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）

• 原计划的目标的web端已经完成。在实际的开发过程中，小程序端综合了时间和开发难度我们选择放弃，继续完善我们的web端。

• 我们按照原计划的交付时间进行了交付。

• 未计划达到具体的用户量，目前的版本仅供团队内部进行初步的调试和使用，后续完善后会面向校内师生开放使用，用户量会得到积累。

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

• 目前尚未积累用户量，产品还是内部人员开发并试用。从目前的版本的效果来看，大部分功能得到了实现，接近预期目标。

有什么经验教训？如果历史重来一遍，我们会做什么改进？

• beta冲刺的时候还是需要稍微紧张一点，除去涉及相关功能设计的组员，其他组员也应当了解一下情况

• 改进：提升跟进进度的频率，及时做出调整，避免ddl前疯狂加班

计划

是否有充足的时间来做计划？

• 由于团队项目很早就发布了，所以对于整个项目的规划还是有充足的时间来完成的，在正式开发之前也对整个软件的框架进行了构想和讨论。

团队在计划阶段是如何解决同事们对于计划的不同意见的？

• 面对面的会议，进行沟通和交流，及时解决分歧。
• 电话会议，毕竟考虑到beta冲刺多数组员其他科大作业ddl。

你原计划的工作是否最后都做完了？如果有没做完的，为什么？

• web端做完了，剩下的就是继续完善我们的功能，显然是有很多bug和反人类的设计的，这个属于final版本的范畴。

有没有发现你做了一些事后看来没必要或没多大价值的事？

• 在周五柯老板体验点名前疯狂加班，其实可以前几天盯紧一点一起做完周四放松一下的。

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

• 是的。在项目的规划阶段，我们做了详细的需求分析和框架的搭建，对于具体功能逻辑的实现做了详尽的讨论，从而分析出了所需的几个前端页面、后端接口和数据库等，以及具体的原型设计，这些作为了我们每一项任务具体的交付件，并将每一项任务进行分配，通过完成这些内容的情况来对成员的工作情况进行衡量和评估。虽然具体的交付件大部分比较明晰，但是评判标准有时不唯一，例如在前端页面的优化和原型设计的美术效果上，每个人的审美不同，不太能定义一个严格意义上的标准。

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

• 组长没有考虑到组员写好的代码可能会和页面设计上会有冲突或者没有接入页面，导致了部分时间浪费在返工上，因为组长很信任组员的代码能力，忽略了与页面交互的实际情况。

在计划中有没有留下缓冲区，缓冲区有作用么？

• 有的有的，让大家及时交付其他科作业，缓解课业压力，以全新的面貌迎接软工新一轮的折磨

将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 缓冲区不设置过长，安排任务的时候更加合理，紧凑中又不会过于繁重，以便更好地完善产品。同时，进一步完善团队的分工安排，使任务分配更加合理，提高团队合作的效率。

我们学到了什么？如果历史重来一遍，我们会做什么改进？

• Beta冲刺虽然经历了一些波折，遇到了一些困难。但是也在具体的技术知识学习之外认识到了团队管理和分工协作的重要性。通过beta冲刺，我们深刻认识到“独木难支”的意思，AIFS的大家还要继续加油。如果历史重来一遍，我们会更加认真的对待这次Beta冲刺。

资源

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

• 我们团队的资源还是比较丰富的。首先，团队的分工合理明确，组长和前端、后端、算法的小组长都非常尽职尽责，起了很好的领导作用和表率作用。网上的学习资源也非常丰富，成员可以学习相关知识快速上手。此外，团队里良好的工作氛围也是我们团队的隐性资源和财富，分工明确，项目的管理也较为合理，各项任务虽然有时候可能实现的不够完美，但是大家都尽心尽力地完成了。并且组长也有较好的组织力、领导力和抗压力。另外，团队也有较为固定的场地和良好的环境供团队成员进行项目的开发，为项目最后的初步完提供了良好的保障。

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

• 对于具体任务的时间和资源的估计，主要是通过已有的经验进行判断，毕竟我们团队的相关经验不够丰富，通过讨论对于具体的任务所需要消耗的资源进行评估。

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

• 测试的时间和相关资源其实都比较有限，产品的测试时间和人力都没有达到一定的量。但是基本能够满足产品投入使用的需求。
• 而在具体的设计和文档的撰写方面，我们总体来说低估了这些任务的难度。相关文档的撰写并非易事，原型设计和前端页面的美观程度也算是一个小小的挑战。在具体项目的体现上，想要真正做出符合规范并且美观整洁的页面还是比较困难，与想象中还存在一定的差距。

你有没有感到你做的事情可以让别人来做（更有效率）?

• 对项目任务的分块工作量估计不够精准，导致一部分的人力资源浪费。

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

• 开发组的同学任务量过大，不管是否擅长开发，有需要的时候应当全员参与到项目开发当中去；要更加细化团队的分工，优化团队管理。

变更管理

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

• 是的。因为每次会议和讨论基本都是全员参与，对于相关功能模块和需求的变更，团队成员都能够及时地知晓并作出相应的调整。

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

• 我们团队综合衡量了现阶段所能投放在项目上的时间以及成员的能力，分析了现有的开源项目所能提供的技术支持，结合产品开发前期我们做的大量的用户需求分析，最终决定必须实现基本的软件运行环境和核心功能。

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

• 项目的出口条件即需求分析报告中我们计划达成的相关功能得到实现。

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

• 可以。临近项目阶段性结束阶段，团队成员集中开发，能够及时制定应急计划。

员工是否能够有效地处理意料之外的工作请求？

• 我们对于具体的任务分配基本涵盖了整个Beta冲刺阶段，几乎没有意料之外的工作请求。

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

• 使用github进行代码管理，代码编写和文档撰写都具有规范性。改进：在变更功能和方向上可以让信息更加通达，让每个团队成员都能及时知晓项目的开发方向。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

• 在Beta冲刺初期，团队通过开会讨论整体的业务逻辑，进行相关框架的搭建。具体的原型设计在冲刺过程中由PM具体实现，过程较为合适。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 有的。部分功能可能会在开发的时候发生冲突。团队成员及时开会讨论进行解决，得出合理的方案。

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

• 有的。设计UML后会发现UML是十分有效的，开发和讨论的时候都可以借助其理清思路和方向。虽然在最终的开发实现中核最初的UML还有一些区别，但正如《人月神话》中所说，“对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性。”

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

• 有很大区别，原因是项目开始时的文档是基于我们的构想完成的，实际开发过程中不断地在调整。

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

• 人脸识别，因为需要调参；调用别人现成代码，并没有细看内部架构。主要还是不是很理解源码造成的。
• 二维码点名，我们期望自己独立实现这一功能而不是单独调用其他接口，因此所产生的二维码并不是动态的，一定程度上可能会失去意义。开发时一心想着实现二维码点名功能，考虑不周，也是技术不够过硬所造成的。
• 由于点名数据量的增大，加上base64编码实在过长，导致ajax请求响应body超限。确实是没有考虑到base64长度的问题。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 前后端是分离的，所以代码规范上会有不同标准，代码规范并没有严格执行。

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

• 代码复审应该随时进行，而不是等项目完结后再进行。代码规范亦是如此。

测试/发布

团队是否有一个测试计划？为什么没有？

• 暂无。团队经验不足。

是否进行了正式的验收测试？

• 进行了“非正式”的验收测试（柯老板上课点名），总体上已经实现的东西可以满足我们的计划需要。

团队是否有测试工具来帮助测试？

• 使用postman进行测试。

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

• 用postman确保每个接口返回的json文件正确。这些测试工作是非常有用的，帮助后端云函数debug以及前端ajax交互的修改。测试数据还不够多吧，还要再多加一些数据提升覆盖率。
• 人力方面及时调整方向，并且大家聚在一起实时检测数据的传输、界面交互等问题，一经发现及时解决。这样做是有必要的，可以帮助我们提高效率。但相互之间的配合还应该在默契些，所使用的工具及环境的配置也应该同步，不然会发生无法及时运行彼此文件的情况。

在发布的过程中发现了哪些意外问题？

• 软件暂未发布。

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

• 分配足够的人手进行测试，同时测试计划应该紧随开发计划之后指定，并随实际开发进度调整。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

• 根据个人的特点和医院进行角色的分配，很好地发挥了每个人的优势，应该来说是做到了人尽其才。

团队成员之间有互相帮助么？

• 有的，因为每个人都会遇到困难，这不可避免，因此就需要进行团队互助，共同攻克困难。

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

-阐述问题的关键，集思广益，共同寻找解决方案。

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

我感谢xxx同学对我的帮助，因为。

我们学到了什么？如果历史重来一遍，我们会做什么改进？

• 团队分工和协作及成员之间的沟通交流很关键，同时学会进行团队的沟通和管理也是一种成长。

总结

你觉得团队目前的状态属于CMM/CMMI中的哪一个档次？

• 可重复级。毕竟还没有实现完全的标准化和文档化。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？

• 规范。团队成员的分工已经明确，有待进一步规范。

你觉得团队在这个里程碑相比前一个里程碑有什么改进？

• 大家都非常的努力，敢于取舍，能及时向组长说出自己的想法。

你觉得目前最需要改进的一个方面是什么？

• 边学习边开发的方式推进整个项目。系统的速成显得起步较慢了。

对照敏捷开发原则，回顾我们的Beta冲刺过程，我们做的比较好的几个原则及具体的示例：

• 第六条：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

  经常进行线上和线下的会议，并且成员间开发过程有什么问题尽量都会第一时间交流。

• 第十二条：团队要定期反省如何能够做到更有效，并相应调整团队的行为。

  经常开会，并及时进行总结反思和调整。

第01组 Beta冲刺 总结

原文：https://www.cnblogs.com/yuqiao1120/p/14058337.html