脚本宝典收集整理的这篇文章主要介绍了团队作业6—事后诸葛亮，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

团队作业6—事后诸葛亮

PART 01 项目Postmortem

一、设想和目标

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

   • 我们的软件提供了一个电影信息来源的整合平台。同时针对目前大多数电影网站界面存在较为复杂的问题，做了ui设计上的改进，保留了影讯网站中的必要部分。追求最朴素的电影资讯平台。对于要解决的问题定义的很清晰。
   • 我们对典型用户和典型场景有清晰的描述，我们的主要受众是达到一定年龄的群体，由于现在互联网飞速发展，信息的来源十分冗杂。并且有些信息源的视觉呈现对这些用户不是十分友好。本项目针对这些痛点设计了一套整合主流电影网站信息和更加优越的视觉呈现的电影信息平台。

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

   • 原计划中的功能基本上满足。包括电影推荐模块、爬虫模块和ui模块等等并且按照原计划交付时间交付。

   • 根据统计，用户数量还未达到预期，但是希望经过宣传之后能够打开我们软件的知名度。

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

   • 相对于上一个阶段，团队的分工更加合理，成员之间磨合更加深入。具体表现在任务的提交日期相较于先前有了很大的进步，现在都是提前一天半左右便全部完成。

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

   • 在用户量有限的情况下，我们发现用户对我们重要功能反馈较为正面，与预想的一致。但是存在一些系统上的安全和健壮性设计不足。对于下次项目，会更加着重考虑系统的边界设计和程序的健壮性。

二、计划

1. 是否有充足的时间来做计划?
   • 有。我们在计划阶段安排了足够的时间，并且有开会进行讨论交流，因此有充分的时间做计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   • 在团队计划阶段各个小伙伴对项目有各自的理解是一种正常的现象，这也表明每个组员对项目都是负责的，都希望做好这个项目，因而对与组员提出的不同的意见我们是采取积极响应的态度，共同商量采取对项目实现最优的方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   • 基本工作都完成了，后面因为期末时间精力安排的问题，没有进一步的优化UI界面
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   • 没有，做的每件事情都比较有意义。
5. 是否每一项任务都有清楚定义和衡量的交付件?
   • 有
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   • 开发过程中没有及时用gIThub进行代码迁入，后面难以修改。没啥风险是没估计到的。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   • 有留缓冲区，有作用。我们都会提早1-2天提交代码，防止出现突发情况，如发现一个大bug，没时间调好就要上线。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   • 将来项目的分工要分的更加细，不能有模糊感，避免大伙重复造轮子，开发的目标也更加清晰。
9. 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
   • 学到了团队合作的重要性，多与成员沟通远比单干有用。如果历史重来一遍，我们会分工更加明确，让任务更符合自己的技术栈

三、资源

1. 我们有足够的资源来完成各项任务么?
   • 人力资源：我们团队有7个人，群除我佬。
   • 开发资源：组长以及队员们都会经常整理很多开发所需的基础知识和技术文档，还有项目必要的相关文档。
   • 设备资源：人手一台电脑，足够完成开发测试任务
   • 时间资源：有些紧张，其他课程也有实验课设作业和考试，软工的项目时间跨度和工作量有点大。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   • 组长发布任务后，由组员先自我评估，组长再结合整个项目进行评估，任务分配到天带小时。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   • 基本足够辽，美工设计上低估了难度，没人熟悉美工。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   • 讨论过后，团队成员人均各司其职，不可替代。
5. 有什么经验教训?如果历史重来一遍，我们会做什么改进?
   • 提前规划好需要的资源，根据需要的资源去寻需要的东西并且评估难度。做好项目方面的实时监督与加强项目资源的管理与部署。

四、变更管理

1. 每个相关的员工都及时知道了变更的消息?
   • 是。我们有专门的项目变更通知群。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   • 该功能是否影响核心功能的正常运行
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
   • 满足项目一开始设想的功能并且能够正常使用
4. 对于可能的变更是否能制定应急计划?
   • 大多数能。
5. 员工是否能够有效地处理意料之外的工作请求？
   • 是
6. 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
   • 学到了变更通知及时的重要性，能够少花很多功夫；还能改进的部分是：一开始先分析各部分互相影响的功能，提前交流，能减少不必要的工作量。

