捷道·敏捷堂 - 敏捷新闻
登录

页面

作者

分类

 

Tags

链接

版权声明

本站文章除转载作品外均属捷道·敏捷堂所有。若需转载,请标明出处。
© Copyright 2008
web statistic
该工具显著提升全球协作和项目管理等级;引入卡片树以可视化的方式简化项目复杂度。

2008年4月15日,中国北京-全球化的IT咨询公司ThoughtWorks今天正式发布Mingle2.0版。 Mingle2.0版是其强大的项目管理工具的升级版本,可帮助软件开发团队对于分布于全球的项目进行高效地管理,并使软件开发项目经理更有效地管理复杂项目。

 "IT界长期以来受到两个问题的困扰-如何高效地在全球分布式开发团队中实现交付,和如何弥补业务团队和技术团队间的沟通缺口。" 负责Mingle开发的ThoughtWorks Studios的主管Cyndi Mitchell表示:"Mingle2.0非常完美地解决了这两个问题,这正是ThoughtWorks一直致力于在IT产业掀起革命的愿景的体现。"


Mingle 2.0最显著的特性之一是卡片树(Card Trees™)的引用。这一突破性的特性使得软件开发团队能够在更高的视角上审视整个软件开发过程,同时在需要的时候深入至细节。使用卡片树,项目经理能够通过可视化的手段查看大型复杂项目中的所有任务,以及与团队合作将项目分解到可管理的不同级别卡片。

Mingle 2.0的其他特性包括:
l  跨项目报告生成和单击查看任意级别的详细信息 -程序, 项目,需求甚至团队成员。
l  计算跨项目关键指标数以保证与需求保持一致。
l  使用应用程序接口(API)和插件轻松将Mingle与现有项目结构进行整合。
 
"Mingle的灵活性允许我们跟踪和组合资源配置,同时按优先级调配和执行我们所有的工作,无论是需要改进的地方还是高端业务活动。"来自最大的网上汽车批发销售网站OVE.com的国际线上运营总监Stephen Brown表示:"我们非常期待Mingle2.0的发布,因为这无疑会拓展我们将所有业务联系起来的能力,并保证所有业务在所有层级组织中的参与。"

Mingle 2.0 距离Mingle的首次发布仅仅9个月时间。在如此短的时间里,Mingle已经拓展至上千家使用客户,其中包括3M,Sungard和McGraw Hill。

Mingle 2.0的30天免费试用版现已提供下载:

关于ThoughtWorks的Studios部门

ThoughtWorks 的Studios部门专注为IT领域从业者开发各种帮助软件开发团队简化工作流程的工具。我们的旗舰产品是Mingle-一个为开发者、测试者、业务专家和项目经理提供分享式工作环境的项目合作工具。

ThoughtWorks的Studios部门是ThoughtWorks(国际领先的咨询公司)下属的专业产品开发部门。更多信息请访问www.thoughtworks.com/studios

关于ThoughtWorks

ThoughtWorks(www.thoughtworks.com)是一家全球的IT咨询公司,为世界1000强的公司提供系统开发、咨询和服务转型服务。公司采用先进的方法,包括业界推崇的精益理念敏捷思想的最佳实践,帮助CIO们实现复杂的核心商业应用同时给其投入带来最大回报 。ThoughtWorks的客户遍布全世界各地,并在澳大利亚、加拿大、中国、印度、英国、美国和香港设有办公室。ThoughtWorks的Studios是ThoughtWorks的产品部门专注提供给客户软件开发的下一代工具。  

当前评分 5.0 , 共有 1 人参与

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

极限编程创始人谈论敏捷开发


捷道发表于2008年04月7日 11:59
来源:IT168

极限编程(XP)的创始人和“敏捷软件开发宣言”的执笔者之一,Ken Beck,一直是敏捷编程的倡导者,他认为敏捷编程可以缩短软件开发项目的开发周期。近日他参加了旧金山举行的Qcon大会,并接受了媒体的采访,谈论了敏捷开发的相关问题。
 
