关于敏捷开发文章的读后感
第一个看到敏捷开发这个词,是前一阵子在看一本叫《精益创业》的书时。
这本书核心思想是建议创业者应遵循敏捷开发思想,有创业想法时,应该先向市场推出极简的原型产品,然后在不断地试验和学习中,以最小的成本和有效的方式验证产品是否符合用户需求,灵活调整方向。在此期间,团队也应该紧密联系充分沟通。如果产品不符合市场需求,最好能“快速地失败、廉价地失败”,而不要“昂贵地失败”;如果产品被用户认可也应该不断学习,挖掘用户需求,迭代优化产品。
在读那本书时,便惊异于敏捷开发思想的巧妙。这周又有幸读到敏捷开发创始人之一Martin Fowler关于敏捷开发的文章(http://martinfowler.com/agile.html),让我对其有了更深的理解。于此文中做一些总结、摘录和感想。
1、敏捷开发的核心思想
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
Martin Fowler认为敏捷开发的核心是:adaptive rather than predictive & people-oriented rather than process-oriented。
翻译成中文大意就是迭代更新比预测更重要,以人为本。
由于用户需求的不可预测性,与其程序勉强预测用户需求的变化方法,不如采用迭代开发的方式。
在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。通过这种方式,开发者能够降低风险,得到早期用户反馈,从而进行持续的测试和集成,使用变更,也提高了代码的复用性。
以人为本里的人,是指程序员们。
2、Extreme Programming(XP/极限编程)
Martin Fowler在《Is Design Dead?》一文中详细地对极限编程做了一些说明。
对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。"Do The Simplest Thing that Could Possibly Work."、"You Aren't Going to Need It".
极限编程挑战很多软件开发常见的假设,比如说自顶而下设计,而支持一种比较属于演进的方式。有人批评XP,觉得这是退回到了 "code and fix" 的开发方式。支持者也常看到 XP 对于UML、principle、patterns 等的排斥,作者在文中对此作出一些解释。我做如下一些归纳。
1、极限编程最核心的地方就在于简洁,不设计明天才需要的功能,把效益发挥到最大。
简洁的标准是:通过所有测试;呈现所有的意图;避免重复;最少数量的类别或方法。
2、极限编程虽然也是支持比较演进的方式,但是不同于code and fix。(这部分专业术语有点多没有读懂)
3,作者对于对于采用 XP 的人使用 patterns 的建议:花点时间学习 patterns。留意使用 patterns 的时机 (但是别太早)。留意如何先以最简单的方式使用 patterns,然后再慢慢增加复杂度。如果用了一种 pattern 却觉得没有多大帮助-不用怕,再次把它去掉。
4,作者对于采用 XP 的人使用 patterns 的建议:花点时间学习 patterns;留意使用 patterns 的时机 (但是别太早);留意如何先以最简单的方式使用 patterns,然后再慢慢增加复杂度;如果用了一种 pattern 却觉得没有多大帮助-不用怕,再次把它去掉。
5、极限编程看上去和UML矛盾,作者的看法是,UML是为了沟通而存在的,在使用XP方法的时候建议做的简短,不要太详细。
3、《Manifesto of Agile Software Development》——敏捷开发宣言
宣言比较短,大意:
我们一直在实践中探寻更好的软件开发方法,
身体力行的同时也帮助他人。由此我们建立了如下价值观:
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说,尽管右项有其价值,
我们更重视左项的价值。