事后诸葛亮分析报告

标签：splay   信息   要求   ec2   指定   done   deb   逻辑   one   

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？
   答：日常生活中，我们常常会为自己制定计划或目标，并给这些计划和目标定下完成的期限，于是Light_Note网页版备忘录应运而生，旨在督促和鼓励用户在规定的期限里完成自己制定的目标，应用的定义也较为清楚。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
   答：基本达到了原计划的功能。交付时间稍晚于原计划。目前用户数量仅限于组内成员，未达到原计划。
3. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   答：在经验教训方面是时间安排，如果再来一次，会指定更加合理更易执行的时间安排。
   改进：提高自己的编程能力、以及对于编程语言和框架的熟练度很有必要。
   

计划

1. 是否有充足的时间来做计划?
   答： 有。之前有充分的时间来讨论、构想整个软件的框架，之前布置的每一项作业都在不断地让整个软件的轮廓在我们的大脑中变得清晰。但由于作业实在过多，加上考试复习， 所以编程时间是不够。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   答：中和大家的意见，少数服从多数。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   答： 基本完成。
4. 是否每一项任务都有清楚定义和衡量的交付件?
   答： 有。在Alpha冲刺的初期，全组成员开会最主要就是讨论清楚整个业务逻辑，讨论完业务逻辑，我们再细分出各个任务，并在teambition网站上进行任务认领和分配，这些东西就是具体的交付件。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
   答：没有刻意留下缓冲区。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   答： 对软件开发的流程有更多的了解，队员间的合作能力明显提高。改进方面，在时间安排，与任务分配，以及人员安排等方面仍需要调整。
   

资源

1. 我们有足够的资源来完成各项任务么?
   答： 有。备忘录应用在现实中已经有很多成熟的产品，我们有足够的资源参考；学习资源的话，网上的资源已经十分丰富了。
2. 测试的时间，人力和软件/硬件资源是否足够?
   答： 由于本次项目是web应用，测试时涉及到的是各浏览器，对硬件资源没有过多的要求，所以软/硬资源足够；但测试的时间和人力不足。
3. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   答：是。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   答：前期准备不充分会影响后期的开发效率。如果重来一遍，由于网上有足够的资源来让我们学习开发所需的技术以及熟悉如何开发项目的流程，那么我会在前期花更多的时间去做足准备，比如深入的去进行需求分析，以及花更多的时间去提高编写代码的能力，同时我们会更加注重对代码的测试，以保证程序代码的健壮性。
   

变更管理

1. 每个相关的员工都及时知道了变更的消息?
   答：Alpha冲刺阶段会进行每日一次的站立会议交流；此外，遇到问题时也会通过微信等方式及时的进行沟通讨论。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   答：必须实行的功能：项目的核心功能和Alpha冲刺实际开发过程中遇到困难较小的功能。
   推迟：由于Alpha冲刺的时间不多，所以“推迟”一般是因为这个功能可能需要较大的工作量。
3. 对于可能的变更是否能制定应急计划?
   答：没有特定去制定应急计划，遇到问题立刻着手解决。
4. 成员是否能够有效地处理意料之外的工作请求？
   答： 大部分能。有些意外情况自己实现不了，也会请教有经验的同学的方式帮忙解决。
5. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   答：计划赶不上变化，开发过程中不会一帆风顺，采用一套好的变更管理策略就变得很重要，如果重来一遍，我们会加强对项目进展的相关细节方面的管理，队员们每日汇报自己完成那部分工作的进度和遇到的困难，是否解决等信息，以便PM能对项目的进展有全局的了解，能及时的对工作进行调整，提高整个项目的开发效率。
   

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   答：在Alpha冲刺的初期，全组成员开会讨论清楚整个业务逻辑，并进行任务认领和分配。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   答：没有出现，队员觉得模糊的地方会及时提出疑问，相关人员会对应解答。
3. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   答：由组长复审，基本严格执行了代码规范，能提高代码的整体质量，提高可拓展性。
   

测试/发布

1. 团队是否有一个测试计划？为什么没有？
   答：有，每个人都要测试自己部分以及选择一部分测试。
2. 团队是否有测试工具来帮助测试？
   答：无。
3. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   答：各个模块的单元测试由相应的开发组员进行，页面整合完后，在不同的浏览器上使用，进行整体测试。
4. 在发布的过程中发现了哪些意外问题？
   答：暂时没有。
5. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   答：良好的测试是保证代码质量的前提，如果重来一遍，我们对不同功能的代码，设计覆盖范围更加全的数据来进行测试，并且把测试的结果和对结果的分析写入测试文档。

总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次??
   答：达到CMMI中的二级，管理级别。

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

3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
   答：合作方面大家任务分配管理的更加的合理，效率也提升了很多。

4. 你觉得目前最需要改进的一个方面是什么?
   答：团队成员仍需要更加积极。

5. 下个阶段需要改进什么？
   答：可能没有下个阶段了，但还是敬请期待。
   

团队贡献

会议截图

事后诸葛亮分析报告

标签：splay   信息   要求   ec2   指定   done   deb   逻辑   one   

原文地址：https://www.cnblogs.com/Dawson-Huang/p/13111547.html