Thunder-Beta发布-事后诸葛亮会议-2017秋-软件工程第十一次作业

小组名称：Thunder
项目名称：爱阅APP
小组成员：王航 李传康 翟宇豪 邹双黛 苗威 宋雨 胡佑蓉 杨梓瑞
一、设想和目标
　　1、我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
　　　　在alpha发布中，我们组开发的软件组要解决在线阅读和本地导入1阅读。功能领域定义的很清楚，通过典型用户和典型场景有清晰的描述。在Bata发布中，我们主要解决的问题包括增加处理文本数量、增加上网查看小说、增加 用户反馈等功能。

　　　　#在alpha发布中，我们组开发的软件组要解决在线阅读和本地导入txt文本阅读功能。在Bata发布中，我们主要解决的问题包括增加处理文本数量、增加上网查看小说、增加 用户反馈等功能。
　　2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
　　　　本阶段我们原计划做9个功能，每项任务都按照交付时间交付的。原计划的用户数量为18人（包括组内成员8人），最终实现了22人的用户量，有部分新增用户。
　　3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
　　　　用户量和用户对重要功能的接受程度和我们事先预想的一致。我们离目标更近了。通过用户的反馈情况来看，我们的需要做以下改进：
　　　　1、在计划实现具体功能之前，多采纳用户的意见和建议，这样可以提高用户的满意度。
　　　　2、没有明确了解用户对软件的真实想法，也没有很好的了解用户的需求。

　　　　#用户数量有微小增加，主要功能和本组预期一致。根据用户反馈报告，我们了解了很多不足的地方以及更新的需求。如果历史重来一遍，我们会针对用户的需求，完成更多的功能。比如：增加对字体的修改、增加对其他类型文件的识别+添加。
二、计划
　　1、是否有充足的时间来做计划?
　　　　是，我们组有充足的时间来做计划。

　　　　#对，我们组讨论完成哪些计划、如何完成、分配任务的时间很充足，大家耐心细致的做了任务完成计划
　　2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
　　　　在Scrum master 的带领下，每位组员发表自己的观点和建议，将观点分类，再对这些分类进行探讨，找出每一个分类的优缺点，最后将矛盾化整为零，意见统一。

　　　　#每次立会的Scrum master都不同，大家轮流担任这个角色。除了商讨以外，更多的时候按照“you can you up,no can no BB.”的原则进行。针对不同的功能，提出设想是好的，但是完成设想相对比较困难。所以，可以完成代码实际操作、完成视频实际制作、完成文档编写的同学，拥有更多的话语权。可以有观点，提出观点的负责完成。
　　3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
　　　　原计划的工作都做完了。本阶段总共共有7个计划，都是按时完成。

　　　　#计划中的事情都做完了，在Beta阶段总共有7个大的计划，（小的计划过于零碎，没有记录数量），计划中的任务都按时完成
　　4、有没有发现你做了一些事后看来没必要或没多大价值的事?
　　　　没有，做了的工作都有价值，尽管看起来是没有用处的功能，但它依旧是有意义的。

　　　　#没有。每一件事的存在一定是有意义、有价值的。但是有的价值大，有的价值小。也许很多用户都没有注意到不同格式文件读取这个功能的添加，（因为他们手头可能只有.txt类型的电子书，没有其他格式的）所以他们仅仅能从“新增功能列表”中发现我们的软件的完善。但是在开发团队看来，我们这么做是有意义的，因为会有不同格式的文本文本件存在，我们增加对同文本的支持就有必要，有意义。
　　5、是否每一项任务都有清楚定义和衡量的交付件?
　　　　有比较清楚的定义和衡量的交付件。

　　　　#每一件任务都有清楚的定义。和“可以衡量”的交付件。

　　　　#这句话有歧义吧，应该是我语文没有学好。我的第一个理解是这样的：“清楚定义和衡量”作为形容词，修饰“交付件”；第二个理解是这样的：“清楚”形容“定义”，“衡量”形容“交付件”。但不管怎么说我依旧认为应该是“可衡量”而不是“衡量”。
　　6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
　　　　整个过程都按照计划进行，项目没有特别的意外。在“本地导入”功能的实现中，将本地的很多文档扫描出来，没有具体的分类，导致查找文档费时费力。在进行新功能“识别人脸”的开发过程中，遇到了技术难题，这是考虑到的可能出现的问题。

