团队事后分析

设想和目标

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

    • 我们的公课网是面向北航本科生的课程评价网站，要解决学生及时得到课程和教师评价的问题，典型用户主要分为管理员、查看课程评分用户和评价课程的用户。
    • 对典型用户和场景有清晰的描述。

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

    • 目标大部分完成了，但仍然有没达到的目标。beta和gamma完成的功能有：安全加强（邮箱验证、验证码验证、session、https、头像格式审核）、用户体验加强（页面修改、忘记密码）、功能新增（管理员系统、信箱系统、删除自己的评论、教师主页、增加全网站中用户课程和教师的跳转、增加点赞点踩、支持emoji）、性能优化。未完成的功能有：为评论增加标签和云图。
    • 按照原计划时间交付。
    • 用户数量预计注册200人，实际注册近100人，登录次数250+次，未达到预期。

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

    • 与alpha相比，软件工程质量大幅提高。我们增加了12个文档，为后端代码增加了注释和统计时间的修饰器，增加本项目相关技术博客4篇。

  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    • 用户量部分如上文所说，比预期要少。虽然我们在微信群和贴吧进行了推广，但是存在两个组完成相同项目的现象，导致了部分用户被分流。
    • 用户对重要功能的接受程度和预期基本一致。

  5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 我们认为预期的目标制定的并不很难，如果再来一遍，我们会花更多的精力进行推广，在分配任务方面我们也会更多的考虑到大家的烤漆等因素，更合理的安排任务量和分工，以完成预期的目标。

计划

  1. 是否有充足的时间来做计划?

    • 在alpha的初期，做计划的时间比较充足。而beta和gamma两阶段的计划工作，在一次组会中就要完成，难免不是很全面。

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    • 通常对于有争议的意见，反对者可以用自己的观点说服大家。

  3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    • 一小部分的功能任务没有完成。主要原因是由于真正能独立开发整套新功能的成员较少，相比其他更加重要的功能，标签功能只能一拖再拖。

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

    • 由于时间紧迫，我们实现的功能都是相对重要的。目前看起来在beta和gamma阶段中，没有哪一个工作是明显没价值的。

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

    • 对任务的定义一般除了在组会中口头安排外，还会在github issues中用文字性的介绍和要求。
    • 对于交付的标准，一般只要能够正常使用即可。但实际上这个要求也不总是能没满足，往往需要几位技术比较强的成员进行二次修改或者重写。

  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    • 项目大部分都按照了计划来进行。但在beta阶段初期，我们收到了攻击，导致功能的部署停止了一周，安排专人进行了安全加强。
    • 没有估计到的原因是组内虽然有人曾经做过网站，但正式上线还都是第一次，没有加强网站安全的意识。

  7. 在计划中有没有留下缓冲区，缓冲区有作用么?

    • 在每个阶段的末期，我们的主要任务都是完善博客和文档作为缓冲期，这就给了应对紧急情况提供了可能性。

  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    • 将来会在每个阶段的初期更好的规划未来几周内的所有工作，而不是每周工作结束后才去想下一周的工作将是什么。

  9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 在选择项目时，要充分考虑到团队成员的优势所在，即他们对哪种开发模式和编程语言更熟悉，或者以前有什么好的开发经验。

资源

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

    • 我们并没有得到足够的服务器资源。部署https需要域名，而国内域名需要经过时间长、材料多的备案。课程组提供的华为云服务器由于无法找到所有者，就不可能完成这项工作。最终我们通过github学生计划中的50美刀优惠券租用了国外服务器才实现相关功能，实现较好的安全性保障。
    • 此外，时间资源也很紧张，很多细微的功能最终由于时间原因被砍掉。

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

    • 根据之前做这些类型任务的经验，估计任务的难度和强度。对于每个人，根据每个阶段的时间不同布置1-2个主题任务（有重要改进的任务）
    • 根据我们的完成情况来看，精度估计较为准确合理。

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

    • 测试的时间和资源相对较充足。
    • 对于代码难度较低的前端和PM部分，我们在其工作量较少时安排了其他修复或后端工作。

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

    • 部分人员认为，由于其对项目的熟悉程度不足，由其他技术人员来进行可能效率会更高。但现实中，其他人员也有自己的任务。

  5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 有时候会因为想赶进整个工程的进度，给了能力更强的同学较多压力，好在大家都是一心为了工程好，也没有听到任何的埋怨。我应该进行严格的验收，不能因为一些同学对技术不熟悉而把一些较难的部分留给其他同学实现。技术交流我们是允许的，但是做出半成品或bug较多的代码就应该回炉重造。但是为了保证项目的进度不被延后，缓冲期就会起到很重要的作用。

