自己没有做过敏捷开发,也不懂敏捷开发,只是昨天听了林承仁分享的敏捷开发那块,有一些自己粗浅的理解,纯粹记录下自己的一些想法。还希望各位不吝指点 ^ ^.
为什么需要敏捷开发?
一般我们传统的开发模式是:
1,需求分析(时间长)
2,架构设计(需考虑周全,严谨设计)
2,文档编写(文档多,内容多,编的越麻烦,就越难理解;表述一定要准确,人打交道的是文档,每个人的理解不一样,理解偏差)
3,模块分配,任务分配(模块固定,任务不够原子,强耦合,模块之间互不通讯,每个人只管做好自己的模块)
5,编码(先要理解复杂的文档,只有结果测试,不敢重构,宁愿不动烂代码,保证结果正确就ok,写足够多的注释,以免其他人调用的时候不够清楚细节。)
6,测试(如果架构有问题,必须要等到所有模块完成之后测试才能发现问题,没有自动测试,重构后很难保证代码正确性)
7,上线(上线后,用户需求不满意,推到重写,或者勉强折衷。发现模块出问题,只能找写该模块的程序员才能解决,其他人不清楚细节,难以修正)
…
敏捷开发是什么?
说直白点,原子化切分,人与人打交道,而不是文档交流,快速迭代,拥抱变化,测试驱动开发,最早的出错,最早的发现问题,清晰细节,敢于重构,快速修正。
0,没有复杂的文档,人与人面对面交流,一起分析,一起设计,一起讨论。
1, 结构松散,将项目横向切分,切分到足够小足够原子,接口单一,弱耦合。
2,功能细分,先将确定的,以后变化小的拿出来先做,变化的模块尽量用接口接上。
3,快速迭代,拥抱变化。
4,测试驱动开发,敢于重构。
5,团队之间没有秘密,互相信任,各自的细节互相清楚。
最后,自己有一个想法,那就是----- 交换开发
1. 交换思想。针对一个模块,交换怎么做的思想,每种做法的优缺点。从而找到一种最好的方式。
2. 交换检查。自己写的代码,其实自己很难看出错误。交换检查代码,既能够看出对方的bug,又能从别人的代码中吸取好的东西,互相成长。
3. 交换角色。你今天是领导者,明天你是执行者。 交换下角色,你能够更清楚自己说下命令或者执行命令时, 对方的思想。这样能够更好的扮演好自己的角色,而且不会有层级关系所带来的不平等性,从而降低隔阂,紧密合作。
嘿嘿,这种模式如何?这只是自己最直白的理解,粗鲁的表达,请大家指点指点。。。