　　　　#在alpha阶段发生的事情Beta阶段没有发生。我们已经不再提出“看起来十分困难”的计划。所有计划都是有计划如何实现，才把它列为计划，而不是想到有新的功能就把它列为计划。不过在完成针对“pdf”等多种格式的支持后，忘记了增加对新增支持文本的添加书架操作。这在用户体验中被及时的指出了。这个原因是我们仅仅计划“支持阅读”，没有“支持将其添加到书架”。但是用户不这么想，他们希望可以看到自己喜欢的pdf文件也在书架上。

　　7、在计划中有没有留下缓冲区，缓冲区有作用么?
　　　　没有留下缓冲区。计划的时候没有考虑缓冲区。

#在本阶段的计划过程中，我们依旧没有考虑缓冲区。所以目前我们没有了解到缓冲区的作用。
　　8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
　　 　 所有计划要具体落实到每一位成员上，按时完成任务，整体计划中加入缓冲区进行测试，提前发现问题并解决问题。

　　　　#将来的计划，（当时）只有一周final发布，大家根据分工完成总结+完成新分配的任务。不需要加班，大家都在期待的时间内完成任务就可以了。
　　9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　　 首先，制定好所有计划，严格按照计划实施。每天都要开Scrum会议，每位组员都要好好总结自己遇到的困难，分享经验。杜绝一切消极态度。

　　　　#本次Beta发布，对于我们来讲，学到的东西，主要在于“充分准备+应对突发情况”。二维码期限只有1天是我们没有发现的，所以才出现了扫描二维码找不到下载文件的情况，当时及时在群内上传了app安装包。
三、资源
　　1、我们有足够的资源来完成各项任务么?
　　　　没有足够的资源。因为大部分小组成员对安卓开发完全不知，都在不断的努力学习。

　　　　#经过2周的开发，代码主干力量已经熟悉了安卓开发的知识，其余成员也不断跟进。
　　2、各项任务所需的时间和其他资源是如何估计的，精度如何?
　　　　 根据大家自我陈述的学习能力和对安卓知识掌握程度来估计所需时间。基本都能在规定的时间内完成。

　　　　#由完成该任务的成员确定，资源主要是自己要用的电脑和相关的学习资料。优先必须使用的同学使用：比如做视频渲染过程就需要配置高的电脑。那这样的电脑将不用于软件开发。时间方面是根据自己能力进行估计和计算。精度在小时这个程度上。
　　3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
　　　　没有缓冲区，所以没测试。
　　　　低估了难度，美工其实不简单啊，结果和预期不一致。发布的模式及设计也是很重要的一部分。

　　　　#人力是足够的，硬件资源也是足够的。美工的不一致体现在图标、进入后界面背景、整体软件主题等方面。这部分的难度低估了。　　
　　4、你有没有感到你做的事情可以让别人来做（更有效率）?
　　　　有。熟悉安卓开发的同学实现一些功能要比我实现这些功能的效率高很多。

　　　　#就撰写这个报告这份工作来说，如果让不同分工的同学完成不同的部分效果会更好。但是总结所有同学的感觉，这样的任务我还是可以胜任的。整体来讲我们没有这样的感觉，因为任务不是硬性分配的，而是大家自己选择的，所以大家都选择的是自己想做的和认为自己能做好的。
　　5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
　　　 了解自己拥有的资源，好好分配资源，了解相关的技术难度和重点。

　　　　#经历过的问题才知道之后如何避免。周三才拿出了可以用于展示的版本，生成了二维码。所以距离展示不足二十四小时，这时候就没有机会知道“二维码有效期是24小时”这样的问题存在。只有用户反应了界面、图标不好看，才想到要修改。问题只有暴露出来才会让大家知道，如果再来一遍，我们会减少这类的小失误。
四、变更管理
　　1、每个相关的员工都及时知道了变更的消息?
　　 　　 变更的消息是小组成员在一起时讨论的，所以变更的消息大家都能及时了解。但有的时候同学不一定能及时的看到消息，所以只能在立会的时候再次说明。

　　　　#但有的时候同学不一定能及时的看到消息，所以只能在立会的时候再次说明。
　　2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
　　　　根据实现功能的难度和用户需求来决定。简单的必须要实现，用户需求度不高且难度大的推迟实现。基础功能不推迟实现，时间不够的情况下才会推迟实现。

