這篇文章是內部的一次郵件討論，晚上寫方案的時候，突然想換換腦子，於是翻出來重新整理了一下，放在園子裡，希望這個磚頭能引來更多的良玉。
最近在專案執行過程中，部分專案經理對於績效考核制度產生了一些情緒，認為有苦勞就不應該考核績效，或是認為專案經理不應對專案收款負責。我不知道有多少專案型的公司中專案經理對成本有著如何的敏銳性，只是覺得一個好的專案經理首先應具備一個良好、開放、感恩的心態。好了，牢騷話不說了，放正文吧。
正文
原文地址如下：http://coolshell.cn/articles/5044.html
準確的說，Scrum只是敏捷的一個分支。敏捷是泊來品，如果全部照單接收，當然有象這篇文章中說的這樣那樣的水土不服。但我相信人的動力和主動性是無窮的，傳統的軟體工程理論從根本上說是違反了人性的，過多關注了過程而忽略了目標。將一個專案目標事無鉅細的拆分成無數的過程和細節，不可否認這樣在流水線的生產環境上可以得到發揮，但在以創新、主動、學習、團結的軟體開發過程中，過多的泯滅了人性中的光輝。
就這篇文章中的內容，根據我個人的一些片面的理解去闡述，僅供大家參考。
Reason 1: Scrum 的基石是相信人。但現實人無法相信。
原文:創造一個安全的環境，這樣每個人都能相互學習，相互直言。但是，這是不行的，這世上有很多人並不關心這些，而且政治和競爭到處都是，辦公室裡無小事，你和別人交心，你相信他們，最終受傷的你自己。你真的以為那裡有空間讓你可以去犯錯，去冒險嗎？別天真了！你啊，too young, too simple, sometimes naive!
Answer 1: Scrum的基石準確地說不是相信人，而是相信人普遍有成就自我的動力，這個動力符合馬斯洛的人的需求模型的理論。我相信投身軟體行業的人，無論抱著成就財富或是成就名譽，甚至成就延續人生價值的目標，都普遍適用。如果你相信一個道理能夠直來直去的普遍適用於地球上的任何環境，那我只能表示遺憾，不懂靈活運用並不是理論的問題，只能說你的經歷太少，書讀多了並不代表你能真正地運用這些理論。
Reason 2: Scrum 認為只要給員工足夠多的自由員工就能做得最好。
原文：。這該死是理論是基於什麼玩意？不可能，人的天性是懶惰的，他們才不會把事做好的，他們只會做相應報酬的工作量，還可能基本還達不到其相應的報酬，大多數人都在混日子啊。尤其是和經理比起來，誰不想能儘快地成為經理或Team leader啊，因為那樣他們就可以即不幹活，又掙得多。另外，你給他們自由，你就會發現，他們會只會做他們感興趣的事，要麼聊QQ，要麼打遊戲，看閒書，反正不幹正事。直到你催了，他們才動一動。
Answer 2: Scrum從未認為給員工足夠多的自由就能做得最好，相反，Scrum要求團隊不斷在短週期內（一週）求證自己的成果，靠一個個劃分成短期的目標來不斷縮減總體目標的距離。只是這個過程中，Scrum要求團隊的領導者有足夠的教練技術，發揮每個員工的主觀能動性，而不是一味的要求正規的過程，完善的管理。大家有興趣的話，可以搜尋一下“NLP教練技術”，這是Scrum中教練職位的理論來源。
Reason 3: 因為前面的原因，所以，我們仍然要把一個PM放在Scrum團隊的上面做管理，這樣才會有產出。
原文：於是，PM給團隊分配任何，管得細枝末節，事無鉅細，天天讓你做進度彙報，等等
Answer 3 :這是中國Scrum變相的更改，我不認為這個更改有什麼不好，難道Scrum中就不要求溝通是最重要的工作了嗎。在中國普遍缺乏專案組合格教練的情況下，加一個PM來進行溝通協調各方的利益是再正常不過了。至於PM是不是要管到細節，那是根據企業管理制度和個人工作習慣，與Scrum無關。
Reason 4: Scrum 只不過是一個流程。
原文：這世上有太多的流程，尤其是那那些操CMMi的公司。幾乎所有玩CMMi流程的公司，你都能看到的是員工都是那一副副苦逼的臉。所以，Scrum的流程同樣會這樣。因為這些都不是開發團隊自發出來的，而是上面管你喜歡不喜歡按給你的。 Scrum 根本不可能增進你的軟體質量和技術，只能是優秀的人才才可能！使用Scrum的公司都是些吝嗇鬼，他們不願花大錢招優秀的人，他們妄圖使用Scrum這種東西讓現有的這些廉價勞動力發揮更大的生產效率，Scrum成了push程式設計師最有用的工具。
Answer 4 : 這個論點有點奇怪，既然說Scrum不好，那又為什麼說其它公司沒有按正規的Scrum來做。Scrum從未提出要優秀的員工來組成，只要求同一配對小組中，兩個人的水平要相近。
Reason 5: Scrum delivers ‘business value’。
原文：不是這樣的，實際上，Scrum不可能。這有很多原因。真正瞭解業務的那幫人根本不可能加入專案團隊，那些人誰TMD願意和苦逼的技術人員加班啊。 那些人喜歡和我們的使用者吃吃喝喝，花天酒地的，根本不會和你們那些奇怪的東西（如：backlog）或是那堆ugly的內向古怪的技術人員打交道，更別說什麼技術了。所以，你的團隊就像一個客服團隊或救火隊一樣疲於奔命。
Answer 5 : 如果沒有客戶參與到專案組，確實傳統的Scrum就無所適從。但任何一個理論都只適用於特定的一個和幾個環境中。如何靈活運用，這是教練的事情，客戶瞭解業務，教練了解客戶和組員，這樣就足夠了。
Reason 6: 一個敏捷的團隊應該是持續進步的。別天真了，人的天性是不喜歡改變的
原文：這就是為什麼Scrum總是在問什麼幹得好，什麼需要改進，並定義行動方案。你真的以為員工想進步嗎？讓他們不得不去想想自己和團隊怎麼進步，然後他們還不得不去執行行動方案。別天真了，人的天性是不喜歡改變的，人的天性是習慣於一些按部就般的事的，也許那樣做令人討厭，但是人家還是能幹點東西出來。如果你逼著人家改變，你就是在壓迫人家，人家自然會反抗。
Answer 6 : 我只能說沒人喜歡改變可能是真的，但沒人喜歡進步和沒人喜歡改變是一個命題嗎？個人進步是自我驅動的，而外界改變一個人是普遍很難的。在一個普遍以知識為謀生手段的行業環境中，拒絕成長的人根本無法生存。寫這篇文章的人恐怕沒有認真的思考一下基本的邏輯。
Reason 7: Product Owner 專注於 ‘what’ 和 ‘why’ 的問題，開發團隊決定 ‘how’。
原文：很不錯的分工，於是可以造就一個即高速有重質量的團隊。然而，這根本不行。你的Product Owner馬上就想要這個功能，他才不管你的軟體開發的技術難題，人家只要快，要你meet deadline，要你給我們重要的客戶做出承諾。另外，你千萬不要以為你們可以哄走這個初級的product owner，因為他的後臺是直接彙報到高層管理。你作為一個程式設計師可能只是其個小部門的一個小嘍囉，或者只是外包公司，你覺得可能嗎？你覺得建立信任可能嗎？
Answer 7: 還是傳統的工程師思維，建立信任的基礎是提供價值，技術如果沒有收益就是廢鐵。而帶來收益的技術哪怕再簡單也會成為無價之寶，如果能深切的理解客戶業務，實現的方式是多種多樣的，只要能提供價值，客戶怎麼會管你具體用何種技術。更何況Scrum中評估工期是自下而上的綜合評估，並非由Master或Product Owner說了算的。
Reason 8: 軟體質量和生產率成正比。
軟體質量和生產率成正比。也就是說，質量越高，生產率越高。如果質量不高，你開發效率就會低下，但是誰管呢？我們朝九晚五的上班，質量好了也是做8小時，質量差了也是做8小時，無所為嘛。另外，我們的 project manager (或者是Scrum master!) 總是會批評我們沒有按計劃完成。所以，這根本不可能。
Answer 8 : 基本常識錯誤，懶得回答了。
Reason 9: “是的，如果我們只做需要的功能，那麼我們就會最低的成本，對嗎？”
為什麼這世上總是會有這些幼稚的人？這種事怎麼可能啊。很多很多的銀行或保險公司的專案在你還沒有啟動專案前就談好了一個價格（可能還會有回扣），為了打單子，銷售什麼都幹得出來，讓你去做專案是因為你是廉價勞動力，而且，他們會不斷地加需求，因為軟體合同談好的價格時候，連需求都沒有，你去做了才有，還是模糊和不確定或根本就是錯的，然後需求是越來越多，越改越多。等你精疲力盡的時候，你才意識到，銷售早就把你賣了。
Answer 9 : 在國外是這樣的，在國內確實這是Scrum的硬傷，所以需要變通，在需求上一定要嚴謹，而這裡恰恰是要用到Scrum的越早將結果呈現給客戶越早發現問題的理念。一個好的原型勝過一萬頁需求分析說明書。