我們自己的開發框架，採用的是scrum為主體，但會根據需要臨時在某個階段或者某些同事之間採用xp的方式。「某個階段」，是比如：我們想讓某一塊的關鍵**，能被兩個人以上的同事了解、熟悉並掌握，那麼對這一塊**的開發，我們就會鼓勵大家採用xp的方式來完成。而當這塊任務完成後，就又恢復成既有的方式。
我們採用scrum方式時，並沒有機械照搬它本身的多種職位設定以及人員設定，最主要的，我們是學習到了它的「神」：那就是，我們講究充分授權，同時，強調關注結果，只對結果負責，且，結果要是明確的，可達成的，以及可周知的，逐漸的，要作到結果是可控的。而，作開發的人都會了解，對於乙個經常變換需求且對發布週期要求苛刻的專案來說，「結果可控」是多麼重要。可以這麼說，如果「結果不可控」，那這種專案，只有死路一條，而這種團隊，其最終結局必然是解散。
老實說，如果是乙個新團隊，一開始就採用我們現在這樣的作法，那可能會遇到比較大的阻礙，因為，在我們的開發方式裡，對個體的專業素質要求比較高，「獨擋一面」幾乎是團隊成員的基本要求。也就是說，無論你原來作的是哪方面的內容，在既有的框架下，把你放在新的任務環境下，也要求你能馬上適應，快速在新環境裡出成果。
但是，不是每乙個人，以及每乙個團隊，都能達到這種狀態的。很多的團隊，特別是初創團隊，需要面臨的，首先是團隊成員專業素質不高的問題，而這一點，如果試圖通過教育、輔導的方式來提高，其效果是比較緩慢的。所以，比較好的方式，是由老人來帶，把一些作事的正確方法，一些良好的專業習慣，通過言傳身教的方式傳遞給新人，最終把他們乙個個都培養出來。我們的最終目標，是讓團隊裡的每乙個人，都能在某一方面獨擋一面，當我們跟他們中的任何一位一起作戰時，我們都可以放心的把自己的後背交給他。
我們自己的團隊，也是這樣一步步走過來的。剛開始，我們也是一群毫無經驗的初生牛犢，我們比別人幸運的是，有比較好的公司背景和資源可以支援我們在這麼長的時間裡去失敗、摸索與提高，而我們比別人優秀的是，在這個過程中，我們從沒有退縮和逃避，也沒有得過且過，而是在這將近四年的時間裡，不斷尋求著精益求精的方法，不斷改進著我們每一天的工作，甚至，我們對自己在質量、安全和穩定方面的要求，已經到了剛來的新人不可理解的bt程度。是的，只要影響到安全、穩定和質量的再小的細節，我們也不會讓步，更不會得過且過，放這些**的絲毫一馬。這，是我們的底限，不可逾越。
「效率，效率！質量，質量！」，每當我們在審視自己的實踐與書本上的理論貌似「脫節」之處時，這兩個詞就會不斷的出現在我們的腦海中，這也成為了我們作出正確選擇的最主要的兩個參考座標。
有很多人，工作沒激情，沒效率，是因為他們的專案沒有壓力感，他們的工作沒有生存的壓力感，作好作壞不會對自己的前途造成太大影響，作多作少不會對自己這個月的工資帶來多少波動，他們總說專案沒前途，公司沒前景，他們總想著，混點時間出來騙點所謂的「時間積累出來的經驗」，然後跳槽換個大一點的公司，找乙個工資更高一點的工作，如此往復。
而事實上，我想說的是，無論你換到哪一家你想換到的「大一點的、待遇好一點」的公司，你最終能從這個公司裡獲得的東西，永遠只是因為你對公司貢獻了多少價值，而我相信，你那些沒有太多有價值經驗而浪費掉的時間，對於這些新公司來說，也同樣是沒有價值的。
而如果，你想讓自己將來更有價值，就應該馬上從現在起，讓自己每一天的工作開始有效率起來，不要總想著用在公司的時間作更多公司外的事，不要總想著在上班時間看更多與當前專案無關的技術書籍，你所最需要作的，就是把每一天你的老大，你的老闆安排給你的事，作好，作到極致！人，總要先有付出，而後才會得到回報的。不要再抱怨待遇不好，不要再抱怨公司沒前景，如果你想找個有前景的公司，那你自己就要首先成長為乙個看起來有前途的傢伙。
扯遠了，本來是想說敏捷來著，竟然談起了理想和人生，汗！好吧，其實，我是想說，我們現在在談的，絕不僅僅只是一種寫**的方式，或者一種作軟體的方式，更深一層次的，它會關聯產生其它很多很多的效果，而這些效果，可能是現在的你連想都不曾想過的。千里之行，始於足下。如果想讓自己變得更有價值，就讓自己每一天的工作更有效率起來，而真正屬於你自己的「敏捷」，其實是你自己在思考和分析了自己當作工作流程、工作環境的情況下，作出的真正符合你自己實際情況的解決方案，絕不是那些書本上所說的各式各樣的理論。
我心中的敏捷 3 兩種世界觀
在瀑布模型中,一旦發生需求變化,給專案帶來的風險是巨大的.而如果不變,那很可能作出來的東西就不是使用者想要的東西,那這個東西對於使用者而言還有什麼意義?所以,在瀑布開發模型中,不管開發團隊願意不願意接受需求變更,這種變更的客觀事實已經給專案本身帶來太多的風險.而敏捷開發呢?是不是就沒有瀑布模型的那些...
我心中的敏捷 3 兩種世界觀
在瀑布模型中,一旦發生需求變化,給專案帶來的風險是巨大的.而如果不變,那很可能作出來的東西就不是使用者想要的東西,那這個東西對於使用者而言還有什麼意義?所以,在瀑布開發模型中,不管開發團隊願意不願意接受需求變更,這種變更的客觀事實已經給專案本身帶來太多的風險.而敏捷開發呢?是不是就沒有瀑布模型的那些...
我心中控制科學與工程中的最美公式
前些年網路上流行了物理學最美妙的十大公式，感覺很有意思，看到美好的事物是一件賞心悅目的事情。本人學習控制科學與工程已經十年了，雖然不能說登堂入室，總歸有一些心得。突然也想總結一下我心中控制科學與工程中最美的公式，本人才學和學科見識有限，歡迎 不同觀點。pid控制是自動化專業的看家本領，百分之九十以上...