精益软件开发的实践智慧

需积分: 10 174 浏览量更新于2024-07-24 收藏 11.98MB PDF 举报

"《精简软件开发的艺术》是关于如何高效、敏捷地进行软件开发的一本书，它探讨了如何在开发过程中去除浪费、提高效率，借鉴精益生产的思想来改进软件开发流程。书中可能涵盖了诸如敏捷开发、极限编程、持续集成、精益原则等核心概念。O'Reilly 出版社还提供了其他相关的书籍，如《HeadFirst Software Development》、《The Art of Agile Development》以及 Extreme Programming 的口袋指南等，这些资源可以帮助读者深入理解软件开发的不同方法和实践。通过访问 oreilly.com 和 oreillynet.com，读者可以获取更多关于开源和新兴技术的新闻、事件、文章、博客、样章和代码示例。此外，O'Reilly 还组织各种会议，将创新者聚集在一起，推动行业的进步，并提供 Safari Bookshelf 在线参考图书馆，供程序员和 IT 专业人士搜索超过1000本书的内容。" 详细说明：《精简软件开发的艺术》这本书的核心在于介绍如何运用精益思想优化软件开发过程。精益思想源于制造业，其核心是消除浪费，提高效率。在软件开发中，浪费可能表现为过度设计、等待时间、不必要的文档、缺陷修复等。书中的内容可能包括以下几个方面： 1. **敏捷开发**：敏捷开发是一种强调快速反馈、迭代开发和团队协作的方法，如Scrum或Kanban，它鼓励在开发过程中灵活应对变化。 2. **极限编程（XP）**：极限编程是一种敏捷方法，主张频繁的客户反馈、结对编程、简单设计和持续集成，以确保软件质量并快速适应需求变化。 3. **持续集成**：通过频繁地将代码集成到主分支，可以尽早发现并解决问题，减少集成风险。 4. **精益原则**：如Just-in-Time（适时生产）、价值流映射、拉动系统等，帮助识别并消除浪费，提升软件开发的效率。 5. **质量管理**：强调预防优于修复，提倡编写可测试的代码，使用自动化测试工具进行持续测试。 6. **团队协作与沟通**：良好的团队协作和有效的沟通是精简开发的关键，书中可能会介绍如何建立高效的团队文化和工作流程。 7. **技术债务管理**：当为了短期速度牺牲长期可维护性时，就会产生技术债务。书里可能会讨论如何识别和偿还技术债务，以避免它对项目造成负面影响。 8. **度量与改进**：通过收集数据和分析，不断改进开发过程，如使用看板系统监控工作流，以便及时调整。除了阅读《精简软件开发的艺术》，读者还可以通过 O'Reilly 提供的相关书籍和在线资源，如《HeadFirst Software Development》和《The Art of Agile Development》等，进一步学习不同角度的软件开发方法和技术。这些资源可以帮助读者拓宽视野，理解和实践各种开发策略，提升软件开发的专业能力。

The practice of software development has been plagued with shockingly low success rates for

decades. At the same time, the number of software-driven products and services continues to

increase dramatically each year. If these were the only two trends, we would be heading for

disaster.

Fortunately, Agile software development methods have been demonstrating that higher

success rates are possible. And Lean techniques (which have dramatically increased

manufacturing success for over 50 years) are now being applied to software development and

validating the successes of Agile.

The Lean principles and the mindset of Lean thinking have proved remarkably applicable to

improving the productivity and quality of just about any endeavor. Lean has been successfully

applied to manufacturing, distribution, supply chain, product development, banking,

engineering, the back office, and much more. However, only in the last few years have the

Lean principles and techniques been applied to software development.

In this chapter we will give you more details on the problems that continue to plague software

development, as well as an overview of Agile software development and the origins of Lean

and its unique approach to improving any kind of process.

The Problem with Software Development

Have you ever worked on a software development project that:

• Went over schedule?

• Went over budget?

• Didn’t meet the needs of the customer?

• Was canceled?

If you said no, you are probably fresh out of school and are still working on your first project.

If you said yes, you’re not alone…not by a long shot!

The actual statistics are shocking.

The 1994 CHAOS Report from the Standish Group is

the

landmark study of IT project failure.

By 1994, the Standish Group had studied over 8,000 software development projects and found

that only 16% were successful. This means that 84% of the projects either failed outright or

had serious problems. In 2004, after 10 years of study, the number of projects included had

increased to 40,000, and the success rate had improved to 29%. Although this is a significant

increase, it’s still nothing to brag about.