　　　　#与之前的想法相同
　　3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
　　　　有，预期功能都基本实现就算做好了。

　　　　#有，举个例子，可以正常读取pdf文件，就算是该功能的“出口条件”。
　　4、对于可能的变更是否能制定应急计划?
　　　　未能做出应急计划，因为我们未想到一些紧急情况。

　　　　#做出了，但是效果不好。上传app安装包到用户体验群，但是只有“有app的”同学才在群里，所以传了也没用，当时没有找到班级群（群太多了，时间紧没找到）。这个是展示的过程中的应急。代码编辑阶段没有“突然新增”等“需要应急”的情况发生。
　　5、员工是否能够有效地处理意料之外的工作请求？
　　　　按照原计划实施，无意外的工作请求。

　　　　#大家都在及时的想办法，但是没有有效处理。
　　6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　　提前考虑到变更情况，并作出相应的应急计划。对意外情况进行防范，并考虑是否添加心计划。

　　　　#应急情况会发生，能及时处理才是最好的。当然能避免，比让它发生更好。历史重来一遍，我们不会让它发生。
五、设计/实现
　　1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
　　　　是在alpha发布之前完成的，设计工作是由小组成员一起讨论得出的。是合适的时间，合适的人。
　　2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
　　　   有，设计“实现翻页效果”功能时出现模棱两可的情况。在Scrum Master的带领下，讨论出该功能的存在价值，最终决定实现该功能。

　　　　#有，在讨论实现支持几种文件的过程中就遇到了类似的情况。可以完成该项任务的成员决定计划，其余的成员的意见仅仅作为参考。
　　3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

　　　　 没有用过。

　　　　#本次冲刺阶段我们依旧没有使用“单元测试”方案。个人认为是有效的，但是不是所有有效的东西都可以真实的贴合与实际。我们没有完成单元测试模块，的主要原因在于，我们将时间花费在了开发的具体项目上，而在课题要求中没有要求“先使用单元测试再开发”或者“根据上一次事后诸葛亮会议的不足，有哪些改进”这类的任务。所以没有使用
　　4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
　　 　　“实现翻页效果”功能Bug最多。因为要涉及到触屏，所以具体实现起来有很多困难。刚开始单纯的认为，该功能特别简单。

　　  　　#修改：本次讨论中代码开发人员提到完成“QQ书友群”时的bug较多。主要是连接模块中的代码总是出错，不能及时跳转到QQ。
　　5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
　　 　　没有进行代码复审，代码不规范。

　　　　#本题回答类似于第3题。完成代码的部分是几个同学分别完成的，所以各自完成各自模块之后，就整合到一起了。完成功能后就没有针对代码的维护工作。这是我们需要改进的地方。
　　6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　 考虑好各种Bug出现的情况，要对程序进行单元测试，要进行代码复审，要让代码规范。

　　　  #设计与实现部分，主要学到了真实的开发经验。但是对于“测试驱动开发”、“代码规范”、“合作编程”等方面的任务我们没有很好的完成。所以如果历史重来，我们会加强这部分的应用。

六、测试/发布
　　1、团队是否有一个测试计划？为什么没有？
　　　　没有测试计划，未考虑到。

　　　　#发布日期前，每个功能是不断完善的，没有整合到一起。每位同学手头都有着自己的任务。只有临近发布日期，才遇到了需要测试的需求。但是已经发布了。与其说“未考虑到”更多的是没时间考虑“测试”这个事情。当然，不能因为“书本上说过，发布前应该进行大量测试”我们就真的能在发布前想到这个问题。真实做完了程序、发布时遇到了各种问题，才让我们意识到“测试的重要性”。
　　2、是否进行了正式的验收测试？
　　　　没有进行正式的验收测试，仅在课堂上演示了一下实现的功能。

　　　　#针对每一个功能，我们都进行了测试，看看是否达到预期的效果。但是不正式，也并不是非常完备的“验收测试”，完成功能就算完成了。
　　3、团队是否有测试工具来帮助测试？
　　　　虚拟机、手机。

　　　　#用过测试工具完成测试：废弃的安卓手机、电脑中装的虚拟手机等。
　　4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
　　　　只在虚拟机和手机上进行了测试，未进行测量并跟踪软件。有用，多运用测量和跟踪软件，提早找出问题并能及时解决。比如现在就发现在部分版本的安卓手机上存在界面显示不全的问题。