记者:你能谈论一下敏捷宣言和极限编程(XP)吗?
 
Ken Beck:在极限编程(XP)后面的基本设想是,肯定有一些对软件开发有帮助的敏捷行为。我曾经问过这个问题,“假若我们尽最大的热情来进行软件开发,会发生什么?”这就是“极限(Extreme)一词的由来。结果证明,如果你采取其中的一些做法,例如技术上的协作、测试,并比以前更加努力的推行这些做法,至少在一般的软件开发项目中你会获得比较好的结果。例如你的错误率会比较低,这意味着你可以更频繁的发布新版本软件。你能够以非常低的成本让项目启动进入最佳的可部署状态,与其他风格的开发模式相比,你获得了更低的开发成本和更短的开发周期。而且如果你将这种理念融入到后续的设计中,持续的对设计进行认真的投入,你可以在很长一段时间内以一种非常稳定的速率来继续部署新的功能。
 
这就是敏捷编程如何启动的方式,事实证明为了实现所有上述目标,无论是作为一个团队还是一个个体,你还必须学习许多新的社会技能:诚实、无私、有责任心。在获得一定的开发速度后,接下来的目标是,如果你想更快的进入下一步,你所要做的是能够更清晰和透明的交流正在进行的开发工作。
 
记者:你提到了推动敏捷编程发展的风格:可靠性、变化的低成本、增加的投资回报率。为什么软件开发市场正在从瀑布风格转向敏捷开发风格呢?或者现在是否只有一小部分开发者正在使用这个方法?
 
Ken Beck:是的,现在是只有一小部分开发者正在使用敏捷方法,但是我认为这一数字正在非常迅速的增长。我虽然没有明确的数字来证实我的观点,但是如果你关注一下敏捷开发者大会的增长,你会清晰的感觉到这一点。我认为现在推动敏捷开发的因素是这种开发风格更加贴近真实环境、更透明和更有责任感,如果你的开发周期比较短你会决定它就是你希望实现的开发方式。对于那些尊崇真实至上的软件开发,存在着巨大的潜在市场。
 
记者:为什么使用者还比较少?
 
Ken Beck:因为它存在的时间还不是很长。
 
记者:你今天早晨提到这个问题:用户不得不自己来确认你的软件是否可以正常使用。这本来是一件理所当然的事情,但是事实并非如此。为什么会出现这种情况?
 
Ken Beck:嗯,我认为造成这种现象的原因比较复杂,是技术和社会因素的综合原因导致了在已部署的软件中存在所有的缺陷。一部分原因是人们抱有软件天生就是不可靠的态度,客户习惯了这种状况。开发者习惯了接受这种观点。测试者也对此习惯了。我们只是觉得它像天气一样,对它无能为力,但这不是一个负责任的态度,因为实际上开发者有很多关于它的措施可以采取。从技术上来说,可以通过测试驱动开发、自动化集成测试、持续集成等手段;从社会学的角度来讲,端正自己的态度,不想推出具有缺陷的软件。以及加强开发团队成员之间的交流和关系等。
 
记者:你所熟悉的这些研究也说明了现在有如此众多失败的软件项目的原因。敏捷方法能拯救它们吗?还是只是一个临时的解决办法?
 
Ken Beck:敏捷方法是失败软件项目的救星吗?我认为许多软件项目依然会失败,问题是除非你非常深入的了解这些软件项目,你不知道会失败的是哪一个。那么敏捷方法是它的救星吗?不。我认为它依然会失败,因为好的想法并不一定在实践中产生好的结果。敏捷开发可以带给你的一件事情是:让这些项目失败的更快、损失的更少,因为你可以将时间和精力用于开始做下一件事情。
 
记者:对于极限编程,你提到隔几个星期进行一次迭代(iterations),而不是六个月到一年,你如何定义这个迭代周期,以及软件发布的周期?
 