Can you think of any other industry that has such a staggeringly low success rate?

2 C HA P T E R 1: W HY L E A N ?

Software development is a highly dynamic process and change is inevitable. During

implementation you’ll find problems with the design. Customers don’t know precisely what

they want ahead of time, and that will change the requirements.

Studies show that the Waterfall method is positively correlated with reduced productivity,

increased defect rates, and project failure. Why, then, was the Waterfall method so widely

promoted, and how did it become so entrenched in the face of so much evidence that it did

not work?

A historical accident

Winston Royce first described the Waterfall method in a 1970 paper titled, “Managing the

Development of Large Software Systems” (Technical Papers of the Western Electronic Show

and Convention). This paper is often cited as if it validates the Waterfall model, but it actually

does the opposite. People who use Royce’s paper to support the Waterfall method must not

have read this paper carefully because it explicitly says that the Waterfall method “is risky and

invites failure.” The paper then proceeds to advocate an iterative development style.

The Waterfall method would likely have slowly faded away, but in the 1980s it became the

Department of Defense (DoD) standard for the development and procurement of software with

the release of DOD-STD-2167. Eventually, the DoD realized that the Waterfall method was

not working and in 1994 replaced DOD-STD-2167 with MIL-STD-498, which supports iterative

development.

However, the damage was done, and a strong mindset with a bias toward Waterfall

development had become ingrained. The Lightweight methods of the 1990s and the Agile

methods of the early 2000s have started to turn this around, but there is a long way to go.

Many people who are not familiar with the evidence are still staunch supporters of the

Waterfall method.

The Agile Success Story

The Agile software development methodologies were the first attempts to improve the software

development situation, with Lean coming onto the software scene much later.

Most of the Agile methodologies, like Extreme Programming (XP) and Scrum, actually predate

the Agile Manifesto (which we will discuss shortly). In fact, using the term “Agile” to refer to

these methods of software development was coined at the famous Snowbird meeting that

created the Agile Manifesto.

In the 1990s there was a growing dissatisfaction with the prevalent heavy software

development methodologies and processes. Using these processes did not solve any of the

endemic problems of software development: high project failure rate, low software quality,

and generally unhappy customers.

T he A g i l e S u c c e s s S t o r y 5

This spawned a number of alternative methodologies, including XP, Scrum, Dynamic Systems

Development Method (DSDM), Crystal, and Feature Driven Development (FDD), that were

collectively known as Lightweight methods. The term “Lightweight” was meant to distinguish

them from the predominant heavyweight methods of the time. Their creators were not happy

with the term “Lightweight” because it seemed to imply that these methods were less

comprehensive or less important.

It became increasingly apparent that these Lightweight methods had a lot in common with

each other. So, in February of 2001, a group of 17 of the leading independent thinkers about

software development gathered at the Snowbird ski resort in Utah to try to find common

ground. The roster of this two-day gathering included many of the most prominent

personalities in software development at the time: Kent Beck, Mike Beedle, Arie van

Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim

Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve

Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.

Three significant things came out of the now-famous Snowbird gathering: the decision to use

the term “Agile,” the Agile Manifesto, and the Agile Alliance. The Agile Alliance (

http://www

.agilealliance.org/

) is a nonprofit organization that exists to further the development and

dissemination of information regarding Agile processes.

As stated earlier, no one was happy with the term “Lightweight.” Alistair Cockburn articulated

this nicely when he said, “I don’t mind the methodology being called light in weight, but I’m

not sure I want to be referred to as a ‘Lightweight’ attending a ‘Lightweight methodologists’

meeting. It sounds like a bunch of skinny, feebleminded people trying to remember what day

it is.” And thus, we now have “Agile.”

The Agile Manifesto

The Agile Manifesto (formally called the

Manifesto for Agile Software Development

) is a model

of simplicity. Written by Kent Beck et al., it eloquently states the four core values that form

the philosophical bedrock of all Agile methodologies:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

6 C HA P T E R 1: W HY L E A N ?

剩余143页未读，继续阅读

hohailzj001

粉丝: 0
资源: 2

精益软件开发的实践智慧

[精简软件开发的艺术].(The.Art.of.Lean.Software.Development).文字版.pdf

软件工程初始sc图到精简sc图

供应商软件开发过程裁剪是什么意思

软件测试 怎么精简测试用例

嵌入式软件开发相关知识

delphi2005精简版

orcad16.6精简版

vc6.0 msdn chm精简版

slim软件项目评估方法的特点

office2019 精简版

最新资源

软件测试怎么精简测试用例