事后分析

事后分析
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要解决的是用户可以畅所欲言；定义的十分清楚；对典型用户和典型场景有清晰的描述。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
原计划的功能做到了四个；未按照原计划时间交付；原计划达到的用户数量未达到。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，质量有所提高；在编码规范，任务分配有所提高；从每天的作业完成量和代码交付率可以看出提高了许多。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量和我们预想不一致，用户对重要功能的接受程度和我们预想一致（游戏游玩功能），我们离目标更近了。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
代码规范很重要，最好先订好数据库规范再作业。
计划
是否有充足的时间来做计划?
是
团队在计划阶段是如何解决同事们对于计划的不同意见的？
听取每个人的意见，集思广益
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
并没有都完成；因为技术力不够。
有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
是否每一项任务都有清楚定义和衡量的交付件?
是的
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并不是；风险虽然预估到了，但是对于风险的排除花费了意料之外的时间。
在计划中有没有留下缓冲区，缓冲区有作用么?
有留下给每个人学习的时间；缓冲区有作用。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
加班加点完善项目
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在计划中要预估风险和估计作业完成时间；预估最佳完成时间和最差完成时间。
资源
我们有足够的资源来完成各项任务么?
人力资源足够，设备资源足够，但是知识储备似乎不够
各项任务所需的时间和其他资源是如何估计的，精度如何?
通过经验和直觉进行估计，精度不高。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试足够，人力足够，软件不足够，硬件足够；对于文案和需求分析，确实低估了难度。
你有没有感到你做的事情可以让别人来做（更有效率）?
确实，如果文案这件事可以分发下去，省了我很多功夫。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
将不需要编程的部分分成多份交给成员解决，效率也许会更高
变更管理
每个相关的员工都及时知道了变更的消息?
是。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
通过会议和投票。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有。
对于可能的变更是否能制定应急计划?
可以。
员工是否能够有效地处理意料之外的工作请求？
如果是过于意料之外，可能无法有效处理。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作一直由蔡佳阳同学完成；是合适的时间，合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
集思广益，听取大家的意见和查找资料
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
使用了其它工具来帮助设计，这些工具十分有效；项目开始的UML文档和现在的UML文档有区别；在项目开发的时候，我们会遇到新的问题，所以更新UML文档是十分有必要的。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
游戏游玩功能遇到的bug最多，因为编写游戏的代码可能套不进框架里；有时会出现游戏崩溃现象；因为我们无法对自己未曾做过的东西进行评估，很多事，是只有做过才知道的。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
通过由代码功底深厚的同学进行复审；大家都有自己的编码风格，没有严格按照代码规范进行。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在设计时要有侧重点，并同时设计好架构和设计规范。
测试/发布

团队是否有一个测试计划？为什么没有？
有
是否进行了正式的验收测试？
未
团队是否有测试工具来帮助测试？
没有
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
准备学习谷歌，先发布，然后由用户对从产品进行测试，提交bug，然后修复；应该先内部测试，修复所有bug后再发布。
在发布的过程中发现了哪些意外问题？
服务器对接项目出问题了。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
测试十分重要，我们不能不进行测试；改进：边做项目边进行测试。

会议照片

成员	分工	评分
张楠	负责整体规划和协调，对整个网站系统的开发和上线负责。	9.5
周广	负责blog系统的数据库设计和开发，包括用户信息、文章、评论等数据表设计和开发。	9.5
张小宇	负责blog系统前台页面的开发，包括用户登录注册、文章列表展示、文章详情页面、评论功能等。	9.5
黄铭浩	负责blog系统后台管理页面的开发，包括用户管理、文章管理、评论管理等。	9.5
曾琳备	负责各页面、系统的测试	9.5