敏捷方法和实践（二）

 

著名的敏捷开发

由于有许多敏捷开发方法都过时了，并且他们之中的不同之处需要花点时间来掌握，本章主要简明的介绍他们其中的两种：Scrum和XP。一旦你简要的浏览了这些方法，就能举一反三了。

一些朋友可能对于混合的方法应经有点迫不及待。但是，这正是敏捷（agile）的关键。首字母是A的敏捷（Agile）专注于纯粹的米哦系那个，小写字母a开始的敏捷（agile）专注于解放你的思想，去帮助你更快更容易的你的完成目标。敏捷（agile）就意味着自适应和加快你的脚步。

现实世界中，当你忙于顾客的工作时，任何你原本打算的按日程完成并且严格遵守理论规矩的进行事情，通常会在实践中出现差错。这可能会让你感到有点无奈，但是这却是使顾客高兴地唯一方法。

Scrum

Scrum是一种（即使是在遵守敏捷标准的情况下）给小型团队带来巨大灵活性的敏捷项目管理方法。下面是Scrum工程所需的典型属性：

❑    你需要一个产品备忘录——一个待办事项的优先列表。

❑    自我管理的团队根据产品备忘录生成冲刺的备忘录。

❑    每个冲刺是指一段短期的持续时间（通常为1-4周），在这段时间里最受关注的事情将会发生。

❑    每个冲刺以冲刺准备周期开始，在这段时间备忘录的冲刺细节就会被确定。

❑    每个冲刺以回溯结束，在此期间将进行事后分析。

每个团队都拥有一位Scrum的管理者，他负责指导促进，并且和外界沟通。Scrum的管理者并不是团队的领导者。许多外行认为Scrum是项目的管理者，但这是错误的。

Scrum认为顾客不愿因改变他们的想要的东西。有时导向的改变是主观的，而且是反复无常的，而有时它们应为市场压力而产生改变。先不考虑原因，变化发生了，并且一般的预测性的方法根本没有机会预计到这些变化（很具有讽刺意味）。相反，Scrum认为这些变化是不可避免的、不可预测的、模糊不清的，更加注重于增强团队的能力去适应变化，并且仍然能递交一个很棒的项目。

团队和出资人（比如说企业主、市场经理、CEO、CFO，等等）紧密合作，以便制定出进一步做讨论的需要备忘录。通常，需求备忘录由一个确定的被称为“商品主”的出资人维护。在大多数情况下，商品主是指CEO，但是他也可能是市场经理或者是项目经理。

备忘录本质上是最终顾客给出的需求优先级列表。在每个冲刺的开始阶段，软件团队将把产品备忘录中的置顶的部分转化为冲刺备忘录中的任务。尤为重要的是，在任何一个周期中只能从事力所能及的任务。

任何一个周期的目标是创造潜在的可交付的软件——换句话说，在限制时间的后期（一个星期或两个星期之类），你所拥有的将要考虑被提交。它将是在功能上完善的，相当无误的，文档编写相当完善的。

 

例如，产品备忘录可能包括下面几个优先级列表：

❑ 顾客希望能够确保每个页面视图和其他网站的统计值都是安全的。

❑   顾客需要带有超链接的报告。

❑   顾客需要能够无延迟的、实时访问数据。

❑   顾客需要带数据的信息图表，而不仅仅是数据表格。

团队可能浏览一遍备忘录后经前面两个重要的部分转化为下面一系列的任务：

1． 创建视图来显示报告。

2． 创建模型来连接数据资源。

3． 创建控制器来鉴定以便分离到不同的目的地。

4． 引入安全模型。

现实中的任务列表要比这长得多，这个你也可以理会。由于团队是自我管理的，所以HTML/CSS的专家会去处理视图，数据库专家回去创建模型，安全专家负责引入安全模型。如果没有安全专家在团队中，可能有人会想起安全模型曾经在另一个项目中写过  ——这个在这部分的内容中有用吗？

冲刺阶段被设置为两个星期，然后团队开始执行任务，每天召开一个不多于十分钟的站立会议。在每次会议中，Scurm管理者问每个与会者三个简单的问题：

