福大软工 · 第十一次作业 - Alpha 事后诸葛亮（团队）
福大软工·第十一次作业-Alpha事后诸葛亮
项目Postmortem 模板
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 针对平常没有很多时间看手机，微信、QQ群消息反而偏多、但是想了解群里面关键话题的人群，如果有这么一款软件可以直接帮助这部分人群提取出群消息里面的关键话题，这样既节省了时间，也方便这部分人群直接处理相关的消息。定义非常清楚，对典型用户和典型场景有清晰的描述。我们的软件主要解决用户在日常生活中对于QQ和微信消息难以在短时间内快速获取重点与关键信息的问题。我们软件解决的问题是定义得较为清楚的。我们的软件针对诸如平常没有很多时间看手机、难以在大量的群聊中get到重点、需要快速获取群聊的重点信息并在第一时间得到通知的典型用户。我们的软件主要应用于诸如用户为了融入群聊环境希望快速了解自己各个群聊热点话题、用户需要第一时间回应上司或者部门群体at通知、用户希望获取自己交际圈最近的话题导向这样的典型场景。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 我们不仅达到了目标，还比原目标超出了许多。原计划的功能要做到群消息的保存、数据库的搭建、界面的初始框架，登录和注册的界面，在Alpha版本我们全部做到了，而且还额外的完成了管道方式的多进程通信模块、无感式单向好友检测模块、基于NLP的热词分析模块。原计划是打算在在Alpha冲刺阶段完成，但是我们的具体功能在开发的期间已经做完了，还剩下几天就是不断的整合在一起。原计划是不打算有用户的，就是本组内部成员在试用。我们达到了部分的目标。原计划的功能我们实际上在后端已经完成了三个，整合进入前端界面的有两个。同原计划有一定的差距，但是核心功能都已经得到了完成。目前阶段用户基本局限于组内人员以及少数同班同学，同原计划的用户数量有一定差距，这与目前的功能开发进度有关，相信在beta版本发布之后会有所改善。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 目前我们暂时就是本组成员在试用。根据Alpha版本答辩的现场状况来看，我们的主要功能还是比较吸人眼球的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 这基本上对于我们来讲就是第一次开发一个项目，经验教训太多了，下面列几点比较深刻地：
（1）对pyqt、wxpy等语言的难易程度没有掂量清楚，一开始就轻易的定下项目开发使用的语言工具
（2）如果遇到一个比较难解决的问题（wxpy造成主程序的假死），我们会在这个问题上卡许久
（3）软件开发过程中的不像畅畅组那么规范专业，没有相应的文档和记录较少
如果历史重来一遍，我们会在开发最开始定语言工具的时候更加仔细衡量用什么语言会比较方便，会在软件开发的过程中更加注重规范化，会在软件开发的过程中更加注重相关语言的学习。
计划
是否有充足的时间来做计划?
- 学期初即公布了本学期项目的安排，因此我们团队有充足的时间对Alpha冲刺任务做出了计划和安排。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们团队的民主氛围比较浓厚，我们团队会一起讨论大家提出的不同意见。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 由于进度安排较为合理，我们团队完成了所有原计划中的任务。
有没有发现你做了一些事后看来没必要或没多大价值的事?
是否每一项任务都有清楚定义和衡量的交付件?
- 在真正开始项目之前，我们对项目进行过程中将会遇到的各项任务不能够做到完全的估计和衡量，随着项目的推进，我们对于各项任务的认识愈发得清晰了起来，基本上对每一项的任务都做出了清楚的定义并制定了衡量的交付件。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 项目的整体进展大致按照着计划进行，我们对前端开发工具PyQt的低估是我们项目进行过程中出现的最大意外。PyQt的学习难度，比如设计难度高、学习资料少是我们没有估计到的风险，没有估计到的一部分原因在于学习时间短，实践经验少；另一部分原因在于真正进行项目的开发之前没有对它进行充分的了解。
在计划中有没有留下缓冲区，缓冲区有作用么？
- 我们在计划上预留下了两至三天的时间缓冲区，这个预留的缓冲区对我们项目的最终完成起了很大的作用。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 将来的计划中将会留下更多的缓冲区用以解决发生在意料之外的情况，以及更好地完善产品；进一步改善任务的分工安排，优化团队间的合作， 提高团队的工作效率，避免不必要的“加班”。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 在本次团队冲刺中， 我们团队协力完成了Alpha版本的发布，在这一过程中我们初次经历了团队的共同开发，认识到了计划对整个项目方向和进度的重要性。如果历史重来一遍，我们会事先做好更加完善的计划，并在项目进行中根据实际情况及时对计划做出修正。
资源
我们有足够的资源来完成各项任务么?
在经历了初期的需求报告调研以及项目展示后，我们组经过总结认为有以下几大块的任务：
- 发现问题（需求或痛点）并将其表述清楚，并转化为规范的文档
- 通过讨论沟通等模式来对发现的问题进行解构、分析
- 基于分析给出可行的方案和思路，并聚合成各个功能
- 将各个功能细化，形成包括但不限于原型、UML等形式的文档供开发使用
- 对项目的开发分为界面、美工、数据库、后端、算法等分支进行协同开发
- 撰写记录项目开展进度的文档、以及进行展示的文档
- 通过PPT、视频、海报、图片、文案对项目进行全方位的展示和推广
- 对开发的代码进行复查、测试
- 通过高效的工具和模式来保证团队成员间的高效合作
- 团队内需要有威望的成员（如PM）和人性化的制度进行项目管理，模块合并来保证项目的顺利完工
而这些任务目前来说，虽然和理想的、完美主义的目标相比仍然有差异，但就实现的角度来说完成得不错。就资源和原因来看：
- 组内的成员都对软件工程这门课十分上心，绝不会敷衍了事
- 成员们都具有高效的学习能力，能够在短暂的时间上手新的技能和技术
- 团队的交流和合作氛围十分良好友善，成员都是儒雅随和的TYPE
- 分工十分明确，项目的管理和协作并没有出什么大的纰漏
- 组内成员都非常有想法创意，并有相应地能力去实现这些创意
- 全员强迫”让成员们对自己工作质量要求都很高，各项任务完成度很高，质量也处于较高的水准
- 组长具有良好的技术和丰富的经验，对自己不妥协不放弃，能及时帮组员填坑
- 因为某些原因，团队有十分稳定的场地以供协作
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 目前作为一个开发经验不够丰富的团队来说，各项任务所需的时间在某种程度上只能根据讨论和臆测来进行估计。
- 在资源的估计上相对来说科学的多。
- 对于大的任务模块本组以半天作为单位来进行估量
- 在小的任务模块上本组以小时为单位进行评估
- 精度方面大多数任务的估计与实际工作量不会偏差过多，在界面方面有一定的偏差
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 功能测试上时间的余量相对来说比较宽松
- 软件资源方面，产品的一项功能（单项好友检测）由于腾讯WXPY库及API方面的政策，导致短暂的封号，使账号资源较为紧张
- 美工/文案方面由于本组有半专职的美工从事相应的工作，同时在PS、AI、PPT等技能上较为熟练，因此人手和资源较为充裕。
- 但由于PyQT的特性，导致设计稿和界面有一定差距
你有没有感到你做的事情可以让别人来做（更有效率）?
- 团队如果能更加高效地使用好GitHub，能在代码的管理上更加高效
对项目任务的分块工作量估计不够精准，导致一部分的人力资源浪费
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 慎用网络上文档资料较少的技术栈
- 在计划设计阶段要对项目功能的可行性、技术政策风险进行评估、对技术栈的使用也要有多方面的考量
- 团队应当更加高效地使用好git工具
- 对于代码的一些规范要进行好约束
- 更加细化分工
- 变更管理
变更
每个相关的员工都及时知道了变更的消息?
- 因为团队每次都是在开会期间决定功能模块的变更，而每个成员几乎都不会缺席，因此团队内的每个成员能及时知道变更消息。
- 团队的计划和任务分配都会同步到团队的协作管理平台--Leangoo，即使偶尔有成员缺席会议，也能通过Leangoo即使知道团队的任务变更。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 我们团队综合衡量了现阶段所能投放在项目上的时间以及成员的能力，分析了现有的开源项目所能提供的技术支持，结合产品开发前期我们做的大量的用户需求分析，最终决定必须实现基本的软件运行环境和核心功能“热词分析”、“单项好友检测”，将“关键词提醒”和“群发祝福”推迟到Beta版本实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 目前我们是有较明确的出口条件的：
- 四大功能在后端算法实现上基本完成，能保证每次都正常运行
- 产品界面美观、前端和后端交互逻辑正常，用户体验良好
- 做好数据库等的安全防护措施，保证用户数据的安全性，并制定完善的用户隐私政策
对于可能的变更是否能制定应急计划?
- 临近deadline，组织团队成员集中面对面编程
- 每日汇报各人任务进度
员工是否能够有效地处理意料之外的工作请求？
- 鉴于团队成员都是在校生，平时课业较为繁重，所以如果要临时增加需求或功能，可能无法在Deadline之前实现。
- 如果是现有功能出现的异常，比如哪个功能突然出现了未知bug，团队还是能够及时处理并解决的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 使用GitHub进行代码管理，而不是把GitHub当成百度云盘
- 编写完善的设计文档，做好注释工作
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 我们暂时没有进行单元测试，我们会在beta阶段加入对每个模块的测试！我们使用了UML进行辅助设计。
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 主要的变化是在数据库上的变更，数据库的结构有发生变化。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 团队之前碰到的BUG主要是在对wxpy进行整合的过程中，主窗口假死的BUG；之后我们使用了多进程通信的方式，在使用多进程通信方式的过程中，又出现了如窗口关闭后wxpy进程无法跟着关闭等BUG。当然，界面开发过程中也出现了很多BUG。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 我们没有很好地进行代码复审（惭愧），代码规范我们尽量的遵循PEP8的编程规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了多进程通信、PyQt的使用（很麻烦，需要手写各种类间的继承）、wxpy的使用、sqllite数据库的使用等
测试/发布
- 团队是否有一个测试计划？为什么没有？
- 暂无
- 团队经验不够足
- Alpha版本时间紧、工作量大
- 是否进行了正式的验收测试？
- 暂无
- 团队是否有测试工具来帮助测试？
- 暂无
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 暂无
- 在发布的过程中发现了哪些意外问题？
- 我们使用pyinstaller打包软件时，发现和本地运行结果的不一样（无法调用wxpy），暂未解决
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了多进程通信、PyQt的使用（很麻烦，需要手写各种类间的继承）、wxpy的使用、sqllite数据库的使用等
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
根据自己的兴趣以及掌握的技术来分配，相对来说能达到人尽其才的程度
-
团队成员之间有互相帮助么？
有，事实上很多困难时是团队一起攻克的
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
摆出事实，然后阐述问题出现在哪，然后一起寻找解决方案
公开感谢（个人）
我感谢 __张扬___对我的帮助， 因为:最后整合的时候，组长帮忙解决了好多问题！
我感谢 __韫月___对我的帮助， 因为:一起熬夜一起肝，有她代码就不怕！
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
整组有部分人员没有分配合理的工作，或者未能交出合理、可用的工程任务。主要的工作都集中在个别成员中。当个人的工作完成后，不能及时的分配接下来进行的任务，只能组员自行安排可行的任务。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合阶段。团队成员开始逐渐熟悉和适应团队的工作方式，面对问题和冲突，能够进行有效的沟通，解决问题。但是问题仍然存在。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 从进程通信和界面编写的坑中爬了出来
你觉得目前最需要改进的一个方面是什么?
- 任务量分配不合理，一个任务完成之后下一个任务没有及时安排
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
讨论照片
现场得分及QA总结
| 第一组 | 第二组 | 第三组 | 第四组 | 第五组 | 第六组 | 本组 | 第八组 | 第九组 | |
|---|---|---|---|---|---|---|---|---|---|
| 本组对其评分 | 81 | 77 | 68 | 75 | 66 | 81.5 | 85 | 81 | 53 |
| 对本组的评分 | 79 | 79 | 77 | 60 | 80 | 74 | 85 | 77 | 75 |
去除最高总分，最低总分，求平均分后，得到：
本组的现场答辩得分：(79+79+77+80+74+77+75)/7=77.28
第一组提出的问题：
问：答辩中提到pyqt的教程数量很少,是否pyqt本身就存在开发的局限才使得它的教程数量少呢?
- 其实个人认为得益于qt框架的健壮性，pyqt的框架也不会很差！目前pyqt教程少一方面是因为社区还不够大，另一方面应该是很少有人拿pyqt去找工作吧！至于是否是pyqt架构本身存在问题，我们只能说我们水平还没到能评价架构上是否存在局限的地步。
问：答辩中提到,pyqt对部分组员太难了,是否考虑分配组员完成其他任务？
- PM向无法驾驭pyqt的队员分配了数据处理、数据库接口、文档撰写等任务
问：用户使用你们的软件是否需要配置相应的运行环境?
- 目前是需要的，因为python存在依赖库，项目开发后期发布release版本后应该就不需要依赖坏境了
第二组提出的问题：
问：既然是扫描微信登陆，为什么还要弄申请账号呢？
- 申请账号为本软件后续的经营提供了收支渠道。
问：关键词提醒功能是在电脑端提醒还是手机微信提醒呢？
- 关键词提醒功能可以根据用户自定义，来设置通过邮件提醒或者通过手机短信提醒。
问：能否对QQ信息来执行相关的功能呢？
- 在Alpha阶段我们实际上是有做QQ消息的保存的，只是因为精力有限没有将QQ端的功能整合进来。
第三组提出的问题：
问：关于封号的问题，是否有一个具体明确的解决方案，还是到时候选择弃用网页端呢？
- 我们的解决方案是设置安全的延时时间，模拟用户的真是操作
问：对于界面是否有想过优化
- 有的，本组的Beta版本任务就包含了美化界面这一块。
问：是否考虑与用户签订隐私协议
- 可以考虑一下
第四组提出的问题：
注：该组在规定时间内未对我组提出任何问题，故不做回答。
第五组提出的问题：
问：关于界面的问题，是否有考虑在后期重新换一种语言写界面？如果不换，如何考虑组员的分工问题
- 考虑过，但是不打算换了，因为目前很多功能都用pyqt实现了，另外换语言的成本也很大（代码重写、TCP链接也不是很容易建立）
问：电脑睡眠状态时，软件能否正常运行？
- 只要网络保持连接、不杀死进程是可以的。若网络连接断开，会造成无法保存的情况。
问：如何解决聊天记录可能泄露的问题？
- 本组不会尝试获取用户隐私。而且从技术层面上我们确实获取不到用户的隐私，主要原因是登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，我们获取不到相关信息。
第六组提出的问题：
问：在alpha版本仅实现了部分功能，是否存在分工不合理现象？
- 事实上，alpha版本已实现了我们的核心功能【热词分析】，并且，本组对alpha版本的任务规划已全部完成，因此进度是在预期内的。
问：是否有考虑在后续版本中增加账号密码登录微信的方式？
- 本组开发的软件登录时是通过WXPY提供的接口模拟用户在web端登录微信，而WXPY提供的登录方式暂时只有用户扫码登录这一方式。
问：在beta阶段是否会考虑对已实现功能的优化？
- 这是肯定会的。
第七组提出的问题（本组）
第八组提出的问题：
问：你们说网上的资料很少很多需要自己手写，那么对于后期如何有效提升团队的整体效率呢？
- 这两者...有关系吗？
问：后期对于组内的分工方面是否还要更细致一点？
- 是的，本组接下来会继续细化组内的分工，做到合理分配任务。
问：对于ui界面准备如何美化？
- 首先，本组会参考目前较为热门的ui设计配色方案，并以此为依据进行美化；并且，会在能力范围内做一些调研，争取让ui界面更加合理，对用户更友好。
第九组提出的问题
问：当前实现的功能较少，是否存在团队分配不合理的情况？
- 事实上，alpha版本已实现了软件的核心功能【热词分析】，并且，本组对alpha版本的任务规划已全部完成，因此进度是在预期内的。
问：扫描登陆微信功能是否安全，是否可以安全？
- 用户登录时是在模拟用户在web端登录微信，登录过程腾讯是有做加密的，因此是安全的。
问：所说的PyQt和wxpy的坑，打算如何越过，有没有具体的计划？
- 目前算是爬出来一半了，之后主要是由已经踩过坑的同学来带领团队开发
各小组对我组提出的建议及我组改进总结
第一组：
建议：美化界面，提升用户操作体验。
- 改进：好的，本组会在接下来的开发过程中进行改进。
第二组：
建议：网页端微信封号的问题能否改善。
- 改进：我们尽可能的不造成封号（设置一定的发送延时）
建议：UI 配色应统一美观。
- 改进：好的，本组会在Beta版本进行改进。
建议：排除掉一些经常用的并且不是用户需要获取的词。
- 改进：可以考虑设计合理的词库，仅统计词库中有的词
第三组：
建议：封号问题之前已经有人提过解决方案了，隐私问题原来小组有说过可以以后寻求专业人士帮助，我觉得还可以跟用户签订协议，以免不必要麻烦。
- 改进：我们并没有查到什么针对封号问题的解决方案！
第四组：
建议：推出更多功能，增加用户体验。
- 改进：好的，谢谢你们的建议。
第五组：
建议：可以多去参考一下一些热门展品的UI以及配⾊
- 改进：好的，谢谢你们的建议。
建议：希望后面能支持对QQ的热词分析。
- 改进：我们会考虑在Beta阶段加入
第六组：
建议：先初步实现各项功能再进行后续的迭代和优化
- 改进：好的，谢谢你们的建议。
建议：优化交互界面的细节
- 改进：好的，本组会在Beta版本进行改进。
建议：实现通过账号密码来登录微信以及增加对 qq 的支持根据用户实际需求改进功能
- 改进：好的！
第八组：
建议：希望后续能够分工分配的更加合理
- 改进：好的！
第九组：
建议：无建议。
个人贡献分
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 420 | 600 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 80 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 0 | 0 |
| · Coding | · 具体编码 | 300 | 520 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 30 | 20 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 10 |
| 合计 | 460 | 630 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 30 | 30 | 学习VS生成命令行程序、单元测试、使用VS性能分析工具等 |
| 2 | 300 | 800 | 35 | 65 | 改进第一次作业、学习《构建之法》第3和8章、学习原型设计Axure Rp 8、画画技能++ |
| 3-5 | 1000 | 1800 | 120 | 185 | Python++、交流能力++、时间规划++ |
| 6-9 | 300 | 2100 | 120 | 305 | 原型设计++、交流能力++、时间规划++、Python++、画图技能+++ |
| 10 | 300 | 2400 | 25 | 338 | pyqt+++ |
| 11 | 500 | 2900 | 22 | 360 | pyqt+++++ |
| 12 | 800 | 3200 | 40 | 378 | pyqt+++++++++ |
| 13 | 2100 | 4300 | 59 | 397 | pyqt++++++++++ |
