其他

文章目錄 1.依賴2.依賴倒置3.控制反轉(IoC)/依賴注入(DI)

按照Scrum的基本理論，Scrum是一種迭代式增量的敏捷開發，包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同專案經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，Team Dev包括了所有開發人員。這個網上都能找到。我們先從中提煉出一些基本點(當然這些點其實網上都能找到)，然後再結合DevSuite來講怎麼實施的：1. 

評審會後就是反思會了，一般情況下會跟評審會連在一起開，反思反思，總得反思出一些東西來，其實也就是一句話，有則改之，無則加勉，好的東西繼續保留，不好的東西就要改正。好的東西就不說了，就說不好的吧，不好的東西可能是開發習慣，也可能是工作的方式不對，甚至是團隊氣氛，團隊協作，有些影響小，有些影響大。我們的原則是，好的東西要繼續，不好的東西就一定得改正，對於不好的東西，會上我們會有專門的個人記錄下來，然後研究解決方案，然後這個人會一直負責這些事情一直到解決為止。當然，理想的情況是發現問題就解決問題，但是

從軟體工程的角度來說，一個軟體的開發必然需要從需求分析到編碼到測試再到交付，雖然我們現在說的是敏捷，但是本質上以上那些步驟還是省不了的，從狹義敏捷上來說，它比較看重的是人與人之間的交流，所以對文檔之類的東西不是很在意，但是說是這麼說了，真正你做起來的時候，缺了文件管理，實在不敢想象後果，比如說這個功能本來是這個人設計的，後來他離職了，沒有留下任何文檔，輕輕地，我走了，不帶走一片文檔，其實，是沒文檔可帶走。然後以後的人想修個Bug或者修改一些點，都無從下手的。所以，對於一個企業的敏捷開發，我們現在

3.      

不過，隨之的，問題也就來了，雖然這樣子可以管理一個功能點的基本屬性，但是在實際工作中，我們的工作往往沒有這麼簡單，因為按照以往的經驗，需求從想法變成設計文檔的過程有一系列的問題需要去解決，只要有一個問題解決不好都可能造成這個功能點的失敗。當時培訓時，我們也把這些問題都列出來了，不過DevSpec的確很強大，基本上都能滿足我們的需要。接下來我就列出幾個主要的問題和他們的解決方案吧：1.      

【本篇是《敏捷測試理論以及實踐》第五篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】  以前在《結合工具來實現敏捷開發》這篇文章中，我已經談到了我們公司目前的開發情況，在這裡也不再重複介紹了，反正主要就是用

好了，已經有了Product

【本篇是《敏捷測試理論以及實踐》第三篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】  現在先來總結一下到底上面說的模型存在著哪些問題：1.       客戶生氣地說：這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力，我不買了！（客戶到交付後來發現產品與當初他們提的需求不一致，所以很生氣，後果很嚴重）2.      

上面大家已經瞭解了一下計劃會的一些情況，計劃會能確定當前衝刺（Sprint）所需要完成的功能點，但是我們知道一個產品不可能用一個Sprint就可以完成，所以接下來就會有一個接一個的Sprint，所以有多少Sprint就會有多少的計劃會。 就我們公司而言，由於用了DevSuite管理了整個開發週期，所以我們用了DevSuite方案的計劃管理工具DevPlan來管理這些Sprint。 我們知道，一個產品的開發，總是會有一個版本號碼，每個版本下面會有幾個裡程碑，類似Alpha

【本篇是《敏捷測試理論以及實踐》第二篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】  所謂的V模型，其實是對瀑布模型的一種修改，也算一個Change吧，詳見：  由於瀑布模型對於軟體的需求分析與設計階段考慮不足，導致可能會出現嚴重的設計問題，最後交付到客戶手裡才會被發現，所以V模型就考慮到這點，針對開發的各個過程都會有相應的測試環節，比如使用者需求會對應驗收測試，需求分析和系統設計會對應確認測試和系統測試等等（詳見上表），這樣子起碼在交付前會把使用者需求方面的問題覆蓋到，不太會

好了，計劃會也開完了，Sprint也建好了，也規定好時間了，這個Sprint要做的功能點也分配下來了，該是開發同志們幹活的時刻了。 按照Scrum的原則，是希望開發人員自己能主動去關注有哪些活，然後去認領。我想這種思想在大家開展Scrum的初期是沒法做到的，甚至很多公司一直沒法做到，因為要做到這種主觀能動性，不是說我讓你去主觀點你就可以主觀了，我相信很多公司很多員工不會有這種主人翁精神，通常是給我的活完了我就自己弄自己的，誰會去攬活啊。通常能實現這種原則的公司，都是讓員工有家的感覺，有種願意為家

