敏捷实践

我们如何从领域驱动开发当中获益--王德水

 

领域驱动设计,遇见你之前

我们公司推行和实践敏捷已经很多年了,SCRUM已经成功应用于大部分项目,得益与业界敏捷开发大师以及国内很多优秀工程师的分享和宣传,我们使用了很多优秀的软件开发实践,比如测试驱动开发(TDD),行为驱动开发(BDD), 持续集成(CI)等等为我们带来了很多收益。由于我们公司以做项目为主,虽然这些软件实践确实能很好的提高软件交付质量和效率,但是要想用好这些实践,涉及到的因素很多,常见的如下:

善用工具——成就高效沟通协作的团队

《敏捷软件开发宣言》 
 
我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:
个体和互动 高于 流程和工具 
工作的软件 高于 详尽的文档 
客户合作 高于 合同谈判 
响应变化 高于 遵循计划
 
也就是说,尽管右项有其价值,我们更重视左项的价值。
 

敏捷实践系列(一)

敏捷实践

开篇:

悟空:师傅,为什么你写东西,喜欢写系列呢?

师傅:因为很多东西需要长期的实践呀。

悟空:怎么又开始说敏捷了

师傅:就像一本好书,常读常新,人生不同阶段过的都是不同的人生呀。

悟空:师傅,为什么你原来用上、中、下呢?

师傅:因为原来只写了个上中,别人一直问下,现在如果只写一二,别人要问,我就说写完了呀!

悟空:。。。。。。

写在盛安德成立14年:用敏捷协助客户业务创新

盛安德14周年:用敏捷协助客户业务创新
这两年国内IT行业有较大发展,尤其是互联网产业突飞猛进,加剧了行业人才竞争。我们一直引以为傲的薪水优势已经消失殆尽,尽管我们在提升报价上不遗余力,尤其在美国市场,近两、三年我们的报价提升了50%以上。如果单纯提高报价,靠传统的项目外包业务和供应商ODC模式(Vender),我们的可提升空间已经不大了,业务转型无法避免。
 
我们必须为客户提供更高附加值的服务,咨询服务是我们最先想到并开始尝试的,但很快我们就发现仅靠咨询服务,仍然不能全面提升我们的价值和报价,除非人人都是咨询师。同时,当我们的咨询师拿到客户合同,开始实施时,他发现实施过程也面临方法问题,照老办法自己累不说,还经常成为团队的瓶颈。怎样与开发(交付)团队合作,能够在保证高质量交付前提下,为客户创造最大价值?
 

测试驱动开发(TDD)实践

不知道大家有没听过“测试先行的开发”这一说法,作为一种开发实践,在过去进行开发时,一般是先开发用户界面或者是类,然后再在此基础上编写测试。但在TDD中,首先是进行测试用例的编写,然后再进行类或者用户界面的开发。由于要先开发测试用例,那么开发人员就必须清楚测试的目的,所测功能模块的业务逻辑以及需要测试的场景。这样TDD确保了项目的代码与所需的业务是匹配的,并且在日后的开发工作中也能确保之前所做的功能的可测试性。
 
很多同学问TDD是使用那种编程语言,或者是某种技术,这里需要明确的是,TDD并不是某种技术,而是一种项目实践。
 
二.传统开发模式与TDD开发模式
 

Software Development Project Management: The importance of the role of project leader

接到这个命题作文已经有一段时间了,一直没有写,主要原因是里面有两个东西影响,一个是标题里的Management,大部分人第一感觉Management就是要“管”人,就是 “权”,另外一个词是Leader, Leader经常被人翻译为“项目经理”,也就是“官”。所以在我写文章之前一定要把这两个词解释一些,因为这两个东西一直是我作为负责人要去弱化的东西。同时,我需要解释一下这两个英文词我的理解,”Management” 就是管理,Leader就是就是引导,就是榜样。

第一次做“敏捷教练”

一位软件产品公司朋友找我,想在公司内部推动敏捷,让我帮忙做研发团队敏捷教练。这是四、五个月前的事情,不久前,团队终于在Scrum模式下完成了一款产品升级,尽管跌跌撞撞,但还是坚持下来了。我在过程中只参加了两次回顾会。
 
第二款产品比第一款困难得多,无论技术难度还是业务复杂度都不在一个量级上,团队里有一半成员经验丰富,另一半几乎是新手。经过商量,他们决定让经验丰富的成员带新手,将项目分成几个大的模块,每个人带一个新手领一个模块。PO和架构师都认为这样既能保证开发进度,也能保证质量,只是将八个人变成四个人的敏捷团队。是这样吗?
 

论“敏捷”之惑

“敏捷”,不仅仅是一种方法论,更关乎思维方式或做事的态度与哲理。

盛安德科技曾是推行“敏捷”理念的先驱者,如今已不再强调这个理念本身了,因为我们发现,多数人只是将其理解为一种工作流程,行事之道却早已背道而驰了。而我们的初衷,是希望团队中的每个人都可以在此理念指导下更加独立地工作,激发自己的创造力。

Scrum 的流行加深了人们对于“敏捷”的误解。因为 Scrum 很容易理解,对于习惯了“瀑布流”软件开发流程的人们来说尤其如此,所以很多人将 Scrum 流程等同于“敏捷”,认为“敏捷”是与“瀑布流”相对而言的一种开发流程而已。可事实上,“敏捷”本身与流程无关,而 Scrum 更像是一种流程。请注意,马丁×福勒(Martin Fowler, ThoughtWorks 公司的 CSO),敏捷开发方法的创始人之一 ,可不认为 Scrum 就是“敏捷”。

Pages