背个帮小组事后诸葛会议
此作业要求参见：https://edu.cnblogs.com/campus/nenu/2020Fall/homework/11545
组名：背个棒
组长：史志腾
组员：张兵杰 孙佳豪 韩志超 吴艳丽 韩亚光 徐灿灿
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的小程序是为了给在校大学生和工作党提供账单记录功能，让用户清晰的了解到自己的金钱去向同时消费额度提醒功能和团队消费功能起到提醒用户合理开支和团队游玩消费记录。
定义的很清楚具有目前其他记账软件所没有的崭新功能。典型用户就是每月感觉自己没怎么花钱钱又奇怪消失掉的人群用消费记录证据让他们清楚的认清自己是剁手党的事实。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
我们达到了之前所定的目标原计划的功能全部完成，也按原计划完成交付用户数量也远超之前所定目标30。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量远超之前目标30，超出我们的设想，对之前发布的小程序进行功能完善界面美化修复离目标已十分相近。
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
组里很多人没开发过类似小程序，团队合作中刚开始会依赖于队友，同时在之前发布未能按计划完成。重新再来一遍可能会详细制定一个可行性分析，并将任务具体分工给出期限，合理安排每个人
的任务量，先做出demo然后在进行改进而不是一开始就进行复杂功能的设计。
计划
1. 是否有充足的时间来做计划?
有充足的时间做计划，每天都会开会讨论安排任务，时间大多在30分钟以上。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同意见进行提出记录，在讨论会上进行可行性分析大家共同对其进行探讨选择多数同意方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划完成。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
5. 是否每一项任务都有清楚定义和衡量的交付件?
是的
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个项目在alpha阶段没有按照计划作出所承诺的功能，由于组内并未意识到alpha阶段的含义导致了推迟发布，小组成员连夜敲代码赶工程进度，
而在beat阶段对任务分工有了明确的划分所以完成状况较好并将之前承诺功能补上。beta阶段的按照计划进行，没出现什么意外。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
beat阶段有预留出缓冲区，对项目进行审核查找bug进行功能检测并多人协助进行补全。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
最好再安排计划时提前一些，这样会使得整体项目更有规划性，对每个人的分工再详细一些，打好提前量
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在一个项目进行中一个人的力量是有限的，掌握组内成员的技术栈合理进行调配并进行任务的分工也是很重要的否则组内开发过程中就会一团糟不仅作出的
产品无质量保证甚至无法完成项目。如果历史重来，除了会在一开始就做好任务分工还要尽早的作出demo最简单的demo证明实现没问题而不要一开始从复杂功能进行设计
这样很可以会卡主并进而影响伙伴的开发进度。
资源
1. 我们有足够的资源来完成各项任务么?
有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
按功能页面进行分配，分给个人之后由个人给出交付时间，时间精度在2-3天。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于beat阶段时间安排合理所以测试的时间很充足，但仍有少量bug未测试到，还好及时人力资源足够，没有低估美工以及文案的难度，文案美工设计关系着一个产品最直观呈现给用户的体验。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在任务的分配过程中有的成员承担着较大的工作量有的成员工作量较少应安排较少工作量人员去帮助分摊工作量既让每个成员得到锻炼又不会给某个成员造成太大压力。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
在进行变更后会在每日组会上进行及时的通知。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
组内进行商讨对应功能部分的实现放在必须上对于界面以及小bug的修改则可以稍作推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，对照提出的目标进行一一测试功能可以正常使用。
4. 对于可能的变更是否能制定应急计划?
否
5. 员工是否能够有效地处理意料之外的工作请求？
能，团队成员都有很好的能力来处理意外。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
项目开发过程中团队的成员是一个整体大家都朝着一个目标前进，所以一定要多沟通交流互相帮助建立深厚的革命友谊而不要抱着依赖他人的心态。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
每周四上完课后当天晚上就会开组会，将工作设计好。由我们全组人员商量决定，是合适的时间和合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有这种情况，我们每天晚上开组会是会首先解决的就是困难或者是自己没有把握的事情，当情况紧急时会直接在群里面提出自己的问题。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
对于测试我们使用人工去测试，将系统安排给周围的人去测试和使用模拟各种情况去发现问题。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
对于数据的异步渲染产生的BUG最多，因为开发经验少，不熟悉的原因。在发布之后没有出现重要BUG。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
严格执行了代码的规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有一个测试计划，我们使用人工来进行测试。
2. 是否进行了正式的验收测试？
在程序发布的前两天内，请周围的人和自己的开发人员进行测试。去发现问题和BUG。
3. 团队是否有测试工具来帮助测试？
没有使用测试工具来进行测试。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有涉及效能和压力测试。
5. 在发布的过程中发现了哪些意外问题？
之前修改之后进行二次审核时间较长，这次预留了三天时间进行发布审核。本次审核时间较短是我们没有想到的。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
对团队的整体人员，我们在后期进行人工测试时学到了测试对于程序的重要性。如果再来一遍我们会尽可能的去使用较为专业的测试工具进行测试。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队每个角色是在中期进行工作时自动确定的，没有进行过多的干预。每个人都在自己最合适的位置。
2. 团队成员之间有互相帮助么？
团队成员之间氛围良好，当平时出现问题时将问题放在群里，有想法的人会将自己的想法表达出来。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们将这些问题一日一总结，在开组会的时候会将问题提出来，然后全组人员去解决这些问题。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI一级，执行级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于规范阶段
