福大软工·第十一次做业-Alpha过后诸葛亮
组长博客连接html
本次做业博客连接前端
项目Postmortem 模板
设想和目标
咱们的软件要解决什么问题?是否认义得很清楚?是否对典型用户和典型场景有清晰的描述?python
- 针对日常没有不少时间看手机,微信、QQ群消息反而偏多、可是想了解群里面关键话题的人群,若是有这么一款软件能够直接帮助这部分人群提取出群消息里面的关键话题,这样既节省了时间,也方便这部分人群直接处理相关的消息。定义很是清楚,对典型用户和典型场景有清晰的描述。咱们的软件主要解决用户在平常生活中对于QQ和微信消息难以在短期内快速获取重点与关键信息的问题。咱们软件解决的问题是定义得较为清楚的。咱们的软件针对诸如日常没有不少时间看手机、难以在大量的群聊中get到重点、须要快速获取群聊的重点信息并在第一时间获得通知的典型用户。咱们的软件主要应用于诸如用户为了融入群聊环境但愿快速了解本身各个群聊热点话题、用户须要第一时间回应上司或者部门群体at通知、用户但愿获取本身交际圈最近的话题导向这样的典型场景。
咱们达到目标了么(原计划的功能作到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?git
- 咱们不只达到了目标,还比原目标超出了许多。原计划的功能要作到群消息的保存、数据库的搭建、界面的初始框架,登陆和注册的界面,在Alpha版本咱们所有作到了,并且还额外的完成了管道方式的多进程通讯模块、无感式单向好友检测模块、基于NLP的热词分析模块。原计划是打算在在Alpha冲刺阶段完成,可是咱们的具体功能在开发的期间已经作完了,还剩下几天就是不断的整合在一块儿。原计划是不打算有用户的,就是本组内部成员在试用。咱们达到了部分的目标。原计划的功能咱们实际上在后端已经完成了三个,整合进入前端界面的有两个。同原计划有必定的差距,可是核心功能都已经获得了完成。目前阶段用户基本局限于组内人员以及少数同班同窗,同原计划的用户数量有必定差距,这与目前的功能开发进度有关,相信在beta版本发布以后会有所改善。
用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?web
- 目前咱们暂时就是本组成员在试用。根据Alpha版本答辩的现场情况来看,咱们的主要功能仍是比较吸人眼球的。
有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?算法
- 这基本上对于咱们来说就是第一次开发一个项目,经验教训太多了,下面列几点比较深入地:
(1)对pyqt、wxpy等语言的难易程度没有掂量清楚,一开始就轻易的定下项目开发使用的语言工具
(2)若是遇到一个比较难解决的问题(wxpy形成主程序的假死),咱们会在这个问题上卡许久
(3)软件开发过程当中的不像畅畅组那么规范专业,没有相应的文档和记录较少
若是历史重来一遍,咱们会在开发最开始定语言工具的时候更加仔细衡量用什么语言会比较方便,会在软件开发的过程当中更加注重规范化,会在软件开发的过程当中更加注重相关语言的学习。
计划
是否有充足的时间来作计划?sql
- 学期初即公布了本学期项目的安排,所以咱们团队有充足的时间对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 配色应统一美观。
建议:排除掉一些常常用的而且不是用户须要获取的词。
第三组:
建议:封号问题以前已经有人提过解决方案了,隐私问题原来小组有说过能够之后寻求专业人士帮助,我以为还能够跟用户签定协议,以避免没必要要麻烦。
第四组:
建议:推出更多功能,增长用户体验。
第五组:
建议:能够多去参考一下一些热门展品的UI以及配⾊
建议:但愿后面能支持对QQ的热词分析。
第六组:
建议:先初步实现各项功能再进行后续的迭代和优化
建议:优化交互界面的细节
建议:实现经过帐号密码来登陆微信以及增长对 qq 的支持根据用户实际需求改进功能
第八组:
建议:但愿后续可以分工分配的更加合理
第九组:
建议:无建议。
我的贡献分


我的部分
我的PSP
Planning |
计划 |
5 |
5 |
· Estimate |
· 估计这个任务须要多少时间 |
5 |
5 |
Development |
开发 |
0 |
0 |
· Analysis |
· 需求分析 (包括学习新技术) |
0 |
0 |
· Design Spec |
· 生成设计文档 |
0 |
0 |
· Design Review |
· 设计复审 |
0 |
0 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
· Design |
· 具体设计 |
0 |
0 |
· Coding |
· 具体编码 |
30 |
120 |
· Code Review |
· 代码复审 |
0 |
0 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
0 |
0 |
Reporting |
报告 |
5 |
5 |
· Test Repor |
· 测试报告 |
0 |
0 |
· Size Measurement |
· 计算工做量 |
5 |
5 |
· Postmortem & Process Improvement Plan |
· 过后总结, 并提出过程改进计划 |
0 |
0 |
合计 |
|
40 |
130 |
我的学习进度条
2 |
413 |
413 |
21 |
21 |
学用git;接触vs性能分析、单元测试功能; |
3 |
0 |
413 |
16.5 |
37.5 |
阅读《构建之法》;结对配合;学习NABCD模型;接触原型开发工具 |
四、5 |
1061 |
1474 |
23.5 |
61 |
结对配合经验up;了解接触爬虫 |
6-9 |
500 |
1974 |
100 |
161 |
团队合做经验up;文档编辑能力up;学习Python;学习PyQt |
10 |
265 |
2239 |
25 |
186 |
继续学习PyQt,开始动手实践 |
11 |
97 |
2336 |
7 |
193 |
继续学习PyQt;进行团队项目;对本身的认识up |
12 |
54 |
2784 |
20 |
213 |
进行团队项目 |
13 |
136 |
2866 |
6.5 |
219.5 |
进行团队项目 |
… |