scrum感言
軟體流程的名稱太多，rup,v model, iso9000，cmm等等不一而足。最近接觸了scrum，收穫良多，與諸位同仁分享。
自從有人類社會活動以來，就形成了各種各樣的組織和制度，上到社會體制下到家庭環境，西方到東方，社會風尚、工廠流程、等等，這些東西都具有一種共同的特點：都是為了適應一點的社會目的、解決一定的組織問題，而形成的。軟體的流程，也具有類似的特點，只不過是適應軟體規模化生產而成的東西。我只所以這樣說，目的是希望大家不要把軟體流程這種東西神秘化，另外也不要把它當成無所不能的鑰匙。所有為社會化活動定義或者自然形成的東西，一方面有其解決問題的一面，同時也有他的瑕疵。
軟體形成的初期，沒有任何所謂的process,天才工程師似乎可以把當時的所有問題徹底搞定。隨著軟體規模化生產以來，所有具體的軟體活動，比如設計、分析、專案管理等都有必要納入流程管理的環節，從而達到可控並優化的目的。軟體流程的先驅們從，工業生產、統計科學、心理學等等借鑑了多方面的有價值的東西，而形成了如今各種各樣的所謂的軟體開發流程。我在工作中也接觸到各種流程的思想和操作。有時候老闆們總是希望流程來解決碰到的問題，可是有時候又形成了乙個過於流程化的局面，為了完成乙個小問題，卻要付出幾倍的流程的成本；有時候某乙個流程過於僵化缺忽視了真正應該重視的問題。軟體生產是一種智力活動，這又具有很大的不同，某些方面非常難以把握，太硬性的東西反而戳傷了員工的創造性。等等，我相信所有參與過軟體開發的工程師，可以列出更多的問題。如何解決種種問題，不同的軟體流程都提出了一套不同的方法。現在看這些，process, 我們不能說那乙個更好，只能說那乙個更適合你。如同找老婆，沒有最好，只有更適合自己的。
繞了這麼一大堆，我只是想澄清一下對軟體流程方面的基本認識。對與不對不同的人可能有不同的看法。下來我想聊聊scrum，我不想列舉scrum如何具體操作的步驟，網路上有好多這方面的資料。諸位可以找相關的資料看看，我這裡只想寫一些對 scrum的感受，列一下我所理解的scrum具體的思想精髓。歡迎網友和我交流，也使我能有所提高。
軟體開發是乙個複雜的群體智力活動
scrum把軟體開發看作，是乙個解決複雜問題的群體的、智力勞動。這一點很重要，首先這把軟體開發與平常的工業化流水線生產區分開來，讓我們認識到軟體開發的特殊性。你可以把軟體生產比作流水線生產，可是軟體生產是一種特殊的群體智力活動。不認清這一點，就不能把軟體開發中人的因素放在首位。不是說，軟體工程師都培養成象流水線上的工人，你的企業就成功了，這恰恰是乙個軟體企業行將沒落的乙個不好的兆頭。軟體生產需要創造，需要思想活躍的人才。蘋果公司有了賈伯斯就活了，還活得有聲有色，這就是人才的重要性。企業的ceo需要如此，同樣從事具體軟體創造的工程師也需要有創造性的環境。真真成功的企業100%都是有創造性產品的公司！scrum基於此，提出軟體開發團隊需要時自我學習，自組織的團隊，來到達充分利用各個員工智慧型來解決複雜問題的目的。
為了充分利用團隊成員的智慧型，眾人拾材火焰高嗎！！！scrum實施的過程中有如下的具體操作：
1）任務不是有scrum master 自作主張分發的，而是有團隊成員主動申請。這就是task 的poll方式；
2）scrum master 不是老闆，開會的時候不是聽取匯報的。而是幫助團隊解決困難的，要保證團隊成員到底徹底的溝通理解；
3）inspection 要做到發揮團隊其他成員的積極性，及早發現錯誤。當然這一條也不是scrum 特有的。但是scrum 對此事重點強調的噢！！！
4）要重視團隊的自組織行為，團隊為了解決一下問題，總是會找到乙個最合適的方式來達到有效解決問題的目的。scrum master 應該鼓勵這樣的行為。
有效的溝通是軟體成功的關鍵
溝通，溝通，溝通。國際問題，家庭問題，上下級問題等等都需要需要溝通。歸根結底是人際問題，人之所以為人，科學家說，因為人有語言善於溝通。可是具體中許多問題，恰恰是缺乏溝通造成的。軟體開發過程也是一樣的道理，客戶需求沒法被所有人理解，變動沒有在個個關係人之間有效地傳達。專案存在的問題，沒有被領導和解決問題的負責人發現，等等都是由於沒有溝通造成的。由於這些原因造成的損失往往是致命性的！！！
需求方面所有的軟體開發過程都強調，需求變更的管理以及能適應需求不停變化的現實情況，可是我個人認為scrum所定義的運作方式做得徹底、做到比較好。表現在如下幾方面：
1. 客戶的需求被product owner全面反映到team中來
2. 客戶看到的是乙個可deliever的東西，基於此客戶可以有更現實的想法或者，更合理的變動
3. 每個sprint開始，需求的變動被及時地反饋給team
4. 需求的優先順序，滿足客戶利益的最大化
團隊開發方面：
1. daily scrum meeting使團隊的進度得到同步
2. daily scrum meeting使問題及時地發現並盡快得到解決
3. 不同component之間的依賴，也能得到有效溝通。這是有效解決的前提
4. 專案的困難進度，能使客戶，領導及時得到
另外，團隊的成果，客戶能及時地看見，客戶能夠通過product owner將需求及時反饋給團隊，這大大促進了專案的成功，減少了專案的風險。
自我檢查及時調整是團隊走向成功的保證
古人云「日三省乎己」，對人如此對乙個組織也是這樣。返過頭來，看看我們的軟體開發。我看到過一些組織有下面一些問題，網友同志們或許有其他補充。
1. process太過於費時，浪費了大量的時間
2. 以前曾經就有這樣類似的教訓，現在還犯
3. ***問題已經拖了很長時間了，為什麼還沒有解決
4. 大家長時間地走一步看一步，沒有乙個規劃。好象沒有人來解決
5. 一件事情，反覆地改，腦子裡面長水了。不理解這些人怎麼想的
6. 。。。。。。
我相信大家或多或少碰到過類似的問題，有問題比有問題卻發現不了問題強得多了。如果有問題，及時地自我發現，並能夠及時地調整，這是乙個健康組織必有的一套體系。只有這樣乙個組織，專案才能很好地適應市場需要，很好地站穩腳跟。可是，能做到這些，並做好並不是容易的事。 scrum有專門的定義來做到發現問題解決問題的目的：
1. sprint結束時要審視自身。retrospection meeting
2. 發現問題要及時調整
3. scrum master 要對這些活動在process上負起責任來
結語scrum是從軟體管理的角度定義的乙個process，現在越來越得到軟體開發群體的認可。本文只是一些個人的認識和看法。軟體管理是一門「藝術」，scrum不可能涵蓋所有的問題。這就需要具體的執行人scrummaster，要具體問題具體分析。希望本文能對大家理解scrum有益。歡迎交流，批評和指正。
初級軟體開發管理
負責團隊一線管理工作的，大多是做而優則仕，在程式設計上表現優異，被提拔成組長，是否具備管理才能，是否適合做管理，一般不會被公司特別考慮，更別說管理經驗了，新官上任三把火，剛剛被授予管理權力的開發人員，在管理上很積極，但由於缺乏經驗，也常常做出過猶不及的事情來，這麼多年工作中，遇到過下面幾種情況 老好...
軟體開發 計畫管理
參考 開發管理，是對開發團隊開發活動的管理，開發活動佔據整個研發工作量的50 70 因此，理順開發管理工作，提高開發的效率，提公升開發的工作質量，是開發管理者所追求的。開發的主體活動 開發活動的範圍很廣，主體活動包括但不限於如下 開發計畫管理 軟體需求分析 總體設計 子系統和模組的概要設計 ui u...
軟體開發成本管理
軟體開發成本管理之由時間 質量 成本是決定專案管理成敗的鼎之三足，每個專案都有乙個預算，專案成功就包含著要在批准的預算範圍內完成專案。但是很多國內軟體業的專案經理，都會認為專案經理抓好兩件事即可，一手是時間，一手是質量。而對於開發成本的管理，始終沒有上公升到應有的高度，即使在一些cmm cmmi級別...