事后诸葛亮分析

一、总结

1、项目管理之事后诸葛亮会

设想和目标

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

本团队项目希望打造一个拥有多功能的端口扫描器，拟实现基本端口扫描、多线程、图形化界面还有其他有关安全的拓展功能；定义得很清楚，典型用户也比较清晰，提供给热爱或者从事网络安全的技术人员。

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

还行，时间总的来说还算充裕，大家集中一起讨论、分工合作。

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

一起商量，求同存异，共同进步。

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

基本一致，离我们的团队目标更近了。

计划

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

有的，我们用了一周的时间来讨论指定计划。

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

在团队计划阶段各个小伙伴对项目有各自的理解是一种正常的现象，这也表明每个组员对项目都是负责的，都希望做好这个项目，因而对与组员提出的不同的意见我们是采取积极响应的态度，共同商量采取对项目实现最优的方案。

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

原计划的功能有部分因难度太大没完成，但是加入了一些之前没想到的功能，项目可以说是很完善了。

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

有的，因为设想的功能跟实现起来还是有一定的区别，有些难度太大的功能，在最后没能完成，替换成另外的功能，这是当时在计划的时候考虑实际条件考虑得不足的表现。

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

在每周的小组会议还有冲刺阶段每天的讨论中，我们对每项任务的分工以及交付时间都是有清楚的定义的

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

整体来说最基本的功能有实现，也有部分功能跟一开始设想的不符，因为实现的难度很大还有实际条件的不足。

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

在计划的过程中有留下缓冲期，如果时间进度太赶的话，而在实践的过程中遇见瓶颈时，这将会影响明天的进度。所以缓冲期还是必要的，当然，如果按任务分配的后出现某一个同学的任务太重的话，我们也会采取一定的补救措施，调动人员分工。

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

先对大体的进度有个粗略的计划，详细分工，更加安排合理时间的缓冲区。

资源

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

团队人数上来说是足够的，但由于大三课程多作业也多，加上能力有限，所以这方面会有点缺，其他方面的话还可以吧。

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

凭感觉估计，时间不太准，但是每天都有开会讨论总结。

• 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源，是否低估难度？

算是足够吧，对于那些不需要编程的资源，真的是低估了难度，因为要进行环境的配置。

• 你有没有感觉你做的事情可以让别人来做（更有效率）？

没有，因为我们都是事先根据能力评估分配任务的，大家都是挑自己最擅长的部分工作。

变更管理

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

那是必须的，有事微信群就call起来，况且大家都是一个班的，课后讨论也很容易。

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

团队探讨决定，综合每个人的意见。

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

有，能完成设想的基本功能，能启动，能运作，能达到最初设想的结果。

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

有，根据团队开发情况有做一些预先安排。

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

可以的，大家相处非常融洽，有困难都是一起解决，若有额外的工作，都是按照每个人擅长的地方来决定分配工作的，所以实现起来还是比较容易的。

设计/实现

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

设计工作在实现功能之前，由小组一起讨论，组长完成实现。
肯定是合适的时间、合适的人。

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

有碰到，团队成员一起出来开会讨论，综合意见，提出解决方案。

• 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

开发思路清晰，设计不算复杂，没有借助其他工具；为了测试运行结果是否正确，使用该软件对redis数据存储记录进行查看，由于其可视化而比较方便，很有效

• 什么功能产生的Bug最多，为什么？

前台与后台交互过程中，由于初学ajax导致诸多语法使用不当，使得前台的数据总是未能在后台接收到。

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

将代码传到github上，大家一起看，运行看。

测试/发布

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

有，根据工作量和每个人的情况进行分配测试任务，成员都能够很好的完成。

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

有，再三进行测试，根据每次的效果进行调试，最终确定版本。

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

有，使用该软件对redis数据存储记录进行查看

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

主要是通过人员检测，实际效能和预期效能决定性能；测试工作还是很有帮助的，因为有一些bug是在开发时没有想到的，经过测试可以看得出来，经过测试发现可以从性能方面进行改进。

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

有些原先设想的功能不能政策运作，没能达到预期目标，存在bug，所以用其他功能替换了。

团队的角色，管理，合作

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

团队的角色是根据团队成员的实际能力确定的，大家都尽力去做。

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

必须有。

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

开会讨论，沟通协调，决定出大多数人同意的意见。

• 对成员帮助的感谢

林泓：我感谢郭泽纯同学和张培烽同学，因为他们认真分析了作业要求，负责了博客记录的大部分工作，使其他组员更能专注于开发工作上。
吴茗睿：感谢林泓同学，抗压能力太强了，没有林泓同学我们的项目也不能完成前端界面就不能让项目画上一个相对圆满的句号。
吴旻哲：感谢林
标签：分析,功能,事后诸葛亮,是否,计划,林泓,测试,团队	

来源： https://www.cnblogs.com/polaris-973/p/14065702.html