Ken Beck:在极限编程中的基本周期,基本的计划周期是一个星期,这是非常合理的,因为它是根据人们工作的时间来定的。在每个星期结束的时候,这个软件应该比这一星期开始的时候具有更多的功能。
 
极限编程(XP)与其他敏捷方法相比如何?比如Scrum。
 
关于极限编程我比较喜欢的一件事情是其全面性。它从关于与好的软件开发一致的观点的全面讨论开始。介绍了一些基本原则,介绍了获得我们讨论的某种目标的具体的实践。因此我认为极限编程区别于其他方法的特点是它具有这种全面性。
 
记者:你能指出一个使用极限编程完成的比较突出的软件项目吗?
 
Ken Beck:例如Carfax。
 
记者:我们曾经听过“牛仔编程(cowboy coding)”的叫法,敏捷方法和牛仔编程有什么区别?
 
Ken Beck:我偶尔会体验一下牛仔编程方式,尽管它在我的工作中不占有重要地位。在牛仔编程中,你可以像一个勇士一样去编程,你会对自己的工作感到很满意,因为你认为这个世界上再没有别人可能作出和你的一样的东西。
 
极限编程风格的开发也是需要勇气的;这一点它与牛仔编程类似。但是牛仔编程是完全不透明的,而极限编程则是透明的。牛仔编程是一种个体行为,而极限编程是一种团队行为。不仅仅是程序员一起工作,还包括用户、管理者和测试者。因此我认为它们还是有差异的。
 
在极限编程风格中,早早结束编码是因为可以更快的看到真正的用户反馈,从而继续改进。一个牛仔式的程序员也会做同样的事情。或许你刚刚介绍了一半问题的定义,它们会说,“好的,我明白了”,然后就去开始编程。是的,这一点看上去和极限编程团队有些类似,但是两者实际上是不同的,因为牛仔式程序员已经结束了这次交谈,而XP团队则是才刚刚开始这次交谈。
 
记者:牛仔编程有成功的时候吗?
 
Ken Beck:当然,在短期内它具有巨大的风险和巨大的成本、巨大的隐形成本。我有过使用它的经历,但是它有时候会效果不错。
 
记者:有的软件项目是由分散在不同地区的团队成员在不同的时间来进行开发的,在这种情况下的开发情形如何?敏捷方法可以解决这个问题吗?
 
Ken Beck:是的,这就是我大多数时间的工作方式,因为我住在南俄勒冈州,出于生计,我的大部分时间仍在编程。因此我一直在进行着跨地区的开发工作。时区是一个挑战,但是最大的挑战是保持团队成员之间的关系。这是一件非常困难的事情。如果你能做到这一点,如果你的团队之间有良好的关系,那么你就能制定出技术的详细信息,例如谁什么时候进行了重构,谁加入了什么代码和已经作出的程序。
 
记者:对于Java和.Net,敏捷方法和极限编程适合吗?
 
Ken Beck:一个技术平台如果可以让你以较低的成本进行修改,它就更适合敏捷开发。你当然可以在Java和.Net中使用敏捷方法。
 
记者:在敏捷编程中有什么比较重要的事情吗?
 
Ken Beck:是的,那就是你在一个技术中需要的东西。在一个技术平台中它真的很有帮助。我的父亲一直在从事敏捷开发的技术方面工作,以汇编语言为微处理器编程。他使用自动化测试、增量设计,他频繁发布小版本,他写绝对可靠的代码。
 
记者:那么像AJAX、Ruby和PHP等脚本语言呢?它们适合敏捷编程吗?
 
Ken Beck:当然。举个例子说,Ruby来自于以人为中心的语言。你可以通过一种非常具有可维护性的风格编写Ruby代码,在很长时间内可以非常轻松的修改。我担心的是当你使用数据库的时候,这种修改可能会突然变得非常困难。
 