1. 从我上一次见到你开始都做了什么？

2. 到下一次我看到你，你准备做什么？

3. 你遇到了什么困难和障碍。

第一个问题专注于完成情况，第二个专注于去做的，第三个专注于风险和担心。站立会议使整个团队能够在尽可能透明的情况下了解项目的进度。很快，每个人都知道什么被完成了，什么还需要完善，什么还正在做。

局外人（除了开发者、Scrum管理者、商品主）也是允许加入这种会议中的，当然他们不允许干涉项目的方向。“干涉”是什么意思？在很多软件开发项目中，你会发现许多商业经理或者完全是外行的人规定需求。这些需求不是从顾客得来的，它们只是武断的存在于高级主管或者外界出资人的大脑中。通常，这种自以为是的需求会打乱日程并且使事情变得更糟。

举个例子，像“必须在第一季（Q1）完成”这种需求，一般是没有多少实际意义的。在提出他的人看来，这个很重要，对于其他人却不尽然。这又意味着什么呢？在一些人的战略规划中，这样或那样的项目必须在第一季完成，并且投资人的分红以此为指标。顾客才不关心项目什么时候完成，他们只在意在项目完成时能够实现他们期望的功能。（这并不意味着，你可以忽略掌管大权的投资人对日程和金钱的考虑。毕竟，他们也希望在将来再聘用你或者联系你从事其他的商业活动。严肃、庄重的对待他们。一定不要让他们挂念你为完成项目所作的一切。）

你将从Scrum中获取一个什么理念呢？备忘录的思想和冲刺的性质是关键。你将会发现在一些小项目中，一个冲刺极端可能会持续一至两天。你同时会发现，你根本不需要例会，尤其是在你忙于工作时。

 

 

 

XP

XP的主旨是将日常实践做到位，使其符合人性化，并且能提高生产效率。这就意味着，相比传统的收集需求的方法，XP给予面对面交流和反馈以更高的分量。

此外，XP的支持者将价值归结为在今天做简洁的事情，而不是担心将来可能会很复杂的问题。比如，当你今天只有五个顾客时，为什么要为将来增至5000个顾客的情形而担心呢？难道就不能扩展为500（或者甚至是50！）个客户，这样就正好有足够的能力使要做的事情运转起来。

另外一个XP运动的贡献涉及程序员之间的互相尊重。贡献是产生于付出并能取得回报的环境中的，事实上，许多结对的程序员正是一起面对问题、处理问题的。最后，就是能让程序员拥有对代码的所有权。我们经常会发现程序员们将代码重构得更加精简，即使并不需要这么做，但是这并不是不常见的。

那么你将从XP中学到什么东西呢？当然是简洁和沟通反馈循环。把其他敏捷开发的好的思路糅合进去也是十分重要的。当和顾客进行一对一的工作时，你将需要经常交流。要确保你能抽出足量的时间来和顾客进行沟通，因为这样会在以你顾客之间建立一种强有力的纽带。

Scrum和XP的改进

Scrum和XP（极限编程），像其他方法一样，是很棒的，但是也有一个明显的缺点，当你阅读这本书时，假设你是一个单独的程序员或者你在一个很小的团队中。如果是这样，你可能会想，这些途径甚至对你来说花费太大了，在某些情况下，你可能是正确的。但是，任何敏捷开发的一个长处就是它可以自适应你的需要。

本章的剩余部分旨在帮助你通过收集需求、做好工作计划、开启实际工作来了解敏捷开发的流程。基础性的修正已经由“老手（long gun）”程序员们提炼，并且已经开到了典型WEB开发项目的成功案例。

本章剩余部分的实例假设你在一个拥有独立企业家的公司中工作。如果你继续浏览本章，你将要考虑怎样从现有的信息中提炼出有用的东西来满足你的特殊需求。不管怎样，方法的基本途径是能够适合各种情形下的很多不同大小的团队的。

因为本书的目标是构建一系列的WEB工具（购物车、新闻列表工具等），但现在还没有时间来开始这些操作。相应的，本书的剩余部分将集中在收集项目的需求上来。

 

