Explore
For Enterprise
Join for Free
Log In

艺术与人文
商务
计算机科学
数据科学
信息技术
健康
数学和逻辑
个人发展
物理科学与工程
社会科学
语言学习
學位
證書

瀏覽 Coursera 的全部課程

瀏覽
搜索
企業版
登錄
免費加入

2.3.2B: Extreme Programming

Loading...

软件开发过程与敏捷开发实践

阿尔伯塔大学

4.7（2,793 個評分） | 50K 名學生已註冊

課程 2（共 6 門，软件产品管理專項課程）

This course delves into a variety of processes to structure software development. It also covers the foundations of core Agile practices, such as Extreme Programming and Scrum.

查看授課大綱

您將學習的技能

Lean Software Development, Agile Software Development, Software Development Process, Scrum (Software Development)

審閱

4.7（2,793 個評分）

5 stars
2,066 ratings
4 stars
624 ratings
3 stars
71 ratings
2 stars
23 ratings
1 star
9 ratings

MD

Nov 20, 2015

Great course, now i have a really clear idea about the many choices in processes to make a better software in a quality and timely manner. I´m enjoying so much this specialization, Thanks!

MB

Jun 02, 2017

Very well done! The instructors covered a lot, their course notes are incredibly helpful, and plenty of supplementary material is provided. One of the better Coursera courses I've taken.

從本節課中

Module 3: Agile Practices

Do you want to help developers reach their full potential? Do you want to impress clients by delivering a great product on-schedule and on-budget? Then this module is the place for you! In this module, you will learn some Agile methodologies that are practiced in the industry today. This module will cover the Scrum and Extreme Programming methodologies. The practices in these methodologies are some of the most popular practices in the industry today. They provide practices that will help to maintain organized and effective development. These methodologies will help you to know the exact state of your product and deliver successfully!

2.3.2: Extreme Programming14:27

2.3.2B: Extreme Programming8:09

教學方

Kenny Wong
Associate Professor

腳本

[MUSIC]

Danielle is the product manager working with a five-person development

team to create a payroll application that allows small business owners to pay their

employees.

After delivering the prototype,

the client sends out a nasty email to the development team saying that they

found a bug in the application that calculates the wages incorrectly.

The client is very upset.

This bug would cost the business owners a great deal of money, and

employees would end up getting more money than they have earned.

Timmy and Maria were the programmers who co-wrote the unit test for this feature.

Steven and Maria were the programmers who pair programmed the source code.

Danielle, the product manager, conducted the acceptance test for

the product before the release.

Who is to blame for this error?

Choose all that apply.

A, Danielle, B, Timmy, C, Maria, D, Steven,

and/or E, the other two developers on the team.

A practice of extreme programming is collective ownership.

This means that all members of the team are responsible for errors that occur.

Therefore, everyone is at fault.

That means A, B, C, D, and E are the correct answers.

Had the client been very satisfied with the product,

the entire team would get credit for the success.

I said earlier that extreme programming is traditionally described

by 12 basic practices.

However, depending on what resource you are looking at,

they could be expressed differently.

Don Wells is the author of the first version of Extreme Programming Rules.

Instead of the 12 practices, he lays out 29 extreme programming rules.

Many of these rules overlap with the 12 we just went over, or

they combine many practices from Scrum.

There are however a few management practices that do not fit into

either of those categories, that are interesting to note.

The first practice is give a team a dedicated, open work space.

Think about the work spaces that you have previously worked in.

Do you think they enhanced your productivity and teamwork?

XP suggests that the work space have multiple computers that belong to no one.

They should be located in the middle of the room and not along the walls.

This encourages the development team to work together.

There should also be a meeting table with white boards where your teams can

collaborate and brainstorm.

The next practice is move people around.

This encourages communication and flexible work relationships.

This means that everyone knows how to develop and

operate all parts of the product.

Think about how detrimental it will be to your project

if there is only one person who knows how a feature works.

What happens when they leave?

You will be left with a void in your development.

An alternative option to moving people around would be to

heavily document features.

