敏捷宣言创始人James Grenning：敏捷尚处早期 将深入嵌入式领域

James Grenning

【Csdn.net 10月11日专访专稿】由ThoughtWorks主办，CSDN承办，InfoQ提供票务支持的第五届敏捷软件开发大会“敏捷中国2010”将于10月14-15日在北京新世纪日航酒店举行。会议正式举办前夕，CSDN记者采访了敏捷宣言创始人、全球知名讲师、过程教练及咨询师James Grenning，他就敏捷相关话题分享了自己的见解。现把采访内容进行了简译，全文如下：

记者：您能简单地向我们中国的读者介绍下您自己吗?

James Grenning：我是在70年代末才开始进行软件开发的。在用BASIC语言编写了一两个程序后，我觉得它非常有趣，并被它深深吸引了。从那以后，我就投身到了软件开发的所有领域，担任过亲自编写代码的工程师、团队领导人、管理者甚至还做过一些市场方面的工作。现在我主要对构建软件的公司和个人进行辅导、训练并与他们一块切磋。

从芝加哥伊利诺伊大学毕业后，我的第一份工作是嵌入式软件开发。我开发的第一个产品是为US-FAA开发的彩色天气雷达显示系统。我也从事过非嵌入式软件开发。

从1999年我才开始学习极限编程，当时我和Bob Martin就职于 Object Mentor公司。我非常幸运地参加了敏捷宣言制定的会议。把非嵌入式软件世界中的好方法（像敏捷、极限编程、TDD和面向对象设计）传播给开发嵌入式软件产品的公司和个人，我将其视为我的个人责任。

记者：作为敏捷宣言的创始人之一，您能否回忆一下十年前敏捷宣言是如何产生的呢？

James Grenning：敏捷宣言是在犹他州Snow Bird上举行的一个会议上产生的。Snow Bird中世界上最好的滑雪雪山之一。我的老同学当时也是我的老板Bob Martin，介绍我参加了那次会议。我不能错过这次会议，这次会议不仅有关于软件开发的激烈讨论和争论，我还可以在Snow Bird上一饱滑雪乐趣。我记得当时我们就我们觉得如何进行软件开发这个问题进行了一次讨论。

有很多直言不讳并且学识渊博的人给了很多观点。最后我们确定了这4个标准。同时在会议期间我们还举行了一些很精彩的滑雪运动。

记者：你认为敏捷开发在软件开发中有什么影响？

James Grenning：敏捷对于开发人员如何开发软件这个问题上有很大的影响力。在我早年生涯中，我们相信真正开发出好的软件的唯一方法就是把它完全弄明白，对它进行设计和制定计划，然后执行此计划。有时我们确实取得了很大的成功，但是当发布时间逼近时仍有问题阻止着开发的进行。我们觉得我们总不能提前做足充分的准备。

90年代，迭代开发开始复苏。我们采用短周期工作方式，与客户保持密切的沟通。1999年极限编程伴随着一系列支持迭代的工程项目产生了。虽然还没成为主流，但极限编程已描述出了软件如何逐步地被开发，并指出要把大部分精力放在编码中，使开发进程可视化，同时保持软件的高质量。

Scrum在使开发人员意识到敏捷的过程中起了很大的作用。Scrum促成了一个强健的开发软件的方法。真希望在15年以前我很艰难地帮助我的雇主由混乱开发模式转向瀑布开发模式时，我就知道了Scrum。

记者：自敏捷宣言诞生近十年来，您觉得什么事件可以称之为敏捷开发的里程碑事件？

James Grenning：我认为在敏捷宣言诞生之前，就已经有很多里程碑事件了。敏捷已经引导很多有激情的开发人员尝试着提高我们的开发技能。全世界开发人员为了找到更好的软件开发方法作出了很多努力。这些激情的开发人员创立了敏捷开发史上一个个小小的里程碑。

记者：作为嵌入式软件方面的专家，您能介绍一下敏捷在这个领域的应用情况吗？

