冰云@Blogging

敏捷的弱点是什么？

“敏捷的弱点是什么？”，一个刚接触敏捷的朋友如是问。

敏捷方法是一种适应性方法，换句话说，由于它本身的适应性，他可以去适应各种情况，并且可以根据实际的效果来调整自身，从而改善它的适应程度。因此，首先我们说，敏捷的弱点或者优点这样的问法是不妥的，应该问，在什么情况下敏捷适用性不好？

敏捷的产生主要是来自于开发团队，开发团队发现他们在进度、质量等方面的能力无法满足业务需求，于是提出要加强交流，增进反馈，避免各种内部浪费。于是开发团队在实践上采用测试、迭代、提高交流效果等等，最终在效率上得到了很大提升。

但是，很快的，这个团队意识到，光提高开发的质量还不行 。开发测试之外的很多东西也需要敏捷才可以，尤其是在发布一个新版本的时候，旧有的发布方法没法满足开发的速度要求。他们于是提出了敏捷的需求管理，要求和业务部门之间建立专门的业务分析来进行沟通；数据库重构技术，要以往DBA所负责的部分也能够变得敏捷，适应开发的需要；部署和发布方面也需要一套高效的方法来适应快速发布，快速反馈的需要。于是，整个IT部门变得更敏捷，从需求到发布的整个软件生命周期都得到了很大的改善。

然而，这个部门很快又遇到了问题。虽然IT部门的开发很高效，但他们和其他的业务部门之间总遇到难以解决的问题。或者是业务变化跟不上，或者是售后支持没法及时反映。于是，由CIO带领，公司开始了整个的组织转型，将一个组织敏捷/精益化，建立敏捷业务和精益企业。让IT部门的价值得到最大的提升，由新的IT系统来促进业务的发展。

不过，问题又来了。由于业务的发展，公司需要和其他的公司之间进行数据交换，共同开发通讯接口。合作公司的反应速度和开发效率极低，大大的降低了合作的效果。于是，公司派出咨询师，帮助合作公司进行过程的改进。最终达到共赢。

这一整套过程下来，敏捷/精益的思想得到了贯彻，开发效率和业务效率得到很大提升，公司获得了很大的企业价值。然而，如果这一切都无法顺利的完成呢？

在某些公司，由于各种原因，一个团队的敏捷程度完全取决和他们合作的部门或公司的敏捷程度。在一个项目中，我的一个同事所在的团队需要和数据库部门以及另一个开发部门协作，从而完成一个系统集成应用，然而，他们没有数据库的操作权限，同时另一个部门的API尚未就绪。他们很快就开发完毕自己所分配的部分功能，在等待中不断的催促和协调另外的部分。一个几周的工作，硬生生的被拖到了三个月。

综上， 敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部门、公司做事方式的时候。

不过，我认为，改变一个人虽然困难，但我们可以去影响他们。只要从基本的实践处做起，逐渐的，周边的人会被带动，从而可以推动整个部门的改变。一个部门改变了，公司领导会很快意识到这种变化，变化也有可能影响到其他部门。只要我们坚持去做。

Tags: Agile 敏捷, consulting

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 思考 | No Comments »

Distributed Agile Software Development

异地分布式敏捷软件开发 (Distributed Agile Software Development)

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。

异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。

但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离岸，通常在时差8小时以上）。如下表。

异地分布式开发的组织方式

异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。

有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。

各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。

基本原则：极尽交流之能事

异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。

为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。

交流频度和价值图，Vincent Massol，2004

每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问题。如果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。

如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更是经常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每日的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。

交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会谈。尽量减少陌生感，使交流效果提升。

任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许，公司应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。

敏捷开发过程的改进

般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一端，一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员到场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。

日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。

项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。

一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持续集成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽搁。

基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。

每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条件不允许，可以分别进行，并互相通报回顾结果和改进方法。

离岸团队的参与度

多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派需求和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。

解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果都处于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目相关的技术决策等等。

不要忽视offsite团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励offsite团队决策和发起讨论，这样可以提高他们的参与度。

实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。

近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。

Tags: Agile 敏捷, distributed

Posted in Agile 敏捷, ThoughtBlogs, 思考 | 2 Comments »

Annotation与技术风险随便写写

Annotation这几天讨论的很火。vincent同学一直叫嚣要AspectJ+Annotation做个project出来。
taowen倒先下手为强，搞了个Singleton。这……离应用还差得远呀。

我现在真是不敢随便在project中引入新东西了。我们的OSS大杂烩，带来了超级学习成本：
JDK5 Generics Webwork Spring Hibernate3 DisplayTag WebStandards Buffalo
JasperReports JFreeChart Hession EclipseRcp 加在一起，能想象是什么样子么？
虽说经过几个月的磨合，已经很稳定了，但这……是一个人就能完全搞定的吗？
如果有CG或IDE支持，可能会更加好用。

想使用新的东西，ok，没问题，至少给我4个水平不错的人。如果只有我和vincent。。。那。。就不用想了
技术的最好的学习办法是实践。不在项目中真正实践一次，绝对不能深刻掌握。
JDK5的新特性中，泛型、for循环、那个…（不知道叫什么）、以及枚举都已经非常频繁的用起来了。

