事后诸葛亮

软工 · 第十一次作业 - Alpha 事后诸葛亮（团队）

组长本次作业链接

现代软件工程 项目Postmortem

• 设想和目标

  • 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
    • A：我们的软件要解决的是结对人的互相提醒的问题，对这个对这个问题定义的很清晰。主要是针对团队，研友，情侣或者亲子，要结对人都关闭闹钟，软件才会停止工作，以达到相互提醒的作用。例如相互约好去学习，设置闹钟，醒来的人可以根据软件的提示知道另一个人是否已经醒来，如果未醒，则可以根据软件设置的提醒方式来提醒对方。
  • 2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?
    • A：我们还未完全达成目标，原定的功能只实现了两个，未能按照原定计划交付。由于未完成整体软件，所以目前还没有任何用户。
  • 3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
    • A：由于未对软件进行发布，所以用户量和用户对功能的接受程度无法估计，所以我们并没有离目标更近。
  • 4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    • A：在交付软件之前，所有人都要有紧迫感，要有压力，有适当的压力才会有动力，才能更好的完成软件。如果历史重来，我们将制定严格的计划进程，将任务落实，给予所有人适当的压力，在deadline前完成软件。

• 计划

  • 1.是否有充足的时间来做计划?
    • A：在Alpha冲刺开始之前，大家的大致分工任务便已分配下去，因此开始各自学习开发所要用到的技术、工具等。Alpha冲刺开始之后，会议讨论上大家一致达成在Alpha冲刺结束前实现基础功能的计划，转而进入了Learning by doing的状态。而后由于各自的任务不同，主要是各自制定个人的规划。
  • 2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
    • A：少数服从多数。
  • 3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    • A：

      有的完成了，有的暂未完成。

      时间上，在Alpha冲刺中后期有期末考试，一定程度上被剥削了一些时间，导致计划没有实现；

      技术上，团队成员之前并没有使用过相应的开发工具，开发语言也基本没有接触，心有余而力不足，技术不够导致一些问题难以解决，原定计划没有实现；

      经验上，缺少开发经验，不知先做什么再做什么，效率降低。

  • 4.有没有发现你做了一些事后看来没必要或没多大价值的事?
    • A：首先是Alpha冲刺初期，算法很多是靠自己设计，代码全程靠自己手写，又由于技术受限经常卡住导致浪费了很多时间，后来懂得借鉴前人的优秀作品，站在巨人的肩膀上，效率得到了提高；再者是缺少经验，提前学习了某些技术但在实际开发中并没有用到，对此次开发而言浪费了时间。
  • 5.是否每一项任务都有清楚定义和衡量的交付件?
    • A：一开始并没有仔细考虑这个问题，导致最后各部分整合的时候出了些问题。
  • 6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    • A：并没有都按照计划，有的部分由于技术等原因暂未实现。

      没有估计到的风险是软件工程比想象中的困难，不管是时间上需要更长还是技术上需要更多。原因一是计划没有制定好，导致后期做的事情比前期多，先甜后苦；二是缺少开发经验，不能很好估计难度。

  • 7.在计划中有没有留下缓冲区，缓冲区有作用么?
    • A：没有留下，只是计划在Alpha冲刺结束前实现基础功能。
  • 8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    • A：会计划提前一天或两天完成，以留下伸缩的余地，解决一些突发事件等。

      以及会更多考虑短期计划的制定，减少拖延症的发生。

  • 9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 制定计划不要刚刚好，应该要有缓冲的余地，否则遇到问题将会很头疼；同时也要考虑制定短期计划，否则容易拖延导致最终计划不能实现。如果历史重来一遍，我们会决定在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, 或者其他工具来帮助设计和实现？这些工具有效么？
    • 团队使用了UML来对需求和软件功能进行分析。使用单元测试，对已实现的函数进行测试。这些工具很有效。UML工具帮我们更加明确了需求，系统功能，类间关系等等，使我们对于软件的开发有更清晰的逻辑。单元测试帮助我们在开发过程中及时排错，更轻松地排错。
  • 4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
    • 没有区别。项目开始后还未对UML文档进行过更新。
  • 5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
    • A：在用户交互的过程中产生的Bug最多。因为涉及到多个用户，每个用户有着不同的操作，控制复杂。系统发布后发现，用户只有在重新登录后才能收到新消息。这个原因在于我们在开发的过程中，没有考虑到两个用户同时在线的情况。
  • 6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
    • A：代码会由队长进行审核，主要要求规范命名和接口。
  • 7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 我们刚开始学习软件开发，要多花时间在学习编程上。如果历史重来一次，我们会在更加花时间在软件开发上，更完善地完成Alpha版本的设计。

