软工网络15团队作业7——Alpha冲刺之事后诸葛亮

事后诸葛亮分析

设想和目标

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

（1）我们的项目要解决的问题是：帮助考研人群记忆考研单词
（2）是，定义清楚；根据之前调查的用户需求进行定义。
（3）是，对典型用户和典型场景有较为清晰的描述；典型用户：考研大军；典型场景：零碎时间以及想要记忆单词的时间，在任何场合。

2.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的？

我们刚刚完成Alpha阶段，并没有上一个阶段。但这一过程也是一个我们不断学习进步的过程。从一开始的懵圈状态也慢慢开始有了比较明确的规划和计划。
（“和上一个阶段相比”这个地方有点理解不清楚）

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

离最初的目标还是有一定差距。
（1）我们完成了页面设计编辑等，但由于还没有连接到数据库，导致基本功能还不能实现。
（2）尚未发布，等于没有按时间发布吧。
（3）因为尚未发布，所以并没有达到原计划用户数量。

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

（1）小程序尚未发布，暂时没有用户量；因此未知用户对重要功能的接受程度。
（2）纵使没有完全实现功能，我们离目标的脚步还是在前进的。

计划

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

因为平时还有其他的课并且大家都在准备毕业之后的出路，考公的、考研的等等，因此并没有很充足的时间来做计划。

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

大家一起讨论，每个人说出自己的想法，然后大家一起讨论出觉得最合适最好的计划。

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

（1）原计划的工作还没有全部做完。
（2）首先最初规划没有规划好，导致每天进行的情况不好；其次技术能力不够，特别是最重要的数据库的连接遇到了瓶颈；最后，时间调整不好并且整体心态不够好。

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

暂时没有，都在很努力的学习项目开发的每一个过程。

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

在计划的时候并没有清楚的明白每个任务，比如服务器的流程等等；在做的过程中逐渐清楚每一项任务的定义和衡量的交付件，花的时间挺多的。

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

（1）项目的整个过程基本按照计划进行，但是没有连接数据库，功能没有实现，也没有想到可以先做一些测试用例存储在本地。
（2）关于服务器等后端的资源方面；不够了解微信小程序发布流程，没有考虑到服务器/域名方面的申请创建备案等。

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

有，缓冲区在五一假期，令每个人可以舒缓压力。

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

在将来的计划中，主要就是要将计划划分到最小的细节，以便更好的完成每一项任务。

资源

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

在服务器方面，需要自己申请的资源较多，比较不熟悉；
在开发方面，技术不过关；
在连接数据库方面，对服务器上的数据库了解不够充分；
在数据方面，没有好的方法整理要用的数据。

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

各项任务所需的时间和其他资源按照团队的能力进行估计；
精度较为准确，但是，由于每个人没有拿出相应的时间，以至于任务没有完全完成。

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

（1）测试的时间一般都是跟着代码一起完成的，用户对于功能的测试并没有完成；人力资源和软硬件资源是较为足够的。
（2）美工没有估计到完成的难度问题，设计的较为复杂，希望在Beta阶段能够完成。

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

除了对博客的编写可以由团队一起完成之外（轮流或者合作），我们要做的事情都应该按照自己的分工来完成，这样反倒最有效率。

变更管理

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

是的，我们会通过线上（Q群/微信群）线下（站立会议/课余时间）及时交流。

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

“推迟”功能一般在前后端的开发不好实现且该功能是非必要功能的时候。

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

我们对项目的出口条件设定为每一个功能都可用并且每个成员都使用的较为满意。

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

如果是比较大的变更，我们会一起讨论如何处理这个变更。

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

是，大家一般都能较快程度的接受并着手处理。虽然目前出现的“意料之外”比较小，但大家在以后的工作中都可以有很好的经验借鉴。

设计/实现

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

（1）设计工作在用户需求调研之后项目开发之前设计（用户需求之前也有了一些构想），由全部成员共同完成（每个人提出自己的设计理念再从中提取更好的）。
（2）是合适的时间，合适的人。

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

设计工作没有碰到模棱两可的情况。（是有了构想再根据用户需求进行更改的）

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

（1）我们使用墨刀进行了原型设计，工具有效。
（2）项目开始的 UML 文档和现在的状态有一些出入，比如我们暂时搁置了词汇书这个功能。
（3）这些区别产生于技术不足以及实际情况不符。
（4）已做完的相应部分以及做出修改的部分需要更新。

4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

