事后诸葛亮

作业链接
现在软件工程讲义 11 项目管理 - 事后诸葛亮会议

前言

事后诸葛亮，望文生义；可知这是为了让我们反思前一阶段的不足，进行总结，然后对下一阶段进行规划。

软件工程课的目的，主要让大家通过做项目，学到软件工程的知识，而不是低水平的重复，有些团队在alpha阶段用比较低水平的方法做了几个功能，beta阶段还是如此的画，就会感觉失去了学习的机会，宁可少做一些功能，也要把单元测试，架构，代码规范等提高。

软件 = 程序 + 软件工程，

软件的质量 = 程序的质量 + 软件工程的质量

会议

设想和目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 软件是用来帮助用户记录自己的出行路线的，此外还可以分享自己的路线。
• 典型用户：18-28岁的，具有照顾好自己能力的人。
• 典型用户场景：小明是一个刚刚毕业的高中生，暑假计划出去旅游，但是在百度中寻找大量的出行攻略实在是太烦人了。美团中对各地的景点美食评论也是千奇百怪，眼花缭乱。选定了这些地点后还要自己把自己想去的地方穿起来，制定计划，实在是工作量巨大。”一步“可以帮您解决这些问题，用户分享自己的路线，供给别人参考，自己进行选择和尝试。

2、我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）

• 原计划的功能
  • 已实现
    • 登陆注册功能
    • 路线记录功能
  • 未实现的功能
    • 路线分享功能
    • 心愿单功能
    • 发现功能
• 未能按照原计划交付时间交付
• 用户数这个问题暂时没有遇到

3、和上一个阶段相比，团队软件工程质量提高了么？在什么方面有提高，具体提高了多少，如何衡量的？

• beta冲刺还未开始，但是我们会竭尽全力。

4、用户量、用户对重要功能的接受程度和我们实现的预想一致么？我们离目标更近了么？有什么经验教训？如果历史重来一遍我们会做什么改进？

• 首先用户量的问题，用户接受程度，并没有投入使用，还没法得出结论。我们离目标更近了，前端人员从不会开发的小白，到工具和语言的熟练，我们会快马加鞭的。
• 经验教训
  • 没有运用好GitHub这个工具，导致后期合并代码，需要人工尽心线下合并，浪费时间。
  • 老师给出了代码签入GitHub的建议没有执行到底，才会有后面的浪费时间，应该多向老师和助教取经。
• 改进
  • PM应该加强团队成员的交流 ，活跃大家的气氛。
  • 前端给后端提需求应该先把所有需求提完。
  • 后端应该尽力完善数据库，甚至是多次完善。
  • 多熬夜。

计划

1、是否有充分的时间来做计划？

• 关于计划团队有做了计划，但是计划总是会出现一些意外。
  • 队友的as崩溃了
  • bug一直卡在那里无法解决
  • ...
• 计划的部分，有部分完成了，有部分没有完成。为什么？
  • 时间安排不合理，花费过多时间在解决bug和工具安装上面，以至开发缓慢
  • 交流不足
    2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
• 集合大家进行开会，进行讨论，会较多听取陈璟的经验。
  3、 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
• 没有全部做完，发现界面没有完成。
  • 开发不够熟练
  • 不懂得寻求帮助

4、有没有发现你做了一些事后看来没必要或没多大价值的事?

• 大家集体出来写代码效率并没有很高，可能自己单独写代码，或者两个人效率会更高。

5、是否每一项任务都有清楚定义和衡量的交付件?

• 任务定义有具体定义，比如说解决**bug，或者说画某某界面的哪部分，或者说完成后端的登陆注册的接口，或者说建立数据库。
• 衡量的交付件倒是没有，更多时候是大家自己觉得ok就ok。
  6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
• 项目并没有整个过程都按照计划进行
• 意外1：突然要考试了，来不及复习了。
• 意外2：后端和前端没交流好，数据库建立也缺少交流，一直返工。
• 意外3：合并代码各种报错。
• 原因：时间安排不合理，终于明白为什么鸣人会那么强了（他会分身）；应该做好事先的各种规范
  7、在计划中有没有留下缓冲区，缓冲区有作用么?
• 有预留了两天的缓冲区，怕项目来不及做完；同时也怕大家太累了，可以安排休息一天。休息是休息了，但是项目最后还是没改完。
  8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
• 会比较少地让大家集中出来打代码。
• 多去开发人员的宿舍看看进度，了解他们的需求。
• 加班，可以提早加班，不要等到后半段时间再开始熬夜之旅。

资源

1. 我们有足够的资源来完成各项任务么?

• 这个不好说，电脑配置确实比较低端，大家的电脑来跑AS会很卡顿。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

• 所需时间是PM和开发人员两者共同协商的，精度一般以天数为单位。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

• 测试的时间分配不足，这是之前没有想到的，因为再去熟悉测试工具也花费了许多时间。
• 对于文案和设计确实低估了难度，每天开会，还有写博客，同一件事做久了确实很烦人。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

• 数据库和后端一个人负责应该就可以了。
• 前端需要多分配一个人

变更管理

1. 每个相关的员工都及时知道了变更的消息?

• 变更管理是课上变更的，大家就在教室互相认识了一下。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

• 推迟功能和必须实现，是看这个功能是否是核心功能，再加上考虑工作量和时间，优先实现核心功能。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

• 大家对于这个并没有深入的了解，目前对于我们来说也用不到。

4. 对于可能的变更是否能制定应急计划?

• 团队这次的变更，结合原来团队的实际，我们打算让新加入的小伙伴去做前端，帮忙写页面跳转逻辑。
• 紧急计划，比如说有人突然生病了，无法开发，将其的任务平均分配给他人。

5. 员工是否能够有效地处理意料之外的工作请求？

• 这个暂时无法做到，因为目前项目的所有功能还没完全实现。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

• 设计工作我们理解成原型开发，是在项目开发之前就完成的，确实是合适的时间；人选，我们让最有审美的人来了，队伍以至认为还不错。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 有，遇到某些比较复杂的界面的时候，会有人提议说，要做就做得完美一点，但是也有人建议说，简化一点，一切从简。不过一般是谁做这个界面，谁自己决定，给开发人员自己设计的权力。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 没有使用；UML图和现在的状态确实有区别，是在建立数据库，开发过程中发现与实际不符，得调整。需要更新。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

• 发现功能产生的bug最多，页面跳转系统一直崩溃，目前还是没找到原因。发布之后，重要的bug发现，安全性的实现未进行考虑。开发过程考虑到了， 不过实现有一些难度。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 代码复审是人工进行合并检查的。一致执行了代码规范。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

• 没有，当时还没考虑那么多，接下来会加上去。

2. 是否进行了正式的验收测试？

• 测试进行了，但是并不是正式的。

3. 团队是否有测试工具来帮助测试？

• 有，后端自己写项目调用自己写的端口，测试注册登陆等功能。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

• 将软件进行手动测试，实际运行效果看来，记录的功能在户外精度还不错，在室内就有点堪忧。
• 测试工作还是有用的。
• 测试的方式和前端的代码和后殿接口的封装

5. 在发布的过程中发现了哪些意外问题？

• 发布可以理解成课堂演示吧，演示的时候，发现合并错了一个页面，那时候也是巨尴尬。