变更管理

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

    • 开发人员的开发工作完成后，会在微信群说明进度。

    • 每次发布新版本，都由分支管理人员在微信群发送版本更新通知，包含新功能和本地项目需要做到改动。

    • 任务更新后，在github issues发布详细说明，由邮件推送，并在微信群里通知。

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

    • 当遇到进度问题时，大家会根据任务的重要性来决定。非常重要的任务如https的实现，会延长任务持续时间，但要保证必须实现；不重要的功能，遇到大问题后可能会被砍掉。

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

    • 测试通过+使用效果和预期一致+部署服务器后行为一致

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

    • 对于重大变更，如砍掉功能，往往由大家一起商量，一起制定应急计划。

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

    • 意料之外的工作请求，一般只发生在出现“服务器行为不同，需要专人debug”和“突然出现较严重bug，需要更多技术人员进行修复”的情况下。团队成员也确实做到了投入额外时间进行有效处理。

  6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 需要根据任务的紧急程度和成员们的时间随时协调任务的进展。但是像bug和服务器等影响上线运作的bug必须立刻修复过程执行backup plan。

设计/实现

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

    • 设计工作主要由两部分，一是组会前技术骨干和PM先确定大体的任务内容和实现分工，二是在组会中和大家讨论后完成设计工作。
    • 人员是合适的，时间可以稍稍提前，做好规划。

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

    • 对于模棱两可的情况，往往会和PM或技术骨干交流后确认细节。

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

    • 只有功能场景的测试，没有单元测试。我们采用ER图来描述数据库各实体和关系的结构图。

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

    • bug最多的功能是邮箱验证部分。一是bug的来源包含了邮箱服务商的问题，如我们的邮箱信誉度不高，连续的拒收可能导致服务商不予提供邮件服务或进入垃圾箱。此外在服务器端，163邮箱的行为和本地不同，更换qq邮箱后才得以解决。
    • 发布以后最重要的bug是在修改js引用后，出现了服务器端js无效的问题。由于没有报错提示，我们只能通过一次次的版本回滚定位问题。
    • 在设计时，没有想到服务器和本地行为不同，这给我们带来了巨大的困难。

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

    • 代码复审主要由开发者提交后，分支管理人员要保证在发布前功能正常实现，此时管理人员进行复审。此外测试人员也经过复审后，才通知管理人员发布。
    • 实际上并不一定完全遵循代码规范，由于改动成本较高，往往不强制要求修改。

  6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 在开组会时，完成一大部分的各功能设计任务，将上下游都规定好，可以从一定程度上减轻成员自己设计时的不确定性也可以大大提高效率。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？
  2. 是否进行了正式的验收测试？
    • 验收测试就是测试的一部分，主要目的就是确保该部分功能得以实现。
  3. 团队是否有测试工具来帮助测试？
    • 团队使用了selenium工具进行了自动化测试。
  4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
    • 我们在view.py中的每一个函数加装了装饰器来计算各个函数的实际运行时间。这些测试工作可以很明显的表现出我们的效能短板，并且给了我们优化的目标。例如在搜索时间的优化上，我们的全局搜索时间从7+秒变到0.2秒。和隔壁组相比，这些效能的改进都是直接优化算法来进行改进，而不是通过缓存来加速二次访问时的速度。
  5. 在发布的过程中发现了哪些意外问题？
    • 由于我们时间没有预料到服务器端和本地也可能会出现行为不同的情况，在上线邮箱验证等功能时，出现了邮箱服务商拒绝我们通过服务器来发送的邮件。
  6. 我们学到了什么? 如果重来一遍, 我们会做什么改进?
    • 验收测试的流程应该更为详细，规范化。对于不合格或者完全无法运行的代码，应该采取回炉重造的方式，以保证代码的质量。

团队的角色，管理，合作

  1. 团队的每个角色是如何确定的，是不是人尽其才？
    • 在alpha阶段的初期，每个团队成员提出自己希望承担的职责。经过协商后，形成了目前的角色。
    • 由于基本是基于每个人上报的职责进行分配，因此基本是人尽其才。
  2. 团队成员之间有互相帮助么？
    • 由于新PM在beta阶段刚刚加入，后端的成员进行了一定的介绍。此外在每次出现bug后，基本都是互相帮助，结对debug。
  3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
    • 有问题一定要提出来，否则大家连问题都无法发现，更无法解决。
    • 提出问题后，最好摆正态度心平气和的协商，毕竟出现问题的是工作而不是团队成员，因此问题总还是可以解决的。
    • 倘若真的遇到无法解决的个人问题，往往只能更换到更适合自己的组去。

