城市安全风险管理项目Postmortem结果

设想和目标

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

本系统希望实现快速识别危害因素，使工作人员对风险作出准确的评估。即让使用者熟悉潜在的危险因素，知道如何防止其发生，明确发生后如何应付。

我们认为已经定义的非常清楚了，在需求报告当中也有详细的用户场景。

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

我们的冲刺基本完成了原计划的功能，只有一些细节的处理可能还不是很完美（比如图表）。项目也是按照原计划的交付时间（即alpha冲刺的作业截止时间）提交的，所以总体来说我们完成了自己的目标。

3. 是否有充足的时间来做计划?团队在计划阶段是如何解决对于计划的不同意见的？

事实上，我们花了很大一部分时间在计划上。因为我们都认为尽量详尽的计划会有助于日后的项目开发，后续的冲刺也印证了我们的想法。面对团队内的不同意见，我们采取投票制度，少数服从多数。但其实由于组内两个女生能力相比两个男生有所欠缺，所以一般我们两个女生对技术上的事情不会有什么不同意见。

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

尽管我们花了很多时间在计划上，可能还是有所欠缺考虑得不够到位吧。比如导致某一天的冲刺有人员处于空闲状态，是当天临时再进行调整分工的。所以历史重来一遍的话，大概在计划上要考虑的更周祥一些。

计划

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

大体模块的功能算是都实现了，要说没做完的应该是图表没能达到我们预期的显示效果吧。因为大家对插件使用的不熟悉以及一些逻辑的复杂性导致我们做这块分级统计展示非常慢。

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

还好，本身冲刺的持续时间很短。我们做好了计划之后每天都马不停蹄地在赶进度，也只是做我们要完成的功能的事情。

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

对任务的定义是有，但衡量这个标准就显得很模棱两可了。而且项目没做出来之前，我们认为很多讨论都是没有意义的，你不清楚实现后的细节或者说不知道成品和预期会有什么出入。衡量这个东西，我们自己团队可能也没什么具体的评判标准。

4. 是否项目的整个过程都按照计划进行？

大体上是的，除了因为计划的分工有些不合理，当天临时调整了一下。

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

是想留缓冲区的，但是因为冲刺的时间太短了，没有再多余的时间留给缓冲区了。开发中遇到的很多问题只能个人及时调整，保证整个项目的进度。

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

其他功能大体都实现了，主要集中完善图表这一块的内容吧。也有一点时间可以留给缓冲区了。

资源

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

前期在开发的过程中，我们花了很长时间去熟悉底层的代码，去研究怎么用，如何用，这是花了比较长时间的。

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

根据代码量和难度来估计各项任务所需时间和其他资源，一开始我们就把精度分的很明确，细到每天要完成什么，谁要完成什么，都分的很明确，后期的时候，团队每个队员一直在赶代码，还好在团队的协作之下，进度勉强可以赶上。

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

测试时间不够，我们只能每天在赶代码，写代码之余，自己测试，有时会请学长学姐帮忙测试，没有专门的测试人员，感觉这样的测试量还是不够的。

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

我觉得写文档可以让会写文档的人来写更有效率。

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

有次调试一个页面，调整了很久，并且代码量很多，多而冗余，最后请教了同学，很快就解决了。如果历史重来一遍，如果自己花了两个小时三个小时解决不了的问题，可以适当的请教同学，否则自己效率低，连同团队的效率都会降低。

变更管理

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

我们团队都在一个实验室，我们团队四个有一个群，有消息可以直接当面交流，或者在群里发公告。

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

在时间较紧急的情况下，按功能的重要性，把较重要的功能分为“必须实现”的功能，把可以暂时缓一缓的分为“可以推迟”的功能。

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

我们的web系统测试基本稳定，

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

我们的代码基本是希望可以写成可以直接复用的，相似功能实现一个，另一个就能很快实现，相似的，有需求改动，是希望能做到改动量最小。

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

项目当中有遇到需要变更需求，都能比较好的解决，没有遇到大的意料之外的问题，整体来说比较顺利。

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

什么叫“做好了”，我们也不敢说自己的系统做好了，我认为如果重来，应该设一个专门的人员来做测试来加大测试量。

设计/实现

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

