团队作业7—事后诸葛亮分析
事后诸葛亮分析
Alpha冲刺，很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是，各组对于软件工程的“Learning by doing”的内涵了解的还不深刻，遇到的问题也不少。停一停，开个总结会，来次事后诸葛亮，为了下一步走的更好。请各小组在Deadline之前，召开事后诸葛亮会议，发布一篇事后分析报告。
1.总结的提纲内容，请参照课本15章内容或邹欣老师的博客：
a. 项目管理之事后诸葛亮会议：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html
b. 博客要附上全组讨论的照片。
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？ 我们的软件要解决日常生活中app记账繁琐功能的问题，就是要做一个符合大众需求的的记账小程序，并且带有提醒和督促的功能，对典型用户和典型场景的描述比较少，一般针对的是学生党，用于生活消费支出和收入的记录。
- 是否有充足的时间来做计划? 我们现在还是学生，平时也要上课，也要顾及其他的课程，所以计划也是匆匆忙忙，猝不及防，就开始了alpha阶段的冲刺。在期间也不断更改计划，讨论功能的设计等等，觉得不合适的地放立马就变更计划，但是总体的计划是没有改变的。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？ 有意见就可以及时提出来，比如觉得功能的冗余，功能的繁琐，或者实现难度太大都可以商量，因为如果花太多时间研究一个组件的使用而影响整体的进度反而会得不偿失。如果大家有不同的意见，项目经理会斟酌利弊，最后定夺。
计划
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么? 原计划的工作没有都完成。原因：一开始后端的交互没有头绪，大家全部开始做前端界面，界面差不多的时候，后端才开始，结果后端的功能研究时间花费得较长，导致进度推迟，前端界面也几乎停滞不前，最后几天加班，所以完成得比较仓促。
- 有没有发现你做了一些事后看来没必要或没多大价值的事? 有！比如找颜色，对齐，调大小，调边距，细致到 rpx，我也是很醉。。。还有就是某天纠结一个授权界面跳转的的问题搞了一个晚上，最后才发现其他界面根本不能跳转到index界面。。。个人觉得可能是个主界面，不容许其他界面跳转到此，而且删掉了这个page，它还会自动生成，这个就很浪费时间，这个道理告诉我们不要瞎搞瞎搞。最后说一点，每日站立会议拍照时候，我们会争论要放哪张照片，最后演变成谁写博客，照片上就是谁好看。。。
- 是否每一项任务都有清楚定义和衡量的交付件? 并不是，我们在做的过程中发现问题任务有不合理的地方就立马改，立马做。由于时间的关系，有些小细节的地方没有考虑到，与预期有一点差距，需要到后期进行完善。
- 是否项目的整个过程都按照计划进行? 前一部分的时间基本是按照计划进行的，但是后半部分，我们遇到了技术上的难点，毕竟我们都是头一次接触微信小程序，没有任何项目开发的经验，需要不断地挖坑，踩坑，填坑，过程坎坎坷坷，导致进度偏慢，最后超期才完成。
- 在计划中有没有留下缓冲区，缓冲区有作用么? 有留下缓冲区，比如连续三个晚上一起写代码之后，第四天就不要求集中学习，可以自行安排，再学我怕有人要跳楼。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班） 给大家缓一缓的时间，经验告诉我拉紧的弦容易崩，人也一样，也会容易产生情绪。 计划上就要强制要求大家再某个时间段内把自己的任务完成，遇到困难，有问题可以相互交流，完成之后，想干啥干啥。
资源
- 我们有足够的资源来完成各项任务么? 我们做的是微信小程序，用到的资源并不多，微信web开发工具，远程服务器一台，java web的环境,tomcat的环境等等都需要花费一定的时间来准备环境。
- 各项任务所需的时间和其他资源是如何估计的，精度如何? 开始做任务分配的时候，写得比较细致，但是真正实施起来还是有差距的，因为我们无法预料到未来会遇到什么困难，无法精确地估摸时间。任务所需时间的估计主要从难度和成员技术上来估计的。
- 用户测试的时间，人力和软件/硬件资源是否足够? 我觉得还不够。测试地比较仓促，比较粗糙地完成。
- 你有没有感到你做的事情可以让别人来做（更有效率）? 我个人更喜欢一个人做事，但是有的时候纠结的一个地方，旁观者反而会更清，我觉得可能是看问题的角度会不一一样。我主要负责的是后端的代码编写，觉得自己做会比较好，如果交付给其他人，还需要说明环境的配置，代码的编写规范等等，也比较费时。
变更管理
- 每个相关的员工都及时知道了变更的消息? 我们创建了qq群，当面不能及时说明的，我们会在群里说，而且我们6个人是一个班的，宿舍就是连着的三间，大家交流也比较方便。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能? 必须实现的就比如说记账功能，这是我们最最最核心的功能，如果一个记账小程序不能记账，那我们要它何用？推迟的功能比如设置月预算，报表等等，这些感觉可有可无，有了更好，没有也不影响，最主要是要从用户需求上面考虑的。
- 项目的出口条件（Exit Criteria）是否得到清晰的定义? 项目出口条件？我们不是很清楚这是什么东东，所以嘛，我们根本没有定义过。
- 对于可能的变更是否能制定应急计划? 如果应急情况没未分配出去的话，差不多就是PM上了（我也很绝望），但是如果这个任务是归属于某个团队成员的，那么就是她来负责，有问题的依旧还是可以互相沟通交流的。
- 员工是否能够有效地处理意料之外的工作请求？ 比如遇到一个问题，实现的效果会与预期的不太一样，但确实不知如何下手，那么这时候就会转变策略，尝试新的方法，团队成员多数是可以有效地解决。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？ 设计工作差不都是在需求分析之后的，界面设计由负责前端的成员来完成比较合适，我认为是比较合适的人，这样大家在设计的时候至少有个框架和方向，不至于各自用各自的界面风格，导致界面混乱。后端数据库就要结合我们要实现的功能来设计，由后端开发成员设计比较合适，因为后端要熟悉数据库的结构才能更好地完成后端的编码。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？ 有，比如设计数据库的时候，没有考虑到主键，对实际情况把握不到位，功能发生了改变等等都会直接造成重新建表，重新设计。团队经过不断地讨论分析来解决，确定了思路之后，由后端开发人员来实现。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 没有用到单元测试，后端只有对数据库的操作，代码就600行左右比较少。因为还不习惯用单元测试，就使用传统的打印输出结果来找bug。我们在这个过程中使用UML，E-R图来帮助设计和实现，这些工具还是有效的，比较直观。
- 什么功能产生的Bug最多，为什么？ 邮箱绑定那边，暂时无法判断邮箱是否有效，我们还得到下一个阶段才能完善。还有设置月预算那边，实际的情况是用户在没有设置月预算的情况下，数据库里面应该是有用户的数据的，但是我们的做法是在用户第一次登录的时候默认创建了未来三年的月预算，占用了数据库的存储空间，万一用户之后不使用了，那么这就是一种空间的浪费，同样这个bug我们后期还需要修复。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？ 代码复审，主要为了检查代码的统一，检查一些细节的地方。要求团队的成员要按照一定的规范，可以让其他成员看得出来这个功能是做什么的，或者这个样式是给哪个组件用的，不至于别人的代码很难看懂。比如我在写后端的时候，功能的命名全部都是小写的，比如：insertusers，findbudget，顾名思义可以看出来，这个是插入用户数据和查找账单的功能等等。
测试/发布
- 团队是否有一个测试计划？为什么没有？ 没有测试计划，原因很简单，因为时间太赶了，测试就由一个比较了解整个项目流程和功能的人来做测试。其次是因为在alpha阶段我们“喵喵喵记账小程序”完成了基本的记账功能和基本数据与后端数据库的写进读出，其他的就是一个界面可查的功能了，因此我们在这个阶段我们并不是特别需要花时间在这个测试上面，有的话都是经过我们小组成员进行远程调试就可以发现的问题漏洞。
- 是否进行了正式的验收测试？ 有，但是不能说是正式的验收测试，正式的验收我们需要多成员来使用我们的小程序迫于时间的关系我们虽然发布了但是未赶在答辩之前审核通过，至于数据库的耐力和小程序的支撑力是否足够都没有得到正式的数据支持。
- 团队是否有测试工具来帮助测试？ 微信有自带的测试工具，可以生成测试报告，需要我们进行远程调试然后测试数据会自行导入程序界面中，并且PM在后端腾讯云数据库中也有自带辅助工具进行测试。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？ 从数据库获取数据的时间效能带上分析，其实感觉这个时间效能分析好像没多大能帮助到我们这个阶段的，我们可能更倾向于功能性的认可。
- 在发布的过程中发现了哪些意外问题？ 比如不知道是小程序平台本身的运作关系还是我们数据库的处理问题不当，总是会出现卡壳没数据更新，最后实现的完整版整合发放到各个成员手里时总是不间断的出现了未预期的结果。
总结:
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们的团队目前还处于CMM/CMMI 中的管理级，这一阶段的判定标准是：产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。
我们团队是有组织有纪律的团队，我们将一个项目系统地划分，将任务功能细分后分配给团队成员，最后再整合大家的成果，而且我们已实现建立过程数据库，获取数据库的数据呈现到前端的界面上，对成员角色分工，对整个项目过程有较好的把握。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段? 我认为我们团队处于规范的阶段。
最开始将界面设计的任务分配下去，大家都是按照自己的喜好，没有统一颜色和标准进行界面的设计，导致整合的时候很丑陋，前端开发成员及时作出调整，统一风格，最后效果良好。
其次，我们小组6个人都没有项目开发的经验，也没有这么多人合作的经验，做事上面还是会出现我行我素，但是经过大家每日站立会议的共同和交流，总结昨天做了上面，今天做了什么，遇到了什么困难等等，有了一个团队的样子，逐渐进入规范化。
再则，在代码上，我们制定了一个编码规范，要从名字就能猜测其用途或者功能，使整体的效率变高，更好地进行学习和交流 你觉得团队在这个里程碑相比前一个里程碑有什么改进? 在前一个里程碑，我们完成了用户需求的信息采集，完成了需求规格说明书。这个里程碑是真正实现了这个需求，相比，我们去掉了一些繁琐的功能，界面美化了，使用户更清晰软件的使用。我们也去掉了自己选择消费类型图标的功能，我们认为这个功能可有可无，对记账这个功能的影响不大，最后采用备注替代这个功能。还有记账提醒采用邮箱的方式，在实现方面会比较好入手，但是这个里程碑只实现了绑定邮箱，具体的功能待下一个阶段实现。 你觉得目前最需要改进的一个方面是什么? 功能实现还不完全，报表功能和设置月预算的功能还未完成，记账提醒作为杀手功能刻不容缓 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 我认为我们小组做得做好的几个原则是：
- 以有进取心的人为项目核心，充分支持新人信任他们
- 无论团队内外，面对面的交流始终是最有效的沟通方式
- 保持简明——尽可能简化工作量的技艺——极为重要
2.根据展示博客中给出的团队成员在Alpha阶段的角色和具体贡献排序：
| 团队成员 | 角色 | 贡献值 | 排序 | 可验证的贡献 |
|---|---|---|---|---|
| 林羽晴 | 王者 | 24% | 1 | 后端数据库的所有处理工作、前端“我的界面”的设计和优化 |
| 顾芷菱 | 星耀 | 18% | 2 | 记账界面的处理和小图标优化放置、测试效能、博客撰写主力军 |
| 丁蓉 | 钻石 | 17% | 3 | 记账界面的处理和小图标优化放置、测试效能、博客撰写主力军 |
| 洪亚文 | 铂金 | 16% | 4 | 明细界面的数据处理、月预算的初略设置 |
| 秦贞一 | 铂金 | 15% | 5 | 前端领头羊、报表界面的设计和优化 |
| 齐畅 | 黄金 | 10% | 6 | 明细界面的美观调试、测试军 |
既然同学们上这个软件工程课，那么就希望大家能够认真的参与到软件工程实践中来。当然，同学们的投入程度会有所不同，所以我们就把大家做了哪些工作亮相给大伙看看，把这些情况量化出来，摆在大家面前。 酱油在哪里，大腿在哪里就一目了然。这样我们的团队贡献分就很好决定了。
请根据每个团队个人贡献排序，总分为N*20，给出每个人的团队个人贡献分（排序无并列，因此每个人的个人贡献分不同）。
- 参考实例
- 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