DevSuite系統中的文件管理工具叫做KnowledgeWise，在以“知識為核心”

文章目錄 測試範例IE6IE8Firefox3.6Firefox4 beta12Chrome8Opera11總結 這個總結來源於一次最佳化的請求，最初某個頁面的載入十分緩慢，load事件遲遲無法觸發，因此希望可以通過對靜態檔案分網域名稱等方式對頁面的外部資源進行最佳化，拿得load事件儘可能早地觸發。於是我查看了頁面的源碼，並對外部資源進行了整理，基於下面2個理念畫出了一個推測的瀑布圖：瀏覽器對同一個域只能並發2個HTTP請求 –

好了，計劃會也開完了，Sprint也建好了也規定好時間了，這個Sprint要做的功能點也分配下來了，該是開發同志們幹活的時刻了。 分完任務後，每個開發同志登入到DevTrack以後，都會在Story Board裡看到自己需要做的任務，一般情況下該任務狀態為“開發中”，然後的話，就和大家平常做的事情就一樣了：寫Code，當然也許你還需要通過任務連結的需求資訊和設計文檔來研究一把。 寫Code的事情就不必寫了，直接進入寫完Code以後的事情吧。寫完Code後呢，首先需要讓其他人來進行一下Code

前面已經說完了各個部門怎麼合作來完成一個Sprint，中間過程可能說的不是太詳細，不過想想看也無非就是實際開發測試過程與DevSuite系統操作的事情了，所以也不需要講的太多，因為我們這次主要是以Scrum怎麼來實現為主， 而開發與測試過程在所有軟體開發中都是存在的，也都差不多，所以我們講的也就是跟Scrum有關的就行了，接下來就講一個有關的：每日立會。 所謂的每日立會，英語叫做Daily standup

新的一天又開始了，早上六點半起來，給老婆和Baby準備好早餐，大約七點半就得趕地鐵了，我離公司不遠，大約地鐵6站地。北京的地鐵總是這麼擠，用摩肩接踵形容已經算不錯，更多時候是前胸貼後背了。下了地鐵，隱隱約約看到公司的美女Judy在前面走著，上前打個招呼吧。跟美女同行總是感覺路途很短，一下子就到公司了，雖然也走了15分鐘了。公司大部分員工都已經到了，我們組的都已經到了，I am always the last

 開始講具體實施了，不過先插一句，雖然我們公司實施了一年多了，但是你說完完全全實施了Scrum的所有規範點呢，那是不可能，我想每個公司都有自己實際情況，怎樣結合公司的情況把敏捷開發落實到實處，使得敏捷能發揮最大的實效才是最重要的，所以接下來講的東西可能並不是所有人都認同，先請大家見諒了，我只能按照我們公司的情況來講我們的敏捷了，有什麼不對的地方還請大家指出哦。 好了，合約也簽了，錢也付了，開始培訓和部署了，我這裡就不說怎麼培訓怎麼部署了，就說一下最後實現了什麼效果吧，中間的過程太多太複雜太枯燥了

其實達到這個目標的“方法”很多，甚至老闆可以強制要求手下必須知道進展，所以手下就很緊張，就去強制他的手下每天報告，每天評估，然後手下的手下也是這個樣子，從而呢，很Perfect，大家都知道自己負責的部分的進展了，所以老闆就會聽到一個聽起來很不錯的答案，但是事實真的如此嗎？有沒有可能手下忘了估計一項資料？有沒有可能兩個部分是有前後關係的（完成一個才能開始另外一個），但是算的時候只考慮了一個時間段？有沒有可能有個傢伙突然請假，但是會造成的延誤無法一下子統計出來（例如他處理的問題其他人不知道或者沒去接

 （休了一個多禮拜的假，今天終於有機會再來寫寫了，讓大家久等了。） 前面講了一個公司或者說一個老闆、一個領導需要清楚兩個問題，一個是把握現在，另外一個是預測未來，其實還有一點也需要知道，就是分析過去，分析過去其實是最好做的事情，因為事情已經發生了，我們只要去總結經驗，分析問題，得出哪些地方以後要保留，哪些要改進，哪些該去除，總之一句話，取其精華去其糟粕。 分析過去，把握現在，預測未來，這三點我相信大家肯定也會認同，可能大家還會有一些其他不同點，但是我自己認為這三點可以稱為一條基準，其它方面可以從