原文

 

 

Notable Agile Methodologies

 Because so many Agile methodologies are out there, and because each of them has different parts that

take a bit of time to absorb, this chapter briefly touches on just two of them: Scrum and XP. Once

you take the brief tour of these methodologies, you can incorporate the ideas you want from each

to make things work.

 

 Some people feel a little anxious about mixing methodologies. However, that is actually at the heart of

being  agile . Where  Agile  with a capital  “A” focuses on the purity of the model,  agile  with a small  “a”

focuses on freeing you up to do whatever will help you quickly and easily achieve your goals. Being

 “agile” is about being adaptive and fast on your feet.

 

 In the real world when you are working with clients, any time you have to decide between getting things

done on schedule and strictly adhering to theoretical rules, always err on the side of getting things done.

It may get under your skin a bit, but it’s really the only way to keep the customer happy.

 

 Scrum

Scrum  is an Agile project management methodology that offers small teams a great deal of flexibility

(even by Agile standards). Here are the typical attributes of a Scrum undertaking:

 

❑ You need a  product backlog  —  a prioritized list of work items that need completion.

 The self-organizing team uses the product backlog to create  sprint backlogs .

 Each  sprint  is a short period of duration (usually 1 to 4 weeks) in which highly focused activity

takes place.

❑ Each sprint begins with a  sprint planning session , in which backlog items for the sprint are

defined.

❑ Each sprint ends with a  retrospective , in which a postmortem is performed.

 

❑ Each team has a ScrumMaster, who acts as coach, facilitator, and buffer against the outside world. The

ScrumMaster is not the leader of the team! Many outsiders view the ScrumMaster as the chief project

manager, but it’s not so.

 

 Scrum recognizes that customers are wont to change their minds about what they want. Sometimes the

changes in direction are subjective and capricious, and other times they come about because of market

pressures. Regardless of the reason, change happens, and normal predictive methodologies have zero

chance of predicting these changes (ironically). Instead, Scrum accepts that change is inevitable,

unpredictable, and indefinable, and focuses instead on maximizing the team’s ability to adapt to change

and still deliver a great product.

 

 The team works closely with stakeholders (such as business owners, marketing managers, the CEO,

CFO, etc.) to develop a backlog of requirements that need to be addressed. Normally, this backlog of

requirements is maintained by a certain stakeholder called the  “product owner.” In most cases, the

product owner is the CEO, but it can also be a marketing manager or project manager.

 

 

 The  backlog  is essentially a list of prioritized requirements that emanate from the end-customer. At the

start of each sprint, the team takes the top remaining items from the product backlog and turns them into

tasks on the sprint backlog. It’s important for the team to only take on as many tasks as can be completed

in any given iteration.

 

 The goal of any iteration is to create potentially shippable software —  in other words, by the time you’re

at the end of the time box (1 week, 2 weeks, whatever), what you have could be considered ready to

ship. It is functionally complete, reasonably bug-free, and reasonably documented.

 

 For example, a product backlog might have several prioritized items on it, like so:

 

❑ The customer wants to be able to securely check page views and other stats about their web site.

❑ The customer wants hyperlinks within the report.

❑ The customer wants real-time access to data, without lag.

❑ The customer wants info graphics associated with the data, not just tabular data. 

 

 

 The team might look at this product backlog and decide to convert the first two bullet items into a series

of tasks:

 1.   Create views to display the report.

 2.   Create models to connect to data sources.

 3.   Create a controller to identify and separate different destinations.

 4.   Implement a security model.

 

 The real task list would probably be longer than that, but you get the idea. Because the team is self-

 organizing, the HTML/CSS expert would tackle the views, the database expert would construct the

models, and the security expert would implement the security model. If no security expert is on

the team, perhaps someone remembers that a security module was written for another project —  might

it not be useful in this context?

 

 The sprint is set at 2 weeks, and the team takes on the tasks, meeting every day for a standup meeting

that lasts no more than 10 minutes. At each meeting, the ScrumMaster asks three basic questions of each

