问题总结

第六章 敏捷流程

问题：敏捷流程和传统的瀑布模式，有什么异同？

瀑布模型的特点

（传统的开发方式）

1、强调文档

前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期才可以看到软件的“模样”。 

2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应。瀑布就意味着没有回头路。 

3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。

 

敏捷开发的特点 

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。

敏捷开发集成了新型开发模式的共同特点，它重点强调：

1.敏捷就是“快”。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多。

2.客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。 

3.强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。 

4.设计周密是为了最终软件的质量，但不表明设计比实现更重要。

5.迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。

6.小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。

 

第七章 MSF

问题：MSF过程模式如何划分阶段，完成一个功能就可以说完成一个阶段吗？

MSF过程模型包含四个主要的里程碑，每个里程碑都是一个阶段的终结点。

      预想和构思阶段在“前景/范围核准”里程碑上到达了终结点。一旦一个新的产品（在信息基础设施实现的项目中，这样的产品可能是某项服务）吸引了大家的兴趣并得到了允许构建的批准后，项目组开始集中起来定义产品。前景描述文档清晰地阐明了产品或服务的最终目标，并提供了明确的方向。

　　设计阶段在“项目设计核准”里程碑上到达了终结点。项目设计包含功能规定文档、每种角色职能组的计划组合（如在MSF组队模型中定义的开发、测试、用户教育、系统实施、程序管理和产品管理）和时间进度安排。功能规定提供给项目组足够的细节情况确定需要的资源并作出承诺。在项目设计核准里程碑上，客户和项目组在要交付的内容上及如何进行构建达成一致。这是一个重新评估风险、建立优先级和对时间进度和资源调配情况做最终估计的非常重要的机会。

　　开发阶段在“范围完成/第一次使用”里程碑上到达了终结点。经过核准的功能规定和相关的项目计划提供了开始开发的基准线。开发组设置了一系列内部交付的里程碑，每个内部里程碑都要经过全部的测试/诊断/排错的过程。在这个里程碑上客户和项目组评估产品的功能，验证产品过渡和支持计划。同样在这个里程碑上，所有新功能的开发都已经结束，推迟开发的功能记录下来作为下一个版本功能的参考。

　　稳定阶段在“产品发布”里程碑上到达了终结点。测试工作是伴随着代码开发工作进行的，在稳定阶段因为集中注意力于寻找错误和修改错误，所以测试活动成为主要的工作。在产品发布里程碑，产品正式转交给操作和支持组。通常情况下，项目组或者开始下一个版本的产品开发，或者拆散加入其它的项目开发组。

 

第八章 需求分析

问题：做调查问卷时，是向大众调查，还是特定的人群调查？

对于不同的调查有不同的方法:

　　常用的调查方式有普遍调查（对调查对象的每个部分每个分子毫无遗漏的逐个调查），典型调查（选择一个或若干个具代表性的单位 做全面，系统，周密的调查），个案调查（对社会的某个个人，某个人群，或某个事件，某个单位所做的调查）。 
　　常用的调查方法有问卷法（合理设计问卷，采用开放式，封闭式或混合式问卷收集信息），文献法（通过书面材料，统计数据等文献对研究对象进行间接调查），访问法（通过交谈获得资料），观察法（现场观察，凭借感觉的印象搜集数据资料）。 

 

第九章 项目经理

   问题：PM如何鼓励队员，增强队员自信心？

　　先设定目标，然后要每个人都要承担一分力，哪怕一点也好，成功后便充分表彰每一个人所出每一分力，让他们充分了解自己在团队中的价值，简单说就是让他们明白自己是有用的，是怀才而遇的。

第十章 典型用户和场景
 问题：用户的需求，如果不能实现，怎么办？
　　换一种方法去实现，实在不行就跟用户讲明白，说清楚。我们这些新上路的产品人员在做产品的时候，务必在动手前理清好的自己的思路，明白我们需要的做的是什么样的产品，用户到底是需要什么，这个我们必须清楚，不清楚去问，去思考，正所谓磨刀不误砍柴工。

