本文出處:
前記：說中國it浮躁，一種表現是，國外只要有個什麼新鮮概念，國內圈子裡就馬上炒起來了，說：人家發明了一種什麼什麼開發方式，多麼多麼先進，效果多麼多麼好，要不我們也試試吧？
這是一篇有關「如何引進開發方式」的作團隊感悟，其核心思想是：
引入正文----
敏捷開發，早已不是什麼新鮮概念，但我本人對於敏捷最本質含義的理解，是在近一兩年才逐漸深刻起來的。
我認為，敏捷二字的含義，至少有這樣兩層：
一是研發速度的敏捷，通過優化協作方式、設計方式等等快速推進研發過程；
二是對市場需求的快速響應，這個決定了產品的方向。
也就是說，在我看來，「敏捷」，是相對於整個產品線而言的，它絕不僅僅只是研發階段需要，這個完整的產品線包含了：策劃設計、產品研發、產品運營、客服反饋、市場營銷等多個環節，敏捷的方法可以從研發拓展到其它多個領域，從總體上提高整個產品對於市場和使用者需求的響應速度，從總體上提高整個團隊對於產品戰略的執行速度。
把「敏捷」僅僅理解為研發的敏捷，是一種狹隘，但研發的敏捷，是其它環節敏捷的根基所在。
單就敏捷開發而言，它本身只是乙個概念，由這個概念衍生了很多可以讓研發更快速的具體開發方式，比如結對程式設計，比如scrum。而無論採用什麼樣的開發方式，其最終目的都只有乙個：又快又好的出產品，敏捷理論也不例外。「快」和「好」，成為我們不斷為之追求的目標。
而事實上，當你對敏捷的應用越來越駕輕就熟，越來越心領神會的時候，你會發現，敏捷不只是一種開發理論，它甚至，是一種宗教。因為，它通過這種非常具體的方式在傳播信仰，樹立共同的價值觀，這種價值觀，就是：分享、務實、精益求精。這種體會，也在我們採用了scrum之後愈加深刻。
我們的scrum，嚴格意義上來說，並不是教科書上那種非常規範的scrum，我們只是擷取了scrum中最精華也對我們最有用的部分加以採用。
1. 制定階段性的研發目標，之前的作法是整個團隊有乙個統一目標，現在已經變成每個小組有乙個目標；
2. 在階段性研發週期內，將研發任務拆解，我們沒有特定的系統分析人員，每個人都從頭到尾設計自己的完整系統，包括了：系統分析、編碼、白盒測試；
3. 每天有乙個晨會，每個研發人員都要參加，在這個晨會上，每個人簡單講三句話：昨天「完成」了什麼內容；今天準備「完成」什麼，需要誰配合；昨天的工作中有哪些教訓和經驗；
4. 在研發過程中，通過多種手段充分分享開發資訊，比如：面對面的交流、im的廣播、**交流等等；
5. 每個研發人員享有充分的自我管理權利，上級只關注你作的結果，而不再關心你作的過程。
由上面的幾點可以看出，這種開發方式，要求每個人都能有良好的自我管理能力，要能管理自己的研發進度，研發質量和研發效率。但是，人無完人，並不是每個人都能很好的作到自我管理，遇到這樣的情況怎麼辦？
我們的作法是這樣：
1. 想盡各種辦法，幫助他提高自我管理水平，比如：由有經驗的同事傳幫帶，參與每個小組的小晨會和關鍵系統研發討論，輔導他們的開發流程；利用各種方式將好的自我管理方法分享給其他人；
2. 如果他的自我管理水平實在太差，但他本人工作很努力，那就只有安排一些對自我管理要求不大的系統給他，把整個產品的研發風險降低；
3. 如果他不僅自我管理水平很差，而且不學習、不進取、不分享，我們只有放棄他，不會再在他身上浪費時間。
可能，我們使用的敏捷和scrum開發方式，會被很多正統人士認為並不是真正的敏捷和scrum方式。但我想說的是，我們學方法、學理論，最重要的，是抓住其核心點，要看怎麼作才對我們的團隊和專案更有利，完全沒必要按照各種敏捷正規化把相關的流程和人員全部準備齊了再來按書本上教的方式進行敏捷，每個團隊完全可以根據自己的情況進行精簡或者完善。
我始終認為，越簡單的東西，就越容易持久。因為，越簡單，就越能讓更多數的人理解、記住並使用它。說到開發方式這一塊，也是如此，如果乙個開發方式的流程太過複雜和繁瑣，它必然無法獲得大面積推廣。所以，在聽到一種新的開發方式時，我會首先思考是否能用於我們的團隊，而後，我會思考如何更簡單的用於我們的團隊，如果使用方式太過複雜，我不會選擇它。
就各種各樣的敏捷方法而言，我們絕不會教條化的去引進，需不需要用、能不能用，完全應我們自己的需求和感受而言。比如，對結對程式設計這種方式的使用，就是非常靈活的。
我們平時的開發，是以scrum為主導，以其它開方式為輔。如果我們遇到一塊邏輯，在伺服器和客戶端的邏輯上是相似的，就會由參與者自己臨時採用結對程式設計的方式，把這塊邏輯作完。而一旦作完了這塊邏輯，就又會恢復成各自開發的狀態。
我聽說，很多單位在採用結對程式設計時，為了讓兩個人能輪流程式設計，甚至採用了兩個人只給配一台電腦的方法，在整個專案的開發期，都是兩人用一台電腦。我不知道其他人在這種情況下會感受如何，就我自己的體會而言，我很反感這樣長期的結對程式設計模式，因為它讓我的工作環境沒了私隱性和自由。在整個的研發週期裡，編碼只是其中的乙個環節，還有很多其它的事要作，而這些事，我不想也沒必要讓旁邊還有乙個人看著。這樣的方式，讓我覺得太過教條化。
我們奉行的是，
所有的所謂管理，其最終的落實，都在乙個「人」字上，一種方式不行，我可以換乙個，但如果你把「人」和「人心」給「毀」了，代價就要大得多。
作團隊感悟 有效溝通
本文出處 http blog.csdn.net sodme 前記 有效溝通 這裡的 有效 指的是有效率。這是一篇有關 如何進行有效溝通 的作團隊感悟，其核心思想是 引入正文 在團隊開發中，我們總免不了與上上下下，左左右右的人協作，交流與溝通，上到乙個需求的含義，下到乙個函式的介面。如何作到 快速開發...
作團隊感悟 允許犯錯
乙個人，無論是作專案還是作人，總免不了會犯這樣那樣的錯誤，有了錯誤，有了改正，才會有成長和提公升。我們通常說的 經驗 其中很大一部分，就是你成長過程中積累下來的因犯錯而帶來的教訓。作為團隊成員，當然，在犯了錯之後，一定要總結教訓，否則，這個錯誤就是真的成了對公司資源和自己時間的浪費 而作為團隊管理者...
作團隊感悟 8 有效溝通
本文出處 http blog.csdn.net sodme 前記 有效溝通 這裡的 有效 指的是有效率。這是一篇有關 如何進行有效溝通 的作團隊感悟，其核心思想是 引入正文 在團隊開發中，我們總免不了與上上下下，左左右右的人協作，交流與溝通，上到乙個需求的含義，下到乙個函式的介面。如何作到 快速開發...