第01组 Alpha冲刺总结

组长博客链接：戳这里

答辩总结

总体过程非常顺利，展示了大家整个alpha冲刺的一个结果，柯老板也为我们提出了建设性意见，指出了β版本的一个前进方向。

全组讨论的照片

贡献分比例

总结思考

设想和目标

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

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

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

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

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

• 原计划的目标大部分已经完成。声纹识别和直接人脸拍照在技术实现上难度过大没有实现；在实际的开发过程中，一些进阶的功能等到beta版本再实现。

• 我们按照原计划的交付时间进行了交付，但是产品的部分功能和预期存在一点差距，待beta版本进一步完善和优化。

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

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

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

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

• 团队大部分成员都是第一次进行项目的完整策划、开发和实现，规划阶段和需求分析阶段对小组成员的能力及精力估计不够准确，对产品的具体功能和细节方面考虑得还不够周全。比如，在讨论的时候感觉想法很好很完善，但是具体开发实现的时候难度较大，常常会遇到各种瓶颈，从而耗费了更多的时间，拖延了进度。

• 改进：在最初开发的时候尽早确定使用什么开发工具、语言和接口等会更加有利于开发，在开发过程中会更加注意细节问题和规范化；在项目具体开发之前，对相关编程语言、框架的使用进行提高。

计划

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

• 由于团队项目很早就发布了，所以对于整个项目的规划还是有充足的时间来完成的，在正式开发之前也对整个软件的框架进行了构想和讨论。在正式开发之前完成的选题报告、需求分析和各类图的绘制等都让我们对于产品的架构有了更加清晰的擘画。但是我们没有投入足够多的精力在规划上面，所以很多细节在具体实现上遇到了困难，感受到了理想和现实的差距。

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

• 讨论的时候大家的分歧比较少，即使有分歧，大家都会直接地进行面对面的交流与沟通，让分歧尽快得到解决，达成共识。

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

• 大部分都做完了，一些没有实现的功能等到beta阶段再进行完善。因为我们后端找到较为合适的语言和云服务时间较迟，在alpha冲刺阶段实现所有功能太过极限，加上组员还有其他科的ddl，所以放到beta部分。

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

• 卡在java的spring boot学习上一周多还是没有弄懂各层的含义
• 过度执着于算法实现（声纹识别和人脸识别），忽视了“可以人为规定使用规则”这一要求
• php语言的摸索
• alpha冲刺每轮的开会和博客同步，在前三轮没有要求组员统一博客格式，导致三轮博客都需要返工调整格式，提交时间也非常极限。
• 本地服务器的搭建，因为我们最终选择了云服务器
• java连接MySQL，因为些小问题也卡住了较久的时间，但最终我们还是选择了云函数云数据库来实现
• 爬虫的使用，并没有现成可以爬取的学生信息，后面的数据是我们自行构建的，

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

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

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

• 大部分时候都是按照原计划进行的，但过程中有调整所使用的方法；期间一直卡在前后端交互的问题上，后面选择了云函数以后便简化了这一过程，接口中的一部分不需要我们自己亲自实现了。
• 低估了后端springboot和声纹识别算法的学习成本，导致后端进度拉跨，前端一直在等着后端；忽视了爬虫必备的物理条件，导致爬虫工作无法进行；课程表需要用vue实现，但是前端当时的决策是没有进行学习。
• 至于为啥没有估计到呢……，spring boot和声纹识别算法应该说是组长以及组员都放不太下沉没成本，导致没有及时切换方向；爬虫是因为有听说之前学长学姐有爬过，然而在往届的博客里并没有发现加上组长考试和运动会太忙orz就忽视了这一点;前端这个就属于真的是不可预估吧，因为一直在等后端，假设性再强也会判断失误咯，还有一些其他因素也不是我们能预料到的，毕竟我们许多组员都没有过开发的经历。

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

• 因为之前缺乏项目管理的相关经验，没有了解缓冲区的相关概念，因而也没有留下缓冲区，冲刺阶段的时间安排都比较紧凑。

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

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

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

