事后诸葛亮分析

事后诸葛亮分析

1.设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
为公司提供简单的项目管理系统，便于管理项目。定义清楚。有清楚描述。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？)
基本达到。项目基本功能完成，但是网页界面不够美观。按原计划时间交付了。用户数量未达标。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
一致。更近了。

2.计划

是否有充足的时间来做计划？
没有。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过开展团队讨论，选出优化方案。
你原计划的工作是否最后都做完了？如果有没做完的，为什么？
没有。分配到软工作业的时间不多，学习的技能不完整。
有没有发现你做了一些事后看来没必要或没多大价值的事？
没有。
是否每一项任务都有清楚定义和衡量的交付件？
基本都有。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
基本按整体进行，因为不能把全部时间都投入到这个作业上，所以有些功能不够简洁方便，有很大的发展空间。
在计划中有没有留下缓冲区，缓冲区有作用么？
有。有作用，突发事件
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
增大缓冲区，合理安排项目进度，松紧安排合理。

3.资源

我们有足够的资源来完成各项任务么？
时间资源、技术资源不足，但还是可以完成大部分任务。
各项任务所需的时间和其他资源是如何估计的，精度如何？
每次一周，按照估计代码的难易程度来，精度一般。
测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
并不足够。文案难度大，美化设计难度大。
你有没有感到你做的事情可以让别人来做（更有效率）？
没有。

4.变更管理

每个相关的员工都及时知道了变更的消息？
是。
我们采用了什么办法决定“推迟”和“必须实现”的功能？
小组讨论功能对项目的重要性。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
清晰。
对于可能的变更是否能制定应急计划？
不能。
员工是否能够有效地处理意料之外的工作请求？
可以。

5.设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
小组讨论，项目经理完成。合适
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？
登录功能上，不能做到单线登录，还有修改信息等。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由开发和测试人员一起进行复审。是。

6.测试/发布

团队是否有一个测试计划？为什么没有？
没有。时间不足。
是否进行了正式的验收测试？
是。
团队是否有测试工具来帮助测试？
使用IDEA编译器自带的测试工具。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有使用
在发布的过程中发现了哪些意外问题？
无。

7.总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
可管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进？
团队合作更加成熟，每个人都做好自己的任务。
你觉得目前最需要改进的一个方面是什么？
增加代码能力储备，开发能力的加强，投入时间。

团队成员在Alpha阶段的角色和具体贡献