2008年5月11日

    在敏捷开发过程中,我们还需要对系统架构进行设计吗?事实上,Martin Fowler在《Is Design Dead?》一文中已经给出了答案,那就是我们同样不能忽略对系统架构的设计。与计划性的设计(Planned Design)不同,我们需要演进式的设计(Evolutionary Design)。在敏捷开发的生命周期中,我们通过每一次迭代来丰富与更新我们的设计方案,以使其最大限度地符合客户对系统的需求。这里所指的需求,包括 功能性需求和非功能性需求。

    在Agile Journal四月刊中,IBM's Methods Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法,他提出了所谓“架构预测(Architectural Envisioning)”的方法,以应对敏捷开发中逐步演进的架构设计过程。

    Scott指出,敏捷模型驱动开发(Agile Model Driven Development,AMDD)明确地包括了初始需求分析与架构建模,这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代,就相当于项目的热 身活动,是项目得以启动的基础。在此迭代期间,团队需要充分地理解项目的范围,甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初 的粗略估计,以制定合适的项目计划,从而获得启动项目的资金与足够的支持。

更多内容,请阅读发表在捷道·敏捷堂的文章
posted @ 2008-05-11 21:00 张逸 阅读(1428) | 评论 (5)编辑

2008年5月3日

agiledon01.gif“敏捷方法”本为舶来品,追求的是灵活、小巧、敏捷地应对软件开发过程中的变化,而不像某些重量级开发方式那般笨拙不堪,流于形式,而忽略了软件开发的变 化万端。敏捷重思想、重精神、重原则、重实践,而轻形式、轻过程、轻方法、轻管理,讲究的是敏捷为本,交流至上,持续改进,因地制宜。若体会了敏捷思想, 只要遵循敏捷的基本原则,各种方法皆可敏捷。若未曾领会敏捷的真谛,那么即使应用了敏捷方法,也不过是“空有其形,大失其意”,终究是“画虎不成反类 犬”!

敏捷方法并非玄之又玄的“道”,不过对于国人来讲,用“道”来阐释敏捷之精神,至少可以避免陷入某种思维定势,少去许多约束与条条框框。至于如何去理解 “道”的含义,就需要实际去推行敏捷方法,从而在过程中去体悟。《敏捷之道》电子杂志荟萃了国内诸多敏捷专家或爱好者的思想体会、工作实践以及个人 认识,是发表在捷道·敏捷堂的优秀文章摘选,其目的在于推广敏捷方法的实践与运用。

本期电子杂志精选了7篇文章,分为敏捷思考、敏捷实践、敏捷方法、敏捷工具、好书推荐五个栏目。由于捷道·敏捷堂还处于草创时期,因而文章内容或有不足之处,或有偏颇之处,不过套用许多电视台的用语,那就是文中观点仅代表作者个人意见,仅供参考。文章包括:

印第安人的灵魂——敏捷回顾

印第安人在赶了3天路后,会停下来小憩一天,因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺(Sprint)后,也需要休整,以等待团队的灵魂跟上来,这一过程被称之为“敏捷回顾(Agile Retrospectives)”。

解开最后期限的镣铐
 
在大型遗留系统基础上运作重构项目

本文以ThoughtWorks中国公司与客户合作的咨询项目为背景,为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目,从而切实有效地改善系统质量。

单元测试实践小结

异地分布式敏捷软件开发

异地分布式软件开发(Distributed Software Development)是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。
 
McDonald & Scrum

Scrum是一种敏捷方法,强调快速反应,讲求人的配合等等。而其团队组织方式是多功能型,由具有各种才能的人组成足以达成既定任务的团队。 

欲善敏捷开发 先利敏捷工具

敏捷开发的潮流并不是由敏捷工具来推动的。但近年来,为了更好地支持敏捷开发,敏捷工具也有了很大的发展。

杂志下载,请访问:敏捷之道第一期
posted @ 2008-05-03 22:04 张逸 阅读(1881) | 评论 (15)编辑

