事后分析

设想和目标

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

Alpha阶段要解决的问题是：根据用户标注的信息完成知识图谱的生成渲染。要解决的问题定义得比较清楚，在功能规格说明书中给出了详细的原型设计。对典型的用户和典型的场景描述可以参见功能规格说明书
我们达到目标了吗？（原计划的功能做到了几个？按照原计划交付时间交付了吗？原计划达到的用户数量达到了吗？）
- 实现了的的功能有：用户登录注册、登出、实体的添加删除、实体关系的添加、知识图谱的渲染。未实现的功能有：导入文本、导出图谱数据结构、保存项目。
- 交付时间：原计划4.29交付，我们在削减了一些功能之后基本按时交付。
- 用户数量：我们预计发布一周后用户注册量为200，截止5.5日，我们的注册量为59人，未能达成预期用户数量。原因分析参见Alpha - 项目展示
总体来说，我们在Alpha阶段的目标并没有完全实现。主要原因是前后端的学习成本非常高，在冲刺阶段大家都还在学习开发相关的知识，这也导致开发时间被大量压缩。
和上一阶段相比，团队软件工程的质量提高了吗？在什么地方有提高，具体提高了多少，如何衡量的？

没有上一阶段，我们从0开始开发的。
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 实际上用户量虽然远远小于团队项目选择时的预期，但在项目发布前夕我们也做好了心理准备来面对这样的结果。但是从用户的反馈来说，用户对知识图谱的美观程度是给予了肯定的，同时也提出了文本标注方面的不足之处。
- 我们的确离目标更近了，从0开始我们已经搭建起了一个框架，后续Beta阶段我们会进行更敏捷的开发。
- 经验教训就是前后端的开发一定要遵从文档，仅凭口头约束是不够的。任务分配一定要合理，PM在做任务分配时要和组员多加沟通，让开发过程更加流畅。如果历史再来一次，我们一定要提前开始学习开发相关的知识。

计划

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

是的。在Alpha阶段前期大家都在学习开发相关的知识，PM有充足的时间来做原型设计、任务拆解等工作。PM每天会跟开发人员沟通来进行下一日任务的分配。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

团队成员会在每日例会上进行讨论，PM会根据成员的意见对任务做出调整，最终的每日任务分配要得到当事人及其他成员的认可。
你原计划的工作是否最后都做完了？如果没做完的，为什么？

没有做完。主要原因：
- 前端技术力受到限制，一些功能的开发需要较长时间；
- 前后端在对接上出现了很多问题，解决这些问题时耗费了大量时间。
有没有发现你做了一些事后看来没必要或者没多大价值的事？

没有。开发、测试、PM都做了有价值的事情。
是否每一项任务都有清楚定义和衡量的交付件？

在任务拆解中所规定的任务都有清楚定义和衡量的交付件。后端体现为代码、接口文档，前端体现为网页模板等，测试体现为测试代码，PM体现为相关的博客。每日会议上的任务分配有一些比较模糊的部分，没有很清晰的交付件。
是否项目的整个过程都是按照计划进行，项目出了什么意外？有什么风险时当时没有估计到的，为什么没有估计到？

项目基本上是按照计划进行的。但是在一些DDL没有被很好地遵守。出现的主要意外是前后端对接上的bug。

没有评估到的最大的风险是PM对一些功能的开发时间预估得过于乐观。大家都对相关的技术不是很熟悉，PM没有预留出足够的时间，开发人员也没意识到这个问题。幸好开发人员及时反馈，组内讨论之后对功能进行了化简。
在计划中有没有留下缓冲区，缓冲区有作用吗？

项目整体的缓冲区留在最后一周的稳定发布阶段。在这个时间内，我们集中解决了很多bug，完成了一些收尾的工作，缓冲区很有用。
将来的计划会做什么修改？

优先完成文本标注的功能，核心功能优先实现。在每周的任务分配上都留下组员休息或者加班的时间。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

在Alpha阶段开始一周后，我们对任务拆解进行了调整，每个人分配到的任务都不同程度地进行了改变，这就导致大家前期地学习方向发生了变动，一定程度上降低了大家的效率。

在任务安排上，每个人每天的时间多寡根据课程安排会有不同，如何平衡每个人任务量的同时不影响前后端的开发进度，对PM来说是一个挑战。

如果历史再来一遍，我们在做任务拆解时会留下更多的缓冲区，跟组员交流要更详细、彻底一点。

资源

我们有足够的资源来完成各项任务吗？

后端在Alpha阶段的开发有着足够的时间、技术资源。但对前端来说，时间和技术资源都十分有限，因此前端的开发压力是比较大的。
各项任务所需要的时间和其他资源是如何估计的，精度如何？

每日例会时由PM和组员协商讨论，精度一般，往往会出现一些预期之外的情况。
**测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? **

对测试来说，Alpha阶段的资源还是比较充足的，我们有专人进行后端测试，PM会兼顾前端的测试和美工设计。

关于美工设计，团队没有将之放到一个足够重视的地位。但就Alpha阶段的开发来说，美工设计方面的难度不是很大。
你有没有感到你做的事情可以让别人来做（更有效率）？

我们团队的分工还是比较明确的，大家的任务都比较具体，从技术上来讲专攻的方向也不尽相同。所以可能没有这种感觉。有成员在开发阶段向PM反映过一些压力，但是在后续都通过自我疏导解决了问题。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?

前端因该安排3人进行开发，或者PM应该尽早参与前端的开发，这样才能更好地完成前端的任务。应该将团队的资源集中到核心功能的开发上。

