软件过程，即软研发过程，不仅仅是编码，还包括但不限于原始需求，需求确认，需求澄清，软件设计，软件编码，代码检视，测试设计，测试，后期维护等。当下最被广泛实践和应用的软件研发方法论是敏捷软件开发。
敏捷软件开发的意义和价值,还有使用范围,核心思想,基本流程,基本理念? 为什么会提出这样的理念。
史前时代
按照每人每月生产多少代码,来衡量软件开发,这种衡量方式对机器生产物品的衡量还是很准的.但是对于很多事情是不使用的,比如对于孕妇生小孩这件事,一个孕妇10月怀胎,然后诞下一个小孩.但是你能让10个孕妇一个月生下一个小孩吗? 对这个时代的失败的总结是<<人月神话>>这部经典巨作.
瀑布开发
将开发严格的分为,需求,设计,开发,测试,维护 ----产生的结果常常是需求后期经常变动，各个过程总在不断的打破，研发的周期很长,导致生产出来的软件产品成本高昂.
敏捷时代
敏捷时代,注重软件开发时候的高效沟通和及时反馈。
持续集成,每天都有可以使用的版本.注重人与人之间的交流,分期交付,及时得知效果.
快速的相应市场的需求.
相比与传统的工程，一个软件工程更强调渐进，你知道大的目标是什么，你也知道最近的几个阶段的目标，但是后面的阶段目标是你无法预知的，你能做的就是提前识别风险，然后依据风险制定对策。
** 为什么说软件后期的阶段目标无法预知呢？**
因为软件开发本质是解决问题的，如果是已知问题，已有解决方案，直接使用即可，软件更多的是面对未知问题。机器善于解决的是繁琐或重复问题，软件研发的过程就是把原本繁琐的问题，做的让程序员能理解，然后程序员做的能让大众能理解，能使用。从这个意义上讲软件最终都是面对用户的，所以一定要做的让人易于理解。
没有重复，每天写的都是不一样的代码，这需要很大的创造力，对于机械的生产你很容易预知未来，但是对于创造，是不能预知的。而且人们本来就不擅长对智力的评估。
** 那么在软件行业是怎么规避无法预知的风险呢？**
小步快跑分解任务，一般最多在一周内能完成的任务。每周都能看到进展万一出现偏差也能及时调整。这个分解者必须对该领域很熟悉，知道有哪些坑坑洼洼，这样的分解才是相对准确的。还有即便是该领域很熟悉，由于人员的技能差别，加之评估之时不会太关注细节，即便有深厚领域经验的人，评估的工作量和实际的平均差异在1：6-1：10之间，这样就可以解释软件行业为什么加班很多。
小步快跑的思路也可以用于我们用来做需要极大耐心才能完成的事，比如背新概念3，比如学习一门编程语言，你只要关注最终目标和下一个小目标就可以了，浪费精力在担心和鼓励自己上都是多余的，你做就是了。