（1）背单词和查询单词等需要用到数据库的Bug比较多；原因：没有比较好的掌握对这些功能的编写。
（2）未发布，但在体验版中未发现较大问题。
（3）设计的时候没有考虑到在实际上实现该功能的难度。

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

（1）代码复审中，首先确定是可运行的，再查看是否有不需要的代码。
（2）严格执行了代码规范。

测试/发布

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

有测试计划，但是除了程序可运行外我们没有进行其他测试。
原因：首先我们团队因为某些原因，之前博客也有提到，在Alpha冲刺阶段没有完成小程序的功能，所以就没有做测试的计划，决定在之后的阶段完成功能再进行测试。革命还在继续，我们必须努力。

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

否。原因如上。

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

微信有自带的测试工具，可以生成测试报告，需要我们进行远程调试然后测试数据会自行导入程序界面中，这个我们测试的小伙伴还在学习阶段，在我们结束开发后会利用该测试工具进行测试。

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

（1）主要是借助微信小程序开发工具中自带的一些调试工具还有数据库的获取，程序响应用户请求时间来看的。
（2）从软件实际运行的结果来看，这些测试工作具有一定效用；比如在代码调试上，报错明确。
（3）在自己的项目中应更加注意细节问题还有各个代码的融合问题。

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

前期了解的内容不够充分，导致数据库与前端没有进行连接，所以没有将单词内容导入，也就功能还不完善。而且一开始不知道通过服务器的链接的事项，微信小程序平台的审核要求等等，该开发版本还没有发布。

总结

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

团队目前的状态属于CMMI中一级（初始级）与二级（管理级）之间。项目的目标大部分完成，在项目实施上大都能够遵守既定的计划和流程，资源准备较为充分，对相关的项目实施人员有相应的知识学习，对整个流程基本把握，但是对项目的审查和测试不够。

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

团队目前处于规范阶段但还未完全成型。这一阶段我们相互配合，很多事情都有了一致的看法，比如在功能的设计上。

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

在前一个里程碑，我们完成了对用户需求的调研，完成了需求规格说明书。
而团队在这个里程碑中，我们根据用户需求开始了项目的开发。

4.你觉得目前最需要改进的一个方面是什么?

对于任务的细分以及每个人任务的落实。

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

对照敏捷开发的原则，相对来说做的较好的有：
“5. 以有进取心的人为项目核心，充分支持信任他们”——在每次想要退缩甚至放弃时，总会有想前进的人带领着一起走下去（具体事例好像不好说）。
“6. 无论团队内外，面对面的交流始终是最有效的沟通方式”——除了每次的站立会议之外，大家遇到问题也会及时当面讨论（毕竟是隔壁宿舍比较方便）。
“8. 敏捷流程应能保持可持续的发展”——虽然我们的项目成果不是很理想，但是我们按照自己的步调初步完成了自己的任务。
“9. 只有不断关注技术和设计，才能越来越敏捷”——我们的技术水平较为薄弱，学的进度是慢的，但是还是在不断学习。

其他

Alpha冲刺，很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是，各组对于软件工程的“Learning by doing”的内涵了解的还不深刻，遇到的问题也不少。停一停，开个总结会，来次事后诸葛亮，为了下一步走的更好。请各小组在Deadline之前，召开事后诸葛亮会议，发布一篇事后分析报告。

1. 总结的提纲内容，请参照课本15章内容或邹欣老师的博客：

a. 项目管理之事后诸葛亮会议：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html
b. 博客要附上全组讨论的照片。

2.根据展示博客中给出的团队成员在Alpha阶段的角色和具体贡献排序：

名字	角色	贡献排序	可验证的贡献	学号	个人贡献分
赵铭	后端开发人员	2	后端数据库，已经可查询	201521123093	23
吴慧婷	PM，前端开发人员	1	前端代码整理，背单词功能，发布体验版	201521123094	26
刘舒婷	后端数据整理/测试人员	5	后端数据库数据整理	201521123096	16
陈敏	前端开发人员	4	前端功能设计：查单词	201521123099	19
吴雅娟	前端开发人员	3	前端功能设计：词汇选择，我的世界	201521123103	21
杨娟	前端设计人员/测试人员	6	完成前端界面设计（外观）	201521123104	15

—————————————————————————————————————————————————————
参考实例
http://www.cnblogs.com/CSLaker/p/6099218.html
http://www.cnblogs.com/ruangong3165/p/6099006.html#wow4
http://www.cnblogs.com/linjin/p/6098937.html