事后诸葛亮分析（广工扫“蝗”小分队）

事后诸葛亮分析（广工扫“蝗”小分队）

目录

• 事后诸葛亮分析（广工扫“蝗”小分队）
• Part one 作业地址
• Part two 总结提纲
  • （一）Postmortem
    • 1、计划和目标
    • 2、计划
    • 3、资源
    • 4、变更管理
    • 5、设计/实现
    • 6、测试/发布
    • 7、总结
  • （二）讨论照片
• Part three 团队成员在Alpha阶段的角色及贡献

Part one 作业地址

这个作业属于哪个课程	软件工程
作业要求	团队作业6——复审与事后分析
作业目标	团队集体协作完成项目开发，促进彼此间的交流

Part two 总结提纲

（一）Postmortem

1、计划和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   我们的软件主要是给大学生用户提供一个购买生活用品以及二手书本的途径，我们的定义很明确，做一个专门服务大学生的平台，在前面的博客中对典型用户和场景进行过明确的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
   很遗憾，限于精力和时间，我们仅完成了大部分目标，原计划功能已实现的有用户显示界面，购物车功能，商品购买功能以及个性签名和收货地址功能。由于一些小问题，我们比原计划交付时间晚了几天，因为没有进行相关推广，故没有达到原计划用户数量。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   由于缺乏推广，用户量与预想不一致，另外通过其他团队对我们的评测复审，可以看出我们的项目过于单一，购买商品的功能还是不能完善，因此我们离目标还有很远的一段路要走。

2、计划

1. 是否有充足的时间来做计划?
   是的，有充足的时间进行计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   通过微信会议，先各自提出自己的想法，再依据商城的具体情况进行判断选择，或进行投票决定
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   基本工作都完成了，后面因为其他考试，限于时间精力，没有对一些完善商城商品的功能进行整合
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   暂时没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
   是的，交付件由组长和测试进行最终衡量
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   项目后期出了一些问题很难处理——商城商品展示的界面显示，是因为前期设计的时候没有考虑好，导致后面完成该功能时会与项目整体框架发生冲突，主要原因还是缺乏项目经验吧。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   有，起到一定作用。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   在设计项目的时候考虑更多点，将组件要求描述更加清楚方便开发人员进行开发。

3、资源

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

• 人力资源：我们团队有6个人，除了PM外，有3名开发和2名测试
• 开发资源：组长整理了部分开发所需的基础知识和技术文档
• 设备资源：人手一台电脑，足够完成开发测试任务
• 时间资源：有些紧张，其他课程也有实验课设作业和考试，软工的项目时间跨度和工作量有点大。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
   组长发布任务后，由组员先自我评估，组长再结合整个项目进行评估，主观评估因此精度不是很准。
3. 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
   不太足够，美工设计上低估了难度，从其他人的复审可以看出，我们的界面过于单一。
4. 你有没有感觉你做的事情可以让别人来做（更有效率）？
   一般来说开发人员编程后应顺手进行单元测试，这样会比让测试人员去测试更有效率，因为此时开发对代码的整个逻辑更为熟悉。

4、变更管理

1. 每个相关的员工都及时知道了变更的消息？
   基本知道，成员更新代码后会上传至Coding.net，并在微信群通知一下大家，测试人员测试有问题时也会进行告知。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
   基础功能“必须实现”，次要功能或实现难度过大则可进行“推迟”。

3. 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？

   有，定义如下：

   • 软件不崩溃闪退
   • 测试发现的bug得到修复
   • 典型用户场景得到测试并无bug
   • 测试矩阵中的典型情况得到测试并无bug

4. 对于可能的变更是否能指定应急计划？
   我们进行了良好的分支管理，对于提交的功能，经过组长和测试review发现没问题后再对项目分支进行合并。即使发生意外，也可以通过回退至上一个正确版本再进行问题解决。

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

5、设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   设计工作在项目开始的第一二周进行，主要由组长来完成，辅以成员讨论。时间充裕，人员合适。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   进行开发时，开发人员与组长的预想实现方式可能不一样，一般这时候会选择在微信上进行会议讨论，选出最佳解决方案。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
   虽然仅是简单的一款大学生综合性平台，但我们运用过单元测试对功能模块进行测试以及利用UML进行需求分析和模块划分。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   返回主商城的界面和加入购物车界面，由于跟早期的设计理念有一定冲突。发布后发现图片资源无法正常加载，商品的购买跳转链接无法正常实现，这导致了商城界面过于单一。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   由组长和测试进行Code Review，由于开发初期已制定代码规范，故对代码规范有做要求。

6、测试/发布

1. 团队是否有一个测试计划？为什么没有？
   有，详见上一篇博客。
2. 是否进行了正式的验收测试？
   进行过验收测试，但不够正式严格。
3. 团队是否有测试工具来帮助测试？
   仅单元测试工具，如Junit
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
   软件的效能主要是指的是商城商品浏览过程中的流畅性和功能的正常运行，从实际结果看，开发工作和测试工作都完成得不错。
5. 在发布的过程中发现了哪些意外问题？
   发布后发现商品的具体介绍界面的图片资源无法正常加载，还有商品购买的跳转链接无法实现

7、总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
   达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
   我认为到团队处于磨合和规范阶段之间，很多事情上能取得一致，但整个团队的规范仍需要完善。
3. 你觉得目前最需要改进的一个方面是什么?
   功能模块的划分需要更清晰明确，方便开发人员进行开发，也减少Bug的发生。角色和职责定义要落到实处，避免出现成员间任务负担失衡。

（二）讨论照片

Part three 团队成员在Alpha阶段的角色及贡献

姓名	角色	团队贡献分	可验证贡献
张天	PM	25	撰写博客，功能代码编写
曾春华	DEV	21	撰写博客，功能代码编写
曾广宁	TEST	22	撰写博客，代码测试
黄炜恒	DEV	24	撰写博客，功能代码编写
黄浩捷	DEV	23	撰写博客，界面开发
陈伟升	TEST	21	撰写博客，代码测试