　　　　#仅仅在手机和电脑上的虚拟机中进行了测试，并没有进行多机真实跟踪测试软件。测试工作是有必要的，真机实际测试也是有必要的。比如现在就发现在部分版本的安卓手机上存在界面显示不全的问题。
　　5、在发布的过程中发现了哪些意外问题？
　　 　　没有足够多的客户参与互动（发送反馈意见到后台赢取奖品）。课前准备的安装链接刚好失效。
　　6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　　 测试很重要，要学会用一些有助于优化功能的软件帮助我们改进。计划也非常重要，每一部分的功能最好都分配给一个同学负责测试。
七、团队的角色，管理，合作
　　1、团队的每个角色是如何确定的，是不是人尽其才？
　　　　根据每个人的学习能力和拥有的技术能力，做到人尽其才。

　　　　#在讨论任务分配的过程中，大家一起商讨有哪些需要完成的任务，之后才根据任务确定每个成员完成什么工作。所以角色是由任务和自己意愿决定的，所以做到了人尽其才。
　　2、团队成员之间有互相帮助么？
　　　　团队成员有相互帮助。

　　　　#互帮互助是当然存在的，当新成员加入群组后，组内成员就积极的培训新成员熟悉安卓开发环境。
　　3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
　　　　各自表述自己的想法，取利益最大的方案。

　　　　#印象里并没有出现很严重的问题，除了各自说各自的想法外，由组长协商、协调也是切实有效的手段。
        4、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

　　　　李传康：http://www.cnblogs.com/lick468/p/7922334.html

　　　　杨梓瑞：http://www.cnblogs.com/vector121/p/7922354.html

　　　　翟宇豪：http://www.cnblogs.com/-Rio56/p/7922595.html

　　　　王    航： http://www.cnblogs.com/wangh013/p/7923251.html

 

　　　4、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
　　　　做到人尽其能。做到更好的协商统计。做好计划。

　　　　 #测试发布阶段，我们没有及时做好测试，分布过程也有小瑕疵，但这并不影响我们团队的团结与努力。只有经历过挫折才会让大家更紧密。历史重来一遍，我们会预留测试的时间。

八、总结
　　1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

　　　　属于CMM阶段。

　　　　#目前处在第二级~第三级之间：可重复级与已定义级之间。这2个级别的内容展示如下。

　　　　可重复级：基于类似项目中的经验，建立了基本的项目管理制度，采取了一定的措施控制费用和时间。管理人员可及时发现问题，采取措施。一定程度上可重复类似项目的软件开发。

　　　　已定义级：已将软件过程文档化、标准化，可按需要改进开发过程，采用评审方法保证软件质量。可借助CASE工具提高质量和效率。
　　2、你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?
　　　　我们团队处于规范阶段。
　　3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
　　　　知道要用软件来对程序进行测试，多沟通，人尽其能。

　　　　#团队更加团结了，分工也更加明确，改进在于，大家知道自己要做什么，想做什么，会做什么。
　　4、你觉得目前最需要改进的一个方面是什么?
　　　　根据进度及时调整功能，有些过于复杂的功能就暂缓制作，优先核心功能。设计计划方面，关注用户需求，根据他们的需求和意见修改计划。
　　5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
　　　　“以有进取心的人为项目核心，充分支持信任他们”。我们都在规定的时间完成任务，互相信任。每个同学都有机会选择自己喜欢的任务去做，在商议后确定任务分配。

　　　　#最好的构架、需求和设计出自于自组织的团队。这一点本文作者深有体会。目前衡量某个组是否有“更优秀”的作品的重要标准就是本门课程的成绩。据我所知，这2个团队在软件工程课程初期就已经有意愿结成团队完成任务了。这就是“自组织”的优势所在。
九、全组讨论的照片

 致歉：因为翟宇豪（楼主）个人原因，导致团队所有成员的该项作业分数（100分）被倒扣，与其他同学分差差值为200分，深表歉意。错了就要改正，每一次错误都是自己前进路上需要经历的过程，十分感谢大家的包容。今天花费了约180分钟重新仔细完成了本次作业，践行“及时改正是一种态度”的信念。

解释：所有黄色底纹的内容均是与alpha事后诸葛亮会议不相同的表述。