這是ScrumAlliance的推薦文章，Mike Cohn轉載Uncle Bob的文章，下面的中文是youdao.com的自動翻譯，非人工。
=================
Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.
Scrum是一個起點。事實上,這是一個很好的起點。但是,作爲一個框架,而不是一個成熟的方法論,Scrum是故意不完整。一些措施例如最好的技術實踐use-are留給個人團隊來確定。這允許一個團隊之間創建最適合他們的項目和環境和各式各樣的技術實踐。
While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.
而選擇的實踐應該屬於團隊或組織,而不是一羣方法學家一些實踐變得如此咄咄逼人地明顯的好處,他們考慮任何Scrum團隊。但是,太多的Scrum團隊變得自滿實現Scrum的一些早期的生產率增長。和他們停止尋求改善的方法。許多人沒有嘗試爲長期成功所必需的技術實踐。在接下來的文章中,羅伯特·馬丁(也許更好的被稱爲“鮑勃叔叔”)告訴我們爲什麼那麼多Scrum團隊無法維持他們早期的成功的承諾。
Bob’s article is the first in a series of articles we will publish in this newsletter. Because Scrum is a starting point with deliberate gaps to be filled by knowledgeable teams, we are looking to those outside the core Scrum community to provide advice to those of us within it. What do leading agile thinkers from outside the Scrum world think our teams need to know or do? I’ve asked a few to share their thoughts with us. And who better to start with than Bob Martin?
鮑勃的文章是第一個在一系列的文章,我們將發佈在這個通訊。因爲Scrum是一個起點與深思熟慮的差距由知識淵博的團隊,我們希望核心Scrum以外的社區提供建議的人。什麼主要敏捷思想家Scrum以外世界認爲我們的團隊需要知道或做什麼?我問過一些與我們分享他們的想法。誰比Bob Martin開始?
The Land that Scrum Forgot
Scrum忘記的土地
By Bob Martin
由Bob Martin
What goes wrong with so many Scrum projects? Why does the velocity start out high, but then precipitously decline? Why do some Scrum teams eventually give up on Scrum? What’s going wrong?
所以很多Scrum項目哪裏出問題了?爲什麼開始速度高,但隨後急劇下降?爲什麼有些Scrum團隊最終放棄Scrum ?什麼錯了嗎?
As someone who has been called in to rescue Scrum teams from this kind of demise, I can tell you that the problem is not that the teams are losing motivation. Often the problem is that the software that the teams are producing is getting harder and harder to work with.
作爲一個被稱爲拯救Scrum團隊從這種消亡,我可以告訴你,問題不是團隊正在失去動力。通常的問題是軟件的團隊生產正變得越來越困難。
Scrum makes you go fast! That’s a good thing. Often the first sprint concludes with some working features. Managers and customers are happy. The team has worked a miracle and is happy too. Everybody is happy, and Scrum is seen as a great success.
Scrum讓你去快!這是一件好事。通常第一個sprint結尾有些工作特性。經理和客戶是快樂的。團隊工作一個奇蹟,也很開心。每個人都快樂,Scrum是視爲一個巨大的成功。
The same thing happens the next sprint, and the sprint after that. Velocity is high. The system is coming together. Feature after feature is working. Expectations have been set. Plans are made. Enthusiasm for Scrum soars. Hyper-productivity has been achieved!
同樣的事情也發生接下來的衝刺,衝刺。速度高。系統是一起來的。功能特性是工作後。預期。計劃。Scrum飆升的熱情。Hyper-productivity取得!
One of the reasons for this hyper-productivity is the smallness of the code base. Small code bases are easy to manage. Changes are easy to make; and new features are easy to add.
這種hyper-productivity的原因之一是渺小的代碼庫。小的代碼很容易管理。變化很容易做,很容易添加新特性。
But the code is growing fast; and when a code base gets large, it can be very difficult to maintain. Programmers can be significantly slowed down by bad code. Teams can be reduced to near immobility by the sheer weight of a badly written system If care is not taken soon, the hyper-productive scrum team will succumb to the disease that kills so many software projects. They will have made a mess.
但是代碼正在快速增長;當代碼庫越來越大,它可以很難維護。程序員可以顯著減慢了糟糕的代碼。團隊可以降低至接近靜止的一個寫得很糟糕的系統如果不小心很快,超高效的scrum團隊會屈服於疾病,殺死了很多軟件項目。他們會搞得一團糟。
“Wait,” I hear you say. “I thought Scrum was supposed to empower the team? I thought the team would take all necessary measures to ensure quality. I thought the an empowered Scrum team would not make a mess.”
“等等,”我聽你說。“我以爲Scrum團隊應該授權?我認爲團隊將採取一切必要措施,以確保質量。我認爲一個授權Scrum團隊不會製造混亂。”
That’s certainly the goal. The problem is that empowered teams are still human, they do what they are incented to do. Are they being rewarded for quality? Or are they being rewarded for productivity? How much recognition is the team getting for good code quality? How much are they getting for delivering working features?
這當然是目標。問題是,授權團隊仍然是人類,他們被鼓勵做什麼。他們被獎勵的質量嗎?還是被獎勵的生產力?多少識別代碼質量的團隊越來越好嗎?他們得到交付工作特性多少錢?
There’s your answer. The reason scrum teams make messes is because they have been empowered and incented to make one. And a Scrum team can make a mess really, really fast! A Scrum team is hyper-productive at making messes. Before you know it the mess will be “so big and so deep and so tall, you can not clean it up. There is no way at all.”
這是你們的答案。scrum團隊使混亂的原因是,因爲他們已經授權和被鼓勵。和Scrum團隊可以製造混亂真的,真的快!Scrum團隊是超高效的在製造混亂。在你知道之前的混亂將會“那麼大,那麼深,那麼高,你不能把它收拾乾淨。沒有辦法。”
And when that happens, productivity declines. Morale goes down. Customers and managers get angry. Life is bad.
當這種情況發生時,生產力下降。士氣會下降。客戶和經理生氣。生活是不好的。
So how can you incent a Scrum team to not make a mess? Can you simply tell them not to make a mess? We’ve tried that. It doesn’t work. The incentives for going fast are based on tangible deliverables. But it’s hard to reward a team for good code If we don’t have some way to objectively measure it. Without an unambiguous way to measure the mess; the mess will be made.
所以你怎麼能激勵一個Scrum團隊不拉屎嗎?你能簡單地告訴他們不要製造混亂?我們已經試過了。它不走了。激勵要快是基於有形的可交付成果。但是很難獎勵團隊好的代碼如果我們沒有辦法客觀測量它。沒有一個明確的方法來衡量混亂,混亂。
We need to go fast, and we need to stay clean so we can keep going fast. How can we incent the team to achieve both goals? Simple. We measure both and reward them equally. If the team goes fast but makes a mess, then there is no reward. If the team stays clean but goes slow, then again, there is no reward. If the team goes fast and stays clean, then there is a reward!
我們需要快,我們需要保持乾淨,這樣我們就可以繼續快速。我們怎樣才能激勵團隊實現這兩個目標?簡單。我們測量和獎勵他們同樣。如果團隊快速但一團糟,那麼就沒有回報。如果團隊保持清潔,但緩慢的情況下,再一次,沒有獎勵。如果團隊快速和保持清潔,然後有獎勵!
We can measure messes by implementing engineering disciplines and practices like Test Driven Development (TDD), Continuous Integration, Pair Programming, Collective Ownership, and Refactoring; i.e. the engineering practices of eXtreme Programming (XP).
我們可以測量麻煩通過實施工程學科和實踐測試驅動開發(TDD)、持續集成、結對編程、集體所有權,和重構,即極限編程(XP)的工程實踐。
It is usually best to start with TDD simply because a code base without tests is a mess no matter how clean it might otherwise be. This is a bold claim, but it is based on a solid rationale from a much older and more respected discipline: accounting. It is just as easy for an accountant to make a mistake on a spreadsheet as it is for a programmer to make a mistake in a program. So how do accountants prevent errors? They enter everything twice.
通常是最好的開始與TDD僅僅因爲沒有測試的代碼庫是一團糟不論多麼乾淨,否則可能會。這是一個大膽的聲明,但是它是基於一個堅實的理由更年長、更受人尊敬的學科:會計。它只是作爲一個會計容易犯錯誤在一個電子表格作爲程序員犯錯誤是在程序。那麼,會計師如何避免錯誤?他們進入一切兩次。
Accountants practice Dual Entry Bookkeeping as part of the GAAP1 (Generally Accepted Accounting Principles). Accountants who don’t hold to the GAAP tend to wind up in another profession, or behind bars. Dual Entry Bookkeeping is the simple practice of entering every transaction twice; once on the debit side, and once on the credit side. These two entries follow separate mathematical pathways until a final subtraction on the balance sheet yields a zero. A set of books that is not supported with dual entries would be considered a mess by the accounting community, no matter how accurate and clean those books were.
會計實踐雙重記賬法GAAP1的一部分(一般公認會計原則)。會計人員不堅持公認會計准則往往在另一個職業,或身陷囹圄。雙重記賬法是進入每筆交易的簡單練習兩次,一次在借方,一旦在信貸方面。這兩個條目按照單獨的數學途徑,直到最後一個減法在資產負債表上產生一個零。一套書籍,不支持雙條目會被視爲會計社會一片混亂,無論多麼準確、乾淨的這些書。
TDD is Dual Entry Bookkeeping for software, and it ought to be part of the GAPP (Generally Accepted Programming Practices). The symbols manipulated by the accountants are no less important to the company than the symbols manipulated by the programmers. So how can programmers do less than accountants to safeguard those symbols?
TDD是雙重記賬法爲軟件,它應該是新聞出版總署的一部分(公認編程實踐)。符號操縱的會計是不重要的公司比符號操縱的程序員。所以程序員如何做不到會計維護這些符號?
Programmers who practice TDD create a vast number of automated tests that they keep together and run as a regression suite. This is something you can measure! Measure the coverage. Measure the number of tests. Measure the number of new tests per sprint. Measure the amount of defects reported after each sprint, and use that to determine the adequacy of the test coverage.
程序員TDD實踐創建大量的自動化測試,他們團結在一起,作爲迴歸套件運行。這是一些你可以測量!測量範圍。測量數量的測試。測量每個sprint的新測試數量。每個sprint測量缺陷的數量後報道,並以此來確定適當的測試覆蓋率。
The goal is to increase your trust in that suite of tests until you can deploy the product based solely on whether that suite passes. So measure the number of “other” tests you feel you need perform, and make shrinking that number a priority; especially if they are manual tests!
他們的目標是增加你的信任測試套件,直到你可以部署套件的產品完全基於是否通過。所以測量數量的“其他”測試你覺得你需要執行,優先考慮減少這一數字,特別是如果他們是手工測試!
A suite of tests that you trust so much gives you an immense amount of power. With it, you can refactor the code without fear. You can make changes to the code without worrying about breaking it. If someone sees something they think is unclear or messy, they can clean it on the spot without worrying about unintended consequences.
一個測試套件,你信任給你大量的權力。使用它,您可以重構代碼而不用擔心。您可以更改代碼而不用擔心打破它。如果有人看到一些他們認爲是不清楚或混亂,他們當場就可以清洗而不用擔心意想不到的後果。
Undocumented systems, or systems where the documentation has gotten out-of-sync with the production code, are messy. The unit tests produced by TDD are documents that describe the low level design of the system. Any programmer needing to know how some part of the system works can reliably read the unit tests for an unambiguous and accurate description. These documents can never get out of sync so long as they are passing.
未登記系統,或系統的文檔已經失去同步生產代碼,是混亂的。單元測試由TDD的文檔描述的低水平設計系統。任何程序員需要知道一些系統的一部分作品可以可靠地讀取單元測試一個明確和準確的描述。這些文件不能離開只要他們通過同步。
Measure the size of your tests. Test methods should be on the order of five to twenty lines of code. The total amount of test code should be roughly the same as the amount of production code.
測量你的尺寸測試。測試方法應該在5到20行代碼的順序。測試代碼的總量應該大致相同的生產代碼的數量。
Measure test speed. The tests should run quickly; in minutes, not hours. Reward fast test times.
測量測試速度。測試應該運行得很快,在幾分鐘內,而不是時間。獎勵快速測試時間。
Measure test breakage. Tests should be designed so that changes to the production code have a small impact on the tests. If a large fraction of the tests break when the production code is changed, the test design needs improving.
測量測試破損。測試應該是這樣設計生產代碼有一個小的變化對測試的影響。如果測試失敗的大部分生產代碼改變時,測試設計需要改進。
Measure Cyclomatic Complexity. Functions that are too complex (e.g. cc > 6 or so) should be refactored. Use a tool like Crap4J2 to pinpoint the methods and functions that are the worst offenders and that have the least test coverage.
度量圈複雜度。太複雜的函數(例如cc > 6左右)應該重構。使用工具像Crap4J2確定的方法和函數最嚴重的罪犯和最少的測試覆蓋率。
Measure function and class size. Average function size should be less than 10 lines. Functions longer than 20 lines should be shrunk. Classes longer than about 500 lines should be split into two or more classes. Measure your Brathwaite Correlation3, You’d like it to be greater than 2.
度量函數和類的大小。平均函數大小應該小於10行。函數超過20行應該縮小。類超過約500行應該分成兩個或更多的類。測量你Brathwaite Correlation3,你想它是大於2。
Measure dependency metrics. Ensure there are no dependency cycles. Ensure that dependencies flow in the direction of abstraction according to the Dependency Inversion Principle4, and the Stable Abstractions Principle5.
測量指標的依賴。確保沒有周期的依賴。確保依賴流抽象的方向根據依賴性倒置Principle4,抽象Principle5和穩定。
Use a static analysis tool like FindBugs6 or Checkstyl37 to locate obvious programming flaws and weaknesses. These tools can also find and measure the amount of duplicate code.
使用一個靜態分析工具如FindBugs6或Checkstyl37定位明顯編程缺陷和弱點。這些工具還可以找到和測量重複代碼的數量。
Implement Continuous Integration. Set up a build server like Hudson8, Team City9, or Bamboo10. Have that server build the system every time a developer commits some code. Run all the tests on that build and address any failures immediately.
實施持續集成。建立一個像Hudson8構建服務器,團隊City9或Bamboo10。每次都有服務器構建系統開發人員提交一些代碼。在構建和運行所有的測試地址任何立即失敗。
Measure the number of commits per day. This number should be larger than the number of developers on the team. Encourage frequent commits.
每天測量的數量提交。這個數字應該比團隊中的開發人員的數量。鼓勵頻繁提交。
Measure the number of days per month that the continuous build fails. Reward months with no failures. Measure the amount of time failures remain unaddressed.
測量每個月的天數,持續構建失敗。獎勵幾個月沒有失敗。測量的時間失敗仍然沒有得到解決。
Story tests are high level documents written by business analysts and testers. They describe the behavior of the system from the customer’s point of view. These tests, written in a tool like FitNesse11 or Cucumber12, are requirements that execute. When these tests pass the team knows that they are done with the stories that they describe.
故事測試高水平由業務分析人員和測試人員編寫的文檔。他們描述系統的行爲從客戶的觀點。這些測試,寫在一個工具FitNesse11或Cucumber12等要求執行。當這些測試通過團隊知道他們完成他們描述的故事。
Measure done-ness by running story tests in your Continuous Integration system and keeping track of the story tests that pass and fail. Use that as the basis for velocity and the progress of the team. Enforce the rule that stories are not done until their corresponding story tests are passing. And never let passing story tests break.
故事通過運行測試測量done-ness在持續集成系統和跟蹤的故事通過和失敗的測試。用這個作爲速度的基礎和團隊的進步。執行規則,故事才做相應的測試是通過故事。測試失敗,從不讓過往的故事。
Practice Pair Programming. Measure the time spent pairing vs. the time spent programming alone. Teams that pair stay cleaner. They make fewer messes. They are able to cover for each other because they know each other’s domains. They communicate with each other about designs and implementations. They learn from each other.
結對編程實踐。測量時間配對與所花費的時間獨自編程。團隊對保持清潔。他們更少的混亂。他們可以互相掩護,因爲他們知道對方的領域。他們對設計和實現相互通信。他們互相學習。
And after all this measuring, how do you reward? You post big visible charts of the metrics in the lunchroom, or in the lobby, or in the project room. You show the charts to customers and executives, and boast about the team’s focus on quality and productivity. You have team parties to celebrate milestones. You give little trophies or awards. For example, one manager I know gave shirts to everyone on the team when they passed 1000 unit tests. The shirts had the name of the project and the words “1,000 Unit Tests” embroidered on them.
畢竟這個測量,你怎麼獎勵?你文章大可見圖指標的餐廳,或者在大廳,或者在項目的房間。你向客戶顯示圖表和高管,吹噓團隊的關注質量和生產率。你有團隊聚會慶祝的里程碑。你給小獎盃或獎項。例如,我認識的一個經理把襯衫給團隊中的每個人都當他們超過1000單元測試。的襯衫有名稱繡項目和“1000單元測試”字樣。
How do you keep a Scrum Team from losing productivity? How do you make sure that hyper-productivity doesn’t veer headlong into a quagmire? You make sure that the team is not hyper-productively making a mess! You make sure they are practicing the disciplines that produce data that can be measured. You use that data to measure the quality of the code they are producing; and you provide incentives for keeping that code clean.
你怎麼阻止一個Scrum團隊失去生產力呢?你如何確保hyper-productivity不轉向在泥潭?你確保團隊不是hyper-productively搞得一團糟!你確保他們正在實踐的學科產生可以測量的數據。您使用這些數據來測定它們產生的代碼的質量,和你提供激勵保持代碼的清晰。