MagicCode团队事后诸葛亮会议
时间：2012-11-24 20:00
地点：主南五层
参会人员：MagicCode全体成员（包括新转会的）
有图有真相~~
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们组负责学霸的UI部分，主要是对Document和QAPair做一个Presentation，功能领域定义的很清楚，典型用户和典型场景已经在Spec中明确说明。
是否有充足的时间来做计划?
由于项目比较简单，计划时间不多，但已经足够。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
在PM的带领下，大家基本没有不同意见。
如果历史重来一遍, 我们会做什么改进?
各个团队各自为战，导致UI这边各个团队做的功能有些重合，而且大家的数据结构有差异，给代码整合带来很大麻烦，同时，软件的具体功能没有定义清楚，比如，对于资源的定义，开始我们UI组并没有想到还要在线展示爬来的网页。
计划
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作都完成，没做完的部分，就是没有与另外两个UI组和前端的pipeline做到完美整合。但这个主要是因为开始各个团队没有协调好，最后我们主动提供了数据添加的API
有没有发现你做了一些事后看来没必要或没多大价值的事?
有，研究silverlight下的PDF在线阅读方案，最后才发现有现成的flexpaper
是否每一项任务都有清楚定义和衡量的交付件?
任务在tfs写的比较简略，但由于比较简单，大家都能明白。
是否项目的整个过程都按照计划进行?
PM一直在赶进度，两位DEV的进度有时候不尽人意
在计划中有没有留下缓冲区，缓冲区有作用么?
没有
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
预留必要的缓冲时间。
如果历史重来一遍, 我们会做什么改进?
1. 善用google英文搜索，多了解流行的开源解决方案，少看CSDN（太多不专业），多读Documentation
2. 预留必要的缓冲时间，留给后期的整合。
资源
我们有足够的资源来完成各项任务么?
资源（书籍，开源解决方案，服务器，素材）非常充足
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务估计精度不是很好，因为任务是由PM估计的，而由DEV完成，PM不知道DEV对技术的掌握程度如何，有时候估计的任务不是很精确。
用户测试的时间，人力和软件/硬件资源是否足够?
我们花了两天半的时间来做测试，相对于工程量而言，已经比较充足。
你有没有感到你做的事情可以让别人来做（更有效率）?
没有。
如果历史重来一遍, 我们会做什么改进?
1. 估计任务所用时间时，需要询问当事DEV意见
2. 留给DEV学习的时间
变更管理
每个相关的员工都及时知道了变更的消息?
变更是由PM短信同时DEV的，DEV能够及时了解。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据功能在整个项目中的重要程度，比如anti-spam，放到beta版本中了。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
所有页面整合在一起，通过了各项测试，就“做好了”
对于可能的变更是否能制定应急计划?
没有。
员工是否能够有效地处理意料之外的工作请求？
两名DEV由于经验不足，不能够有效处理，但是大家在PM的带领下出色的应对了各项突发情况。但是PM还是会在DEV比较忙的情况下独自处理各项变化。
如果历史重来一遍, 我们会做什么改进?
1. 善用TFS的源代码管理，少用QQ互传文件
2. 多开碰头会，少通过短信通知
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在Sprint的前三天。由经验最丰富的PM来完成。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
PM做出页面的草稿，交给UI的DEV具体做，PM做的模棱两可的地方，DEV都给考虑全面了~
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
团队使用了Visual Studio 2012自带的web应用程序性能测试工具和Sikuli IDE UI自动测试工具进行测试。我们准备再beta Sprint阶段使用更多的技术。
什么功能产生的Bug最多，为什么？
结果列表功能产生的Bug最多，其实也不多，只不过这个在各个页面中反复重复，造成了“泥球”，改起来相当麻烦。。。。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有想这么多。。。
如果历史重来一遍, 我们会做什么改进?
将UI的部分组件控件化，方便修改与维护
测试/发布
团队是否有一个测试计划？为什么没有？
团队有明确的测试计划。
是否进行了正式的验收测试？
没有。。
团队是否有测试工具来帮助测试？
有的，团队使用了Visual Studio 2012自带的web应用程序性能测试工具和Sikuli IDE UI自动测试工具进行测试。我们准备再beta Sprint阶段使用更多的技术。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们并不了解效能测试，但是会在beta中考虑，我们使用软件进行了负载测试，找到了几个致命的数据库操作的bug，在前几篇博文中我们有过总结。
在发布的过程中发现了哪些意外问题？
TA给的服务器，有各种小问题，如用户权限不足，Sql server无权限等，这些小问题都是我们团队第一个发现，并报告给TA的。
如果历史重来一遍, 我们会做什么改进?
1. 熟悉VS2012、LoadRunner等负载测试工具的使用（beta目标）
补充问题：
1. 对比敏捷的原则, 你觉得你们小组做得最好的是什么?
1.1 简单----使未完成的工作最大化的艺术----是根本的
由于我们在开发过程中，始终不渝地遵循MVC的开发模式，虽然大家各自编码，但由于PM设计的架构使得各层次之间的耦合度非常低，整合起来非常顺手，这也在跟其他UI小组进行整合是带来了极大的便利~
1.2 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
我们在整个Sprint阶段，坚持每天拿出2h+的时间coding，良好的进度使得我们的工作能够按部就班地进行下去。虽然平时的作业也很多，但我们基本能够把边边角角的时间放到Coding上，这样总的时间投入不会与其他课程冲突。
1.3 不断地关注优秀的技能和好的设计会增强敏捷能力
我们在项目开发过程中，前前后后使用了贫血模型、MVC等设计模式，采用了FlexPaper，SWF2PDF等优秀的开源解决方案，这使得我们能够把精力集中在满足用户需求之上，而不是一味的拘泥于采用何种技术，何种算法。
1.4 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
在最后的整合阶段，一夜之间涌现除了好多新的需求，最后PM熬夜到2点搞定~~
2. 什么是在下个阶段 m2 要改进的地方?
由于邹欣老师安排我们在M2阶段进行搜索引擎的开发，我们准备从以下几个方面入手：
1. UI方面，2Dev（孙胜，陈宇宁）负责，主要有两个方面：搜索首页，搜索结果页设计。主要要求：中英文支持，Tab式的文档、资源搜索结果自如呈现（符合用户习惯）
2. 搜索方面，PM负责，采用Lucene.Net开源解决方案。开发定时构建索引工具，定义索引结构。
3. 测试方面，1dev（谷骞）负责，熟悉vs2012下的效能测试，负载测试等各种测试手段，对网站进行各项测试，同时协助PM进行搜索引擎开发。
附：Lucene索引结构
Name Index Store TV Boost Description
qid UN_TOKENIZED YES NO -
tags TOKENIZED YES NO 4
title TOKENIZED YES NO 2
content TOKENIZED YES NO -
created UN_TOKENIZED NO NO -
repiles UN_TOKENIZED NO NO
views UN_TOKENIZED NO NO
