著名的敏捷開發
由於有許多敏捷開發方法都過時了，並且他們之中的不同之處需要花點時間來掌握，本章主要簡明的介紹他們其中的兩種：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.