• 测试/发布

  • 1.团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
    • A：有一个比较简单的测试计划，主要由于团队中也没有比较有经验的人，也没有进行比较完整的规划。
  • 2.团队是否有测试工具来帮助测试？
    • A：有试着用测试工具帮助测试，但基本都是靠自己研究探索，毕竟缺乏经验。没有进行正式的验收测试，就目前完成的软件来说，仍存在着一些小小的问题，也还没有达到令人满意的程度，因此还在尝试完善优化软件。
  • 3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
    • A：测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，改进主要还是从软件本身出发，争取能更优化下用户体验。
  • 4.在发布的过程中发现了哪些意外问题？
    • A：发布的过程中，也是因为网络的问题，没有统一规范的原因，导致了最终代码整合的时候出现了难以解决的困难，基本上每次遇到的困难都是新的困难，都是令人意外的，之前没出现过的问题。
  • 5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • A：软件的开发过程中，测试这一环节是必不可少的。一款软件即使测试完毕发布后，仍然会出现或多或少的问题，而这就体现了在测试环节你付出了多少，就决定了你最后遇到的问题是大是小。而测试也是需要有技巧性，有针对性的去测试你的软件，而不能照搬其他人的测试方式，软件都有各自独有的特点。如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，并分配给多人重复测试，争取减少发布后遇到的问题。

• 团队的角色，管理，合作

  • 1.团队的每个角色是如何确定的，是不是人尽其才？
    • A：有某方面基础的组员优先安排，有意愿做某方面的组员优先安排。由于团队基本处于零基础状态，所以是否人尽其才无法回答
  • 2.团队成员之间有互相帮助么？
    • A：团队成员注重交流，互帮互助，一直是我们的作风
  • 3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
    • A：当出现这方面的小问题时，我们会在群内交流，提出各自的看法，当问题较大时，我们会召集开会，商讨解决方案
  • 我感谢蔡子阳对我的帮助， 因为某个具体的事情:我们共同写的后端。
  • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 总结:

  • 1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    • A：我觉得团队目前的状态还处于第一档次，即初始级。也是刚刚起步，正学会走路但是走的不快的状态。
  • 2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
    • A：我觉得团队现在刚刚要从磨合阶段跨出去，走向规范阶段。
  • 3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
    • A：相比于前一个里程碑，团队现在在队员沟通这方面做得更好了，基本上遇到难以独自解决的问题都会是多人一起合力解决，不再像当初自己一个人埋头苦干，独自探索了。
  • 4.你觉得目前最需要改进的一个方面是什么?
    • A：目前最需要改进的地方是，团队没有一个比较核心的人物，比如有丰富的开发软件的经历，能够很好的解析并安排工作的巨人，需要一个这样的巨人的肩膀。
  • 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

    • A：做得比较好的敏捷开发的原则有

      面对面交谈

      每隔一段时间反省自己，并作出相应调整

      围绕有积极性的个人构建项目，并且信任他们能够完成工作。

      主要在Alpha冲刺阶段，两天一次的站立会议会督促着每个人是否有积极完成自己的任务，而且本组成员基本上的基础都是比较少的，每个人都会遇到大大小小的问题，解决这些问题只有当面交流，现场调试修改的效率才是最高的。而在这个项目中，基本也是围绕着学习能力比较强的大佬们，辅助他们来完成主要的功能。当然除此之外，合作的部分也是占着很重的比例。

答辩总结

贡献比例

组员	工作比例	工作内容
白晨曦	答辩工作准备与前端制作
乐忠豪	0.12	数据库搭建与后端指导
蔡子阳		接口制作与前端对接
黄培鑫		前端制作
李麒		接口制作与服务器搭建
王焕仁	0.14
陈德斌	0.11
林志华	0.15	前端制作（主要功能的完成）
何裕捷

工作流程

• 我们组的情况挺特殊的，可能是所有组里面技术能力最差的一组（只是针对于本次作业），面对这个问题，我们并没有立马开工进行制作，而是先进行学习（当然是在分好大类前端后端之后），利用了2次的博客报告时间（四天）进行学习和讨论。具有一定基础之后，我们展开了细节商定大会，先进行自己的学习报告，前后端交流，商讨前端界面的一些细节，功能如何实现等等，之后根据个人的能力来领取任务，对前端后端进行详细分工。在基本确定所要制作的内容后，开始赶进度，期间经常一起出来肝软工，有的人在部分前端制作完成后，帮助其他有困难的人进行制作。在所有分工完成后，进行整合，测试。

本组的现场答辩得分

平均分：68.67

其他组对本组提出的问题及本组回答

• 针对第一组问题：
  • 项目进度似乎落后于Alpha前制定的目标,是否考虑在beta前继续完善产品?
    • A:项目进度似乎落后于Alpha前制定的目标，对此我们感到十分抱歉，在beta冲刺前我们将会完成Alpha制定的目标。
  • 产品的UI似乎缺少必要的风格统一,是否考虑后期统一一下?
    • A:后期我们将会对页面经行一个统一的美化。
  • 后端如何保证同一时间提醒一个闹钟的各个关联用户,实现的原理是?
    • A:这个和普通的闹钟实现原理是一样的，相当于每一个关联用户都有一个这样的闹钟。
