敏捷

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

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

 

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

 

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

 

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

 

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

 

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

 

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


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

相关 [随笔文章 ] 推荐:

在路上

- Alex Yu - 人月神话的BLOG
那一天,我不得已上路,为不安分的心,为自尊的生存,为自我的证明. 路上的心酸,已融进我的眼睛,心灵的困境,已化作我的坚定. 在这里想讲一个真实的创业团队的故事,是上个周末我和这个公司老总聊天得知的一些信息,这些信息基本完全真实,老总是原来我部门的一个产总,另外一个项目经理是我原来科室的骨干,可以间接算我的师傅.

谈工作型PPT的制作

- Ivan - 人月神话的BLOG
首先要明确是做哪方面的PPT,根据目标进行破题,破题后形成大致的框架结构,支持PPT的一级和二级目录. 工作中常见的PPT包括方案类的PPT,工作总结类的PPT,项目汇报类的PPT,专题培训类的PPT. 破了这个再来考虑传递的东西应该是如何一步步传递,传递的结构应该如何. 方案类的PPT可以延续IT咨询或问题分析和解决的标准思路,即问题定义,问题分析,解决方法,初步验证.

理想和现实

- pu - 人月神话的BLOG
周末在网上看了电影《老男孩》,最先想到的就是理想和现实. 读书的时候估计每个人都写过《我的理想》,那时候写的最多的估计就是老师,工程师,科学家,医生之类. 要么是灵魂的工程师,要么是无私奉献的白衣战士,或者是保卫边疆,再者是发明创造. 很美好,也很符合主旋律,可是真正搞清楚为什么的又有几个呢. 写都能够写,真正的感兴趣又作为自己毕生追求的又有几个呢.

工作十年,写博五年

- 旭斌 - 人月神话的BLOG
今天比较特殊,是我工作十年和写博客五年的一个纪念日. 最近工作事情繁多,经常出现思维和注意力无法常时间集中的情况,如果按五年一个周期来计算,那到今年已经走完两个周期,又是需要好好进行思考和总结的时候. 很多时候确实很忙,但是很忙的时候最怕的又恰恰是忙的来思考的时间都没有,或者是念头一闪而过又无法深入进行思考.

再谈问题分析和解决思路

- Typhoon - 人月神话的BLOG
如果从问题层面来将工作中的能力,那么一个是独立解决问题的能力,一个是自己提出假设创造问题自己解决的能力. 前者足以应对复杂多变的内外环境,后者足以提出有价值的创新. 而独立解决问题的本身又包括两块,一个是针对问题现象提出应急解决方法,一个是针对问题根源提出的风险管理和预警机制. 问题分析和解决本身就应该是一种通过迭代不断收敛的过程,因此根源分析和机制建立就显得更加重要.

为什么做不出好产品(2)

- zhoujg - 人月神话的BLOG
一个好产品必须是可用加可行,可用代表会产生价值,可行代表可以实现. 一个软件产品要成功最终的衡量标准还是用户的使用和喜爱程度. 用户经常会主动想起来要用你的软件,即成功一半,用户在用的过程中感觉很易用,即成功了一大半. 在这里我们不讨论赢利模式的问题. 现在有两组人,一组是技能全部达标但是个性突出不喜欢受太多约束的人;一组是技能不达标,工作态度都挺好的人.

微博点滴整理(3)

- Ranagerol - 人月神话的BLOG
经验说:一见钟情是因为他/她的面容、气质一下子牢牢攥住了我的心. 实验说:喜欢上一个人仅仅是因为他/她长得很像我们生命中重要的某人. 有教养的头脑的第一个标志就是善于提问. 好问的人,只做了五分种的愚人;耻于发问的人,终身为愚人. 一个人经验的积累或解决问题的能力,不是其穷举式的定义和分析问题的能力,而是提出精准假设的能力.

集成测试-意义和方法

- - 人月神话的BLOG
集成测试是将模块按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的问题. 如数据穿过接口时可能丢失;一个模块与另一个模块可能有由于疏忽的问题而造成有害影响;把子功能组合起来可能不产生预期的主功能;个别看起来是可以接受的误差可能积累到不能接受的程度;全程数据结构可能有错误等. 集成测试是单元测试的逻辑扩展.

再谈企业2.0的核心逻辑

- - 人月神话的BLOG
对于企业2.0的三重境界,宝明有一篇文章做了详细的阐述 http://www.huohua.me/view.php?id=46,其中分为三个重要的阶段:. 社会化社区:形成知识社区和各种社区的进一步融合,消灭传统知识社区的孤岛. 社会化使能:挖掘知识社区能力,也挖掘业务系统能力,并进行进一步的融合.

再谈IT规划的核心逻辑

- - 人月神话的BLOG
前面我写文章谈过IT咨询规划的核心逻辑,说到了IT规划本身就是一个问题定义,问题分析和解决的过程. 是一个通过现状分析,了解差距,明确目标,达成目标的目标驱动的过程. 下周再谈下IT战略规划的核心步骤和关注点. 对于IT规划,基本遵循的思路还是从业务到技术,从流程到IT,围绕价值链优化和分析的核心驱动模型.