封闭式开发小记(8)：封闭式开发的项目讨论
项目讨论的主题大多是需求，项目讨论的主要目的也是为了理清需求。项目讨论主要集中在两个阶段：
第一个阶段是全员参与，讨论项目的功能需求。由于封闭式开发到了一定阶段，框架基本稳定，但是初步的需求还不太稳定，由于封闭式结束日期的限制，所以需求在不断的裁减之中。那些被规定的需求是必须要完成的，当然，在故事列表中，还有好多，可能由于优先级和时间压力被推后了。
第二阶段，各自开发小组细化需求和流程。这个阶段是实际的开发阶段，每个小组在这个迭代选取了各自的任务后，都要进行故事的拆分工作，把大的故事（复杂的需求）拆分成可执行的任务，这里各个任务的时间估算工作。开发人员的估算会和结果有点出路，但如果不估算，那么实际的时间可能会更多。这里估记有一种心理做用在，毕竟我们在这次会议中还有制定在迭代最后一天对应每个故事进行演示的简单流程。所以这次需求细化讨论会议，基本确定了能完成的故事点和对应的接口调用规范。
可能的问题：
第一：任务太多做不完。
你开发的模块可能是核心模块，可能是集成性的模块，可能用户使用率最高的模块，可能已有成熟应用的模块。那么，产品经理或其它开发人员对此模块的需求更多，或者要求更高。如果你开发及时通信，那么就会和QQ比，如果你开发门户，就会被拿来和网易新浪比。但是，要求高意味更高的提高。能增加思考问题的全面性。如果你写的代码或构架是可质量比较好的，有覆盖率较高，用例较全面的测试，那么可能减少你的任务量，也能把需求以代码的方式确定下来。我们的单元测试或才测试驱动而编写的代码，就相当于是可以重复验证的需求说明书，如果结合每日构建的测试，跑一遍后，可以把好多问题都扼杀在摇篮里面。而且，重复执行的成本也十分低廉。
我们不需要有太多太多的功能，我们需要提交的功能是没有问题的。
第二：容易跑题，没有结果。
在进行项目讨论的时候，有些实现方式没有对错，如果把所有人放在一起，则会浪费不相关小组的开发人员的时间。所以细化需求的会议可以在各自小组开展。全员参与的会议时间尽量的短，这样不会激起成员对会议的反感，也会增加会议的有效性。
PS：会议有时候是浪费时间和降低战斗力的主要原因。
目录：
封闭式开发小记(7)：如何和谐沟通、提高士气（结合开发实际冲突来深入讨论合作与沟通）
封闭式开发小记(8)：封闭式开发的项目讨论(10.9)
封闭式开发小记(9)：封闭式开发的最后一天(10.10)
封闭式开发小记(10)：封闭式开发的项目汇报(10.11)
封闭式开发小记(11)：封闭式开发的测试发布(10.12)
