讓我吐槽先

1. 風雲突起

現在的工作最開始並不是Scrum模式，計劃經濟模式，計劃到連bug都要老闆分配的狀態。突然有一天公司開始號召快速適應變化。革自己的命，搶別人的路，讓別人無處可走，成為變革的主題。2015號稱是自我革命的一年。說到Agile，自然最先想到的是就是Scrum。於是下面就開始炸鍋了，高喊著口號向Scrum大躍進。從上到下生生將Scrum搞成了群眾運動。各種Scrum分享，內部培訓，外部培訓，每一個有空地的角落都被白板佔據。會議室，角落，位置都是站會的陣地。按理說都已經全員動員了，應該情況scrum越走越順才對。但是1年下來，似乎沒看到團隊真正的敏捷起來，會倒是越開越順，每次會議的內容越來越發散，時間越來越長... ...。

2. 邯鄲學步

大老闆搭臺，小老闆指揮唱戲。剛開始有老闆連Scrum是什麼估計還沒弄明白，看著別人每天站會，也開始有樣學樣，一個4、5個人的團隊，就敢每天上午安排一個小時的Scrum meeting（花點時間google一下Agile/Scrum真的很難！你懂的）. 每天把狀態過一遍，狀態包括但不限於做了什麼，結果是什麼，怎麼做的，怎麼想的，打算怎麼做... ....。尼瑪超過一個小時是常有的事。最奇葩的是有人BBB一個上午，跟你分享他一個問題是怎麼分析，怎麼解決，怎麼驗證，怕不明白還拉著大家每一步的demo。一個上午過去，下午你一驗證他的方法，發現最簡單的case直接fail的時候。當時就感覺一股強大的衝擊波迎面而來，恍惚中有種看到了猴王的感覺，敬仰之情難以言表，唯有跟隨萬千猴子猴孫載歌載舞，在風中搖擺！

3. 自娛自樂

慢慢的，一切開始上了正軌，backlog，planning... 有模有樣。4個禮拜一個sprint，雖然經常delay release 但是好歹規律了。但是做著，做著在sprint中間，PO／SM會突然說sprint週期是3個禮拜了是怎麼回事。提點一下，JIRA翻出來看一下，嗯，搞錯了，原來以前都是4個禮拜。好，過了一個禮拜，又變成3個禮拜了是咋回事！！！

臨近release，今天說release時間是下週二，大家開始計劃把一些未完成低優先順序事情推遲到下一個sprint，並且開始做測試相關工作。過兩天突然變成release時間是下週五。到了下週一，再來release時間是再下週...... 這個時刻估計思路最清晰的也只有PO／SM， 深得Agile的精髓——擁抱變化，雖然是大冬天，抱得太緊也難免太熱燒包啊！！！

4. 我不入地獄，誰愛去誰去

碼農最不喜歡的也許就是改需求。碼農第二不喜歡的事情就是每一個feature都有N種方式實現，但總有人要求你用一種最爛的方法去做。但是，碼農應該是喜歡敏捷文化的，因為Agile號召將每一個story都拆分得足夠小。所以需求改變也會相應的被拆分，分解，將變化無限縮小，所以號稱擁抱變化的Agile神奇的將一個Sprint變得相對靜止了。另外敏捷文化的一個重要根基是信任，基於信任的基礎去除繁雜的規則、流程。讓每個碼農都可以放手將大部分的精力放在開發上。

實際執行中，當一個團隊從計劃驅動的方式轉換到scrum模式時，中層管理對往服務型的管理團隊轉變充滿了畏懼（當然也有可能是其他原因），不願放手權力，又不敢承擔責任。最中導致Scrum跑得不論不類。程式猿夾縫中求生存，日子過得反不如計劃式，戳一下走一步的方式。Scrum的快+傳統的亂，這是何等的煎熬！比如：

1），Sprint過程中，PO不能在Sprint開始的時候確定一個sprint中需要完成的需求，隨便拉幾個backlog。然後在Sprint執行過程中，借擁抱變化之名，隨意增加新的backlog，將正在開發的backlog移出當前sprint，隨意打亂開發計劃。尼瑪，馬上要release還在換feature，這算什麼情況。加feature我能理解，客戶需要，開發好的feature移到下一個sprint，我也接受。尼瑪費了老大勁設計、實現的程式碼也得花時間移出去，等需要這個feature再加進來... ...

