软工 · 第十一次作业 - Alpha 事后诸葛亮（团队）
组长本次作业链接
现代软件工程 项目Postmortem
-
设想和目标
-
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- A：我们的软件要解决的是结对人的互相提醒的问题，对这个对这个问题定义的很清晰。主要是针对团队，研友，情侣或者亲子，要结对人都关闭闹钟，软件才会停止工作，以达到相互提醒的作用。例如相互约好去学习，设置闹钟，醒来的人可以根据软件的提示知道另一个人是否已经醒来，如果未醒，则可以根据软件设置的提醒方式来提醒对方。
-
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?
- A：我们还未完全达成目标，原定的功能只实现了两个，未能按照原定计划交付。由于未完成整体软件，所以目前还没有任何用户。
-
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- A：由于未对软件进行发布，所以用户量和用户对功能的接受程度无法估计，所以我们并没有离目标更近。
-
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- A：在交付软件之前，所有人都要有紧迫感，要有压力，有适当的压力才会有动力，才能更好的完成软件。如果历史重来，我们将制定严格的计划进程，将任务落实，给予所有人适当的压力，在deadline前完成软件。
-
计划
-
1.是否有充足的时间来做计划?
- A：在Alpha冲刺开始之前，大家的大致分工任务便已分配下去，因此开始各自学习开发所要用到的技术、工具等。Alpha冲刺开始之后，会议讨论上大家一致达成在Alpha冲刺结束前实现基础功能的计划，转而进入了Learning by doing的状态。而后由于各自的任务不同，主要是各自制定个人的规划。
-
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
-
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- A：
有的完成了，有的暂未完成。
时间上，在Alpha冲刺中后期有期末考试，一定程度上被剥削了一些时间，导致计划没有实现；
技术上，团队成员之前并没有使用过相应的开发工具，开发语言也基本没有接触，心有余而力不足，技术不够导致一些问题难以解决，原定计划没有实现；
经验上，缺少开发经验，不知先做什么再做什么，效率降低。
-
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
- A：首先是Alpha冲刺初期，算法很多是靠自己设计，代码全程靠自己手写，又由于技术受限经常卡住导致浪费了很多时间，后来懂得借鉴前人的优秀作品，站在巨人的肩膀上，效率得到了提高；再者是缺少经验，提前学习了某些技术但在实际开发中并没有用到，对此次开发而言浪费了时间。
-
5.是否每一项任务都有清楚定义和衡量的交付件?
- A：一开始并没有仔细考虑这个问题，导致最后各部分整合的时候出了些问题。
-
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- A：并没有都按照计划，有的部分由于技术等原因暂未实现。
没有估计到的风险是软件工程比想象中的困难，不管是时间上需要更长还是技术上需要更多。原因一是计划没有制定好，导致后期做的事情比前期多，先甜后苦；二是缺少开发经验，不能很好估计难度。
-
7.在计划中有没有留下缓冲区，缓冲区有作用么?
- A：没有留下，只是计划在Alpha冲刺结束前实现基础功能。
-
8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- A：会计划提前一天或两天完成，以留下伸缩的余地，解决一些突发事件等。
以及会更多考虑短期计划的制定，减少拖延症的发生。
-
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- A：
制定计划不要刚刚好，应该要有缓冲的余地，否则遇到问题将会很头疼；同时也要考虑制定短期计划，否则容易拖延导致最终计划不能实现。如果历史重来一遍，我们会决定在Alpha冲刺结束前一天实现我们的计划，同时会细分计划，做短期计划制定，循序渐进。
-
资源
-
1.我们有足够的资源来完成各项任务么?
- A：网上的安卓资源充足，我们有足够的资源来完成各项任务。
-
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
- A：各项任务所需的时间和资源是根据大家公认的难度来进行估计的，精度一般。
-
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- A：测试时间，人力和软件/硬件的资源不够充分，对于不需要编程的资源并没有低估难度。
-
4.你有没有感到你做的事情可以让别人来做（更有效率）?
- A：因为组内大家都是萌新，所有东西都要新学，所以大家的效率应该都是差不多的。
-
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- A：资源要充分的利用，要站在巨人的肩膀上来看世界。如果历史重来，我们要充分学习利用网上已有的项目资源应用到我们自己的项目上，这样会更具有效率，能更好的完成项目。
-
变更管理
-
1.每个相关的员工都及时知道了变更的消息?
- A：我们会在群内进行通知，并确保每个人都能知道并正确理解
-
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
- A：我们针对产品的核心定义进行筛选，分清核心功能和附带功能
-
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- A：我们产品的出口条件是：具备能够正常运作的核心功能
-
4.对于可能的变更是否能制定应急计划?
- A：若出现突发变更，我们会根据项目当前的状况和剩余时间制定应急计划
-
5.员工是否能够有效地处理意料之外的工作请求？
- A：若出现意料之外的工作请求，我们会制定应急计划，让员工尽可能有效地处理
-
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- A：这次alpha冲刺体验，具有重要意义，也收获颇丰，不管是技术方面，还是团队写作方面，但是我们也还有许多不足之处，如果历史重来一遍，我们就能多避免出错，并有更好的安排计划
-
设计/实现
-
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- A：设计工作是在小组会议上不断讨论决定的。由组长牵头讨论，大家共同商讨，最后由组长决定。时间一般是晚上9点过后，这时候大家都在宿舍。
-
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- A：有碰到过。早期关于关联闹钟的取消方式团队有过争议。最终采取少数服从多数的办法解决。
-
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- A：
团队使用了UML来对需求和软件功能进行分析。使用单元测试，对已实现的函数进行测试。这些工具很有效。UML工具帮我们更加明确了需求，系统功能，类间关系等等，使我们对于软件的开发有更清晰的逻辑。单元测试帮助我们在开发过程中及时排错，更轻松地排错。
-
4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- A：
没有区别。项目开始后还未对UML文档进行过更新。
-
5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- A：在用户交互的过程中产生的Bug最多。因为涉及到多个用户，每个用户有着不同的操作，控制复杂。系统发布后发现，用户只有在重新登录后才能收到新消息。这个原因在于我们在开发的过程中，没有考虑到两个用户同时在线的情况。
-
6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- A：代码会由队长进行审核，主要要求规范命名和接口。
-
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- A：
我们刚开始学习软件开发，要多花时间在学习编程上。如果历史重来一次，我们会在更加花时间在软件开发上，更完善地完成Alpha版本的设计。
-
测试/发布
-
1.团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
- A：有一个比较简单的测试计划，主要由于团队中也没有比较有经验的人，也没有进行比较完整的规划。
-
2.团队是否有测试工具来帮助测试？
- A：有试着用测试工具帮助测试，但基本都是靠自己研究探索，毕竟缺乏经验。没有进行正式的验收测试，就目前完成的软件来说，仍存在着一些小小的问题，也还没有达到令人满意的程度，因此还在尝试完善优化软件。
-
3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- A：测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从软件本身出发，争取能更优化下用户体验。
-
4.在发布的过程中发现了哪些意外问题？
- A：发布的过程中，也是因为网络的问题，没有统一规范的原因，导致了最终代码整合的时候出现了难以解决的困难，基本上每次遇到的困难都是新的困难，都是令人意外的，之前没出现过的问题。
-
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- A：软件的开发过程中，测试这一环节是必不可少的。一款软件即使测试完毕发布后，仍然会出现或多或少的问题，而这就体现了在测试环节你付出了多少，就决定了你最后遇到的问题是大是小。而测试也是需要有技巧性，有针对性的去测试你的软件，而不能照搬其他人的测试方式，软件都有各自独有的特点。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。
-
团队的角色，管理，合作
-
1.团队的每个角色是如何确定的，是不是人尽其才？
- A：有某方面基础的组员优先安排，有意愿做某方面的组员优先安排。由于团队基本处于零基础状态，所以是否人尽其才无法回答
-
2.团队成员之间有互相帮助么？
-
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- A：当出现这方面的小问题时，我们会在群内交流，提出各自的看法，当问题较大时，我们会召集开会，商讨解决方案
我感谢乐中豪对我的帮助， 因为某个具体的事情:帮助我进行工具所需环境的配置_。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
总结:
-
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- A：我觉得团队目前的状态还处于第一档次，即初始级。也是刚刚起步，正学会走路但是走的不快的状态。
-
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- A：我觉得团队现在刚刚要从磨合阶段跨出去，走向规范阶段。
-
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- A：相比于前一个里程碑，团队现在在队员沟通这方面做得更好了，基本上遇到难以独自解决的问题都会是多人一起合力解决，不再像当初自己一个人埋头苦干，独自探索了。
-
4.你觉得目前最需要改进的一个方面是什么?
- A：目前最需要改进的地方是，团队没有一个比较核心的人物，比如有丰富的开发软件的经历，能够很好的解析并安排工作的巨人，需要一个这样的巨人的肩膀。
-
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- A：做得比较好的敏捷开发的原则有
面对面交谈
每隔一段时间反省自己，并作出相应调整
围绕有积极性的个人构建项目，并且信任他们能够完成工作。
主要在Alpha冲刺阶段，两天一次的站立会议会督促着每个人是否有积极完成自己的任务，而且本组成员基本上的基础都是比较少的，每个人都会遇到大大小小的问题，解决这些问题只有当面交流，现场调试修改的效率才是最高的。而在这个项目中，基本也是围绕着学习能力比较强的大佬们，辅助他们来完成主要的功能。当然除此之外，合作的部分也是占着很重的比例。
答辩总结
贡献比例
| 组员 |
工作比例 |
工作内容 |
| 白晨曦 |
0 |
答辩工作准备与前端制作 |
| 乐忠豪 |
0.12 |
数据库搭建与后端指导 |
| 蔡子阳 |
0.12 |
接口制作与前端对接 |
| 黄培鑫 |
0.12 |
前端制作 |
| 李麒 |
0.12 |
接口制作与服务器搭建 |
| 王焕仁 |
0.14 |
前端制作 |
| 陈德斌 |
0.11 |
前端制作 |
| 林志华 |
0.15 |
前端制作（主要功能的完成） |
| 何裕捷 |
0.12 |
前端制作 |
工作流程
- 我们组的情况挺特殊的，可能是所有组里面技术能力最差的一组（只是针对于本次作业），面对这个问题，我们并没有立马开工进行制作，而是先进行学习（当然是在分好大类前端后端之后），利用了2次的博客报告时间（四天）进行学习和讨论。具有一定基础之后，我们展开了细节商定大会，先进行自己的学习报告，前后端交流，商讨前端界面的一些细节，功能如何实现等等，之后根据个人的能力来领取任务，对前端后端进行详细分工。在基本确定所要制作的内容后，开始赶进度，期间经常一起出来肝软工，有的人在部分前端制作完成后，帮助其他有困难的人进行制作。在所有分工完成后，进行整合，测试。
本组的现场答辩得分
平均分：68.67
其他组对本组提出的问题及本组回答
-
针对第一组问题：
-
项目进度似乎落后于Alpha前制定的目标,是否考虑在beta前继续完善产品?
- A:项目进度似乎落后于Alpha前制定的目标，对此我们感到十分抱歉，在beta冲刺前我们将会完成Alpha制定的目标。
-
产品的UI似乎缺少必要的风格统一,是否考虑后期统一一下?
-
后端如何保证同一时间提醒一个闹钟的各个关联用户,实现的原理是?
- A:这个和普通的闹钟实现原理是一样的，相当于每一个关联用户都有一个这样的闹钟。
-
针对第二组问题：
-
计划界面中的黄底是存在计划吗？黑字和红字是什么意思？
- A:黄底表示当天有团队计划，红字表示当天有个人计划，黑字表示当天无个人计划。这些在答辩过程中我们解释过了，请尊重演讲者。
-
计划界面中的日历和2018年11月的日历不相同，是还没完成吗？
-
计划是否也会响起闹钟？还是会弹出信息提示？
- A:计划本身并没有附加提醒功能，只有当关联上闹钟后才会弹出信息提示。
-
针对第三组问题：
-
忘记密码这一块如果手机也换了有考虑怎么解决吗
- A:我们的账户并不是绑定手机的，忘记密码的话可以通过邮箱找回或其他方法。
-
有考虑过如何调动组内积极性吗？如果有考虑好的话也可以给我们组一些建议
-
进度似乎有些堪忧，接下来有没有具体的计划与任务分配呢？
- A:接下来会完成Alpha定下的目标，其实我们的进度并没有落后很多。
-
针对第四组问题：
-
界面美观问题是如何解决的呢？
- A: 后期将会对界面经行美化，可能会参考一些当前热门的界面风格。
-
上次提到过的团队闹钟问题考虑如何解决吗？
- A: 闹钟发起者会将闹钟传到数据库中，团队中的其他人可从数据库获取闹钟，以此实现团队闹钟
-
无视频演示及现场演示，是否有动态可行式的演示视频？
-
针对第六组问题：
-
界面不够美观，颜色单调，怎么解决？
- A:后期将会对界面经行美化，可能会参考一些当前热门的界面风格。
-
如何处理闹钟之间关联的问题？
-
是否要重现面对打“0分”这一问题？
- A: 没错我们要重现面对打0分的问题，这次就打了零分，我求你看一看。
-
针对第七组问题：
-
如果手机默认闹钟设置的时间和你们的APP闹钟冲突了，会出现什么情况，你们怎么解决？
- A: 举个例子，比如你在听歌的过程中上优酷看视频，歌曲播放器将会暂停，我们这个闹钟也是一样的，后出现的会顶掉先出现的。
-
ui设计的日期选择界面配色不够美观,考虑再优化一下吗？
-
演示时并未展示视频,项目进度似乎不太好,有考虑如何加快开发进度吗？
-
针对第八组问题：
-
对于落下的进度准备如何弥补？
- A: 在Beta冲刺开始前，我们将补完Alpha冲刺落下的任务。
-
小组成员可能学习成本太高而在时间紧凑的情况下如何提升push到每一个人？
- A: 每一个人尽量不学习到重复的知识，然后互相交各自会的部分。
-
对于ui界面准备如何美化？
- A: 可能会参考一些当前热门的界面风格来进行美化UI。
-
针对第九组问题：
-
ui不够漂亮，是否有考虑过更简洁清楚的界面呢？
- A:UI确实不够漂亮，我们的界面已经算是比较简介的了，没有多余的东西。
-
有组员中途参加比赛，对于落下的进度，你们如何弥补？
- A: 在Beta冲刺开始前，我们将补完Alpha冲刺落下的任务。
-
对于目前实现的功能是否与做到了开始时想做的功能呢？
- A: 还有些差距，但我们将在Beta冲刺倾尽我们所能完成它。
-
针对关于零分的问题发起的对话
- 在答辩现场，有人提出了这个问题，我也做出了相应的回应，我说过给出零分的理由，也给出了后续调整的方案，但是你们貌似并没有认真听讲。在提问环节只是为了怼而怼。对于你们看不出前面几次作业的分数微调，我只能在这里用这种极端的方法来让你们明白。就是酱紫，不是所有人都是为了分数来做这个实践课的，我也不是什么魔鬼，谢谢————白晨曦
个人部分
PSP表格
| PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
| Planning |
计划 |
60 |
90 |
| · Estimate |
· 估计这个任务需要多少时间 |
60 |
90 |
| Development |
开发 |
370 |
460 |
| · Analysis |
· 需求分析 (包括学习新技术) |
120 |
150 |
| · Design Spec |
· 生成设计文档 |
30 |
30 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
0 |
0 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
| · Design |
· 具体设计 |
60 |
60 |
| · Coding |
· 具体编码 |
60 |
90 |
| · Code Review |
· 代码复审 |
10 |
10 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
100 |
120 |
| Reporting |
报告 |
30 |
30 |
| · Test Report |
· 测试报告 |
0 |
0 |
| · Size Measurement |
· 计算工作量 |
10 |
10 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
20 |
20 |
| 合计 |
|
460 |
580 |
学习进度条
| 第N周 |
新增代码（行） |
累计代码（行） |
学习小时数（小时） |
累计学习小时数（小时） |
重要成长 |
| 1 |
100 |
100 |
15 |
15 |
Axure的使用，设计文档的书写，复习了数据库的基本操作 |
| 3 |
1000 |
1100 |
25 |
40 |
Java基本语法，STL容器的使用 |
| 11 |
1568 |
2768 |
30 |
70 |
html,css,js学习，实战项目编写修改，sql server操作 |
| 12 |
300 |
3068 |
3 |
73 |
复习曾经学过的一些算法，及STL容器知识 |
| 13 |
400 |
3468 |
5 |
78 |
复习曾经学过的一些算法,java安卓基础开发 |
照片