由于我们队员相互比较熟悉，这应该算是合适的人，在老师上课的时候开始讲要求的时候，然后我们就开始商量是否要组成一队，要进行什么项目，要怎么操作。后来在博客园上的作业发布的那天晚上，我们就进行仔细的讨论，项目由我们4个共同设计，设计的时间应该算是合适的吧。

2. 工作实现过程中有没有碰到不能解决的问题，团队是如何解决的？

工作过程中是有遇到一些难度比较大的问题的，不会的我们就组内讨论，不行的话就问学长学姐，问老师。

3. 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

是有部分区别的，由于我们在需求上的分析上有部分不合理，导致在实现的时候遇到一些冲突以及UML的不合理，随着工作的进行，慢慢的将遇到的问题解决了。

4. 在发布之后有没有发现bug? 我们在设计/开发的时候为什么没有想到这些情况?

是有发生bug的，由于我们在实现的过程中是边学习边工作的，虽然有一定的底子，但是不可避免的会遇到一些没有想好的问题或者自己不能解决的问题。但是所幸我们的bug不会有什么严重的影响。我们还需要不断提高。

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

我们学到很多以前没有遇见多的东西，比如在项目经验上的，与队友沟通交流协作上的等等。如果让我们在来一次，我们可能会将我们的需求弄的更加清晰，在项目开始前先进行一段时间的队伍磨合。

测试/发布

1. 团队是否有一个测试计划？

有的，团队在项目进行时会用一段时间来进行测试，而且在项目结束的时候也有测试安排。

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

是的，在项目的验收前有测试安排

4. 团队是如何测量并跟踪软件的效能的？

我们在测试过程中有队友相互测试，请实验室学长学姐进行测试，请认识的同学进行测试。我们的测试不是只有一次，而是不断循环测试，直到暂时没有发现bug为止。

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

在这个过程中，我懂得了测试的重要性以及一个软件在测试时候如果遇到问题没有解决会导致下次同样的问题不断出现。如果在来一遍，我们会在实现过程一步一步来，在一个功能完善之后再进行相似的功能，让相同的错误不要不断发生，并且不断提高软件的健壮。

团队的角色，管理，合作

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

由于各个模块之间的难易程度不同且我们小组的两个女生编程基础稍微薄弱点，所以刚开始安排她们比较基础的模块练练手，熟练之后再慢慢接触比较难的模块，大家配合得都不错，都能按要求完成指定的模块，达到人尽其才，能个发挥每个人的优势。

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

那当然了。一个好的团队离不开团队成员之间的融洽的沟通以及成员之间的帮助。每个成员发挥自己的优势，相互帮助。比如女生对html页面，css比较有优势就可以帮助男生调页面，男生逻辑相对比较好，可以帮助女生调bug等等。

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

我们实行一天一小会。主要对当前的项目进展和遇到的难题进行一下总结。当遇到模块之间有交叉时，我们都会开会讨论，明确需求和每个人具体需要完成哪个功能在着手开始编程。以免出现重复开发或者漏掉某些功能，从而提高效率。

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

    从整个项目来说，我们经过了选题、需求分析，编程实现，测试，验收等阶段学做了一个完整的项目。从中受益的太多太多了，论需求分析、文档编写、 编程能力、团队意识和团队沟通都有一个质的飞跃。但在项目过程中也遇到很多问题，这些都是我们日后应该多学习以及注意的地方。如果历史能重来，我们团队可能会在需求分析这块在多花点时间，因为这次的项目由于时间比较紧张，需求没有做足，导致后面的政府模块花了太多的时间，完全在计划之外。所以在之后的开发过程中，我们会在明确需求之后再开始动手编程。

总结:

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

我们团队目前的阶段应该是过了磨合期进入规划期。

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

首先编程能力的提升不用说，大家都增强了团队意识，团队成员之间都能融洽的沟通，乐于帮助团队的其他成员。

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

（1） 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

我们每天都会开一个短时间的会议，对今天开发规程遇到的难题，以及项目进展进行一下汇报总结。

（2） 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

我们是以每个大模块进行开发的。每个模块的完成都能先交给用户使用。

（3） 不断地关注优秀的技能和好的设计会增强敏捷能力。

这次遇到的主要难题是图表的显示。我们在使用chart.js插件之后，显示的效果不如意，想用更好的插件进行数据的图表显示，后来研究了下决定使用highchart.js进行图表的显示。