在敏捷中找到好的实践

今天在看架构相关的文章时突然看到一段,和敏捷有关。所以也就想起了自己现在参与的项目中的敏捷概念。

我们一直在强调敏捷,但怎么个敏捷法呢?项目周期不断的缩短,中间两次迭代,CR不定期的出现,即使在版本即将发布的最后几天,此前可是经过四轮的SDV啊。

 

另外还特别遵循了敏捷方法中的站立会议,但我不知道是否起到了敏捷的作用,原本是想将过去一天的工作与问题进行总结,并对新一天的工作做合适的安排,但到最后,这个会议却显得很无用,每天每人一句话,甚至一半人的那句话别人都听不清楚,不知道这样一个团队是在做着什么样的配合与协作。而领导者呢,对于整个项目的周期与计划并不很强调,导致大家心里根本没有一个对整个项目周期的清晰轮廓。

此前开发此项目时(此项目从南京转移到深圳开发,此前项目指的是在南京开发时的那一时期)对于敏捷中的一些方法比如结对编程使用的很好,代码质量得到一定保证,同时无论需求,测试用例,编码这些重要的过程组内除了结对人要要进行检视外,组内所有手中有时间的成员都要进行检视,并填写检视表单,然后组织大家开评审会议,争取把项目问题最早的暴露并把风险降到最低。但现在这些做到的很少。当然这一段时间属于项目交接期,所以会出现很多问题,但我在想是不是正是因为这样,管理者才应该将那些好的实践方法引用到项目中来,让整个项目更加高效的交接。

 

而更重要的一部分——持续集成也没有得很好的运用。华为对于持续集成工具已经做的很好,光版本从我看到的就换了三次。但对于现在这个项目却没有真正的运用起来,反而还不如以前。而现在项目的交付去责任更重,因为多了一个现网局点。

 

也进行了大半年的敏捷实践,现列出我认为的好的实践

 

1、站立会议。 此会议不是例行,我个人认会不是每天都需要,如果没有确实的需要而举行,感觉真的很空洞。此会议多数应该由领导者以特定议题发起,且时间不需要固定。如果组内成员有想法需要与大家共同讨论同样也可以发起。

 

2、测试驱动开发。 此方法也是一个重要和很好的实践。在未进行代码开发之前将可能和必须出现的场景进行预料,写出测试用例,以方便代码完成后对基本的逻辑和特性进行有效验证。但我发现有很多人不愿意去执行此步,即使是在使用自动化测试工具的时代。

 

3、结对编程。 有一次和同事聊开发,他问我们是不是在搞敏捷,我说是,他说:敏捷就是耗尽一个人所有精力的开发方式。这句有点太过,人的精力是有限的,如果所有精力都用在今天了,那明天谁为我们来开发。但他这种说法和我以前自认为的敏捷实践中的结对编程有点像。既然是结对,那应该是这样的,两人对于从需求开始就要对要做的事以及对此前做的事都达成共识,然后一台电脑,两把椅子,一人执笔,一人紧跟。如果一人对于思路的实现遇到了问题则另一个人可以很快的接手过来,将此前已商讨过的实现方式进行下去,或修改前者错误,或直接走下去。两人都在一种编码的兴奋状态。这样才会高效的,真正的达到一种结对。当然这个实现过程并不需要两个人都进行编码,也可以只一人执笔,但对于遇到的问题(或者是在此兴奋过程中又想到什么此前没有考虑到的问题)两个人应该可以马上进行讨论然后修改和确定新的实现方案。


4、文档检视和评审。 这里的文档包括规格,需求,测试(方案)用例,以及代码,另外相关的VDD等。此检视所有成员都应该参与到其中,而领导者更应该是此中的重中之重,他对规格和现场(局方)需要的方案和特性应该最熟悉,所以他需要对规格,需求提出最有效的检视意见,对于代码则应该所有成员都去保证逻辑正确,结对人保证所有细小的地方都没有忽略检视。而检视完成后的重要一步对是组织评审,此评审必不可少,要让问题提出人与问题解决人都要明确提出的问题是否正确和必须,所以必须当堂对质。当然这些所有的问题不一定要等到评审上才解决,此前任何时刻都可以将发现的问题与问题负责人进行沟通,确定问题的存在性。这一过程包括对代码的一些特殊的问题检视,通常都会按统一要求进行checkstyle检查,还要进行findbugs的检查。

 

5、每日构建。 对于现在的敏捷开发来说,写个ant脚本加入到ICP中进行每日构建是必须的事,否则对于整个系统的完整和正确,还有项目的风险都无法预估。而项目的一些checkstyle与findbugs的问题将会遗留到第二天。这可不是一个好消息,因为它的存在意味着你们此前做的检视都被忽略了。而日后这些问题必将积重难返,你必将为当初的软弱而后悔。


