敏捷开发实战：经验与教训（第二版）

5星 · 超过95%的资源需积分: 6 49 浏览量更新于2024-07-21 收藏 464KB PDF 举报

"Broken.Agile.2nd.Edition.1484217446" 是一本关于敏捷开发实践的书籍，作者通过实际经验的故事来阐述敏捷开发中的问题和成功案例，旨在帮助读者理解并正确应用敏捷原则。本书详细介绍了在采用敏捷开发过程中可能遇到的好与坏的例子，涵盖了各种敏捷价值观和原则。每个章节都围绕特定的敏捷价值和原则，用故事来说明它们在实际应用中可能会被误解或误用的情况。书中的故事不仅教育性强，也具有一定的娱乐性。作者通过这些故事揭示了在真实世界中敏捷开发的运用及其不良适应所带来的后果，并分享了一些公司在成功采纳敏捷方法上的实例。学习目标包括： 1. 了解敏捷开发的正确和错误应用案例。 2. 理解敏捷开发的特定价值观和原则。 3. 分析这些价值观和原则如何被误解或正误应用。 4. 探索敏捷方法在实际项目中的运用。 5. 明确不良敏捷适应可能导致的后果。 6. 学习一些公司成功采纳敏捷开发的经验。这本书面向有经验的软件开发者，尤其是那些正在向敏捷软件开发过渡的人群，对于考虑实施敏捷流程的团队尤其有帮助。书中的章节主题涵盖了： 1. 引言：介绍本书的背景和目的。 2. 扩大规模的成功：讨论如何在大型项目中应用敏捷。 3. 沟通：强调沟通在敏捷团队中的重要性。 4. 薄弱的基础：分析基础工作的重要性。 5. 长期成功计划：探讨如何为敏捷项目的长期成功做准备。 6. 及时调整：讲解如何灵活应对变化。 7. 发送错误信号：提醒团队避免误导行为。 8. 平衡生活与工作：讨论个人与团队的平衡问题。 9. 假装到成功：关于假装熟练直到真正掌握的策略。 10. 建立团结：促进团队协作的方法。 11. 保持参与：保持团队成员积极性的策略。 12. 根本的误解：澄清常见的敏捷误解。 13. 估算法的挑战：讨论敏捷估算的难点。 14. 透明度：强调透明度在敏捷过程中的作用。 15. 规范与测试：如何有效地进行需求定义和测试。 16. 适度的过程：平衡结构与灵活性。 17. 实体与虚拟：比较实体与虚拟工作环境的影响。 18. 结语：作者对敏捷开发的一些最终思考。通过本书，读者可以深入了解敏捷开发的实际应用，从中汲取教训，避免常见的陷阱，以更有效地实现敏捷转型和优化团队效率。

Chapter 3 | Communication

Story 5: Lack of Productivity

While on a small e-commerce team (nine developers), I had to attend a daily

9 a.m. meeting. All developers had to attend this meeting. The problem was

that usually the developers were working on completely different projects.

After about a week of attending these meetings, I asked some other team

members, “Do you find this useful?” The answer I received from all of them

was a quick “no.” Every day I noticed that most of the developers would

bring their laptop into the meeting and would hardly pay attention to what

was going on in the meeting, which lasted for about 30 minutes. I would like

to say that there was some value to these meetings, but that was usually just

not the case. However, the manager was insistent that everyone be there at

9 a.m. sharp. In one meeting I recall we spent almost the entire time watching

the manager try to test a defect that had been discovered. Unfortunately, this

manager didn’t realize that the value of the meeting was basically nonexistent.

I should mention that this team was moving toward Scrum but did not claim

to be an Agile team.

Thoughts

I thought that Story 5 provided a good example of a missed opportunity for

productive communication. One solution would have been to have that meet-

ing once a week or even every other week and have a Daily Stand-up meeting

for developers who were working on the same project. A Daily Stand-up

meeting would have provided much more value to the developers and would

