事后诸葛亮会议
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是通过基于微信给用户提供一个信息平台，我们的定义很明确，做一个比较简单的寻找失物和发布招领信息的平台，在前面的博客中对典型用户和场景进行过明确的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 由于项目比较简单，计划时间不多，但已经足够。
- 比较遗憾的是目前还没有与学校的失物招领处取得合作上的沟通，暂时不能实现作为官方渠道来推广。
- 目前小程序的用户数量最高峰达到30人在线。注册用户达到103人，没达到预期。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量：不一致。目前还没有与学校的失物招领处取得合作上的沟通，暂时不能实现作为官方渠道来推广。只是在朋友圈和微信群等社交平台进行宣传，导致用户数量增长缓慢
接受程度：基本一致。用户发布信息后，当出现了匹配信息后及时得到了通知，同时也可以在自主浏览招领列表
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
首先分工尽量明确，让每个人都有任务可以做并且是愿意做的，能做好而不是草草应付，或者说因为不擅长而做得很费劲。
二、计划
1. 是否有充足的时间来做计划?
是的，有充足的时间进行计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
先各自提出自己的想法，再由组长依据情况进行判断选择，或进行投票决定。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有做完。Beta测试做得不够完善。同时，在测试阶段，压力测试受限于设备，导致之后使用过程中存在卡顿的不确定性。sa
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
按照目前所做的来看，没出现到什么senseless的事。
5. 是否每一项任务都有清楚定义和衡量的交付件?
在代码规范这一块可能做的没那么好，函数、变量等命名比较随便。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
意外：基本按照计划进行。但是在测试阶段时有考试需要考复习去了没时间考虑太多情况的测试类型。
风险：程序没有对用户信息进行加密处理，可能会导致别有用心之人利用漏洞窃取用户数据信息。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 预留必要的缓冲时间；
- 将各个模块的功能需求描得述更加清楚，以方便开发人员进行开发。
- 站立式会议应更加针对问题并更快地提出解决方案。
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
收获：对于计划好的内容，应尽早解决，不要过度依赖deadline。并且在计划时应该边行动边计划，按照实现进度适当调整改变计划，不可以硬生生地只照着初始计划执行，会导致进度发展变得缓慢。
改进：应该预留好缓冲时间。
三、资源
1. 我们有足够的资源来完成各项任务么?
- 开发资源：组长整理了部分开发所需的基础知识和技术文档
- 设备资源：人手一台电脑，足够完成开发测试任务
- 人力资源：我们团队有6个人，人力是够的
- 时间资源：时间比较紧张，除了软工这门课，还有其他课程也有实验课设、作业和考试，软工团队项目工作量也不小。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
通常是组长列出任务后，团队成员按兴趣以及能力分配，如每周负责撰写博客的主要负责人轮流做，其他人辅助填写等。
任务精度是精确到3天为一周期。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们的界面美化比较单一是真的，因为队里的比较缺乏这一块的经验
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：在项目进行过程中，知道了应该如何更好地去分配各种资源，对于时间的管理其实是不好的，被ddl赶着走，可能漏掉了很多细节。还有就是任务有出现过重叠，导致效率降低。
改进：应该更加明确些，具体到某一点的哪些内容，否则会出现队员做了相同的事，而产生了无用功浪费了人力物力。同时沟通真的很重要，队员间要多多加强沟通，防止因为误解队员的意里而产生误会。
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的。通常出现其他变更时i，在微信群里发个通知，大家都知道的了，再讨论一下问题不大。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 核心功能中容易实现的必须在 alpha 版本实现；
- 核心功能中有技术难点的推迟到 beta 版本实现。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
每个成员负责的模块整合在一起，并通过测试，实现一个稳定的版本。
4. 对于可能的变更是否能制定应急计划?
项目开发过程中没考虑这个问题。
5. 员工是否能够有效地处理意料之外的工作请求？
可以。比如撰写博客任务，当任务量比较大的时候，负责人会按情况分配一些给其他成员。、
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在需求文档完成后开始着手的，由组长带头开会，一起讨论好然后由PM来完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有。页面的跳转流程起初没有一个确定的方案，导致各个模块的界面零散。当时是再具体研究需求文档后按照逻辑顺了一边流程图后再设计界面。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
信息匹配功能。因为涉及到数据的遍历，需要设计好算法和数据结构，当时的算法没有写好。
新bug：不能匹配表情符号。当时没考虑到有些用户会在输入框中加入表情emoji，导致数据类型出错。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由于时间关系，并没有太多的代码复审。
代码规范方面也是，每个人代码风格不统一，导致整合后代码阅读起来比较慢。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
教训：我们对于代码复审比较不重视，导致整合后代码杂乱，不易阅读理解。之后会让一个人专门负责代码的复审，提高规范性。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划。
2. 是否进行了正式的验收测试？
没有做好这一块的工作。
3. 团队是否有测试工具来帮助测试？
借助微信小程序开发者工具自带的调试功能以及微信小程序的开发者模式中的测试调试功能。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测试能否成功连接数据库以及相应的SQL语句的是否正常执行等等。改进的方面就是大家应该在如何运用测试软件上多做些学习，这样可以保证正确的执行测试任务同时节约时间提高效率。
5. 在发布的过程中发现了哪些意外问题？·
小程序发布时的审核需要一定的时间，来不及在博客提交前完成审核。
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
按照我们各自的兴趣先主动选择，后出现重叠后按照模块来分配。
2. 团队成员之间有互相帮助么？
有。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
目前我们组在合作这一块还是比较和谐的，没有出现大问题。项目管理我们是由专门队友负责。
八、总结:
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
3.你觉得目前最需要改进的一个方面是什么?
测试的全面性。
4.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 首先我们做到了可以尽早持续的交付有价值的软件。三个阶段中，我们都可以做到交付一个可以使用有具体功能的小程序供大家使用。
- 组内成员也都做到了精益求精，不仅仅将眼光放在完成布置的任务中，而是对整个小程序性能的提升做出一些建议，并且实现它
5.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 开发者必须严格按照流程进行代码编写和提交
- 复审过程像上述中的流程一样，有测试人员经手再通过管理人员发布。
- 严格按照代码规范文档，严谨地进行变量名的书写和格式等等。
- 如果结果不合格会进行一定程度的惩罚并且责任到人，再次进行修改。
6. 其它软件工具的应用，应该如何提高？
我们在测试方面，需要使用软件工具，帮我们完成代码覆盖率和一些压力测试。在这些方面，我们缺乏调研，仅凭自己的判断就认为网站不需要覆盖率是不正确的想法。
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
我们通过小程序开发者工具的后台工具查看，并借助云服务器查看登陆的用户
6. 项目文档的质量如何提高？
对于文档来说，最好的方式就是有固定的统一的模板。并且文档是需要不断更新的，在一个阶段结束前需要更新该阶段的文档保证文档是不断扩充，不会落后于代码工程。
- 1. 全组讨论的照片。
- 2. 团队成员在Alpha阶段的角色和具体贡献：
|
姓名 |
角色 |
团队贡献分 |
可验证贡献 |
|
石竟贤 |
PM |
20 |
撰写博客，功能代码编写 |
|
林剑峰 |
DEV |
18 |
撰写博客，功能代码编写 |
|
周惠龙 |
TEST |
17 |
撰写博客，代码测试 |
|
陆君健 |
DEV |
15 |
撰写博客，功能代码编写 |
|
饶元兴 |
DEV |
16 |
撰写博客，界面开发 |
|
梁景涛 |
TEST |
14 |
撰写博客，代码测试 |