五、设计/实现

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

   • 设计是在项目计划完成后由界面开发人员和UI设计人员共同完成的。是合适的时间，都是在团队中相对合适的人员。

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

   • 有，讨论选择更加美观的方案

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

   • 团队项目主要侧重点在于算法，界面简单且利用pyside2开发界面也比较方便并没有用到很多的工具。

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

   • 暂时没发现什么bug，只有不完善的地方，比如在注册时，昵称，手机号码，邮箱等没有做一定的限制，导致任何格式的文本都可以被注册。产生原因是当初计划时没有太注重这一块。

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

   • 代码复审由负责开发板块的同学相互检查各自的板块，严格执行代码规范。

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

   • 要更加注重设计工作，界面很影响用户体验感。

六、测试/发布

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

   • 有

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

   • 是

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

   • 有，utest，mocker-cpp等开源测试框架

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

   • 我们利用Pycharm插件，本地客户端发送多个请求，模拟多用户情况，模拟dDOS
   • 测试工作有用，极大的改进了用户体验

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

   • 服务器配置出现一些小意外，稍作修改即可

七、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

   • 团队的每个角色都是每个队员根据自身的特长以及熟悉的技术进行选择的，所以是人尽其才。

2. 团队成员之间有互相帮助么？

   • 我们团队注重交流，会经常在群上交流遇到的困难，队员直接遇到的技术问题也会互相帮助。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

   • 我们会在群上沟通交流，团队成员都会发表自己的意见，最终协商出较满意的解决办法。

八、总结

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

   • 团队项目可以正常使用，没有逻辑性错误，达到CMM的第二级。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

   • 规范阶段。负责各部分的团队成员已经形成了高效的交流模式，能够相互吸收接纳对方的想法，集体意识强有清晰的共同目标盘。

3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

   • 团队成员在过程中不断学习，已经具备了与自己不了解的领域对接沟通的能力。

4. 你觉得目前最需要改进的一个方面是什么?

   • UI界面设计

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

   • 我们都有充分的信任与支持，对于团队的工作也尽量的简明扼要，对于遇到的困难要一起解决。

6. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

   1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
      • 注重代码规范文档，开发人员要严格遵守写好注释，方便代码复审。
   2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
      • 开发者要有一套完善的架构体系(包括指定统一的框架等)，并对项目技术有充足的知识储备，学习更多精简的算法和结构来提高程序框架。
      • 用重构后程序精简易读程度以及程序的运行速度等与原来的对比，来衡量质量是否提高
   3. 其它软件工具的应用，应该如何提高？
      • 多学习！多看软件工具应用实例，阅读官方说明文档。
   4. 项目管理有哪些具体的提高？
      • 通过站立式会议掌握项目动态与进展，通过任务分解简化开发任务并能实时debug，减少测试工作量
   5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
      • 可以通过日志系统来跟踪用户数据方面的信息
   6. 项目文档的质量如何提高？
      • 统一文档格式，以及文档命名方式方便整理
   7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
      • 增强大局观念，能够考虑到项目开发的方方面面，把握好时间节奏。

PART 02 会议截图

PART 03 团队贡献分

@H_192_512@

脚本宝典总结

以上是脚本宝典为你收集整理的团队作业6—事后诸葛亮全部内容，希望文章能够帮你解决团队作业6—事后诸葛亮所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。

名字	角色	团队贡献分	可验证的贡献
林俊斌	爬虫开发		完成爬虫开发，能够爬取一定量需要的数据。
曾聿昊	测试		测试出程序bug10余处，参与版本改进2次，对版本改进提出建议3项
徐国涛	开发		1.每次作业的博客完成自己的部分 2.负责了项目的主要开发工作以及代码管理 3.积极参与团队项目交流 4.帮助团队成员解决技术问题
潘百林	算法、爬虫		统筹安排团队成员工作，完成项目定位，需求分析，部分爬虫模块和全部推荐算法模块。负责课堂展示
马悦	PM，UI设计		1.组织博客撰写，写博客2. UI设计
谭清允	开发		开发了功能实现的后台逻辑，优化了数据库结构
张伟龙	PM		根据需求跟进算法模块、优化UI