Alpha反思与总结
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
拟解决问题：国内外各地区新冠疫苗覆盖率、新冠感染率可视化，将每天数据的变化以统计图的形式展示和地图的形式展示；根据感染数据、疫苗接种数据进行数据分析，将各地区感染率、疫苗覆盖率、疫情潜在风险系数等作为指标生成疫情风险（安全性）排名；根据分析结果给每个地区生成疫苗接种建议；疫情及新冠疫苗相关新闻、科普推送；疫苗接种点、新冠疫苗检测点查询
功能定义明确，在功能规格说明书中对典型用户以及典型场景做出了清晰的描述
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
Alpha阶段目标顺利达成，按计划交付了项目，并基本达到了用户量目标。详见项目展示
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
根据用户的反馈及意见，用户对重要功能的接受程度和我们事先的预想一致。根据开发的进度，正在朝最终目标稳步迈进。
-
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
在部署测试阶段没有做出明确计划，工作比较混乱并且没有书面的记录。在Beta阶段将会对这一点进行改进，对部署测试阶段也预先做出计划。
计划
-
是否有充足的时间来做计划?
有，在冲刺阶段的前一周，团队对该阶段的目标和工作都做出了详细的计划。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
讨论协商最终达成共识。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
都做完了！
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
仓库分支的管理方式没有体现除应有作用。
-
是否每一项任务都有清楚定义和衡量的交付件?
对每一项任务做出了清楚的接口定义，但在交付上没有做出明确要求。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本上按照计划进行，但由于其他课程的任务，中间出现了一定的延迟，但没有对整个项目的进度产生重大影响。在部署时发现爬虫模块比较占用服务器内存，没有意识到的原因是团队对这方面技术的不熟悉。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
留下了，起到了重大作用。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
会新增在部署测试阶段的计划。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进？
计划要详细，如果重来一遍会提前做好部署测试的计划。
资源
-
我们有足够的资源来完成各项任务么?
主要的资源限制来自于团队成员的时间安排，团队内部自己克服了该困难。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
以单个子任务（issue）的粒度精度进行估计，基本符合实际的情况。
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间比较紧张。对推广的方面的难度有一定的低估。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
没有，团队分工明确合理，每个成员都是不可替代的。
-
有什么经验教训? 如果历史重来一遍,我们会做什么改进？
没有提前预估团队成员在不同时间的空闲情况，推广方面也存在经验不足的情况。重来一遍，将在这两方面作出改进。
变更管理
-
每个相关的员工都及时知道了变更的消息?
通过微信群，相关的变更能够及时通知到每一位成员。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
团队根据目前的开发情况，在例会中进行协商讨论达成一致，讨论的依据主要为此工作是否会影响接下来工作的执行。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在功能定义中做出了定义，并在测试阶段时进行的相关的测试。
-
对于可能的变更是否能制定应急计划?
事先并没有制定相关的应急计划（实际中还好没有发生突发情况
-
员工是否能够有效地处理意料之外的工作请求？
能，对开发中出现的额外情况均能快速处理。
-
我们学到了什么?如果历史重来一遍， 我们会做什么改进？
在开发过程中出现不可控的因素是很正常的，团队要有一定的弹性能够迅速解决这些不可控因素。如果重来一遍，会针对可能的变更制定详细的应急计划。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在冲刺阶段开始之前，由团队共同商议完成。团队达成一致有助于节约开发中的沟通成本。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
数据库设计刚开始没有充分考虑存储的效率，由后端成员进一步协商讨论后进行了一次了修改。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
在后端运用了单元测试的方法，在开发的流程上，采用的是先开发后测试的方式，没有使用测试驱动开发的方式。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
地图部分的显示出现了较多的bug，造成bug的原因主要是地图使用的json文件与后端爬取的地区名称不能一一对应。发布后产生的bug主要集中于在不同设备上界面的显示会出现挤压、偏移的情况，出现这些bug的主要原因在于团队在前端的开发上经验比较不足，未能提前预见这个问题。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审主要自我评审以及同行评审为主；严格执行了代码规范。
-
我们学到了什么?如果历史重来一遍， 我们会做什么改进？
测试工作在条件允许的情况下，应该尽早开展。在本阶段的测试阶段，团队的测试压力确实比较大。重来一遍的话，会提早开始测试工作。
测试/发布
-
团队是否有一个测试计划？为什么没有？
没有。主要在于PM低估了测试的工作量，并没有明确的形成测试计划。
-
是否进行了正式的验收测试？
是，在最终的测试中多个角度进行了测试，详见测试博客
-
团队是否有测试工具来帮助测试？
使用了
http_load进行了压力测试，详见测试博客。 -
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在软件效能的测试方面，主要通过请求时间的分析进行衡量。使用了
http_load进行了压力测试，详见测试博客。由于软件的实际运行过程中，实际的并发量并没有达到测试中使用的并发量，因此并未能明确体现出压力测试的作用，但是压力测试指出了限制系统并发量的部分，指明改进的方向。 -
在发布的过程中发现了哪些意外问题？
数据源中的腾讯新闻在数据的处理上有一定问题，导致爬取的数据不符合实际情况，目前只能通过变更更新时间解决这一问题。
-
我们学到了什么? 如果重来一遍,我们会做什么改进？
测试阶段也需要做出详细的计划，并且使用测试工具的辅助提高测试效率。对产生的bug也应该以书面形式进行记录，方便事后分析。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
量化管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
你觉得目前最需要改进的一个方面是什么?
在文档的管理和规范上有待进一步加强。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 主张简单。在Alpha阶段的目标的建立中，团队就一致通过了先完成基本的显示功能，复杂的分析功能后续继续添加的开发目标，以提供一个能正常服务的项目为最低要求。
- 快速反馈。得益于例会以及微信群，在开发过程中产生的问题都能及时通知到个人，在一天之内解决问题。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码的管理上需要加强对代码的复审，在条件允许的情况下要以团队为单位对代码进行审核，同时对代码规范进行更加详细的约定，形成文档供团队参考。
-
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
针对压力测试的结果，对薄弱的环节进行改进（必要时进行重构）。完成后，使用回归测试的方法，验证该部分在性能上有无明显提高，以此提高程序的质量。
-
其它软件工具的应用，应该如何提高？
增加对CI/CD工具的使用，使用相关的开发测试工具辅助开发的进行。
-
项目管理有哪些具体的提高？
issue的划分需要依据实际情况进行考虑而非均匀的划分。充分的利用issue的讨论功能。
-
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
在用户的数据方面，使用CNZZ平台进行跟踪统计。在下一阶段也将继续使用该平台对用户数据进行分析。
-
项目文档的质量如何提高？
目前团队的相关文档更新不够及时，下一阶段会在更新的频率上做出改进。同时对测试计划也形成相关文档。
-
对于人的领导和管理， 有什么具体可以改进的地方？
- 任务的分配做出更详细的记录，比如：提前完成或出现了推迟
- 开发进度落实时要稍微push一下团队成员
-
对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
要保证项目的顺利完成首先需要规范化的管理，包括：如何分配任务、如何验收、团队如何解决问题等，规范化的管理可以最大程度上避免意外事件的发生，增强团队的稳定性。其次，团队是否团结也是影响项目质量的重要因素，团队同心同德才能高效的完成预定开发计划。
讨论照片
