答:用两个词吧,一个是拥抱变化,一个是进度可视。
1.任何软件类系统或项目,即使你前期花在需求上的时间足够长,你也很难在需求阶段真正的分析和挖掘出所有的需求。有些需求注定会在设计实现或用户使用过程中才逐渐出现。要承认软件开发中存在这种不确定性。而瀑布模型将这种识别变化延迟到最好的测试或用户使用阶段才发现,极大的增加了返工或变更成本。敏捷思想里面通过短周期迭代,尽可能早的交付可用的迭代版本来拥抱和适应变化。
2.任何一个软件项目,需求或设计做完我们并不清楚进度是否真正完成了60%或者更多,任何不是经过测试通过的功能我们都很难把握真正的完成进度情况。因此在敏捷里面换了一种思路,如讲这个项目拆分为100个粒度差不多的功能点,如果有60个功能点全部完成并通过验证和测试,我们就比较有把握说整体进度完成了60%。这种可视化的评估进度模式在瀑布里面较难以做到。
其它的优势就太多了,可以仔细看敏捷方法论和思想,在这些里面最重要的又是从方法和工程转到对人主观能动性,沟通和协同交互,自适应的关注。
1.任何软件类系统或项目,即使你前期花在需求上的时间足够长,你也很难在需求阶段真正的分析和挖掘出所有的需求。有些需求注定会在设计实现或用户使用过程中才逐渐出现。要承认软件开发中存在这种不确定性。而瀑布模型将这种识别变化延迟到最好的测试或用户使用阶段才发现,极大的增加了返工或变更成本。敏捷思想里面通过短周期迭代,尽可能早的交付可用的迭代版本来拥抱和适应变化。
2.任何一个软件项目,需求或设计做完我们并不清楚进度是否真正完成了60%或者更多,任何不是经过测试通过的功能我们都很难把握真正的完成进度情况。因此在敏捷里面换了一种思路,如讲这个项目拆分为100个粒度差不多的功能点,如果有60个功能点全部完成并通过验证和测试,我们就比较有把握说整体进度完成了60%。这种可视化的评估进度模式在瀑布里面较难以做到。
其它的优势就太多了,可以仔细看敏捷方法论和思想,在这些里面最重要的又是从方法和工程转到对人主观能动性,沟通和协同交互,自适应的关注。