tiG - 事后分析与项目审计

施工中

事后诸葛亮分析

设想和目标

我们的软件的预期目标？

　　我们的软件主要是用来提供友好方便的Git版本控制功能，预期目标就是完成便捷提交和历史显示的功能。

我们达到目标了吗？

　　达到了预期的目标，基本功能按时交付。

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

　　考虑到中间考试等因素，我们最初设定预期目标不高，并非以发布为主要目的，所以最终并没有上线。

 

计划

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

　　有。

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

　　大家意见基本很统一，有不同意见的在开会过程中都讨论解决了。

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

　　已完成。

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

　　暂无。

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

　　是。

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

　　整个项目大致按计划进行，虽然中间有几场考试，但是队员们都在考试后积极参与开发，确保进度不受影响。

资源

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

• 人力资源：团队中一共有5个人
• 开发资源：参考Libgit2和Qt的官方文档
• 设备资源：每个成员各自的笔记本电脑
• 时间资源：较紧张    

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

　　预先根据开发计划进行估算，并考虑到成员学习使用Libgit2和Qt的大致耗时。

　　精度基本和实际情况一致。

测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？

　　各类资源基本足够，最缺乏的还是时间资源。

　　本次项目我们没有引入美工设计/文案，设计到UI的部分是仅作了基础的设计。

 

变更管理

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

　　不一定。一般只有重大更新或修改才会通过群聊或开会的方式逐一告知。更多情况下，即使没有及时了解变更消息，成员们也能通过Git的合并操作很好地解决冲突。

　　基本的策略是“谁负责开发，谁处理冲突”。

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

　　从需求程度和实现难度来综合考虑是否实现或推迟某项功能。例如，历史提交树的部分，考虑到后续考试较多以及这个功能并非刚需，故推迟了其bug的修复进程。

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

　　有定义。

　　定义如下：

1. • 程序可稳定执行，具有优良的鲁棒性。
   • 主体功能完善可用
   • 测试过程中发现的严重等级Bug均已修复

对于可能的变更是否能指定应急计划？

　　可以。团队对Bug的紧急响应和修复能力是不错的。在遭遇一些突发事件（如考试），也能通过后续的敏捷进行补足。

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

　　可以。在开发流程中，对于指定接口需求的不同，会向对应的负责者提出不同的工作请求，队员们对此的处理都十分高效。

 

设计/实现

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

　　设计工作安排在编写规范文档的阶段，由我来完成，主要是对程序主体架构的设计和示例代码的编写。完成后再通过开会的方式向队员介绍结构设计和分工方向。

　　设计工作安排在初期我觉得是最合适的。

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

　　有，比如，对于是否保留Add暂存区的功能，我们通过开会的方式讨论解决，最终决定将Add与Commit合并为一个操作。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

　　是。单元测试是贯穿整个开发流程的，只有通过测试和复审后的代码才会合并到主分支。

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

　　提交历史视图产生的Bug最多，因为这部分涉及到绘图的运算较为繁琐。

　　在发布后暂无发现什么新的重要Bug。

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

　　代码复审虽然有进行，但并不是很严格，许多时候是存在疏漏的。代码规范执行得不错，但是提交规范没有严格执行，存在一些无效提交或重复提交。

 

测试/发布

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

　　有。接口模块的单元测试由对应的负责人进行测试，GUI测试则受限于时间没有安排计划。

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

　　是。有在多个环境下进行验收测试，也发现了一些Bug。

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

　　受限于时间没有采用自动化测试。

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

　　当前的关注点并不在软件效能上，过早优化可能不是一个较好的选择，因此我们更倾向于关注软件的功能完善，在开发过程中注意性能损耗，但不会刻意跟踪效能。

 

Alpha版本完整演示

　　

总结

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

　　达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。

 

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

　　我认为到了规范阶段。我们团队成员们的职责分工明确，交流也充分及时。

 

心得总结

　　通过这次项目，深刻体会到了团队合作的优越性，也学习到了许多与软件工程相关的知识。较为遗憾的地方在于因为其他事务安排较多，时间紧张，无法腾出充足的时间在软工团队作业上，所以最开始的预期目标就没有定的很高，主要定位不在于最终发布程序，而是开发过程中与团队成员的协作、学习和交流。

贡献统计

名字	角色	团队贡献分	可验证的贡献
邹卓辉	开发		Git Diff接口、Git Commit接口、单元测试
卢明凯	开发		Git Push接口、Git Clone接口、工作区视图
张凯亮	测试		单元测试、回溯测试
刘海港	测试		回溯测试、博客编写
泽瑞坤	开发/产品		Git Show接口、Git Log接口、提交历史视图、界面设计与交互逻辑、博客编写、单元测试

Alpha阶段项目复审

由团队成员共同编写，但受限于我们的水平，难以各个技术栈都有了解认识，仅能提供浅显的复审建议，仅供参考