变更管理

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

是的，每日例会上会对任务进行安排，如果有变化，PM会随时和各位组员联系。
我们采用了什么办法决定“推迟”和“必须实现”的功能?

在例会上进行讨论，前后端会提出意见，由PM整体把握进行决策。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有，参见功能规格说明书
对于可能的变更是否能制定应急计划?

没有预先的计划，一般都是在会议上决定任务变更之后由PM另行制定计划。
员工是否能够有效地处理意料之外的工作请求？

我们在前后端对接时出现了很多bug，前后端都能根据PM的要求进行修改。在前端开发时总会遇到API“不够用”的情况，这时后端也能及时应对。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

做计划时要考虑到计划失败的情况，每周应该留出一天的时间进行休息/加班。对接口设计方面PM应该做更充足的考虑。

设计/实现

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

设计工作在Alpha初期由PM完成。PM进行了功能设计和原型设计。时间合适，如果当时设计能和组内的多加沟通会更好。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，针对这些情况，一是参照功能规格说明书，二是与PM进行沟通交流。
团队是否运用单元测试、测试驱动开发，或者其他工具来帮助开发？

我们团队进行了单元测试、覆盖率测试、issue进度管理、愿你下那个设计等工具，这些东西都很大程度上帮助了我们的开发。在Beta阶段我们会延续使用这些工具，让开发更加顺利。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 实体和关系的添加发现的bug最多。因为前后端沟通不及时，前端返回给后端的json格式出错，导致后端没能成功解析。
- 发布之后最重要的bug就是IE浏览器不能进行正常的页面重定向。这个bug我们目前还不清楚原因，还没有解决。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

我们没有指定严格的代码规范，后端使用的PyCharm的PEP8规范，前端要使用一些模板，所以没有规定代码规范。代码复审是由测试和PM进行的，王政同学进行了后端的代码复审，PM进行了前端的代码复审。
我们学到了什么？如果历史重来一遍，我们会做什么改进

设计一定要清楚详细，尽量能准确清晰地描述出功能的细节。单元测试十分重要，在前后端对接出问题时后端的单元测试能提供很大的帮助。若果历史重来，PM在做原型设计的时候会进行更详细的考虑。

测试/发布

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

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

是。在发布前，我们对前后端都进行了详细的测试。不过遗憾的是，我们没有进行压力测试。
团队是否有测试工具来帮助测试？

后端采用了Django的测试框架。前端没有使用测试工具，主要是使用主流的浏览器进行兼容性的测试。
在发布的过程中发现了哪些意外问题？

发布过程中，我们遇到了firefox、IE等浏览器上会出现实体无法添加等问题。我们详细查看了后台结果，发现是前端数据异步更新导致前端与服务器断开连接。针对这个问题我们进行了修改。

其次就是发布时大家的反映并不是很好。我们这个阶段项目的功能不是很完整，使用起来还是比较简陋的，所以会有这个问题。
我们学到了什么？如果再来一遍，我们会做什么改进？

关于测试，我们会进行更纤细的测试，并进行压力测试。时间充分我们还会对测试出的bug进行修复。

团队的角色，管理，合作

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

团队的角色时大家抽签决定的，在抽签的基础上根据大家的意愿进行了调整。总的来说大家都没有这方面的开发经验，姑且还算是合格，PM有时也很迷茫。
团队成员之间有互相帮助吗？

有，PM会帮前端做一些工作。后端与测试之间也会进行一些沟通交流。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

在每日会议上交流讨论，PM也会组织小会议与出问题的组员进行商讨。

成员的感谢

姓名
李健	我感谢博哥和阳子哥，他们能够在做好自己工作的同时帮助我解决一些我自己难以解决的问题。
柴博	感谢刘阳对我的帮助，在前端任务压力大的时候及时调整目标；感谢李健，帮助我建立前端的框架。
刘享	我感谢刘阳对我的帮助，因为他承担了重要的pm工作让项目有序的运转起来。
王政	我感谢刘享对我的帮助，因为某个具体的事情: 在写后端接口测试时，帮我解读后端代码，解答我的困惑；我感谢刘阳对我的帮助，因为某个具体的事情: 我在服务器部署发现部分端口未开放时，向刘阳寻求帮助，他积极与助教、老师沟通，解决了问题。
左正	开发比较独立，没什么跟其他人的交互。（不过PM在这里也感谢左正同学能负责地完成后端地开发。）
刘阳	我感谢柴博和王政对我地帮助。柴博和我一起解决了一些bug，在项目的设计上也给我提出了很多意见。王政同学协助了我一些代码复的工作，在项目进展缓慢的时候对我进行了鼓励，感谢。

总结

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

CMMI二级，管理级。基本实现了权责到人，软件开发流程有监控、审查。
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

磨合期，大家在这一阶段都进行了很多合作，已经有一个不错的合作模式了。
你觉得目前最需要改进的一个方面是什么?

做好任务安排，在功能设计上要花费更多的时间。

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

业务人员和开发人员在项目开发过程中应该每天共同工作。

PM每天都会跟前后端进行会议，及时沟通项目进度。PM会经常性地询问开发人员的进度。前端在开发过程中也会经常和PM进行交流。每日博客也会成为开发人员的任务指导书。
可用的软件是衡量项目进展的主要指标

我们在认定软件的进度时，通常不会单纯的检查代码，PM一般在项目可用的情况下才会认定为该issue已经完成。这样成员就会积极地协作去解决对接上地问题。