2008年4月29日

   鉴于产品开发目的的不同,微软永远不可能与开源社区走到同一条道路上来,但并不排斥双方有合作的可能。然而,让我们感到奇怪的是,一直以来微软对于开源的态度始终让人捉摸不定,时而漠不关心,时而高调抨击,时而又主动示好。

   目前,我们唯一可以肯定的是,微软不再视开源为洪水猛兽,甚至于一步一步的,微软也在亦步亦趋的踏入开源社区的领域,例如微软成立的开源实验室,公布 Windows和.NET Framework的部分源代码,以及成立类似于SourceForge的开源网站CodePlex。分析动机,有业内专家指出,微软真正关心的的问题不是一个公司是否是开源性质,而是这个公司是否可以帮助销售微软的平台产品。真是一语道破天机!商业利益是凌驾于一切之上的。

    我们观微软的态度,已经有了与开源和睦相处的苗头。那么,微软对于开源项目,尤其是对于开源的.NET项目究竟保有怎样的态度呢?最近,Redmond Developer News的编辑Michael Desmond就提出了这样一个疑问,那就是:开源.NET项目是否受到微软的冷遇?

    文章提到了Redmond在去年六月对Jeff Atwood的专访。Jeff是Coding Horror Developer Blog的创始人,他对.NET领域的开源项目贡献良多,除了进行博客创作之外,同时还创建了自己的开源项目Stackoverflow.com。

    Jeff在Coding Horror Developer Blog上曾经承诺,会将广告收入的一部分回赠给开源社区。近日,Jeff兑现了他的这一承诺,将5000美元的奖金颁发给了ScrewTurn Wiki开源项目的开发者Dario Solera。ScrewTurn Wiki是一个基于ASP.NET的Wiki引擎。实际上,奖励仅仅表明了Jeff的一种态度,那就是感谢那些为.NET开源开发领域作出卓越贡献的开发者们。

    这正是Jeff举措的关键目的。Jeff认为“开源项目在微软体系中被当成了二等公民。”他说道:“微软错误地降低了对开源项目的支持,而事实上这些开源项目对.NET世界贡献良多。”他相信微软作为开发工具的提供商,其命运取决于公司是否愿意改变其一贯的做法。

    Jeff的观点颇具争议性。实际上,在全球的.NET开发人员中,有很多都使用了各种开源工具,例如DotNetNuke、MbUnit、NAnt、 NHibernate和ZedGraph。而开发人员使用的.NET开源工具还有很多,以上列出的仅仅是冰山一角而已。微软也正在积极地参与和响应与开源社区(CodePlex、IronPython和IronRuby项目、Mono开发等)的合作。

    那么,开源.NET项目的开发者们为何没有切实感受到微软对他们的支持呢?

    确实,微软虽然在自己的开发工具中集成了部分优秀的开源.NET工具,但这些工具终究是凤毛麟角。此外,微软虽然对开源项目提供了一定的支持,但这种支持与微软对其商业产品的庞大投入相比,实在是九牛一毛。

   很多时候,微软表面上对开源社区的支持,实质上却是醉翁之意不在于酒。例如,微软在四月初发布了与开源兼容的XAML/WPF规范,允许开源项目使用这些规范。这或许是微软的示好之举,对于开源开发起到了一定的促进作用,但此举的背后却代表着微软可以借助开源的东风进一步推广WPF与XAML。

    微软对开源.NET项目确实提供了一定的支持,但很多时候,微软却是以其强势地位对开源项目给与了沉重的打击。例如微软于去年推出的MVC Framework以及LINQ,它确实为.NET开发者带来了极大的便利。但随之而来的,却极大地影响了Castel MVC Framework以及NHibernate的发展。显然,集成在Visual Studio中,并作为.NET Framework一部分的MVC Framework和LINQ对于普通的.NET开发人员而言,更具有吸引力。但对于开源社区而言,却是极大的挫败。

   显然,Michael Desmond提出的所谓“开源.NET项目遭遇微软冷遇”的观点是站不住脚的。微软不可能忽视开源社区的力量。相反,微软会极度关注开源社区的发展,一旦意识到某个开源项目的商业价值,或者感觉到它对微软产品的威胁,微软这头猛兽就会主动出击,或者吞并蚕食,或者打造利器与之分庭抗礼,进而掠夺市场占有率。这是微软的一贯伎俩,因为微软在面对商业竞争时,永远都不会坐以待毙。

本文最初发表于IT168
posted @ 2008-04-29 22:27 张逸 阅读(2932) | 评论 (33)编辑

2008年4月20日

几天前,InfoQ发表了文章《给敏捷团队发奖金就像在刀尖上跳舞》,单从标题就可以看出其中的“惊心动魄”,显然我们需要高超的技艺,以及皮粗肉糙的脚底,就像某些非洲土著那样,方才能够游刃有余地舞动在刀尖之上。

确实如此,通过发奖金的形式来激励团队成员,本身就是一把双刃剑,弄得不好,可能就会破坏团结,导致彼此之间的矛盾与冲突,这对于一个团队而言是绝对致命的。然而,如果一个团队缺乏合理的激励方式,又无法调动成员的积极性。如何取舍,真是伤透脑筋。

现在,让我们思考一个场景。项目成功结束了,要奖励整个团队与团队成员所付出的艰辛吗?当然要,那么应该如何奖励,才能在避免吃大锅饭的情况下,既能避免团队成员之间不必要的勾心斗角,又能最大程度地激励成员的工作热情,从而皆大欢喜呢?从玩具到游戏,我的思考是抛开传统的奖金策略,采用如下的另类激励机制:
1、“技术玩具”
2、小礼品
3、自由控制的时间
4、教育与培训机会
5、选择团队成员的权利
6、开发游戏

适当的奖励可以让我们踢开刀刃,自在轻舞,但必须还要谨记如下两个原则:
1、在奖励优秀的开发人员的同时,不要忘记对优秀团队的奖励;
2、奖励方式应因人而异,必须最大程度地投合员工的喜好。

更多内容,敬请阅读捷道·敏捷堂发表的我的文章《从玩具到游戏,另类的项目激励机制
posted @ 2008-04-20 21:48 张逸 阅读(2200) | 评论 (10)编辑

2008年4月15日

博客园自从建站开始没有多久,我就成为了其中的一员,说句毫不谦虚地话,我可以算是博客园的元老了。数载春秋,博客园在不断的壮大与成长,随之相伴的是我的成长与发展。在这期间,博客园为我们创造了无数多的价值。所谓“滴水之恩,当涌泉相报”,不过,我却不知道各位园友是否体会到了这些价值?突发奇想,想问问大家,博客园为你带来了什么价值?

我想先说说自己,若以重要程度排序,依次是:
1、提高了自己的技术水平;
2、认识了许多朋友;
3、开阔了自己的视野;
4、有了自己的技术积累,出了书,翻译了书,也算是出了名;
5、当上了微软的MVP,这得益于博客园;
6、是自己的资料库后备,需要解决问题的时候,可以看看博客园。

那么,你呢?

posted @ 2008-04-15 19:03 张逸 阅读(2819) | 评论 (80)编辑

导航

公告

logo.gif
我的著作与译作

《软件设计精要与模式》

《WCF服务编程》

MVP_Horizontal_BlueOnly.png

From 03-03-2006
Counter: site stats

与我互动

我参加的小组

我参与的团队

随笔分类(240)

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