小组的名字和链接	优点	缺点，bug报告 （至少140字）	最终名次 （无并列）
小谷围驻广东某工业719电竞大队   http://www.cnblogs.com/TaoTaoLV1/p/9934585.html	页面选项做得很详细，功能完善，画面较为美观	修复的bug： 前端：websocket协议通讯时遇到版本号问题，与后台对接时传参形式和格式出现错误 后台：重点解决spring-security和spring-websocket之间的bug 没有演示具体的交易流程，所以具体体验如何不清楚，主要问题应该是支付的解决
夕阳红   https://www.cnblogs.com/hhg52516/p/9935999.html	界面简洁，一目了然，上手容易	修复的bug： 设置了登陆拦截器，中断程序的执行，但是没法重定向到login页面，只能重启 只能通过iphone运行，安卓不可以，这导致没有iphone就无法使用，没有提到具体交易的实施
EmbarassedBirds   http://www.cnblogs.com/HappyCodeingkc/p/9937152.html	页面开起来简洁大方，设计好	可惜暂不能上线，此项目初衷是根据每个用户的需求，自己建立问题，然后通过答题的方式来筛选哪些人是用户想找到的，从而帮助用户让他们认识交流
拉登是我罩的   http://www.cnblogs.com/kiewillis/p/9937345.html	虽然只有文字描述，而且我对偏硬件的开发并不了解，不过看起来是很有趣的工程	没有看见具体的游戏效果和代码，且水平有限，不做评价
C++轮子队   http://www.cnblogs.com/coothen/p/9937470.html	完成度高，在传统的基础上对游戏做了修改，增加了障碍，也出现了奖励方块	总共发现了7个Bug，修复的bug有7个 游戏图片中，4位数字出现数字分两行显示的情况，对用户有点不大友好
假如我们的坦克继续前进队 http://www.cnblogs.com/5164a/p/9937642.html	对比经典坦克大战，除去了需要守家的顾虑，游戏难度降低	修复的bug： 敌方坦克阵亡时血条不消失的 运行程序jar无法运行 在进行风骚的走位时会将操纵的坦克卡进墙内，好像没有设计每一关的场景，这会使场景比较混乱，影响游戏体验
宇宙最帅叉叉   http://www.cnblogs.com/hzquestion/p/9937677.html	有查询对象功能，以及关注功能	修复的bug：7个 下版本修复的bug：2个 没有权限的设置，无法拉黑别人，别人想关注就关注你，貌似无法拒绝别人和你聊天
你吼辣么大声干什么嘛   http://www.cnblogs.com/traehowo/p/9937584.html	可以两个人一起玩	快速或同时按左下右三个键会让蛇死亡 两条蛇的头部侧面穿过不会死 豆（绿色方块）会在蛇身刷新出来 游戏中的尸体仅为颜色，不够精致
大马猴队   http://www.cnblogs.com/busizzzz/p/9937805.html	可以不需要客户端，直接使用网页，模仿微信，界面还原度较高	已修复的bug：7个 还有些功能尚未实现，不够完备，没有实现朋友圈，以及好友添加权限等
月裙抓瓦98分队   http://www.cnblogs.com/happyeven/p/9937879.html	游戏玩法多样，可玩性比较高，修复了很多bug	还有很多已知bug未修复 一个RPG没有NPC，还未达到可以游玩的地步，没有界面提示，菜单栏等，不利于上手，RPG游戏有音乐的话会更好
无言以队   http://www.cnblogs.com/chaojiruozhi/p/9938262.html	界面比较简洁清新，可以两个人一起玩，	分数和计步还没有显示 游戏结束条件判断不足，若一人存在反杀的可能时，会被直接终结
企业管理系统   http://www.cnblogs.com/zero010/p/9938479.html	实现了对员工数据的管理，界面比较简洁	发现的bug：3个 好像没有查看所有员工信息的功能，只能对一个员工的信息做修改删除，发现的bug不知道解决了没有，界面看起来过于简洁
微信小游戏五子棋   http://www.cnblogs.com/macrae/p/9940387.html	界面设计简洁易懂	程序有很多bug为解决，出现了许多与其外的错误，却没有解决这些问题 开始界面只有一个开始游戏，较为简单，人机没有难度的选择
甜美女孩   http://www.cnblogs.com/serendipity-zeng/p/9937832.html	界面比较简洁清新，有两种模式可以选择，有趣	Bug：（不知道是否已经修复） 由菜单点进去基础2048无法玩 基础2048有时会无法移动 纸牌2048的牌移走一个后下一张牌无法移到原来第一张牌的位置 对需求的取舍：先做好基础和纸牌，舍弃自定义模式；考虑游戏性，暂时抛弃游戏成绩的显示和成绩的记录 基本实现了项目的目标
菜鸡互啄队   http://www.cnblogs.com/tworld/p/9942563.html	架构足够清晰，分工细致，从提交历史中可以看出队员们的开发热情	已修复的bug： 使用commit命令出现的数字长度溢出问题 在Windows端的编码问题 架构足够清晰，分工细致，但是git与github交互需要账号密码以及密钥，可以的话最好在博客和readme中说明
ACT小游戏   http://www.cnblogs.com/xonoc/p/9940978.html	画面简洁，玩法易懂	Bug：（不知道是否已经修复） 循环场景时敌人并不会持续生成 主角目前是无敌的，碰撞敌人也不会死亡 循环场景时还会超出背景边界 博客太过简单，没有说明具体操作，以及游戏的场景，敌人的攻击方式是什么，博客中只有一张图片具体很难判断
菜鸡互坑队   http://www.cnblogs.com/hhx3116005133/p/9943689.html	画面清晰利落	Bug： 同时按下和蛇前进方向相反的键和垂直方向的任意一个键贪吃蛇会死亡（比如贪吃蛇向右行走，同时按左上或左下都会死亡） 刷新的苹果会在蛇身上出现 程序运行界面给的太少，很难做出正确的判断
莪的拽、像省田各号①样没尽頭队   https://www.cnblogs.com/m870100/p/9859127.html	选题新颖	Bug： 角色绘制计时器跟过场绘制计时器发生冲突，导致过场动画无法加载 界面CSS定位有问题，左右没对齐，还没来得及写自适应 成长系统还没设计完全，角色也只有一个 作为机械宠物应该有更多的交互功能，图像需要有反馈，让人感觉到有真实感一点，这样才更像一只宠物