记者:和Ruby语言有关吗?
 
Ken Beck:一般来说是和关系数据库有关。但是敏捷社区正在推出解决这个问题的技术。厂商也正在让数据库接受增量修改。
 
记者:Web开发如何?它是否与敏捷开发特别适合?还是它只是另一个应用程序领域?
 
关于Web开发的最伟大的地方之一是其开发非常省钱。而且如果你一直在做部署的话,简单的把它放到一些服务器上就可以了。传统应用软件的刻录成光盘然后进行分发,部署的成本要大很多。

当前评分 3.0 , 共有 1 人参与

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

微软欲变身敏捷开发典范


捷道发表于2008年03月24日 12:18
来源:CSDN

微软可能是当今世界上最大的软件厂商,但是它同时也可能是在编程实践方面犯错误的数量最多的软件厂商。我们经常可以听到针对微软的各种批评意见。

它要么是发布软件太晚,例如Windows Vista和SQL Server 2005,要么就是太早发布,例如Windows ME;要么发布的产品太不安全,例如Outlook Express 5.5和6.0和IE 5.5,要么发布过于“安全”的产品,例如Vista;要么在新产品中的变化太少,例如Visual Studio 2003,要么新产品的变化让你感觉跨度太大,例如Office 2007的Ribbon界面;要么编写的程序过于臃肿和复杂,例如Vista,要么编写的程序过于简单,例如的微软的Bob产品。总之,微软很少有不被人们批评的时候。

很明显,在微软的31000名开发者中并不缺乏天才的存在,他们绝大多数都是程序员中的佼佼者。但是由于这个公司的编程团队过于庞大,再加上它的产品数量的繁多、产品的重要性和产品的普及范围广,所有这些因素加起来就形成了一个可能妨碍高效编程的环境。

但是,如果你相信微软服务器和工具部门的管理者所说的话,你或许会对微软的看法有所改观,据他们表示,与过去几年相比,微软已经变成了一个更加敏捷的开发商。

采取新开发策略 向敏捷开发进军

在这个微软内部称为STB的部门领导下,微软已经利用新的开发策略来帮助它的程序员使其产品更快上市,同时还可以保证代码的质量更高,以及更快速的响应来自用户的反馈。

这是一种什么策略?其中包括在开始编写任何代码之前收集来自用户的反馈;加强推出新的社区技术预览版(CTP),替换或淡化传统的alpha和beta测试版模式,CTP模式使用了一种“早发布,常发布”的方式来实际测试软件;创建独立的“feature crews(功能小组)”,可以迅速的创建特定的功能,并且针对这些功能直接与用户交流。

负责微软开发工具的高级副总裁Soma Somasegar在本月的一次采访中表示,“我不认为有猛然醒悟的说法。我们只是认识到我们是在为客户开发产品,而不能仅仅从技术角度考虑问题。因此我们如果能越早的与客户结合起来,我们就能越早的做出一个更好的架构、功能、品质产品和可扩展产品,而所有这些都是客户所关注的。”

四年开始的这种改革在近期达到了顶点,上个星期微软正式发布了2008版的Windows Server、SQL Server和Visual Studio,它们每一个的开发过程都使用了上述列出的所有新技术。

反对者:微软现状令其很难敏捷


当然批评者依旧存在。首先,批评者们指出,尽管微软在用户反馈和开发的灵活性方面取得了一定成效,但是最近的同时发布三个新产品不是它们取得成功的体现。

Visual Studio 2008自从去年11月份就早已有之,而Windows 2008上月初才交付生产。同时,RTM版的SQL Server 2008最近被推迟到几年第三季度,比原先的计划推迟了一个季度,尽管微软的确发布了一个成为完整功能的社区技术预览版。

来自kirkland的一个微软方向分析师Greg DeMichillie表示,“设定发布日期是一个公共关系手段”。他曾经作为一个开发者在微软服务器和工具部门工作了十年之久,他依然不能相信微软现在是敏捷开发的典范。

