CMMI跟Agile之间的冲突

InfoQ刚才在别的讨论组上,你还提到了CMMI跟Agile之间的冲突,能不能再多讲一下你的看法?

Bas:我认为CMMI一点用都没有。

InfoQ:呃……

Bas:CMMI关注的是管理和组织,而不是开发本身。在CMMI的一大堆关键过程域(key process area)中,只有一个是跟开发有关系的。大多数的CMMI实施都会带来很大浪费。

InfoQ:不过很多人也认为,即使组织中用了CMMI,他们照样可以使用一些敏捷实践,例如测试驱动开发,持续集成等等。

Bas: 没错。我的意思是,CMMI跟Agile在价值观上有冲突,而不是在实施上。我不知道CMMI的价值观到底是什么,但是看上去它们的价值观是过程重于人, 文档重于可以运行的软件。我不是直接从实施的角度去看敏捷,而是去看敏捷的价值观和原则,但是CMMI的价值观和原则是什么?我不知道,因为它们从来没有 被记录下来。不过我敢打赌,如果它们被记下来的话,那肯定跟敏捷是冲突的。

InfoQ:哈哈,过程重于人,文档重于可以运行的软件……

Bas:所以,即使你满足了CMMI 5的标准,你依然可以使用Agile;你用了Agile,也可以过CMMI 5认证,但是我还是认为,二者是冲突的。CMMI……它不会关心源代码写成了什么样子,你们团队怎么协作,你是否雇到了恰当的人……

InfoQ:好的,非常感谢你能接受我们的采访。

Bas:多谢!

 


----------摘自《Bas Vodde谈新书“Scaling Lean and Agile"及敏捷与CMMI的冲突》

作者 李剑 发布www.infoQ.com于 2008年9月27日 上午12时4分

转载于:https://www.cnblogs.com/badapple126/archive/2008/10/28/1321057.html

Foreword: Why Scrum Works<br/>Suppose I’m traveling from Chicago to Boston by airplane. Before and during the flight, the pilot gets instructions from air traffic control. We take off on command and follow the prescribed route. Once we are in the air, computers predict almost to the minute when we will land in Boston. If things change—say the air is bumpy—the pilot must get permission to move to a different altitude. As we approach the airport, the pilot is told what runway to land on and what gate to go to.<br/><br/>If, however, I set out for Boston in a car, I can take whatever route I want, whenever I want. I don’t know exactly when I’ll get there, and I probably haven’t planned what route I’ll take or where I’ll stop for the night. En route, I follow traffic laws and conventions: I stop at red lights, merge into traffic according to the prevailing customs, and keep my speed consistent with the flow. In an automobile, I am an independent agent, making decisions in my own best interests framed by the rules of the game of driving.<br/><br/>It’s amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shipper’s Web site and a driver will arrive at my door before the time that I specify. The driver isn’t dispatched to each house; he or she receives a continually updated list of addresses and deadlines. It’s the driver’s job to plot a route to get all the packages picked up on time.<br/><br/>As complexity increases, central control and dispatching systems break down. Some might try valiantly to make the control system work by applying more rigor, and indeed that works for a while. But the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. It might work to provide same-day delivery with a dispatch system that plans a driver’s route at the beginning of the day. However, it is far more difficult to preplan a pickup route when customers can enter pickup requests at any time. Taxi companies sort things out at a central control center. Some shipping companies send the request to the driver responsible for the area and let the driver determine the best route based on current conditions and other demands.<br/><br/>The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulate—relinquishing control to independent agents is a time- honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work.<br/><br/>Another reason that Scrum works is that it dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment. Again, complexity plays a role here. When a system is simple, it’s not so hard to know in advance what to do. But when we are dealing with a market economy that changes all the time and with technology that won’t stand still, learning through short cycles of discovery is the tried-and-true problem-solving approach.<br/><br/>We already know this. We try out various marketing campaigns and discover which approach works. We simulate vehicle behavior during car design to discover the best slope of the hood and best distribution of weight. Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches.<br/><br/>Scrum is built on 30-day learning cycles that prove complete business concepts. If we already know everything and have nothing to discover, perhaps we don’t need to use Scrum. If we need to learn, however, Scrum’s insistence on delivering complete increments of business value helps us learn rapidly and completely. One of the reasons complete increments are important is that partial answers often fool us into thinking that an approach will work, when in reality, the approach doesn’t work upon closer examination. We know that until software is tested, integrated, and released to production, we can’t really be sure that it will deliver the intended business value. Scrum forces us to test and integrate our experiments and encourages us to release them to production, so that we have a complete learning cycle every 30 days.<br/><br/>Scrum doesn’t focus on delivering just any increment of business value; it focuses on delivering the highest priority business value as defined by the customer (Product Owner). The Product Owner and the Team confer about what that definition is, and then the Team decides what it can do in 30 days to deliver high-priority business value. Thus the short feedback loop becomes a business feedback loop—Scrum tests early and often whether the system being developed will deliver value and exactly what that value will look like. This allows the system to be molded over time to deliver value as it is currently understood, even as it helps to develop a better understanding of that value.<br/><br/>Another reason Scrum works is that it unleashes the brainpower of many minds on a problem. We know that when things go wrong, there are people around who knew there was a problem, but somehow their ideas were overlooked. For example, when the space shuttle disintegrated on reentry, a widely reported interpretation of the causes of the disaster suggests that there were engineers who were well aware that there could be a problem, but they were unable to get their concerns taken seriously. What management system can we use to leverage the experience, ideas, and concerns of the people closest to the work to be done?<br/><br/>According to Gary Convis, president of Toyota Motor Manufacturing Kentucky, the role of managers in a healthy, thriving, work environment is “to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.[1] <br/><br/>Scrum turns small teams into managers of their own fate. We know that when we are responsible for choosing our own driving route to Boston, we will find a way to get there. We will detour around construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned by a central control and dispatching center.<br/><br/>If teams are of a size that encourages every member to participate, and team members feel like they are in control of their own destiny, the experience, ideas, and concerns of individual members will be leveraged, not squelched. When team members share a common purpose that everyone believes in, they will figure out how to achieve it. When teams understand and commit to delivering business value for their customers, when they are free to figure out how to perform tasks, and when they are given the resources they need, they will succeed.<br/><br/>Gary Convis notes that Toyota’s sustainable success comes from an “interlocking set of three underlying elements: the philosophical underpinnings, the managerial culture and the technical tools. The philosophical underpinnings include a joint [worker], customer-first focus, an emphasis on people first, a commitment to continuous improvement…. The managerial culture…is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, and finally, fact-based decision making and long-term thinking.[2] <br/><br/>Scrum works for all the same reasons. Its philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of these factors are in place, it’s hard for Scrum not to succeed.<br/><br/>—Mary Poppendieck<br/>Poppendieck.LLC<br/><br/>
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值