敏捷

标签: 随笔文章 | 发表时间:2014-09-06 05:02 | 作者:人月神话
分享到:
出处:http://blog.sina.com.cn/cmmi

对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面。其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化。

 

对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:

 

对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发。这类系统对全局业务建模和数据建模的要求会更高,以保证架构完整性和概念一致性。而不是任务已经并行分配下去,出现问题了再去做调整,敏捷的短周期迭代不是做这个用的。这类的总体设计个人理解主要包括了子系统或模块的划分,接口的识别,底层全局数据概念模型,这些必须一开始就要搞清楚。

 

对于新组建的团队,团队成员相互不了解或能力差异过大,团队没有历史项目实践的磨合和经验积累,没有比较成熟稳定的技术框架时候,建议慎用敏捷开发。敏捷开发是迭代计划和版本,但是当前的迭代版本仍然是需要我们能够做出合理的估算,而不是存在大量的不确定性。

 

敏捷开发里面有一个重要的实践,即CI持续集成,这里面会涉及到单元测试,但是这不是XP极限编程里面的TDD测试驱动开发。有人认为没有采用TDD就不是敏捷开发是相当教条型的错误。即使再CI持续集成和每日构建,冒烟里面我们仍然是多种做法。一种是只写能够冒烟测试通过的少量单元测试用例,一种是只对按界面展现和逻辑实现横向分工的团队要求对于技术组件接口的朝外提供要首先写单元测试代码。TDD测试驱动开发真正能够实践好能够坚持下来的多内基本很少,这个根本就不是熟悉了TDD就能降低工作量的问题,其次对于希望通过写测试代码来想清楚需求的方法不推荐,需求是需要可验证但是不代表必须测试代码能够写清楚需求才可验证;再次单元测试往往比较难到UI和展现层,即使有Junit自动跑了还是需要人工测试,这个工作量并没有省。

 

敏捷方法论本身的思想是重视沟通和协同,减少不必要的文档,因此敏捷并不是没有文档。当前还是很多人认为通过实施敏捷方法可以不写文档,认为文档没有用处这又是走到一个极端。那么什么叫不必要的文档?个人理解其一已经在项目团队里面形成规约性质的内容,则已经有历史规约可以追溯到;其二是各种日常沟通协调中形成的讨论,记录,白板等内容,不会太注重规范格式但是要能够记录下来;其三是对于他人看你的源代码就能够理解清楚的东西不必再文档化。

 

想到哪里就做到哪里,拿着需求点就马上去做,出现问题了不断的返工和修改还美其名曰重构,通过敏捷为幌子来逃避写文档,虽然第一个迭代快速能出来但是产品能够真正上线运行进度周期反而成倍增加,再者或强调我们是敏捷每周40小时工作时间。这些都是中敏捷的毒太深,还是那句话,传统的类似瀑布的软件生命周期模型都没有应用好,能够把敏捷应用好是不可能的。团队人员本身编程能力和经验就差距较大,对自我能力和生产率评估也很弱,相互也不了解情况下能够简单的通过敏捷来纠正这些问题也是不可能的。


  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [敏捷] 推荐:

敏捷

- - 人月神话的BLOG
对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面. 其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化. 对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:. 对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发.

忘记敏捷

- Guan - 所有文章 - UCD大社区
瓦沙奇山下那段著名的敏捷宣言,至今已近十年. 似乎在不经意之间,敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论. 当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡.

在敏捷

- - 崔凯
这是在 www.scrum.org 网站上轮播的一张图,网站上 SCRUM GUIDES 一栏,详尽的介绍了敏捷开发的方式和方法,有兴趣的可以看一下. 这里仅谈一下 Scrum 怎么玩更舒服. 回到那张图,想玩的舒服,一起聊聊很重要. Scrum 不是定死的一种模式,每个团队有每个团队的玩法. 通过不断的磨合、反思、改进,形成最适合自己团队的模式.

敏捷个人和敏捷开发

- beralee - 博客园-首页原创精华区
    自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法. 没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题. 我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因.

敏捷中国2011

- Ben - 梦想风暴
果然是按照个人规律来的,我又参加了单数年的Agile China. 其实,真正仔细听的只有两个人的session,吴军和Fred George. 至于其它关于敏捷的讨论,好吧,我承认,我不是很感兴趣. 刚看完吴军的《浪潮之巅》,于是,很敢兴趣他关于工程师的说法. 在《浪潮之巅》里,他提到了五级工程师的说法,但是,书中并没有详述何为五级工程师,在敏捷中国上,他给出了答案:.

敏捷开发——Programmers(27)

- plidezus - 西乔的九卦
载于《程序员》杂志2011年第7期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

漫谈敏捷开发

- scotty - ITeye论坛最新讨论
软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上,所以软件开发必须实现双赢,帮助客户成功的同时帮助自己成功. 如:通过软件帮助客户把手上的5块钱变成50块钱,然后从客户那里拿5块钱. 通过软件帮助客户节约50块钱,然后从客户那里拿5块钱. 传统的汽车制造是以计划驱动,如根据往年的经验判断今年应该生产多少汽车,但是这样带来的问题是有可能等汽车生产出来,市场已经不需要了,而这就是一种极大的浪费.

敏捷不能当饭吃

- stern - BlogJava-首页技术区
喜欢敏捷的很多想法,喜欢它务实的态度. 我说“敏捷不能当饭吃”,当然不是说敏捷无用,相反,我倒是挺推崇敏捷的. 之前有两篇文字都涉及到一些对敏捷的看法. 一篇是 与神对话,另一篇是 对敏捷的一些想法. 只是看到很多人好像敏捷是他爷爷写的一样,龟孙子似地迷信和追捧敏捷,把工作一条一条跟书上描述的对照,一旦工作中实际操作跟书上有不一致,口诛笔伐,吐沫拳头无影腿就一齐上来了,那就太过了.

设计师谈敏捷

- xg - 所有文章 - UCD大社区
腾讯一直推广敏捷开发,也在强调敏捷开发,但你会发现,即便如此,还是会陷入以下情景. 我们如何构建一个更轻巧的开发流程,让我们更快更好的交付结果. 作为一个设计师,如何成为敏捷的一分子. 以下是一些心得方法,希望和大家分享. 作为设计师,最简单能让大家明白你的想法就是先把它画出来,不要用晦涩的语言和结构图,毕竟不是所有人都能把你的语言转化为图像.