敏捷开发
文章平均质量分 71
文斌
个人成长咨询顾问,北京航空航天大学软件工程硕士,信息系统项目管理师。
22年软件研发和管理经验。曾任数码视讯战略研究院架构师,百度架构师,百度技术委员会委员、最佳导师。
5年合伙人创业,经历了完整的企业生命周期。
展开
-
重构之法
对于代码重构,要用代码质量为标准,作为日常的一种编码方法和习惯加以强化。对于架构重构,要以架构师为主导,慎思笃行。原创 2015-03-06 19:55:16 · 3480 阅读 · 0 评论 -
利用优先级拥抱需求变更
需求变更这件事,每个开发人员都遇到过,每个产品经理也都遇到过。 以前,我们会追求需求不变更,但无论是产品型团队还是项目型团队,需求不变更都是天方夜谈,不可能实现的。即使把需求变更的成本提得很高,流程搞得很复杂,又要填变更单,又要几级经理审批,又要需求评审,依然无法避免。 于是,团队的目标变成了少变更,希望尽量少的变更既能满足业务的需要,又能减少开发团队的反感。但‘少’是个相对的概念原创 2014-07-01 20:06:18 · 2507 阅读 · 0 评论 -
重构之度
对重构活动,尤其是架构重构活动的实施,需要提升到架构层面来进行,利用架构师的丰富经验避免重构不足和重构过度,同时利用度量指标进行跟踪评价。原创 2015-03-06 20:00:44 · 3281 阅读 · 1 评论 -
90% 之伤
“小刘,你的XX任务现在到了什么程度了?” “领导放心,完成90%了,很快就做完了!” 这样的场景还是很熟悉吧,不说每天都在发生,也是时常上演。90%是一个美好的数字,既能使我们踏实,也能使我们更加担心。于是在伤痕累累之后,我们再思考一下,90%是个什么概念呢? 要想回答这个问题,我们还是得从100%说起,也就是“完成”的定义。到底什么是完成?是写完了代码,是已经调试结束,原创 2014-07-09 20:25:06 · 2214 阅读 · 0 评论 -
移动开发团队的测试实践
测试是软件工程过程的一项重要活动,其重要性、必要性无需多言,但是,在Android开发团队中,认真执行测试工作的却少之又少,没时间往往成为最有份量的理由。但这个理由在一个注重质量、注重代码长期演进的项目当中就站不住脚了,不久以后的几个bug、几次重构就要花费更多的时间。那么在移动开发中的测试要做些什么呢?下面就介绍一下一个Android开发团队的测试实践。 先来说单元测试,这个最基础的测原创 2014-07-03 20:57:30 · 1959 阅读 · 0 评论 -
敏捷之伤——燃尽图
燃尽图(burn down chart)是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。(引自百度百科) 一般燃尽图的样式如图所示。(图片来源《硝烟中的Scrum和XP》) 由于燃尽图也在传达开发速度的信原创 2013-01-03 14:29:26 · 37160 阅读 · 2 评论 -
走在过程改进的路上
忽然想到了这么多年来软件企业对软件过程模型、质量改进模型的认识变化,随笔几句。 十年前,软件企业经过前几年的发展,普遍认识到了随着软件规模、团队规模的扩大,仅靠粗糙的管理已经无法保障软件质量了,于是乎纷纷寻求外力的援助(当然,也有的是因为可以在竞标时为自己增加一份砝码)。但不管怎么样,ISO认证已经开始在企业中兴起了。可以看到企业设立了内审员等角色,甚至有的专门成立了部门,整理了相当原创 2013-11-04 20:25:22 · 2134 阅读 · 1 评论 -
防御性编码有助于快速定位问题
利用防御性编码,对不符合前置条件的情况进行快速反馈,对可以预见到的陷阱进行主动防守,通过明确的预期行为来代替运行时的不确定性,可以为问题跟踪带来非常大的便利,提升开发效率。原创 2015-01-07 19:53:49 · 3571 阅读 · 0 评论 -
软件工程过程及过程改进
软件过程主要指的是软件工程过程,即在软件开发的过程中组织内发生的各开发阶段、各项开发活动的先后顺序及其关系。这些活动有机的运转即可以完成软件开发过程。 有人将软件生命周期当作软件工程过程,这个观点是有偏差的。软件生命周期指的是软件从无到有再到消亡的过程,是软件本身的特性。软件工程过程是创建软件或者修改软件过程中所经历的分析、设计、实施、维护的过程,该过程的作用对象是软件。对于一次性开发软件,可能软原创 2011-03-07 09:35:00 · 3422 阅读 · 0 评论 -
再谈对“重构”的学习
数月前,我曾经写过一篇博文《在代码重构中蜕变》,文中提到了我对重构的一些认识,今天再谈重构,缘起于近期针对重构进行了6次技术分享,每次对应《重构——改善既有代码的设计》一书中的一章内容,在此过程中与团队一起再学习了一次重构,因此,这次再谈重构,就从学习的角度说起。 当再次拿起这本书时,想到的就是第一次阅读时的体会。几年前,第一次打开书,读完了第六章——重新组织你的函数,知道了大体上重原创 2011-12-27 20:21:53 · 2140 阅读 · 2 评论 -
敏捷之伤——站会
站会,几乎在所有的敏捷开发相关的书籍中都必然会加以阐述,虽粗略不同,但都把他视为敏捷开发过程中不可或缺的一环。个人认为,站会最大的意义是沟通,是在面对面沟通的敏捷原则之上创造的一次强制性的沟通机会,为那些在需要面对面沟通时由于个人性格、时间、被沟通者不在现场等客观理由创造一次机会。因此,站会在敏捷开发中具有非常重要的意义。 但在具体的执行过程中,有一些现象还是让敏捷开发很受伤。原创 2013-01-01 17:05:12 · 8824 阅读 · 0 评论 -
移动团队交叉双迭代的敏捷实践
作为移动开发团队,对“快”这个字看得尤其重要。本文总结了在团队中采用的交叉双迭代模型的实践经验,希望以此引玉,共同探索开发过程改进,打造高效团队。原创 2014-09-24 09:30:04 · 7115 阅读 · 5 评论 -
在代码重构中蜕变
本文介绍了代码重构过程中的心得体会,希望开发人员重视重构并以此得到编程能力的提升原创 2011-02-23 11:11:00 · 10315 阅读 · 37 评论 -
用非正式沟通减少需求和交互的矛盾
我在微博上抛出了一个问题:敏捷开发,在没有项目经理的前提下,如何协调产品经理、交互设计师、开发工程师在一个需求或交互上的不同看法?得到了好友们的关注,现在在这里做一个小结。 移动应用开发团队,共有以下五种角色:PM:产品经理,负责规划产品方向,确定产品需求;UE:交互设计师,负责设计某项功能的交互方案;UI:视觉设计师,负责设计界面元素的视觉产现;RD:开发工程师,负责软件开发;原创 2012-02-21 20:47:05 · 2783 阅读 · 1 评论 -
瀑布式迭代与敏捷
在采用敏捷开发的实践当中,有一种特别的开发过程,他融合了瀑布模型和迭代的思维,但又与敏捷的思维存在差异,我把这种过程称之为瀑布式迭代。 瀑布式迭代过程总体上采用迭代的方式,即像敏捷一样,以迭代为单位逐渐推进,每个迭代以启动会、迭代活动、迭代总结为全过程,并且每个迭代都会交付产出物。唯一不同的是单独看一个迭代过程,会发现其采用了瀑布流程。 在一个迭代周期内,首先是产品经理、交互设计师原创 2014-09-23 19:22:05 · 5672 阅读 · 0 评论 -
提升开发效率之工具篇
开发效率主要取决于开发速度和开发质量,我们都希望速度越快越好,质量越高越好,也就是开发效率高,但明显速度和质量是鱼和熊掌不可兼得,所以提升开发效率就要从这两个角度去平衡了。 影响开发效率的因素太多了,我们就先来总结一下如何利用工具来达到目的。工具分类 开发工作中会用到各种工具,我们不妨将他们分分类。建模工具 用于支持业务建模、业务分析、架构设计、详细设计等原创 2012-09-28 11:19:56 · 5135 阅读 · 0 评论