James Grenning：当我首次听到Kent Beck，Martin Fowler和Ron Jeffries描述如何进行极限编程时，我联想到嵌入式开发。他们谈到的技术确实可以帮助嵌入式开发人员。Test First与模拟对象的使用意味着在代码构建过程中就可以测试它们。在嵌入式开发中，我们经常要等与软件相关的硬件搭建好后才能去测试代码，这一等就是好几个月。依靠Test First方法（现在称为测试驱动开发），我们现在就可以让代码运行起来，以便当我们把代码移植到硬件上时，它可以很好的工作。我们还可以利用可执行的用例显示工作进度。

现在，敏捷意识正在嵌入式开发社区中不断增强。但敏捷仍处在早期接受阶段。一些在桌面程序开发中采用敏捷的公司现在都在建议嵌入式开发团队使用敏捷方法。敏捷正在帮助嵌入式开发团队获得价值。

记者：我们了解到您正在写一本关于在嵌入式软件开发中应用TDD的书，您能给我们介绍一下它吗？

James Grenning：我的这本书《Test Driven Development for Embedded C》已经完成了。为了它我付出了大量的工作，它很值得一看，因为我觉得它是嵌入式开发人员学习TDD很好的入门教材。嵌入式开发人员可以通过阅读其他众多的关于TDD的好的书籍来学习它。但是我这本书的独特之处在于它是专门针对嵌入式开发人员而编写的。这本书使用他们的语言C语言编写而成，还包含很多专业术语和范例问题。使用非嵌入式C语言开发的人员也可以阅读这本书。现在几乎有500人已经从这本书的电子Beta版本中获益了(http://pragprog.com/titles/jgade/)。

记者：你对未来几年敏捷的发展情况有什么预测呢？

James Grenning：我认为很多团队能够并将从敏捷中获益。当很多团队无法从中获益时，敏捷将受到指责。像任何一种标签一样，敏捷也会被滥用、曲解。我更喜欢把敏捷看作是可以使你开发出满足客户需求的产品并可以让开发人员在合理需求下高效工作的管理方法，而不是让你及团队变得如何敏捷。不切实际的需求会导致严重、代价沉重的缺陷，是很多软件开发失败的根源。各个企业必须了解高质量工作与符合实际的需求所带来的价值。它并不是关于敏捷的，而是关于如何把工作做得更好。

现把英文采访原文附上，请作参考：

CSDN:Could you give a brief introduction about yourself to our Chinese readers?

James Grenning:I started developing software in the late seventies. While trying to avoid programming in engineering school I had to write a couple programs in BASIC. It was fun; I got hooked. Since then I have been involved in all aspects of software development, from hands-on engineer, team leader, manager, and even a bit of marketing. Now I coach, train, and consult with people and companies that build software.

I've been involved in embedded software since my first job after graduating from University of Illinois in Chicago. My first product was a color weather radar display system built for the US-FAA. We fit this state of the art system into 16K or EEPROM and used the first 8086. I have also been involved in non-embedded software, where I have been able to take main stream practices back to the embedded world.

I started learning Extreme Programming in 1999 while I worked at Object Mentor with Bob Martin. I was fortunate enough to participate in the meeting where the Agile Manifesto was written. I have made it my personal mission to bring good ideas from the non-embedded world (like Agile, Extreme Programming, TDD, and Object Oriented Design) to people and companies developing products with embedded software.

CSDN:As one of founders, could you recall how the Agile Manifesto was born ten years ago?

James Grenning:The Agile Manifesto was created at a meeting in Snow Bird, Utah. It is one of the best ski mountains in the world. Bob Martin, my long time colleague and boss at the time, invited me to attend. I could not pass it up, not only would there be great discussions and debates about software development, I'd be skiing Snow Bird! I recall how we wanted to make a statement about how we felt software should be developed. There were numerous outspoken and knowledgable people with many opinions. In the end we were able to settle on the four values. There also was some great skiing as the snow fell continuously during our stay.

CSDN:What influences do you think Agile development have on software development?

James Grenning:Agile has had a great impact on how people develop software. In my earlier career we believed that the only way to produce really good software was to figure it all out, lay out a design and a plan and then execute the plan.Sometimes we had great successes, but still problems would plague development as delivery time drew near. We figured we just were not doing enough up front.

Iterative development started making a comeback in the 90's. We worked in shorter cycles and communicated with our customers. Then in 1999 Extreme Programming appeared with a set of sound engineering practices that supported iterations. Though still not main stream, XP described how software can be done incrementally, putting most the effort into the code, making visible progress and keeping quality high.

Scrum has made a big impact in making people aware of Agile with its management practices. Scrum backed by the XP engineering practices makes for a very robust way to develop software. I wish I knew about it 15 years earlier as I toiled to help my employer move from chaos to waterfall.

CSDN:In the decade from the birth of the Agile Manifesto, what events do you think can be characterized as milestone for agile development ?

James Grenning:I think that many of milestones happened before the manifesto was written. The publishing and on-line discussions around Extreme Programming and Scrum started late last century. Having IEEE software dedicate a full issue to Test Driven Development meant people should definitely look at it. Though many look at the Scrum certification as a meaningless exercise, but it has led to Agile great awareness in the software development community.

The fact that Agile has led to so many passionate people trying to improve and evolve our craft is a tribute the the community. There are grassroots efforts all over the world to find better ways to develop software. It's all these little milestones by people that are passionate about learning and getting better that characterize agile.

CSDN:As an expert in embedded software, could you introduce the status of applying agile methods in this field?

James Grenning:Well, expert is a strong label; I've just been doing a lot longer than most people, but thank you.

When I first heard Kent Beck, Martin Fowler, and Ron Jeffries describe how to do XP, I thought of embedded. These techniques will really help the embedded developer. The genius of Test First and use of Mock objects meant that code could be tested as it was built. In embedded we often had to wait months to try code as the hardware was being built in parallel with the software. With test first (now called Test-Driven Development) we could get code working now, so that when we integrate it with the hardware it had a really good chance of working. We could demonstrate progress with executable use cases.

Unfortunately, few embedded developers were aware of Agile or XP. They were still mostly convinced that more up front work is the answer. Yes, embedded has unique challenges, but in the end, embedded or not, it's still just software. Like every niche of development, developers think they are unique, and they are. But the same techniques for incremental delivery work in embedded and non-embedded. The challenges designing repeatable tests in the presence of a database or internet connection, are the same design challenges faced by embedded developers where code depends on some specialized hardware. The only think different is that the spoken language used by embedded developers is very different than the database programmers and web developers. The same techniques work for both.

Now, Agile awareness is growing in the embedded community. I am not the only one talking about Agile at the Embedded Systems Conferences. Though I think it's still in the early adopter stage. Companies that adopted Agile in their desktops, are now suggesting the embedded teams use the same approach. Agile is helping the embedded development organizations that embrace the values, learn the practices and listen to what their agile plans tell them.

Some organizations think Agile is something engineering needs to do to fix their problems. These companies won't get as much benefit from agile as companies that realize agile has impact beyond engineering and into how companies develop the whole product.

CSDN:We know that you are writing a book on TDD in embedded software. Could you say something about this?

James Grenning:My book, Test Driven Development for Embedded C, is almost done. It's a lot of work, but worth it as I think it will help embedded developers get a good start with TDD. Embedded developers could learn TDD by picking up one of the many other fine books about TDD, but what is unique about my book is that it is written for them. It is in their language, and I mean C as well as the terminology and example problems. The book could be used by non-embedded C programmers as well, after-all, it's just C. Almost 500 people are already getting benefit from the book in its electronic beta form (http://pragprog.com/titles/jgade/).

CSDN:What's your prediction for the development of agile methods in the next few years?

James Grenning:I think many organizations can benefit from Agile and will. Many won't, and Agile will be blamed. Agile like any label will get misused and misinterpreted. I like to think it is not really about how Agile you or your organization becomes, but how well do you develop software products that meet your customer needs and allow people to do quality work with reasonable expectations. Unrealistic expectations are at the root of many software development failures and severe and costly failures. The industry must learn the value of high quality work and realistic expectations. It's not about Agile, it's about getting better.