总结:

  1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    我认为团队已经达到了已定义级，正在迈向量化管理级。首先因为整个工程的进行都有博客做为记录，并且我们已经有了完善的文档。开发过程严格遵守git-flow流程。并且我们也没有出现，不小心删库或者网站被攻击到瘫痪的现象。
    就量化管理而言，我们已经有了对于工程规模的量化标准，在展示博客中也用数据证明了我们工程的代码质量。之所以还未完全到达量化管理级是因为我们还未能对于将来的项目做出一个可以量化的难度和强度的估计，从而预测性能。

  2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
    团队已经较为成熟，介于规范和创造之间。在后期可以明显感觉到，对于新功能的增加团队已经可以达到游刃有余，但是大家的创造力和热情也在逐渐消退，可以提出一些极大满足客户需求的惊喜功能，但是却在实现上显得有些力不从心。

  3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
    gamma阶段最重要的是我们在优化用户体验一下做足了工作。我们意识到一个网站的好坏不仅仅在于它的功能是否全面而在用户的体验是否流畅顺滑。因此，gamma阶段所添加的新功能，仅仅是为了完善alpha和beta阶段的功能。我们尝试着从一个用户，而不是开发者的角度出发，对我们的网站进行一个全面的评估。最后达到的效果也令人满意，可以看出我们的网站功能较为完善，并且可以给用户带来顺畅的体验，无论是从网站信息量还是优良的反应速度上看，都有不错的表现。

  4. 你觉得目前最需要改进的一个方面是什么?
    首先是网站的UI延续上一届的主题，但是随着我们页面功能的添加同一个主题显得过于单调，如果可以改进的话，可以在UI方面进行改进。

  5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

    • 首先我们做到了可以尽早持续的交付有价值的软件。 在三个阶段中，我们都可以做到交付一个可以使用有具体功能的网站供大家使用。
    • 在需求变更中我们也有非常优秀的应变能力，例如在优化用户体验中，将不可点的放大镜图片变成可点击的按钮，另外，有用户提出的相关问题，我们都做了及时的修改和回应。
    • 组内成员也都做到了精益求精，不仅仅将眼光放在完成布置的任务中，而是对整个网站的提升做出一些建议，并且实现它。
    • 在有限的时间中，我们也做到了选择最重要的功能去完成，放弃了一些价值不高的改进点。例如对于网站的词云功能，我们认为，在评论数不够高的情况下，这个功能体现不出很大的价值。于是我们将眼光放在了管理员与信箱等控制评论的功能上。我们的目标就是在一定范围内可以实现一个良好的，有完善功能的系统，将网站和用户的行为都变成可控可管理的，而不是未知的危险的。

  6. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
    主要需要在两个方面进行提升，一是我们的验收流程，二是我们的工作可量化标准。

    • 对于验收流程的必要性来说，每个人的工作需要责任到人，而不是混在一起解决。
    • 对不同工作的难度和强度来讲，需要制定一些可量化的规则，不然就会出现，每个人对某个工作的理解不同，导致高估或低估其难度和工作量。但是，这些规则的制定也不能完全表征一个工作的难易程度。任何可量化的标准都有可能带来一些投机取巧的方式，但是他们的存在是有必要性的。只不过他们不是最后的决定手段，对于一个团队来讲，最后的决定应该在整个团队的沟通讨论过程中完善。

  7. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

    • 开发者必须严格按照流程进行代码编写和提交
    • 复审过程像上述中的流程一样，有测试人员经手再通过管理人员发布。
    • 严格按照代码规范文档，严谨地进行变量名的书写和格式等等。
    • 如果结果不合格会进行一定程度的惩罚并且责任到人，再次进行修改。

  8. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
    由于我们的网站项目采用django框架，这个框架的提升空间不大，因此我们在数据库的重构中通过重新设计实体和关系，来优化框架减少冗余。此外，我们丰富了测试的方法以及提交的流程，进一步提高了工程质量。

  9. 其它软件工具的应用，应该如何提高？
    我们在测试方面，需要使用软件工具，帮我们完成代码覆盖率和一些压力测试。在这些方面，我们缺乏调研，仅凭自己的判断就认为网站不需要覆盖率是不正确的想法。

  10. 项目管理有哪些具体的提高？
    通过一学期的项目管理，我了解了项目管理者需要对整个项目和团队成员有详细的了解，才能更好地找出项目前进的方向。在后期，我更能了解到多少任务量适应多少时间。在大家其他任务紧迫的条件下及时修改任务量，在某些成员任务完成的情况下分派其他任务。

  11. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
    我们的数据来源是通过后台查看数据库得到的，我们曾经计划编写python脚本处理最原始的log文件，进而得到最全面的数据，并且通过这些数据分析用户行为。同时使用Linux中的工具crontab，实现每日数据的例行。但是，由于当时使用的服务器无法开启此服务，如果在之后的发展中可以实现这方面的统计，我们的项目就有了更多的优化目标。

  12. 项目文档的质量如何提高？
    对于文档来说，最好的方式就是有固定的统一的模板。并且文档是需要不断更新的，在一个阶段结束前需要更新该阶段的文档保证文档是不断扩充，不会落后于代码工程。

  13. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
    PM：人的领导和管理我还有很多的不足，对整个项目来说，我尽了自己最大的努力，认真思考我们项目的前进方向，尽量合理的去安排每个人的任务。我没有任何觉得愧对自己的这份工作。但我没有办法做到和团队中每一个人都建立起无话不谈的关系，我的理想状态是希望每个人有了意见后都可以主动地来找我商量，这样的话于项目、团队、个人都会更加有利。

  14. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
    通过本学期的软件工程团队项目，我们总结出了如下开发规律：我们不能理想化的，将项目的推进工作分给每一个团队成员，而是要有PM和技术骨干等人先制定大致的方向，甚至细节。在组会中，布置给每个成员并进行讨论，适当修改。在开发完成后，汇总给测试人员或管理人员进行审核和发布，然后再进行新一轮的开发。

posted @ 2019-06-21 19:23  笨拙软件工程  阅读(174)  评论(0)  编辑  收藏  举报