最近Hibernate 3.1和jbossEJB3都release了新版本。Java EE5也投票了。Peter他们的JFox应该开始跟进了吧。
我想不妨引进来一点看看效果。一来练习一下，二来看看是否和以前的版本冲突
Annotation也在想到底如何使用才好，做了个Transform的Annotation，vincent说还不如Factory…
Annotation需要一些标准。不然大家最后都定义自己的Annotation了，岂不是又白统一了？
Apache赶紧行动起来推出commons annotation就好了。
今天大家讨论的WebOnSwing很不错，如果配合上Michael的Buffalo当实现和我的WebStandars Component做模版，
那vincent同学就可以参与界面开发了。但这东西，如果想要实用，至少要解决一些常见的技术应用或提供组件：
例如，上传，报表，分页，不知道它table组件怎么样。还需要经过一段时间的磨合，把多种技术真正整合出一个能用的framework，就像上面那个大杂烩，虽然东西多了点，但能用，而且还能快速开发。

Thoughtworks的价值观很好，人是最重要的。
所谓的技术风险，根源还是由于人。只要有足够优秀的人，就不会有技术风险。

Posted in 思考 | 1 Comment »

Java培训、实践与认识

人的学习过程是渐进的，人的认识是来源于实践的。

最近有个人问我，刚学Java看什么书好。我推荐说《Java与模式》《重构》。
诚然，这两本书不是入门就能看得懂的。但，问题在于，Java的功力并不看语法。

大学里经常有人抱着一本Java语言教程看来看去，直到最后也没看出点什么。
Java的学习在于实践。其实，任何东西的学习都是。除非你是天才，不需要动手就都会。

我推荐看这两本书，是希望一个初学者能够先提高自己的眼界：
Java与模式讲了UML、模式和Java中不少地方的原理
重构讲了JUnit和基本的重构思想。这些都是一个Java程序员的基本素养。
哪怕第一次看不懂，也要浏览一遍。等到用到的地方，自然会想起来。这时再去看。

公司有一名新来的刚学Java的同事，我帮他配好所有环境，告诉他如何用Eclipse
然后，每天告诉他几件简单的事情让他做。例如，今天是修改Hibernate配置，
明天是写Webwork的Action，后天是统一修改页面某处。
他开始并不知道自己在做什么，但能够照猫画虎的做个囫囵。

之后，等他有了直观的感受后，我一点点地开始培训，
这次是OO基础知识，下次是Web原理，再下次是开源软件，然后是元数据与反射，
再往后是O/RMapping，想到什么就培训什么，问到什么就解答什么

很快的，大概一周之后，他就能够自己独立修改一部分项目代码
也对项目和整个框架有了大体的了解。

对他的培训是从易到难，实践和理论相结合的培训。这样的效果最好。
如果希望集中培训三天就能上岗胜任的话，我想那效果不会比这样好。
带入到项目中，用实战来培训。不怕出错，就怕不好学。

这是我最近的一点体会~

Posted in 思考, 项目管理 | 1 Comment »

组织组织的组织

偶然看到了一个网站，非常有意思。MeetUp.com，也是属于SN一类的website.
它的主要服务是为各类组织注册网上小组，发布聚会信息，和提供用户加入。

meetup的宣传Flash，号称是21世纪新的交流方式

之前它一直是免费的。免费注册Meetup Group，免费加入Group，免费聚会。
它的注册人数众多，因此各地餐馆咖啡厅都纷纷跑来合作，提供聚会地点。而它也因此盈利。

4月，meetup.com开始对普通用户收费，Group月费$19。
会有人每月花19元去活动吗？一定会的。而且会是那些比较稳定的Group。

这种模式在中国能行的通吗？我想是可行的。毕竟人基数多阿。
在中国，凡是和大量人口有关的东西都赚钱。

Posted in 思考 | 8 Comments »

灵感千万要写下来

去年这时候我有过一个想法。那时候几个朋友闲着没事，考虑做点什么项目来做。
我提议做一个Blog，是给bookstore作Blog。由很多人写他们的书评或读后感。同时提供对书的评价等。
当时还笑称，要做好了就卖给China-Pub。免得大家老买到烂书。

well，现在有人作了类似的东西了。当然，比我想的更丰富。豆瓣，一个SN网站。
提供了书价比较，书评，读后感，藏书，标签，小组等功能。
不过真是不知道他们靠什么盈利，自己开始卖书吗？但无论如何，人家做了。

得到的教训是，有了灵感要记录下来，多想想，能否付诸行动。然后，do it，宣传并找到商业模式。

Posted in 思考 | 3 Comments »

de parvis grandis acervus erit

de parvis grandis acervus erit，这句话是Google Toolbar的About中写的
意思是： Out of small things a great heap will be formed

中文的意思大概是： 合抱之木，生于毫末；九层之台，起于累土。。。

Posted in 思考 | 3 Comments »