And*_*mer 8 agile scrum waterfall software-design
我知道,对我来说,我首先开始遵循项目管理的瀑布方法,并且我采用了软件设计的预测方法.在这里我的意思是我们有大量的文档包,UML,数据库模式,数据字典,工作流,活动图等.
从事软件工作已超过10年,我发现从反应式方法进行软件设计更为现实.我经常遵循scrum方法进行项目管理,并且生成的文档很少.我们的工作流程规范很少(尽管它们仍然有用).这是一种更加动态的软件创建方法.当然随着时间的推移经常进行重构,因为随着时间的推移我们发现我们预先计划的新功能将会大大改变.
对我们来说最大的区别在于,第一种方法需要更长时间,似乎在软件构建领域更频繁地失败,并且几乎不那么灵活.第二种方法提供了更大的灵活性,使我们更快地意识到故障(因此我们可以更快地纠正),并在每次迭代结束时提供某种形式的功能.
从经验中了解双方,我仍然发现很多人喜欢使用瀑布式方法来处理敏捷的软件开发方法.我不明白.
问题:为什么有人会使用瀑布而不是某种形式的敏捷与所有支持敏捷的研究？使用瀑布而不是敏捷有什么强有力的论据？
我认为人们仍然经常坚持瀑布的部分原因是它给人一种控制的幻觉.在瀑布中,你可以做足够的前期工作来整理一个漂亮的时间表,很好地解决你能想到的每一个意外事件,然后为业务方面的任何人提出详细的路线图,询问功能X何时会出现可用.
问题是,你几乎永远不会遵循这个计划,你几乎总是迟到/丢弃功能.然而,从前期开始,它看起来非常可控和易于管理.
我是一个敏捷的大粉丝,但我一直在努力的是销售和营销人员经常要求的长距离路线图/预测.我认为瀑布的确定性幻觉对经理人和商界人士来说都是非常令人欣慰的.
当我开始编程时(使用COBOL不少),瀑布是"新的"方法.今天,我告诉你我使用了一种瀑布式敏捷方法.对于较大的系统,我发现瀑布式启动效果最佳.不创建大型文档(这是浪费时间IMO),而是采取一些步骤,如创建UI原型和/或用例来解决手头的业务问题.一旦我们感到舒服,我们就会解决问题,并且我们有一个充分的理解,我们进入敏捷开发模式.
不过要回答你的问题,我认为瀑布的主要原因是许多人不喜欢改变.改变并从瀑布走向敏捷是一件很可怕的事情.