问题51： Day-DayBuild指的是什么，应该如何执
答：
也许你指的是daily-build。Daily-build就是每日构建，每天对实现的代码进行构建，构建出可运行的一个版本，来确保Check-in
的代码是正确的。通常我们会将Daily-build和冒烟测试同时进行，也就是在每天工作结束前，对今天check-in的代码进行构建，然后再构建的
系统上对基本的功能进行简单的测试，确保生成的代码对系统的功能没有不好的影响。当发现问题是及时进行调整，保证每天的Daily-build和冒烟测试
可以正常的进行，这样对于提高整体的代码质量有很大的益处。
问题50： 单元测试的开发应该有开发人员来完成呢？还是应该由测试人员来完成？
我个人认为应该是由测试人员来完成的，但网上很多文章都说单元测试应由开发人员来完成，根据MSF，应该由哪个角色来完成单元测试的开发呢？
答：
单元测试是由开发人员自己来进行的，因为单元测试通常关注的是类或模块内部的功能和方法在实现的过程中出现的一些问题，而且具体的实现逻辑只有开发人员自
己才知道，测试人员只关注系统在功能上是否实现了用户的需求，他们并不知道里面实现的原理。所以测试人员无法对开发出来的类或模块进行单元测试，除非它可
以理解每一行代码的含义。所以在MSF中单元测试是由开发人员自己测试的。
问题49： 在项目计划阶段，需要在完成技术验证和功能规格说明书的基础上，完成项目主计划和进度表。可是我们面对客户时，经常在深入交流前（合同签订前），客户就要看到项目主计划和进度表，甚至根据这些来谈价格，许多情况下价格决定能否成交，这种情况下怎样处理好呢？ 答：
这种情况在国内已经是比较普遍的形式，但是从实际操作上来看会有很大的问题。在没有深入交流前，只能够根据项目和行业的经验做一些估算，但是估算的结果会
和实际的工作量有较大的偏差，一般会在25%-400%左右，甚至更高。此时确定的价格也是非常的不准确，一般都是在公司的高层确定价格后然后签订合同，
再进行项目，所以里面很多的估算都会考虑到客户关系的维护、今后的项目机会等多方面的影响。MSF和A2K可以在项目的管理实施及架构设计上给我们一些帮
助，但是对于这种公司运作上的原则来说是无能为力的。
问题48： 为什么MSF哪一个角色负责客户最后签字认可过程的答案是发布管理角色？在19章中的收尾工作中提到了产品经理负责客户最后签字认可，我觉得有可能是产品管理角色或者是程序管理角色，因为这两个角色会有产品经理参与。 答：发布管理会负责项目后期的部署实施以及选择合适的发布版本，所以发布管理最后的工作就是将项目成果平滑稳定的部署到生产环境中，最后的签字认可由发布管理来负责，来确认其工作已经顺利的完成。很多情况下程序管理和发布管理的角色会合并。 问题47： 请问第四集缩小团队规模的图表为什么没有P、U、N三个字母标在上面呢？
答：无论如何组织项目团队，只要合并的角色在项目中没有利益上的冲突基本上都是可以合并的，也就是说可以把在项目中有共同利益取向的角色合并。
问题46： 程序管理不仅仅负责需求吧?
答：是。 问题45： 项目经理最需要具备的是什么，简单来说就是对项目经理来说技能和经验相对来说哪个更重要？ 答：对于项目经理来说技能和经验同等重要，但这里的技能并不只指技术，更主要的是指项目管理技能。 问题44： 请问一下微软是怎么样做任务估计的？ 答：经验很重要，但也结合了大量的预估工作。 问题43： 如何有效地进行Bug管理？ 答：要有一套有效的BUG管理系统，具备发现、报告、解决、日志等功能，同时要有专人负责BUG管理。 问题42： 那么国内的开发管理属于MSF中的什么角色?程序管理?问题41： 开发文档应该由谁来负责更新？ 答：开发和测试人员。
问题40： 在项目中设立里程碑有什么好处？
答：可以有效的控制项目进度，掌控项目。
问题39： 功能规格说明书是从用户的角度描述的系统的功能点吗? 答：既要从用户角度考虑，也要顾及开发环节。
问题38： 在产品开发过程中，何时我们可以发布产品，发布的判断标准是什么？
答：原则上说，产品发布的标准是零BUG，但是我们不得考虑市场问题，如果市场“凉了”，那产品发布的意义就没有了。
问题37： 对于用户需求的描述,采用什么方式比较好?UseCase?
答：不错
问题36： 原型需要做到什么程度？有文档说明吗？微软有原型方面的建议文档吗？
答：建议有，这个还没发现，你可以到微软网站找找。
问题35： 怎么在项目里体现风险？BufferTime?
答：风险无处不在，充分了解项目本身所设计的方方面面才能准确估算风险。
题34： 请问孔文达老师有没有实际带队开发的经验？能不能结合实际分享一下？
答：有，但不是用文字就能说得了的。
问题33： 什么情况下需要建立程序管理团队和开发管理团队？
答：建议任何情况下都要有程序管理团队。
问题32： 无论项目多小都应该最终由测试人员测试吗？
问题31： 我认为开发管理和程序管理都是属于程序管理角色，这是否正确？
答：其实，国内的软件开发商很多都和你的情况一样,角色不完整，但只要合理合并，也无妨。
问题30： 请问谁负责系统的总体框架的设计?程序管理角色?
答：对，不过要结合其它角色共同完成。
问题29： 往往目前的都只是一个程序管理角色和一个开发管理角色,这就是角色合并，可是你只合并成两个也太惨了吧！
答：程序管理角色只需要有一个，但不一定只是一个人。
问题28： 一般项目达到多大时，需要更多的程序管理角色的团队来管理？
答：要注意，不管项目多大，都需要有MSF中的所有角色，缺一不可。
问题27： 具体实现部分的东西都有开发人员直接在代码里做注解,最后通过程序提取所有注解…，这是否合理？
答：当然，不可能所有细节都在文档中有所描述,但凡是涉及最终用户使用的技术细节最好都写在文档中,而不要写在程序中,我觉得这样一来更加的麻烦?
问题26： 代码实现的时候有变化，却没有更新文档，开发人员不善于写文档，时间上也不充足，如何解决这个问题？
答：是啊，常事，原则上开发文档应该由开发团队负责更新，培养这样一个人吧，有用。
问题25： 如何有效保证设计文档和代码的同步?
答：Day-DayBuild是个不错的方法
问题24： 产品原型在和用户确认需求上有重要意义吗？
答：有，很有。
问题23： 如何在项目中看待基础架构?
答：基础架构很重要，它包括很多方面，如：软硬件的配置和设置部署脚本及其过程,自动部署工具和部署检查清单,疑难解答和解决问题的指导方针,备份、恢复以及回退过程。
问题22： 对于开发角色而言,系统的功能点与开发的构造块并不是等同的,如何实现这种转化?
问题21： 如何有效地鼓舞团队成员？
答：富有激情的远景陈述、表彰、电话、电子邮件、奖金都可以啊,这只是建议。
问题20： 在项目的前期准备中，如何准确知道客户的需求？
答：最好能够深入用户的应用环境，了解用户的抱怨,收集用户最想实现的功能是什么等等，这样才有可能明确用户需求？
问题19： 在产品开发过程中，DailyBuild的最重要的意义是什么？
答：Day-DayBuild的最大好处是使项目团队能够及时掌握项目的状态，也能够在第一时间内找到错误并更正，这样便不会有某些问题一直贯穿在解决方案中的现象。
问题18： 有关如何识别和控制风险的一个问题,msf里面说风险的评估可以交给相关的负责人，比如，技术方面的风险可以由开发人员评估,但很多技术人员都希望能在项目中使用新的技术，而他们对此的掌握又不是很好，没法很合理的给出风险,这种情况如何处理？
答：建议MSF的所有角色都需要关系项目风险问题,因为风险会存在于整个项目的各个阶段。
问题17： 开发人员自己设计开发模块的《设计文档》是否合理？
答：需求文档应该由程序管理角色负责，而技术性的开发文档可以由开发角色负责。
问题16： 对于开发角色而言是尽量的了解需求好还是尽量的在设计中屏蔽需求？
答：建议MSF的所有角色都要明确客户需求,但开发角色的最主要工作还是按照功能规格说明书开发组件。
问题15： 规避风险的具体手段有哪些？如何控制?
答：
成功开发解决方案的关键在于控制项目的固有风险,在MSF风险管理准则中，风险管理是指采用主动的、有预见性的方法确定、分析并控制项目风险。风险管理的
目标是，使项目风险的负面影响（损失）最小化并同时提高项目的正面影响（收益）。因此在理解和管理风险方面，运用一套有效的准则可以确保风险和收益之间的
平衡。可以肯定地说，没有,任何一种办法只要用了就能成功规避风险。要充分了解项目所设计到的软件、硬件、环境、人员、资金等问题,才能有效的管理风险,
问题14： 开发角色构建解决方案的依据是什么？
答：功能规格说明书。
问题13： 我觉得在MSF中沟通是一个至关重要的东西,那么如何确保良好的沟通呢？有些人不喜欢和人交谈。
答：沟通不一定非要多交谈，可以通过其它形式啊,比如让他参与会议，发电子邮件等。
问题12： 如果组织是矩阵式的组织结构，项目管理上应该注意哪些啊？除了沟通，还有什么？
问题11： 一个人同时兼顾2个项目是否违反msf原则？
答：不违反MSF原则
问题10： 可不可以一名开发人员同时进行两个项目的开发？是否违反MSF?主要问题是什么？因为他的工作在一个项目上不饱满。
答：虽然不建议这样做，但在开发人员极少的情况下勉强可以,如果是这样的话，我认为可以考虑,但我们要考虑一个人的工作效率。
问题9： 那项目经理所需要具备的最重要的素质是什么？
答：我认为项目经理的技能中经验和理论占80%，技术占20%。
问题8： 我负责的是维护的项目，经常需要和日方的产品经理沟通工时和Schedule，请问如何准确地估算工时呢？有没有什么可以参照的模版？
答：估计工时的确是件让人头疼的问题，这就需要我们能够明确项目目标,并且要制定出详细的功能规格说明书，再利用OfficeProject会比较好。
问题7： 有时候客户总是认为没有办不到的，只有不想办的,我们应该如何做？
答：那我们就要然他们明确不是没有办不到的，只是时间问题,这样项目会无限期拖延下去,所以就要制定发布版本。
问题6： 在提交软件给客户看时，总是要反复修改，应该如何处理？
答：这是很多项目中都回碰到的问题，所以MSF的基本原则中才会包含“主动应变”这一条。
问题5： 如何让项目按时完成交付？
答：21的问题太具有代表性了,保证项目按时交付需要注重很多方面的问题,简单说，就是严格按照MSF的各种建议进行项目,另外，保证沟通。
问题4： 用户需求说明书与软件规格说明书，可不可以省掉一个？
答：用户需求说明书与软件规格说明书倒是可以合并，但不能省略。
问题3： 为什么应该把设计结果也包含在软件规格说明书中？ 答：因为贵功能规格说明书也会作为项目结束后，和客户确认目标是否完成的标准，所以要包含设计结果。
问题2： 我想请问一下孔老师，测试角色是否可以与开发角色合并？
问题1： 在项目经理的工作说明(SOW)中，每一个阶段的工作描述，应该包含那几个关键部分？
答：应该至少包括MSF中的两模型三准则，即团队模型、过程模型，项目管理准则、风险管理准则、就绪管理准则的相关内容，但也会根据项目的不同有所调整。