have been shorter, and people would have paid more attention because the

topics would directly relate to what they were working on.

Story 6: Inability to Share Knowledge

While on a small project with three Scrum teams, I saw first-hand how poor

communication leads to a lot of wasted time. I was on one of the teams for

only a few weeks when it became clear that all the teams had major commu-

nication issues. For example, one team had problems with the management

of issues in its defect tracking system. One of the team leads held most of

the information in his head, and the User Stories contained very few details.

I was assigned one such User Story. When I wanted more details about the

User Story I asked other team members. Everyone I asked said that only the

team lead had knowledge about how a certain part of the application worked.

This is an obvious case of “single point of failure,” but even with that being the

case the User Story could have contained comments that would have helped

me work on it. Another situation that occurred often was being assigned a

User Story for the current Sprint, where the User Story was marked as “not

started.” After working on one of these User Stories for several hours I was

Broken Agile

told that someone else was already looking into it. Again, time was wasted

because something as simple as updating the status of the User Story hadn’t

been done. Poor communication comes in many forms, and since these teams

relied so heavily (like most teams do) on an issue tracking system, it was one

source of miscommunication.

Thoughts

Story 6 demonstrates how a few minutes of someone’s time to add comments

or update the status of a User Story could have saved hours and duplicated

work and allowed the work to be started sooner. This may not sound like a

big deal, but multiplied by several developers over months, it adds up.

The bottom line is that our tools are just one of the communication channels

we use on teams, and that communication needs to be good. So take the time

to make sure you are not a point of failure on your team: create documenta-

tion (the “teach others how to fish” metaphor), and make sure that you keep

User Stories updated in whatever defect tracking tool you are using. It is a

matter of discipline, but updating will improve communication on your team

Story 7: Simply Too Much Noise

On a large project there is always a chance for communication overload,

which just creates noise. What I mean by “noise” is simply a lot of things that

distract developers throughout the day and ultimately result in a lot of wasted

time. I am not talking about the normal amount of company communication,

e-mails, and chat rooms that we have all become accustomed to in software

development; those just come with the territory.

On one large project, though, I saw an extreme misuse of communication

channels and the amount of “noise” was ridiculous. For example, there were

several e-mail distribution lists (developers only, architects, team leads, etc.).

At first this worked, but over time people started sending things to the

“everyone under the sun distribution” list. Literally hundreds of e-mails a day

went out. Probably somewhere around 90% of these e-mails only pertained to

10–15% of the recipients. We also had many IRC channels and Skype rooms.

But again, people started to use them in unintended ways that just created

noise. People would tell jokes, and that would snowball into an hour-long

comedy hour. That is great, but it is very frustrating when someone is trying

to ask a legitimate question. It was not unusual to be away for ten minutes and

come back to a Skype window and see hundreds of unread messages. In the

end, most people just stopped watching the Skype rooms and IRC channels

and filtered most e-mails.

Chapter 3 | Communication

Thoughts

There have been a lot of studies showing the cost of constantly being dis-

tracted throughout the workday and switching contexts. It all adds up to a lot

of wasted time. I definitely experienced that, as I mentioned in Story 7. It was

simply overwhelming. I think there are things that could have been done bet-

ter. Following are some ideas of how things could have been done differently:

It would be better to educate people on using the right communication chan-

nel, not just what is easiest—the use of the right e-mail distribution lists,

the use of the right IRC channels, and so on. Make this part of the onboard

process for new hires on the project. Kindly remind people about using the

correct communication channels when you spot misuse.

Something else that can help is to write succinct e-mails. There have been sev-

eral articles written on this topic. One of my favorite suggestions is using just

the subject line for short e-mails and putting “EOM” at the end of the subject

line. EOM stands for “end of message.” When people see EOM at the end of

the subject line they know they don’t need to open the e-mail and read it; they

can just read the subject and then delete the e-mail. This probably saves three

or four button clicks per e-mail. This is just one tip for using e-mail more effi-