“很明显,采用CTP版和其它改变带来了一定好处,”他表示。“用户可以比较早的对产品有一定了解,微软就可以更早得到来自他们的反馈意见。但是,还不能因此断言,这个改进就会让微软能够更快发布更可靠的软件。”

关注开发工具的市场调查公司Evans数据的CEO John Andrews通过电子邮件表示,诸如Google、Salesforce.com等以Web为中心的厂商在软件开发方面都非常敏捷,甚至IBM的敏捷性也在微软之上。

Andrews在电子邮件中写到,“我相信微软正在尝试在所有可能的方面实现敏捷编程,但是它面临的实际处境是,它的代码基础的复杂性和大小使它不能够真正的实施这个编程方法,现在它做的是在可能的地方实现半敏捷开发。”

但是微软官员声称,敏捷与否和减少多少一个产品的预定计划发布时间没有多大关系,更重要的是能够在产品的第一个版本中发布更高质量的软件。

微软负责数据库开发的副总裁Ted Kummert承认,听到这个说法的用户可能会表示不同的意见,因为SQL Server 2008的发布刚刚被推迟。“但是,我们之所以决定延迟发布这款产品,是考虑到我们必须保证最终交付的软件具有很高质量,”微软上周发布的SQL Server 2008社区技术预览版是迄今为止Kummert的团队发布的第六个版本。

微软实现敏捷开发还有新武器

SQL Server和Visual Studio开发团队已经完全切换为发布社区技术预览版CTP模式,这是一个中间性质的过渡软件版本,通过它可以有机会快速得到来自用户的反馈,但是它得不到像具有完整功能的beta版那种来自微软的广泛支持。Windows Server组在开发Windows Server 2008的时候,综合使用了beta测试版和CTP版这两种模式。

微软客户服务部门的副总裁Rich Kaplan表示,在微软企业产品开发过程中,还有另外一个比较关键的地方是它的技术采纳计划TAP(Technology Adoption Programs),在这个计划中,测试软件厂商先对产品进行测试,然后将beta版或社区技术预览版应用到生产环境中,这样通过这个计划可以让微软从测试的软件厂商那儿得到丰富的线索信息。技术采纳计划由微软的客户服务和支持团队来管理,微软可以通过非正式的评论和更多的调查型数据来从参与者那儿得到反馈信息。

据一些在最近的开发周期中参与这些新产品的预览版测试的用户表示,他们发现微软在响应速度和灵活性方面有了很大的进步。

Garanti 银行的数据库系统经理Umit Nazlica表示,“我们在测试SQL Server 2008的时候要求的几乎每一个事情现在都体现在了最终版本的产品中。”Nazlica表示,举个例子来说,Garanti的IT职员要求具有更强大的资源管理和监管功能,同时还有数据压缩和解密方面的改进,这些功能都已经在新版中实现。

这个银行运行了140个微软的数据库实例,具有约 11TB的数据,它在这之前还参与了目前使用的SQL Server 2005的TAP计划。据Nazlica表示,这次的测试过程比上次要好很多。他表示,“我们投入了更多的时间来测试这个产品,而且在与微软的工作人员进行交流方面我们现在更有经验了。”

Michael Ruminer是波士顿的一个敏捷开发顾问,同时也是Visual Studio Team System软件方面的微软最有价值专家MVP,他表示,微软的开发团队现在真正的聆听客户要求,并且兑现自己的承诺。他们现在并没有表现出以往所具有的自大傲慢的态度。

Rbuminer表示,敏捷开发不可能简单的通过管理的方式来被规定。但是他又补充说,当他与微软的开发者交流的时候,他感觉到他们的管理者正在采取实际的措施来为敏捷开发扫清障碍和不必要的过程。而且他表示,在听到外部开发者对Visual Studio测试工具的抱怨后,微软公司已经相应进行了显著的改进,这一步让Ruminer看到了微软响应迅速的一面。