2），當前架構不能適應新的需求變化，需要對原有架構進行改變才能適應新的需求時。PO／SM居然第一反應不是怎麼樣才能保證滿足需求的持續迭代，而是需要做這麼大的改變，作為“豬”的你怎麼說服更大的老闆同意花efforts去這個改變。思想，思想要跟上啊，親，需求是客戶說了算啊！覺悟，覺悟要有啊，小弟，升職，加薪都還得靠老闆！

3），PO將計劃經濟的流程帶入scrum，每一個細節都不放過，每一個feature的設計原則，實現都要確保自己能明白，最終才能開始實現。尼瑪一個feature我寫程式碼才只要一個禮拜，讓PO明白居然要花兩個禮拜。文件寫了兩輪，講要好幾遍，講的時候聽明白了，過幾天又不明白了，又得重新來一遍，這算是啥情況！

Agile

Agile與其說是一系列軟體開發的方法論，不如說是一種觀念，一種思想。有很多流程框架用於敏捷文化。Scrum是其中最出名，應用最廣的一種。但是不管是哪一種都僅僅是一種參考，並不是一個絕對的方法。要實現敏捷，最關鍵的依然是團隊，而不是方法。只有方法跟團隊完美結合才能真正將敏捷的效果發揮出來。所以沒有一成不變的Scrum流程，流程應該根據團隊成員配置，團隊文化，在敏捷過程中不斷改進，流程與團隊互相磨合、改進，最後確定一個適合團隊的敏捷迭代方式。 鑑於個人經驗，資歷，我沒法在這裡討論正確的Scrum流程應該是怎麼樣，只是討論什麼是我覺得不對的方法。不斷意識到錯誤，在錯誤中不停修正，震盪中趨向穩定，也是一種不錯的方法。照著教科書照搬Scrum流程，都是對產品和團隊不負責的行為。

1. 職責

1） Project Owner。 PO是團隊與外部的介面，與客戶合作確定產品需求。負責擬定每一個Sprint需要交付的需求，向團隊輸出待辦事項，並確定優先順序。在Sprint中要確保待辦事項及其進度對所有專案成員可見。PO還需要確定開發團隊下一步做什麼，delay什麼來權衡範圍、進度以確保有最好的產品交付。 2）Scrum Master。SM是團隊的教練，幫助團隊遵守流程，協助PO建立維護待辦事項列表。和開發團隊一起發現並實施技術實踐，為團隊清除外部障礙。 3）開發團隊（“豬”）。專案具體實施者，負責對產品的增量實現。開發團隊採用自組織的方式完成工作，對於專案而言，開發團隊應該是全職的，具有完成每個產品增量所需的所有技能。開發團隊成語與產品負責人共同預測在一個Sprint裡面能完成的工作，並決定如何實現。 在傳統的計劃式開發中，命令自頂向下，一級一級傳達，每一層都有相應的責任人。為了明確責任，做任何事情前都需要詳盡的文件，提供足夠充分的理由，證據，一級級申請，批准，然後立項才能開始實施。創新和敏捷就在這個冗長的過程中被扼殺了。 在Scrum中，所有的執行都是基於客戶需求，每一個Sprint持續迭代，互動。開發成員直接作用於backlog，並承諾每個sprint都完成相應待辦事項，目標明確，責任清晰。 但是在實際實施過程，Manager引入Scrum，又對傳統的方式依依不捨，管理層不想放權，不想向服務型管理轉變就會是什麼一種情況呢。PO依然用瀑布式方式管理，在Sprint過程中隨意更改待辦事項，打亂開發計劃，最終導致開發效率低下。按照Scrum的方式對一個Sprint能完成的工作做plan，但是執行過程中，每一個實現方法都需要PO或者團隊外的Manager審閱，批准，導致專案進展緩慢，臨近期限，為了趕進度又不得不作出妥協，delay互動或提交一些低質量程式碼。最終導致Scrum流離於形式，相比於傳統的計劃是模式，又增加了更多的流程，會議。這種混雜模式更加的混亂，低效。

2. 文化