6、总结会议。 这个会议必不可少,通常在一个版本快结束时进行。你会说我每天都在忙着开会,把我的文档编写的代码编写的时间都挤没了。你错了,在IT行业的会议中应该所有会议都简可能的简短和有效,如果你们的会议不是这样,那应该向组织者提出建议了。此前的会议都是必要的,现的会议是为了将来更好的将项目开发组织好,让项目中的每个人都参与到项目的管理中来。所以这个会议,与会者都要拿出一个自己对此版本开发中有需要改进的或是好的实践的例子来,当然,多多益善。这样整个团队才会有凝聚力,更重要的是这样才能不断的发现问题,现将这些问题规避在进入下一个版本之前。

 

目前,对于敏捷项目的心得就是这些,而如果你们开发的项目有一个好的系统架构,那会更加有利。因为敏捷本身就要求对所开发的代码要将各自设计模式运用起来,真正体会到代码之美丽。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
付晓岩:虽然做了六年的企业级业务架构,但是总觉得业务架构不是个好讲的东西,业务架构离不开业务模型,所以讲它就会搬出一堆枯燥的模型来,甚至会让人觉得业务架构就是建模。但建模只是个手段,建模的目的是把现象总结成模式,再从模式找到结构,将业务上看到的结构传递给技术,如果二者能够基于同一结构思考,沟通上将产生最大的便利,这就是通用语言的基础,其实说通用语言,还不如说通用结构,因为说语言,经常会把人带到语法层面,纠结于规则、概念、标准之类似是而非的东西。所以,我总结建模的原则无非是把握整体、穿透现象、保证落地,建模即不能死守规则、冥顽不化,也不能脑洞大开、信马由缰,必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦,而是传给后续过程的设计图纸。业务建模可以有前瞻性,但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。 业务架构是不断演进和迭代的,它有生命力,可以成长,如果架构管理工具本身支持历史记录和模式比对,你也可以看到企业架构的演进历史,而不是只看得到现在,只能听别人讲讲过去,过去是可以看见的。这种可视化的历史是一种宝贵的学习资源,人是从历史学习未来的,毕竟有很多行业还是需要积淀的。 但是,业务架构的形成过程的确是在一种看起来科学的方法论下,不完全科学地操作的,这点我曾经也很纠结,后来软件架构的书看多了,再加上到项目的观察,也逐渐释然了。软件架构其实很羡慕建筑架构,觉得建筑架构有力学基础做支持,有很多可以计算的东西,但是软件架构却没多少能算出来的。在开源思想时兴之前,行业内部交流分享较差,都比较愿意看别人的架构,而不想亮出自己的,很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式,共享让思维发展更快、普及更快,但是,软件架构本身却只是增加了大量的案例,依旧难以标准化,哪怕是同一个行业的企业,给这家做的软件也不一定能直接搬到另一家去,很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程,但是,依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此,业务架构也就不需要纠结了。 业务架构设计可以很快,也可能很慢。快无非是两种情况,一是架构师自身炉火纯青、天生慧眼,设计能力超强;二是原有业务模型已经很清晰,可以快速分析业务变化,形成架构设计,我们可以追求的是第二种,这也意味这首次建模,尤其是首次建设企业级模型,不要过快,对模型设计方法、业务流程分析、标准化过程,都要细致点儿,基本功扎实了,才有后边的“敏捷”。企业级转型没有轻松的,不少企业是把转型仅当成一个项目,而忽视了对自身的调整。一个普通士兵变成一个特种战士,不是因为给了他一身价值 10 万的装备,而是经过了地狱般的训练。上至最高管理者,下至普通员工,人的思维不转变,哪来的企业转变呢? 为了推动企业真正的数字化转型,业务架构设计人员永远不要忘记,业务架构最重要的职责不是传递需求,而是藉由自身的努力,推动业务和技术的深度融合,桥梁作用才是业务架构最重要的职责,如果不能实现这一目标,也就不能真正实现一个快速响应内外部变化的企业级业务系统。 其实台并非万能,客观地讲,一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的,也不会执着甚至偏执于方法间的争论,没有哪种设计方式是完美无缺的,软件行业没有“银弹”,任何一种方法都需要坚持与灵活的结合,都需要通过长期的实践不断总结和改良,如果一个方法没有被坚持数年以上,可能连入门都谈不上吧。我对台认识更多还只能算个一般观察者,论述难免有失,感谢读者朋友们能够宽容地看我一路“叨叨”下来。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值