participant:

 

 1.   What have you done since the last time we saw you?

 2.   What are you going to do until the next time we see you?

 3.   What obstacles or barriers are in your way?

 

 The first question focuses on  accomplishments , the second on  to do’ s , and the third on  risks or

concerns . The standup meeting allows the entire team to check in and understand how the project is

going with a great deal of transparency. Very quickly, everyone gets a feeling for what’s been

accomplished, what is still left to do, and what’s standing in the way.

 

 

 Outsiders (other than developers, ScrumMaster, and product owner) are allowed to join the meetings, of

course, but they aren’t allowed to interfere directly in the project. What does  “interfere” mean? Well, in

many software development projects, you see many business managers or complete outsiders dictating

requirements. These requirements don’t come from the customers, they just arbitrarily live in the minds

of senior management or outside stakeholders. Often, these arbitrary requirements impede schedules

and complicate matters.

 

 For example, there is rarely any real value to a requirement like  “It must ship in Q1.” In the mind of the

person who brought it up, it has importance, but not to anyone else. What does that mean? Well, on

somebody’s strategic plan, such-and-such a product must ship in Q1, and the stakeholder ’s bonus

depends on it. The customer doesn’t care when the product comes out, just that it works the way they

need it to when it does come out. (This is not to say that you should totally disregard a powerful

stakeholder ’s concerns about schedules and money. After all, they will hopefully be rehiring you or

referring you to another business in the future. Treat them seriously and with respect. Just don’t let their

concerns interfere with what you need to do to accomplish the project.)

 

 What concepts are you going to take from Scrum? The idea of a backlog is key, as is the nature of sprints.

You’ll find that on many small projects, a sprint can last 1 or 2 days. You’ll also find that you don’t need

to have a daily standup meeting, especially if it’s just you working on things.

 

 XP

 The main thrust behind XP is to put in place daily practices that reconcile humanity and productivity.

What this means in practice is that there is more weight given to face-to-face communication and

feedback than to formal requirements’ gathering.

 

 Furthermore, XP proponents expound on the value of doing something simple and clean today rather

than worrying about future problems that might entail complexity. For example, why worry about

scaling to 50,000 customers when you only have 5 customers today? Wouldn’t scaling out to 500

customers (or even 50!) be good enough to get something working now?

 

 Another great thing from the XP movement involves the collegial respect between programmers.

Contributions are made in a give-and-take environment, and in fact, many programmers pair up to

tackle problems and work through issues. Finally, there is the matter of allowing programmers to take

ownership of their code. It is not unusual to see programmers refactor code to simplify even when it isn’t

needed.

 

 What are you going to take from XP? Definitely the simplicity and communication/feedback loops. It’s

important to incorporate good listening skills to any Agile approach. When working with a client one-

 on-one, you will need to interface often. Make sure that you allow a significant amount of time for the

face-to-face contact, as it can create a powerful bond between you and the client.

 

 

 Modifying Scrum and  XP

 Scrum and XP (extreme programming), like all methodologies, are wonderful things, but one immediate

drawback for you right now, as you read this book, is that you’re probably a lone programmer or work

with a very small team. If so, you may be thinking that these approaches provide too much overhead 

 

even for you, and in some ways, you might be right. However, one of the great strengths of any Agile

methodology is that it can be adapted to your needs.

 

 The rest of this chapter is devoted to walking you through an Agile methodology for gathering

requirements, planning your work, and getting started on the actual work. This basic modification has

been refined by various  “lone gun” programmers and has seen lots of success with typical web

development projects. The example provided throughout the rest of this chapter assumes that you are

working as a solo entrepreneur with a single small business owner. As you continue through this

chapter, you should consider how you might tailor the information presented here to fit your specific

needs. However, the basic approach to the methodology is applicable to many different-sized teams in

various situations.

 

 Because the goal of this book is to build a series of web tools (shopping cart, newsletter tool, others),

there’s no time like the present to start the process. Accordingly, the rest of this chapter focuses on

gathering the requirements needed for the projects in the book.