However, this is not the agile way.

You wouldn't have a professional soccer team without a backup goalie.

Likewise, the success of your project should not depend on one person.

In sports or development,

the most useful team members are the ones who are good at multiple skills.

The final management practice is about changing XP itself.

That is, fix XP when it breaks.

You may have noticed that it says when it breaks, and not if it breaks.

That's because it is going to break.

It's not going to run smoothly throughout the entire life cycle of your product.

Not all of the practices of XP will work well with your team.

When something doesn't work, change it.

You're going to want to have your team follow the rules until they break.

Frequent project retrospective meetings are a great way to determine

what's working and what's not.

You have been hired by a company that say they have tried to

implement the extreme programming methodology exactly.

You walk into the workplace and see a maze of cubicles.

As you walk around the work space and peek into cubicles,

you see pairs of programmers working together.

You pop into a cubicle and ask the developers where they can find the client.

One developer hands you a business card that has the client's phone number on it.

He says you can leave a message there and the client will get back to you.

You go into the next cubicle and

ask the two programmers working there when the next release is due.

They tell you that the releases are due every second Friday.

They have a release coming up this Friday.

You ask these programmers what they are working on.

They explain that they are the database team, and

that they exclusively work on maintaining and building the database.

You realize that there are many areas of extreme programming that they are not

following properly.

What are some areas of development that you are going to need to change in order

to have extreme programming running precisely in this office?

A, the workspace, B, pair programming, C, client availability,

D, small, frequent releases and/or E, developer versatility.

An Extreme Programming workspace environment is open and

encourages collaboration.

A maze of cubicles does not align with that practice.

The client should also be available at all times.

A hard-to-reach client does not encourage effective communication.

Finally, developers should move around and not specialize in a feature.

Having two developers exclusively working on the database does not comply with

extreme programming.

Therefore A, C, and E are the correct answers.

This company is not completely off base.

They do engage in pair programming and

deliver small, frequent releases, which are good extreme programming practices.

Now that you are well versed in the rules of XP,

let's talk about some of the downfalls of XP.

One downfall of XP is the need for the all or nothing approach.

If you are adopting XP for your development team,

you are encouraged to adopt all the rules of XP to get the full benefits.

Yes, I did mention that you can change aspects of XP that are not working.

But at what point is it still considered extreme programming?

What happens when half the practices don't work for your team?

The individual practices do not have as much value as the overall methodology.

But sometimes, implementing all of the practices is just not practical or

possible.

Another weakness of XP is that it is designed for small development teams.

What happens when you have over twenty people on your development team?

You are going to run into many issues with collective ownership and integration.

There is also a lack of upfront planning with XP.

Compared to other methodologies, XP does not encourage real up front software

architecture planning, and this could lead to a lot of reworking in the future.

And what about pair programming?

Sure it has a lot of benefits, but

it has not been as widely adopted as other practices.

I can guarantee it will not work with all teams.

Personality conflicts will play a huge factor.

And finally, it's difficult to arrange an on-site client.

It's uncommon that a client be made available for the time required by XP.

It's often unrealistic to expect the client to be there every time an issue or

question arises.

In an ideal world, yeah, it would be awesome for a client to always be there.

But this is real software development, where things are often far from ideal.

Extreme programming outlines many great practices for software development.

But the process also has many downfalls.

As a product manager, you're going to need to find practices that work for your team.

You'll need to experiment, maybe XP will work perfectly for you, and

maybe it won't.

That's why you must examine many methodologies, so

that you can discover the right one for your team.

You need to gather data to support which practices can work for you.

On that note,

in the next lesson you will get to move onto another methodology called Scrum.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2019 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取

Coursera
關於
管理團隊
工作機會
目錄
證書
MasterTrack™ 證書
學位
企業版
政府版

社區
Learners
Partners
Developers
Beta Testers
Translators

連接
博客
Facebook
領英
Twitter
Instagram
YouTube
技術博客

更多
條款
隱私
幫助
內容訪問
媒體
聯繫我們
目錄
附屬公司