• 针对第二组问题：
  • 计划界面中的黄底是存在计划吗？黑字和红字是什么意思？
    • A:黄底表示当天有团队计划，红字表示当天有个人计划，黑字表示当天无个人计划。这些在答辩过程中我们解释过了，请尊重演讲者。
  • 计划界面中的日历和2018年11月的日历不相同，是还没完成吗？
    • A:兄弟，你是在搞笑吗？哪里不一样了？
  • 计划是否也会响起闹钟？还是会弹出信息提示？
    • A:计划本身并没有附加提醒功能，只有当关联上闹钟后才会弹出信息提示。
• 针对第三组问题：
  • 忘记密码这一块如果手机也换了有考虑怎么解决吗
    • A:我们的账户并不是绑定手机的，忘记密码的话可以通过邮箱找回或其他方法。
  • 有考虑过如何调动组内积极性吗？如果有考虑好的话也可以给我们组一些建议
    • A:请喝奶茶。
  • 进度似乎有些堪忧，接下来有没有具体的计划与任务分配呢？
    • A:接下来会完成Alpha定下的目标，其实我们的进度并没有落后很多。
• 针对第四组问题：
  • 界面美观问题是如何解决的呢？
    • A: 后期将会对界面经行美化，可能会参考一些当前热门的界面风格。
  • 上次提到过的团队闹钟问题考虑如何解决吗？
    • A: 闹钟发起者会将闹钟传到数据库中，团队中的其他人可从数据库获取闹钟，以此实现团队闹钟
  • 无视频演示及现场演示，是否有动态可行式的演示视频？
    • A: 后期会补上视频。
• 针对第六组问题：
  • 界面不够美观，颜色单调，怎么解决？
    • A:后期将会对界面经行美化，可能会参考一些当前热门的界面风格。
  • 如何处理闹钟之间关联的问题？
    • A:闹钟之间并没有关联，是闹钟关联计划。
  • 是否要重现面对打“0分”这一问题？
    • A: 没错我们要重现面对打0分的问题，这次就打了零分，我求你看一看。
• 针对第七组问题：
  • 如果手机默认闹钟设置的时间和你们的APP闹钟冲突了，会出现什么情况，你们怎么解决？
    • A: 举个例子，比如你在听歌的过程中上优酷看视频，歌曲播放器将会暂停，我们这个闹钟也是一样的，后出现的会顶掉先出现的。
  • ui设计的日期选择界面配色不够美观,考虑再优化一下吗？
    • A: 配色方面我们后期可能会去修改优化一下。
  • 演示时并未展示视频,项目进度似乎不太好,有考虑如何加快开发进度吗？
    • A: 我们这两天已经有在加快开发进度了。
• 针对第八组问题：
  • 对于落下的进度准备如何弥补？
    • A: 在Beta冲刺开始前，我们将补完Alpha冲刺落下的任务。
  • 小组成员可能学习成本太高而在时间紧凑的情况下如何提升push到每一个人？
    • A: 每一个人尽量不学习到重复的知识，然后互相交各自会的部分。
  • 对于ui界面准备如何美化？
    • A: 可能会参考一些当前热门的界面风格来进行美化UI。
• 针对第九组问题：
  • ui不够漂亮，是否有考虑过更简洁清楚的界面呢？
    • A:UI确实不够漂亮，我们的界面已经算是比较简介的了，没有多余的东西。
  • 有组员中途参加比赛，对于落下的进度，你们如何弥补？
  • 对于目前实现的功能是否与做到了开始时想做的功能呢？
    • A: 还有些差距，但我们将在Beta冲刺倾尽我们所能完成它。
• 针对关于零分的问题发起的对话
  • 在答辩现场，有人提出了这个问题，我也做出了相应的回应，我说过给出零分的理由，也给出了后续调整的方案，但是你们貌似并没有认真听讲。在提问环节只是为了怼而怼。对于你们看不出前面几次作业的分数微调，我只能在这里用这种极端的方法来让你们明白。就是酱紫，不是所有人都是为了分数来做这个实践课的，我也不是什么魔鬼，谢谢————白晨曦

个人部分

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning		60	90
· Estimate	· 估计这个任务需要多少时间
Development	开发	370	460
· Analysis	· 需求分析 (包括学习新技术)	120	150
· Design Spec	· 生成设计文档	30
· Design Review	· 设计复审 (和同事审核设计文档)
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)
· Design	· 具体设计
· Coding	· 具体编码
· Code Review	· 代码复审	10
· Test	· 测试（自我测试，修改代码，提交修改）	100
Reporting	报告
· Test Report	· 测试报告
· Size Measurement	· 计算工作量
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	20
合计		580

学习进度条

第N周	新增代码(行)	累计代码(行)	本周学习耗时(小时)	累计学习耗时(小时)	重要成长
1	200		6		Java复习
2		15	21	学习Axure RP8
3		400		31	Java学习
4		工具学习
5
		后台搭建学习
7		800		后台搭建
8	270	1070

照片