• 本次Alpha冲刺是我们团队第一次共同完成一个项目的开发与发布。在这一过程中虽然经历了一些波折，遇到了一些困难。但是也在具体的技术知识学习之外认识到了团队管理和分工协作的重要性。在《人月神话》中有句话说，“系统编程的进度安排背后第一个错误的假设是：一切都将运作良好”。通过本次Alpha冲刺，让团队中的每个人都认识到了虽然在项目的规划和设计阶段往往没有什么难度，但是在实际的开发过程中常常会遇到重重困难，要尽早对团队的资源和能力进行分配和管理，重视跟进项目的进度，让团队尽早进入到有实际产出的阶段，而不是纠结于某一方面进行讨论和无尽的了解。

资源

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

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

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

• 对于具体任务的时间和资源的估计，主要是通过已有的经验进行判断，毕竟我们团队的相关经验不够丰富，通过讨论对于具体的任务所需要消耗的资源进行评估。虽然这缺乏足够的专业性和严谨性，精度也不是很高，但是大多数时候能够保障我们的项目顺利推进。

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

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

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

• 团队如果能更加高效地使用好GitHub，能在代码的管理上更加高效；对项目任务的分块工作量估计不够精准，导致一部分的人力资源浪费。

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

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

变更管理

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

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

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

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

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

• 项目的出口条件即需求分析报告中我们计划达成的相关功能得到实现，并做好数据库的维护，保障用户数据的安全性。

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

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

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

• 项目初期，我们对于具体的任务分配基本涵盖了整个Alpha冲刺阶段，几乎没有意料之外的工作请求。一些额外的小任务布置给团队成员，大部分情况下大家都能够比较好地完成。

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

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

设计/实现

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

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

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

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

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

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

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

• 状态还是有很大区别的，原因是项目开始时的文档是基于我们的空想完成的，实际开发过程中不断地在调整。而UML文档当然需要进行不断地更新。

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

• 人脸识别，因为需要调参；调用别人现成代码，并没有细看内部架构。主要还是不是很理解源码造成的。
• 二维码点名，我们期望自己独立实现这一功能而不是单独调用其他接口，因此所产生的二维码并不是动态的，一定程度上可能会失去意义。开发时一心想着实现二维码点名功能，考虑不周，也是技术不够过硬所造成的。
• 点名的过程中，语音读名字的间隔是2秒钟，但如果在期间点击暂停后，再次点击继续时，这两秒钟会被卡掉。这是由于我们使用的语言是单线程的js，我们利用了其他方法实现了其“多线程”，从而造成了此问题。也是由语言以及技术瓶颈造成的。

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

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

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

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

测试/发布

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

• 暂无。团队经验不足，本轮冲刺时间紧、任务重。

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

• 无，因为实现程度只有80%，还不是成品
• 但进行了“非正式”的验收测试，我们在视频中所展示的功能都可以实现，总体上已经实现的东西可以满足我们的计划需要。

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

• 使用postman进行测试。

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

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

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

• 软件暂未发布。

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

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

团队的角色，管理，合作

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

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

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

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

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

• 摆事实讲道理，阐述问题的关键，集思广益，共同寻找解决方案。

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

我感谢叶昊明同学对我的帮助，因为他最早完成了原型设计的雏形，为我后续的设计指明了方向。

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

• 团队分工和协作真的非常重要，成员之间的沟通交流很关键，同时学会进行团队的沟通和管理也是一种成长。沟通是解决问题的唯一途径。

总结

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

• 可重复级吧，还没有完全的标准化和文档化。

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

• 磨合，因为前后端的方向才开始彻底的明确，还要继续磨合。

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

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

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

• 还是尽量以边学边码的一个方式来半推进整个项目吧，系统的速成显得起步较慢了。

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

• 第二条：欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势

  我们从一开始的声纹识别砍掉变成了只有语音代点，老师操作考勤信息的一个操作，然后人脸识别也是从拍照变成了大家走过机器进行人脸识别

• 第四条：项目过程中，业务人员与开发人员必须在一起

  卓越全程都有参与了解开发过程

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

  我们基本上是两天开一次会议，讨论一下后续的修改

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

  开了好多次会……调整了很多回

测试组问题回答

缺勤名单除了姓名可以看学号吗？

答：可以

二维码点名有扫码位置的定位吗？

答：小程序端有这么计划，但是实现的话要看项目进度，毕竟不是刚需功能

第01组 Alpha冲刺 总结

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