20201029-3 事后诸葛亮会议
此作业要求参见：https://edu.cnblogs.com/campus/nenu/2020Fall/homework/11433
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是记录用户的对于日常生活的支出和收入，定义清楚。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
发布之后的程序达到了目标，原计划用户是20人，实际人数31人达到目标用户数量。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
上一阶段我们是对于选题的确定阶段，没有进行软件的开发，因此没有产生对比。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
对于用户量和用户重要功能接受程度于我们预想一致，对于程序的开发完美更近一步。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
对于用户调查不够详细，如果历史重来一遍，我们会做对于用户的更加详细的调查，对多个用户进行调查，使功能的设计更加完善。
计划
1. 是否有充足的时间来做计划?
由于我们对于Alpha阶段理解错误，让我们的程序进度时间不足。但是对于程序的分析、调查、功能的来源我们有足够的时间来进行计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同的计划我们采取少数服从多数原则，产生分歧时我们会进行一次投票。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作已经完成。对于发布程序的功能没有完成是我们通过紧急加功来完成任务。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
在程序发布以后我们开事后诸葛亮会议时，整体队员分析确实做了不少价值不大却花费时间挺多的任务。
5. 是否每一项任务都有清楚定义和衡量的交付件?
对于大部分任务我们都有清楚定义和衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程出现了意外，我们没有按时交付程序，对于程序的进度我们低估了程序编写的难度。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
留了缓冲区，我们留下了对于小程序审核通过时间的审核。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
对于将来的计划我们将会根据此阶段的工作能力，来进行
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了对于计划我们应该安排的更加详细。如果重来一遍，我们会对进度安排更加紧凑一点，对于程序功能的实现更加快速一点。
资源
1. 我们有足够的资源来完成各项任务么?
有，我们有足够的人力，软件以及硬件的资源来完成我们的各项任务
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
对于任务所需时间，每个人有每个人的进度以及其他要素影响，我们采用额进度单位为天
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
人工和软件、硬件资源足够，对于页面的美工我们大大低估了它的难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
小组内任务分配，我们采取自愿原则，让小组每一个人员去做自己最拿手的任务。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
对于任务分配不够详细，不够准确。如果再来一遍我们将会安排足够详细和准确的任务。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
答：每个队员都及时知道了变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：小组讨论，各自发表意见，说出意见，以理服人，说服他人。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：多轮测试。
4. 对于可能的变更是否能制定应急计划?
答：大多可以进行应急计划，比如详细分工，熬夜代码上线。
5. 员工是否能够有效地处理意料之外的工作请求？
答：队员都能够有效地处理意料之外的工作请求，大家齐心协力，都是为了小组的共同目标而努力。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：组员之间进行有效的沟通，遇到问题，即使着急组员一起商讨，尽快制定有效的方案。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：在设计工作中，主要任务由具有丰富经验的组长完成，其余成员进行辅佐。在项目开发至今，认为是合适的人与时间。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：在设计工作中遇到过模棱两可的内容，比如：小程序的主体颜色等；解决办法：由审美较好的女生进行选择，选择合适
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
答：团队开发中，用了少许的单元测试。但是测试驱动的开发等工具未使用。开发过程中，组内采用自测自改、他测自改的形式进行。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：在进行数据可视化即图表展示时，产生的bug较多。因为小程序这个插件不熟悉，后台封装的数据格式不对，在前台中一直不展示。发布后，发现弹窗提示与页面下部的图表相重合，使得用户不方便进行点击。因为在开发者工具中这个问题并为测试到，且小程序经过审核需要时间。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：由于开发周期短，代码规范还没有拟定。代码复审主要是Alpha阶段项目整合之后，产品上线之前，通过代码互查、组内个人代码分享的形式进行了复审。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：我们学到了开发项目的基本流程。改进：首先，我们会在开发项目初期，确定好明确的项目需求，随后根据项目需求进行分工，严格按照项目流程开发项目。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
答：团队有一个简略的测试计划，但由于时间紧张，未全面的进行测试。
2. 是否进行了正式的验收测试？
答：是的，项目进行了正式的验收测试。
3. 团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
答：目前还没有测试工具进行测试，以后会使用工具对系统进行详细的测试。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：Alpha阶段没有涉及效能分析。
5. 在发布的过程中发现了哪些意外问题？
答：小程序发布由于程序介绍填写不恰当，审核未通过。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
答：学到了小程序的多人开发及发布流程。如果再来一遍，我们会选择合适的测试工具对系统进行测试，会提前发布，修改发布后出现的问题。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
答：定角色时，人尽其才，每个人发挥自己特长，及选择自己感兴趣的部分。
2. 团队成员之间有互相帮助么？
答：团队成员之间互帮互助，友好相处。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：我们认为目前的状态属性CMM/CMMI中的“可管理级”
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：我认为团队目前属于磨合时期，即将步入规范时期。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：成员之间互相了解，大家积极向上，都有明确的的方向。
你觉得目前最需要改进的一个方面是什么?
答：大家的分工问题与时间问题，需要有一个详细的标准。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
答：开会前明确开会商议内容，不做无效的讨论，集中开发，多人测试。
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
答：制定详细的代码开发规范，如注释的方式，变量的定义等。严格按照代码规范进行开发。
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
答：在制定整个程序时，团队要全面考虑各个功能，制定一个好的架构。通过重构方法，提高质量。
3. 项目管理有哪些具体的提高？
答：代码提交合并中需要提高，防止成员开发代码被冲突掉。
4. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
答：查看昨日关键用户指标，反映小程序昨日用户活跃概况，以及对比一天前、一周前的增长率。实时统计，查看关键指标的趋势。
5. 项目文档的质量如何提高？
答：在编写项目文档时，指定明确的项目文档规范，编写完成后，进行文档审查。
全队的讨论照片：
