關於敏捷的一次內部爭論

這篇文章是內部的一次郵件討論，晚上寫方案的時候，忽然想換換腦子，因而翻出來從新整理了一下，放在園子裏，但願這個磚頭能引來更多的良玉。

最近在項目執行過程當中，部分項目經理對於績效考覈制度產生了一些情緒，認爲有苦勞就不該該考覈績效，或是認爲項目經理不該對項目收款負責。我不知道有多少項目型的公司中項目經理對成本有着如何的敏銳性，只是以爲一個好的項目經理首先應具有一個良好、開放、感恩的心態。好了，牢騷話不說了，放正文吧。

 

正文

原文地址以下：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的越早將結果呈現給客戶越早發現問題的理念。一個好的原型賽過一萬頁需求分析說明書。