ciently, and there are a lot of great articles on this topic which are worth read-

ing. One such article, by Brad Isaac, can be found at http://lifehacker.com/

5028808/how-eom-makes-your-email-more-efficient.

When you are using Skype and are part of several groups, change the notifica-

tion settings so that you only get an alert when certain words are entered into

the conversation. Then, you can look at conversations that did not trigger a

notification when you have time.

If a conversation in a Skype group or IRC channel really only pertains to a few

individuals, take it offline into a new group or channel. This will help cut down

on the amount of noise for all the others in the channel.

If you are fortunate to be co-located, have face-to-face meetings—which are

much more valuable from my experience. Also, just get out of your seat and

go talk to someone if he is close by. You get the added benefit of stretching

your legs, too.

Story 8: A Common Language

Over the last 17 years or so I’ve worked with people from all over the world

while at various companies. With these companies being located in the United

States, knowing English was typically a requirement. At one of these compa-

nies, all the teams that worked on similar parts of the application sat in the

same area. Co-location is one of the smartest things I think a company can do

for Agile teams. It promotes conversations and you overhear things that you

Broken Agile

might not ever find out about had the team(s) not been co-located. It is a great

way to increase productivity—at least that has been my experience. So, when

I noticed that many conversations in this area where my team was located

were taking place in Spanish, it made me wonder if this could have a negative

effect. About a third of the team spoke English and Spanish and the rest of

the team spoke English and perhaps one other language other than Spanish.

When I heard these conversations, I wondered if what the developers were

talking about would benefit the rest of the team. Would someone on the

team be able to offer valuable information if he or she could understand the

topic being discussed? Basically, I always wondered, “Is this harming the team

in anyway?”

Thoughts

I think this is a sensitive area. No one wants to be the person to say, “Can you

please use English.” It might not come off as being a constructive suggestion.

But I do think something is lost in a co-located team if people are not speak-

ing a common language. For example, I was in Argentina for one company and

I remember seeing the curious look on other developers’ faces when some

of us had work-related conversations in English. They wanted to be in on the

conversation, as well they should be.

So, I think there is a polite way to simply ask team members to speak in a

language that everyone can understand in that particular environment. It is

nothing personal but is meant to help the team better communicate and get

the most out of being co-located.

Story 9: Scrum Master Should Not Be a

Part-Time Role

On many teams, a developer on the team or even the manager sometimes

plays the role of Scrum Master. While I’ve seen this work in some instances, it

can also hurt the Scrum team. For example, I was a member of a Scrum team

where the manager played the Scrum Master role. The problem was that the

manager had several teams and had a lot on her plate. Because of this, she

would miss many of the Daily Stand-up meetings, at least for my team. This

led to several instances where the manager was completely blindsided. I recall

that during one Daily Stand-up meeting I mentioned that my User Story had

some changes to its scope. I had mentioned this in several previous Daily

Stand-up meetings, but the manager had not attended those meetings, so on

this day when I mentioned it again, the manager was completely caught by

surprise and not too happy.

剩余96页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

敏捷开发实战：经验与教训（第二版）

全局安装 Vue cli3 和 继续使用 Vue-cli2.x操作

Revo Uninstaller Pro 2.5.3破解版

uTorrent v1.8.3.15358 Beta/v1.9 build 14981 Beta 多国语言版

Addison.Wesley.Agile.Software.Engineering.with.Visual.Studio.2nd.Edition.2012

Agile.Product.Ownership.2nd.Edition.1530399882.epub

The.Agile.Samurai.How.Agile.Masters.Deliver.Great.Software

Software.Engineering.Modern.Approaches.2nd.Edition.14786

Scrum.and.Xp.from.the.Trenches.2nd.Edition.1329224272

The.Art.of.Agile.Development

The.Art.of.Agile.Development.2007

最新资源

全局安装 Vue cli3 和继续使用 Vue-cli2.x操作