不过,他也表示,关于微软推出社区技术预览版的频率是否太快这个问题,还需要更多的讨论。因为这样将给用户和第三方开发商带来比较大的压力,它们可能被迫去忙于测试所有版本,Ruminer表示。但是对他来说,其积极的一面超过潜在的负面影响。他表示,“没有人会强迫你去安装CTP版。”

微软:敏捷源于用户需要

微软方向分析师DeMichillie表示,微软并不是一直就这样响应迅速。在这个公司的大部分历史中,它严格的坚持一种叫做零缺陷的开发哲学,尽管这种方法没有明确禁止公司的开发团队使用敏捷技术,它要求在编写任何新的代码之前要先修复现有的漏洞,从原理上来说,立即进行修复所花费的时间和金钱要比以后在开发过程中修复它少的多。

同样微软也不是一直这么积极的去聆听来自用户的意见。Somasegar表示,“三四年以前我们的大多数人观点是,‘我知道我怎么开发对你是好的,因此只要我认为有些功能已经成熟,我就会把它提供给你,然后我将等待你来证明我做对了。’”

微软的Windows Server分部的总经理Bill Laing补充说,“我们希望得到的反馈是‘这儿有些漏洞’,它不会改变这个产品。”

除了采取社区技术预览版之外,Visual Studio和SQL Server团队已经尽可能的去掉了体现部门本位思想的开发者、测试者和客户支持员工团队。它们都采用了Kummert所说的“feature crew(功能小组)”模式,通过由5到12个员工组成的更小的团队,一般来说包含一个编程经理和几个开发者和测试者。他表示,“通过采用这种方式,一个小组能够真正的控制一个特定的功能。”

Somasegar表示,通过使用一个功能小组的方法,他能够快速的跟踪某些与创建 Office 2007应用程序相关的Visual Studio 2008功能的开发,因此它们同时能够通过一个Visual Studio 2005的服务更新包的形式发布,这个新的桌面套装在去年就早已经发布。

同时,微软的客户服务机构已经被服务器和工具部门整合,以收集和分析来自早期用户的反馈。Kaplan表示,分析结果然后会在Red Zone会议上与开发经理分享,以帮助他们做出正确的决策。他表示,之所以为这个会议选择这个名字,是为了强调在产品发布之前需要修复漏洞的重要性。

但是,社区技术预览版模式不是包治百病的灵丹妙药,它并不一定适合所有的事情。Laing表示,虽然正式的beta测试版会花费微软更多的研发时间,用户要等多的时间来安装,但是Windows Server团队将继续借助于这种方法。“我认为测试者更换像Windows Server这样基础软件是一件不能草率处理的大事情,”Laing表示,“因此我们同时发布社区技术预览版和beta测试版,以鼓励测试者真正在生产环境中去尝试它们。”

波士顿Continental航空公司的系统架构师Dawn Getteau表示,在Windows Server 2008的开发中使用的这种过程非常适合这家公司。Getteau表示,“这种版本周期非常适合Continental,虽然我们在生产环境中部署了 Windows Server 2008 beta版,我们的更改管理、测试和验证过程都需要一定的时间来完成。”

对于自己希望得到多大的灵活性,微软同样有清晰的限度。举个例子来说,尽管上个星期微软宣布将对竞争厂商和开源开发者公布它的一些关键的应用程序编程接口(API)和通信协议的详细信息,Somasegar表示他没有考虑接受外部的对微软的.NET编程框架的源代码的贡献。

他表示,“我们希望你获得成功,这是我们给你访问.NET源代码权限的原因。但是我不知道该如何接受来自外部开发者的代码,并把它们放到一起,及时的作为一个产品的一部分进行发布。我们不会这么做,我们要确保对我们的用户负责,我们不能拿客户做试验。”

当前评分 5.0 , 共有 1 人参与

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5