第十一章 软件设计与实现

    问题：软件设计需要不断与客户交流，如果客户每天的要求都不一样，怎么管理设计变更？

　首先，看这个需求变更是否合理。如果合理，那么是肯定要变的。 其次，如果同一个地方他反复变更需求，那么就要想是不是客户自己根本没有明确想要什么。这时候就该缓　　  缓，等客户想清楚了再定。  再次，同样是一个地方他反复变更需求，也有可能是你拿出的东西并不是他想要的，这时候就要尽量引导客户把需求描述清楚，然后在理解客户想        表达的意思的情况下，抽象出结果，再确认。  最后，如果客户的需求不合理，就应该尽量和客户解释哪里不合理，合理的情况下应该是怎么样的。要让客户理解为什么不合理。　如果实现他不合理的需求，等以后客户明白过来时，还会要求改的

 

第十二章 用户体验

 

问题：到用户体验这个阶段，产品基本完成了吗？只需要做一些修改就行了吧？

　　这阶段基本完成，还有一些BUG问题而已。

 

第十三章 软件测试

问题：软件测试能把所有Bug找出来吗，那些新出现的Bug是软件更新才出现的吧？

　　 软件测试是必要的，要不然也没有更新这一说法。其实更新也是在更新

    我们不怎么知道得Bug,例如：360占100%内存，下次就要设置软件不这么大

    软件是死了，人是活的，凡是软件基本都有Bug.

第十四章 质量保障
问题：软件的质量保障包括那些方面？
软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

第十五章 稳定和发布阶段
问题：代码到发布阶后，如何保持软件的生命周期，这个阶段的Bug比测试的时候更多吗？
不断测试更新软件，开发更多功能。

第十六章 IT行业的创新

问题：很多人都试过创新，但是能成功的人不多，那么IT行业的创新不被人接受，该如何？

谁不喜欢创新呢? 然而细细想来, 创新就是做和以前不一样的事, 并不是所有的人都喜欢“不一样“。 当你提出一个创新的想法时, 你可能不会得到别人的认可。
在我们熟悉的电脑和IT 领域, 所有我们看到的“酷“ 的东西, 都是几代人, 几个团队前赴后继持续创新的结果。 就像拼图一样, 很多聪明人都看出了最终图像, 都在一块一块地拼接, 往往拼好最后一块的同学得到最大的荣誉。 但是没有前人的积累，没有自己扎实的能力, 没有 ”最后一块” 等着同学们去拼。

第十七章 人，绩效和职业道德

 问题：团队不断有新人更换，那么团队是要不断经历磨合期吗？

所谓磨合期就是相互适应的阶段。例如到新的工作岗位，要适应新工作、新领导、新同事、新环境等。同样领导、同事也要熟悉、了解你。这一时期就叫磨合期。磨合期可能会产生一些矛盾。当互相熟悉、了解、相互适应了，就可以很好地配合工作了。磨合期也就过去了。每换一次工作，你所失去的就是经验与熟悉，需要一切重来，肯定会有一段磨合期。每换一次工作，你所得到的就是新的机会，新的学习，新的舞台。这一切你得到的将会弥补你所有失去的。

所以，不要忧虑和浮躁。给自己足够的时间熟悉环境，除了工作方面之外，一定要建立一个完好的人际网，多认识些人，请他们一人给你一个“入职建议”，碰到问题最好能有几个“智囊”帮你出出主意。和老板的关系要处好，确认他对你的期望值和你能做的是一致的。

刚进入一个公司，你如果犯错，大家会原谅的，你如果问傻问题，大家也不会怪你的。所以，一定要把握好这段时间，把错都犯了，把傻问题都问了。看得出你是一个想做事的人，也是一个负责人的人。相信你一定会做得很好。

在工作的磨合期还会有很多需要注意的事项，要学会端正自己的心态平复自己的心情，度过了种种关卡就能顺利融入社会融入工作，从而在工作中实现自己的人生理想。