團隊成員應該有足夠的自信，以“我能做到”的心態去迎接，支撐敏捷。敏捷中強調的更多的是實踐，通過實踐去發現問題，解決問題，論證問題。但是傳統的方式中，由於流程的限制，責任的明確劃分。沒有人拍板，所有人都不敢做決定，總是強掉問題，但是少有主動提出解決問題。 敏捷中，團隊成員之間是相互信任的，相信別人能完成工作。所有團隊成員的工作進度是透明的，但是完成方式並不需要每一個人都明瞭。所有團隊成員都相信別人會在規定時間內用最好的方式完成並交付任務。團隊成員也被賦予足夠的信任和自由，可以自主的設計、解決問題，而不用得到實現許可。 團隊成員被賦予了足夠的決定權可以獨立完成自己的工作，又與團隊其他成員相互緊密協助，共同解決完成相關的工作，確保不會因為自己的工作阻塞別人的工作。 實際執行中，如果團隊成員之間沒有足夠信任，往往會造成過多的干涉別人工作，剝奪別人開發工作中的自主權，導致別人進展緩慢，同時自己也因為精力分散，而效率低下。比如PO不信任團隊，覺得只有自己參與其中才能把控產品質量，進度，但是其實對每一塊的具體細節PO都是瞭解的最少的一個人，參與其中，只會佔用開發成員過多的時間去幫助PO理解細節。同樣，如果兩個開發成員的工作相互依賴，一人懷疑另一個人的開發不能很好契合自己的部分，不是通過兩個人很好的溝通，協商解決問題，而是以為自己能力更高一籌，直接指手畫腳，干涉別人的工作，結果往往適得其反，久久不能達成一致，相互block。

3. 產品交付

敏捷中產品以增量的形式的交付，每一個Sprint結束都向客戶交付功能增加的產品。即使收集客戶反饋，根據客戶反饋資訊，實時改變後面的產品開發策略，需求。敏捷中的變化應該是根據客戶需求，調整產品功能，待辦事項優先順序。保證每一次都向客戶互動擁有最重要增量的產品。 傳統開發模型中，產品在一個預定的期限完成幾乎所有的功能後再交付給使用者。互動後除進行bug修復外，基本不在進行大的改動。如果客戶有其它的需求需要引入，則需要以release升級包的形式在原來產品基礎上進行升級。甚至在原來產品基礎上，進行大的重構，再經過一個漫長的開發週期後向客戶交付升級換代的產品。 敏捷中，需求的變化頻率遠高於傳統開發模型。敏捷開發中，有些需求在開發的早期不明瞭，甚至根本不存在。所以在敏捷開發中，開發早期可能並不能確定一個能適用於整個專案生命週期的開發模型，架構。在開發過程中，需要實時的，快速的根據需求變化在不影響持續迭代進度的基礎上對design進行改進。所以在敏捷中變化的是需求，隨之而變的是適應需求變化的設計。 傳統開發模型中，由於在專案早期立項時就已經確定的專案的走向，目標。所以在專案立項是，架構，模型就已經確認。在執行過程中，更多的變化來自於PM的安排，PM可以指定每次release需要包含的feature，fix哪些bugs。甚至PM可以在一個release週期中，更改需要release的事項，只要確保專案能在最後的期限完成所有的預期就可以。 在Scrum的執行過程中，如果PO／SM打著擁抱變化的旗號把傳統開發模式的release方式帶入了Scrum中，會是什麼情況呢。就是可能在Sprint做到一半的時候，PO／SM出於某種不嚴謹的原因打斷當前開發程序，把正開發的story挪出當前sprint，新加入一些其他待辦事項，造成開發效率低下。 當然在Scrum模型中，開發過程中完全有可能客戶出現新的優先順序更高需求，也有可能客戶不在需要某個正在開發的需求。這樣的話，就對PO／SM提出了更高的要求，要求PO／SM有更高的責任感，嚴格評估新的需求的優先順序，確定只把特別重要的需求插入正在開發的待辦事項中。PO／SM在開始篩選Sprint待辦事項時，也確定只篩選backlog中最重要，優先順序最高的事項。以確保儘可能少的影響開發中的待辦事項，打亂開發進度。杜絕傳統開發模式中權利在手，任我胡來的不負責任的方式。

小結

鑑於個人經驗有限，暫時能想到的就是這幾點。希望能拋磚引玉，收集更多的不正確的方式，正確的方式。